KRACK脆弱性の影響は大したことない？ 66
ストーリー by headless
影響 部門より
影響 部門より
GoogleはAndroidの「KRACK」脆弱性を11月のセキュリティパッチで修正しているが、Nexus/PixelデバイスにはKRACK対策を含むパッチが12月まで提供されないそうだ(Ars Technicaの記事)。
10月に公表されたKRACK(Key Reinstallation AttaCK)はWPA2の脆弱性で、偽アクセスポイントを使用してWi-FiクライアントにWPA/WPA2の暗号鍵を再インストールさせることで通信内容の復号が可能になる。wpa_supplicant 2.4以降を使用するバージョンのLinuxへの影響が特に大きいとされ、Androidでは6.0以降のすべてのバージョンにおける影響が大きいとして注意喚起されていた。
GoogleがAndroidのKRACK脆弱性を修正したのはセキュリティパッチレベル2017-11-06だが、11月に提供されるNexus/Pixelデバイス向けのセキュリティパッチはレベル2017-11-05までとなっている。その結果、OEMメーカーがKRACK対策パッチを続々と提供するのに対し、GoogleブランドのすべてのAndroidデバイスは12月まで対策されないことになる。これについてArs Technicaの記事では、KRACK脆弱性のAndroidに対する影響は大したことがないと指摘する。
10月に公表されたKRACK(Key Reinstallation AttaCK)はWPA2の脆弱性で、偽アクセスポイントを使用してWi-FiクライアントにWPA/WPA2の暗号鍵を再インストールさせることで通信内容の復号が可能になる。wpa_supplicant 2.4以降を使用するバージョンのLinuxへの影響が特に大きいとされ、Androidでは6.0以降のすべてのバージョンにおける影響が大きいとして注意喚起されていた。
GoogleがAndroidのKRACK脆弱性を修正したのはセキュリティパッチレベル2017-11-06だが、11月に提供されるNexus/Pixelデバイス向けのセキュリティパッチはレベル2017-11-05までとなっている。その結果、OEMメーカーがKRACK対策パッチを続々と提供するのに対し、GoogleブランドのすべてのAndroidデバイスは12月まで対策されないことになる。これについてArs Technicaの記事では、KRACK脆弱性のAndroidに対する影響は大したことがないと指摘する。
実際にWPA2の暗号が破られたとしても、街中でオープンWi-Fiスポットに接続したのと大きな違いはない。Googleのアプリはそれぞれ通信の暗号化が行われており、WPA2の暗号を破っただけでは通信内容を盗み見ることはできない。HTTPS接続のWebサイトを閲覧する場合も同様だ。Googleではアプリ開発者に対しても、通信を暗号化するよう促している。KRACKのデモではsslstripを使用してHTTPSをバイパスしているが、適切に構成されたWebサイトでは使用できないことをデモの中で認めている。なお、HTTPSをバイパス可能な脆弱性がたびたび発見されたことも指摘されているが、例示されているのは2年以上前のものばかりだ。
つまり、セキュリティをWPA2に頼るようなデバイスでない限り、KRACK脆弱性の影響は小さいという話のようだ。
一ヶ月前から既出 (スコア:5, 参考になる)
http://www.silex.jp/blog/wireless/2017/10/krack.html [silex.jp]
今回のKRACK論文、「既存の実装系は全て影響を受ける」「WPA2のプロトコル設計根本に関わる脆弱性」という枕詞でネットではかなり騒がれていましたが、実際に読んでみると「手間がかかる(偽APの設置と接続誘導が前提)割に大して有効な攻撃方法じゃない(PTKやPMKが解読できるわけじゃない)」と感じました。
そのうち直しておくべきものですけどね (スコア:3)
現状ユーザー側ですべきことは無い，
そのうち配信されるアップデートで修正されるかもだし，
されなくても，そのまま使って危険，ということも無し。と答えておいた。
もっとも，「たいしたことない」のはユーザー側の影響や対応の話であって，
致命的な脆弱性には変わりないわけで，メーカー側がソレを言い出すとうさんくさくてアウトよね。
Re: (スコア:0)
ルーターのアップデートは手動ですよ
Re: (スコア:0)
む？ うちのNTTからのレンタルのルーターは自動アップデートだけど？
そもそもクライアント側で対策が必要であって、
ルーター側では特にいじる必要はないんじゃなかったっけ？
＃リピーター機能は除く
Re: (スコア:0)
＃リピーター機能は除く
だからアップデートしないとだめじゃん
しかもお前んとこのルーターだけが自動だからどうしたと。
Re:そのうち直しておくべきものですけどね (スコア:1)
リピーターになってなければ問題ない。
Re: (スコア:0)
そもそもリピーター専用端末も販売されているのでユーザー側では最低限リピーターになってないかの確認は必要だが。これがユーザー側ですべきことは無いと言えるのか？
Re:そのうち直しておくべきものですけどね (スコア:1)
リピーターにしてるとルーターとして使えないような気がする。
# 今時はそうじゃない機種もあるのか？
Re: (スコア:0)
それなりに数の出ているであろう（かつ詳しくない人が採用するであろう）NTTのレンタルのルーターで
デフォルトで自動アップデートがオンになっているよって話なんですが。
リピーター云々もルーターをリピーターとして新たに設置したときの話で、
リピーターを設置していなければそもそも考慮する必要すらないんですが。
Googleの閉鎖的な社風を甘やかすべきではない (スコア:0)
このような重要な脆弱性について、あえて数か月も無防備でよいと判断しているなら、その判断根拠を開示するよう要求すべきだろう。
なぜ周りが都合よく憶測してあげてるんだ。ただの怠慢でないとなぜわかる？
Googleはほんっとに閉鎖的で秘密主義的な社風で、こういう情報をほとんど公開しない。
情報公開とユーザー教育は情報セキュリティを維持するための重要な構成要素だ。
それらの重要性を理解しない会社の製品のセキュリティは信頼できないというべきだ。
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:3, すばらしい洞察)
まあみんな公衆無線LANにホイホイつなぐのだからWiFiのセキュリティなんてもとからあってないようなものだという主張は多分正しい。
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:1)
ここに一票かな〜。
少し前に調べた範囲では、そもそもAPの近くに行かないと使えない、しかも攻撃のタイミングがシビアな脆弱性なので、攻撃側にとってはコストが大きい。軍とか政府、およびその関係者が持つ、よっぽど価値のあるデータを狙いに行くならともかく、世間一般のほとんどのユーザーを対象にそんなめんどくさいことをする意味はない気がする。
まあ、それでも、WindowsPCの場合は企業内ネットワークにアクセスしていることが少なくないだろうから多少は気にすべきかもしれない。
しかし、AndroidやiPhoneの場合には企業内ネットワークに直結というのは少数派だろうし、そもそも会社設置のAPのみで利用するというのは（ないわけではないが）少ない。重要なデータへのアクセスさせるなら公衆無線LANや社員の自宅のネットワークのセキュリティ管理レベルを考えると別の手段を使って保護される必要がある。
・・・となると、ほとんどのユーザーにはそんなに深刻とは言えないんじゃないかと思う。
まあ、そのうちどんどん攻撃ツールも簡単化されていくかもしれないので、どこかで対策したほうがいいだろうけど。
＃結局、WiFi使ってるのに何をいまさら・・・としか思えない。
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:3, 興味深い)
ここにぶら下げるのが妥当かな？
公共系や企業研究部門で最高セキュリティが必要なところでは、
そもそもスマホであってもVPNを強制（＋MDMとかも当然強制）しているので
Krackの問題があっても影響なしとしているところが多いです
困ってるのは、一律最高セキュリティというわけでもなく
普通の複数部署の共有社内オフィスに普通の自社用WIFIがあって、
そこに社員のiPhoneやAndroidをつないで使っていいよとしているところです
今回の件を踏まえてスマホからの自社用WIFIを接続禁止にしたところもあります
※ で、経理は先月今月の3G/LTEのパケット代がいくらになってしまうかと戦々恐（省略されました）
中期以上の視点で見ると、
業務で使用するスマホにはMDM必須＋強制VPN必須にするように企業側も負担して設備が整っていくでしょう
国から出ている、
オリンピック開催や働き方改善に備えたリモートワークへの対応要望とも合致する設備投資ですし
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:1)
前回はiPhoneがAppleがと随分大騒ぎしていたのに、風向きを見て主張を変えるんですね。
まあ、無線LANのセキュリティというものが、不正利用対策はともかくとして、安全性の面では
有線と同等のプライバシーが目的のものでしかないということが分かってればいいんですけどね。
Re: (スコア:0)
> 前回はiPhoneがAppleがと随分大騒ぎしていたのに、風向きを見て主張を変えるんですね。
というよりも、Appleが対応しきれなかったから
さんざん騒いでた連中がこの問題を大きくしないように風向きを変えた、
ってのがカネの力で支配されたネット全体での流れでしょうけどね
Krack自体は問題として大騒ぎされたので自分も報道ソースが出た直後から何度か発言しています
（あなたの言い方を見ると、どうやら自分以外の発言も多数自分が書いたと誤認されているようですが）が、
手間がかかりすぎて最重要な軍や研究施設などを除けばこれでスマホを狙うのは現実的ではないと一貫して主張しています
Re: (スコア:0, フレームのもと)
ふーん、Appleの力ってすごいんですね。別に大したことがないわけじゃないけど、Apple様が対応しないとお決めならGoogleすら対応しないし、脆弱性情報の公開よりパッチ提供を遅らせるのも当然なんですね、あなたの中では。
あなたがちょっといい気分になりたくて騒いでみたけど誰も乗ってこないから怖くなってきたってわけじゃないんですね。ふーん。
Re: (スコア:0)
好都合なことも不都合なことも陰謀説か > 負け組無能
Re: (スコア:0)
IDで異常な発言するのは最近の流行りですか？
自傷行為にしか見えないのですが
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:1)
いいえ。私はslashdot.jp時代から完璧狂人を目指してますので、流行ではないです。
最近の悩みは発狂ぶりが年々衰えてることですね。ま、ID取ればいいんじゃないですか?
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:1)
> 負け組無能
こういう言葉をホイホイ使うもんじゃない。
5chでも行ってなさい。
Re: (スコア:0)
ご忠告感謝。一応使う局面は弁えているつもりです > 負け組無能
Re: (スコア:0)
困ってるのは、一律最高セキュリティというわけでもなく
普通の複数部署の共有社内オフィスに普通の自社用WIFIがあって、
そこに社員のiPhoneやAndroidをつないで使っていいよとしているところです
今回の件を踏まえてスマホからの自社用WIFIを接続禁止にしたところもあります
そんなもん、コンシューマ用のＡＰを設置してるんだったら仕方ないけど、企業向けのＡＰを
設置してるならＶＬＡＮでスマホ用のトラフィックを社内ネットワークから分離してしまえばよいのでは？？
まあ、後からやると既設の機器（有線側）のＶＬＡＮ対応も要るので、とりあえずではあっても面倒といえば面倒だけど。
Re: (スコア:0)
簡単に更新できない無線LANの暗号機能に頼る方が中長期的に考えると問題だし、Googleが提唱してる
ネットワークSSL化ってのは至極納得できる話だがな
正直、無線LANって民生品ルータ側はそんなちゃんとサポートしてんの？ってくらいな状況だし
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:2)
これ本当に重要なんですか? APの出口側NICで平文が読めるなら、無線LANの暗号化なんて意味がないじゃないですか。味方側勢力圏の中にいるうちに帰っちゃう護衛みたいなもので。
Re: (スコア:0)
> APの出口側NICで平文が読めるなら
これって既に自宅に侵入されてるってことですか？
まずは戸締りをちゃんとしてください。
Re:Googleの閉鎖的な社風を甘やかすべきではない (スコア:2)
企業や公衆なら特に、全APからスイッチまで、スイッチからルータまで、ルータからDCのエッジまでのUTPの全長が守れてることに社運を賭けるのは良くないと思うんですよ。
そこは端末上のNICからDC内のどこかのNICまでくらいを保護した方が良くないですか?
Re: (スコア:0)
この脆弱性は、偽APに接続させて解読用の暗号キーをクライアントに返す事で実現していると理解してます。
その原理から接続後の通信は、偽AP経由になるので、偽APのNICをキャプチャすれば通信内容が読めるという話ではないでしょうか。
Re: (スコア:0)
WiFiのパケットは盗み見できますが、通信内容がWiFi以外の、たとえばHTTPSで暗号化されていたら暗号化されたままです。
WiFiの暗号化は破られましたがHTTPSの暗号化は無事なので、見られても読まれません。
WiFiの暗号化が破られて読まれるのは、平文の通信だけです。
平文が盗み読みし放題なのはネットの常識。ことさらWiFiの暗号化が破られた！ と騒ぐには当たらない、と。
Re: (スコア:0)
WiFiをインターネットと端末の間の通り道として扱う場合はまあそれでもいいのだがWiFiをLANとして使っている場合はそうでもないと思うのだよ。まあその場合今回の脆弱性が現実的に使えるかは疑問だが。
Re: (スコア:0)
端末メーカー「」
Re: (スコア:0)
Apple「お、そうだな」
Re: (スコア:0)
「重要な脆弱性である！その判断根拠を開示するのは首相の責任である！」
Re: (スコア:0)
「想定されて居ません。想定されて居ないのですから対策も必要ありません」
Re: (スコア:0)
このような重要な脆弱性について、あえて数か月も無防備でよいと判断しているなら、その判断根拠を開示するよう要求すべきだろう。
なぜ周りが都合よく憶測してあげてるんだ。ただの怠慢でないとなぜわかる？
これだよな。
ここにも「大して影響ないだろ」みたいなコメントがぶら下がってるけど、周りが都合よく憶測して擁護しないでGoogleが明示的にパッチを出さない理由を示すべき。
Re: (スコア:0)
> Googleが明示的にパッチを出さない理由を示すべき。
「出さない」ではなく「12月くらいに出す」なんだけどね、なんでまったく別の意味にすり替えて暴れるんだろう？
Re: (スコア:0)
ぜい弱性が報告されてから1ヶ月以上も出さない、12月まで出さない、明確な理由を出さない、とれでもお好きなのをどうぞ。
てか、Googleが「12月くらいに出す」って言ってるソースは？
Ars Technicaのソース見ても「11月のパッチには含まれないから12月まで待つしかないっぽい」って言ってるだけのように見えるが。
全世界の機器に影響するぜい弱性が報告されてから何日もたってるのにパッチを出さない、出さないなら出さないでユーザーに理由の説明もしない企業の擁護する奴って金でももらってんの？
俺は別にGoogleだから批判してるわけじゃなくてAppleだって他のメーカーだって情報出さない企業はクソだとおもってるが。
AppleのiPhoneのほうが生み出している混乱 (スコア:0)
iPhone7よりも前のiPhoneについて、一部のKrack脆弱性が修正されていないようだとして結構混乱が生じています
日本のマスメディアでも確定した情報がなく、かといって修正されないとも報道してはいけない規制がAppleからかかっているのか？ 記事の内容が変
https://internet.watch.impress.co.jp/docs/news/1089292.html [impress.co.jp]
（うち、 CVE-2017-13080 の箇所）
Re: (スコア:0)
混乱なんか生じてるか？
修正したってアナウンスがないんだから
修正されてないって思っておけばいい話だと思うが。
それで足りないなら実験するなりAppleに問い合わせるなりすればいいし、
何にしてもやるべきことは明確で、混乱する要素なんかどこにもない。
メーカーが脆弱性等にきちんと対処してくれるかどうかがよくわかりましたありがとうKRACK (スコア:0)
去年発売の某社のスマホは二度と買わないことを誓いました。
Re: (スコア:0)
iPhoneSEのことかーーーーーーー！！！！
Re: (スコア:0)
blueborne対策パッチをGoogleの1ヶ月遅れでWW版に提供開始したあげく、そこから1月経った今でもJP版は放置のみZenfone3無印のことですね、わかります。
#8月のは次の週くらいには出てたんだけど
Re: (スコア:0)
KrackはKrackで実際にはこんなの悪用する奴はいない的な内容ですが、
blueborneも同じくらい実際にはこんなの悪用する奴はいない的な状況になってますね
そういうことにしておきたい (スコア:0)
そういう願望を持ってる人達が誘導したいのかね
Re: (スコア:0)
#3311039 のようなGoogleそのものの否定コメまで書かれてても不服ですか
さすがApple信者の方の現実認識は最高に歪んでいますね
Re:毎度恒例の二重基準 (スコア:1)
#3311039 のようなGoogleそのものの否定コメまで書かれてても不服ですか
邪悪なM$叩きが行われてた当時の水準からすると随分と生ぬるい。
もっとGoogleは叩かれ続けられるべき。もう少しまともになるかもしれん。
Re: (スコア:0)
邪悪なM$は今回、いい動きをしましたよね。
一般公開前にパッチが当たってた。
Googleは確か、脆弱性の通知から90日で対策するんでしたっけ。
8月には通知が行ってたはずなんですが。
Re:AndroidはKRACKS云々以前にわけのわからないポートスキャンを止めろ (スコア:3, 参考になる)
> てめーら繋ぎに行く先々で、UDP7とかUDP1900とかUDP3702とかUDP5353とかTCP62078とか叩きまくってんだろ？
> あれをまず止めろ
それ、ロングポーリングを実施するためのパンチングでしょ
疑似プッシュの実装の典型的な動作で、それを嫌ってるならコストの高いSMSプッシュとかにするしかなくなるよ
これ、理解できる？
> 次に、とっととDHCPv6に対応しろ
明確にDHCPv6への対応にはデメリットや本末転倒となる部分があるから対応していない
https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-p... [techrepublic.com]
https://www.networkworld.com/article/2939436/lan-wan/it-pros-blast-goo... [networkworld.com]
上記のような議論の結果「対応しない」と判断したのに対して「とっとと対応しろ」と言っても、それは単に「私はAndroidが嫌いだ」にしかならないよ
Re: (スコア:0)
IPv6はもともとRAでIPアドレス・DHCPでDNSを構成する前提だったわけで、
RDNSSができてもDHCPを使っているネットワークは多数あるのは当然。
それを経緯とか現実とかを無視してDHCPでのアドレス構成のまずさを理由に使えなくしているのは利用者として大変困るわけだよ。
それともおたくさんのIPv6は最初からDHCPなしでDNSが設定できたの？
Re: (スコア:0)
反論になってない
本来の目的とは反するが過渡期は仕方なく、というものについて
本来の目的通りの規格実装ができたなら後者のほうに対応するというのは至極当然
ここで、わざわざ本来の目的とは反する過去の規格にも対応しろと言われても
そんなのその実装サイズ、保守コストなど鑑みて優先度が下がるのも普通のこと、そのコストは利用者全体が被るんだからね
それが気に食わない俺が使いたい機能は何かなんでも入れろコストは俺以外の全員にも分担して負わせろ
って言われてもね
ほんとAndroidが大嫌いなんだねとしか言えないな
Re: (スコア:0)
そうだねじゃあ過渡期のIPv4は今すぐ捨ててね。