小容量契約がピンチ【総務省お知らせ】無線LAN（Wi-Fi）暗号化における脆弱性・・・
10月18日(水)、総務省が「お知らせ：無線LAN（Wi-Fi）暗号化における脆弱性について（注意喚起） 」を公表しました。
「ご利用されている機器の各メーカーから修正プログラムが配布され次第、速やかに修正プログラムを適用し、最新の状態にアップデートしてください。」って、総務省さん、いきなり(関係者には、公然の秘密or周知の事実だったのかもしれませんが)、これですか。拙宅のWi-FiルーターのメーカーさんのHPは、現時点(10月19日23:49)でも何の発表も、ありません。
1GB契約と3GB契約を行ったり来たりの招き猫＠東京下町は、自宅ではWi-Fi利用が前提です。と、いうことで、今月は容量ピーンチかなorz
18 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
これが正解です。
WPA2というWi-Fiの暗号化アルゴリズムを採用している一部機器に脆弱性が見つかっています。
この脆弱性は、WPA2で暗号化されたWi-Fiの親機と子機の間に入って攻撃できると言う物です。この脆弱性によって、Wi-Fiのパスワードが漏洩する可能性は極めて低いです。
ただ、攻撃されていんる時に、SSLなどで暗号化されていない通信を行うと、通信内容が漏洩する可能性があります。
Windowsでは、直近のアップデート（パッチ）で、この脆弱性は対策済みです。
iOSやmacOSでは、近いうちに脆弱性対策アップデートを配信するようです。
WPA2の脆弱性が喧伝されていますが、少しばかり奇な感じを抱いています。
IPAの記事によればプロトコルレベルの脆弱性のように読めるのですが、そうだとすれば「WEPは危険だらけだよ」と同レベル、WPA2なんか使っている場合じゃない、と思うのです。そこに「修正プログラムの適用をしてください」と言われて、「修正プログラムで対応できるって、みんな実装は同じなん？すげー危なくない？」と不安がつのるのです。
とはいっても、所詮wifiのお話ですし、最近のトレンドは「～sをデフォールトで使いましょう」ですから、暫くは猶予があるのかなあ。
組み込みブラウザの携帯電場がhttps化（SHA2かな）の波においてけぼりをくって文鎮化しましたが、今回もいくつかのワイヤレスデバイスは文鎮化は不可避なのでしょうね。
どうぞよろしくお願いいたします。
と思っています。
気になるようであればwifiの出力を弱めるのが良いのでは？
ちなみに、外に出るときスマホのwifiはオフにするようにしています
＞wifi親機についてはステルスにするとかmacアドレス制限かければより安全になるかと思います
ステルスにしても、電波を出している親機のMacアドレスは簡単に解析できますし、Macアドレス制限をかけても、そもそもMacアドレスを通信している子機のものに偽装されると、どうしようも無くなるので、安全かどうかと言われると微妙です。
＞WPA2の脆弱性が喧伝されていますが、少しばかり奇な感じを抱いています。
＞IPAの記事によればプロトコルレベルの脆弱性のように読めるのですが、
はい
＞そうだとすれば「WEPは危険だらけだよ」と同レベル、WPA2なんか使っている場合じゃない、
修正前のWPA2に関して、ということでしたら正解です
＞「修正プログラムで対応できるって、みんな実装は同じなん？すげー危なくない？」と不安がつのるのです。
プロトコルに基づく実装部分なので、基本的に同じでないと相互に通信できません。
今回、結果的に修正のみで回避可能だったのは幸いでしたが、次回は分かりません。
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update
https://www.wi-fi.org/security-update-october-2017
＞とはいっても、所詮wifiのお話ですし、最近のトレンドは「～sをデフォールトで使いましょう」ですから、暫くは猶予があるのかなあ。
既に原理もデモも公開されていますので、猶予があると断言できる人は居ないでしょう。
特にアプリ組込ブラウザについては証明書の確認が不適切な実装も多いと言われています。
＞組み込みブラウザの携帯電場がhttps化（SHA2かな）の波においてけぼりをくって文鎮化しましたが、今回もいくつかのワイヤレスデバイスは文鎮化は不可避なのでしょうね。
はい。Android 6.0”以降”で今回対応のセキュリティ修正ソフトが出なかったものに関しては即死クラスの厄災です。
他の場合でも私もまだ細かい条件分けでの把握はしていませんが、修正されていない端末の場合、成りすましAPへの誘導が可能になるという話もあるようです。
従って同様に文鎮化は免れないでしょう。
> 自宅周辺に攻撃者は来ないかなと思っています。
> 気になるようであればwifiの出力を弱めるのが良いのでは？
私も同じようなもんです。AP側は出力を絞りきって、かつ5GHzのみで使ってます。
今回の KRACKsって結局 WPA2が破られたのではなくて「WPA2を含めてインプリしている仕様の中で『クライアント側で一度認証したキーに対し、AP以外から別のキーを混入可能』という脆弱性がある」ってことであって、AP側からすれば「APは仕様に従ってインプリしただけ。キーを Refresh市内クライアント側に主因がある」と言い切ってしまっても良いじょうきょうですからね。
ひとまず OS側含めて更新可能なものは更新して利用していけば良いだけだと思っています。
追伸：
無線ネットワークに問題あり、ということであれば、免許不要で
使える 50GHz帯簡易無線などを利用すれば良い、なんて考え方も
ありますね。個人レベルでは非現実的ですけど:)。
10年以上前のことですが、その名もライフルと呼ばれるアンテナを使って、規格上は10mの通信距離である
bluetoothを1km先からハックする輩が話題になりました。
https://wired.jp/2004/08/17/ブルートゥースの脆弱性、携帯電話に予想以上の-2/
http://hackedgadgets.com/2007/01/03/building-a-bluesniper-rifle/
同様の手法で通信距離の長いwifiなら10km遠方からでもハック可能かと思うと、見通し距離の長い集合住宅の高層階などは、狙われたら防ぎようがないというきがします。
> 同様の手法で通信距離の長いwifiなら10km遠方からでもハック可能
> かと思うと、見通し距離の長い集合住宅の高層階などは、狙われたら
> 防ぎようがないというきがします。
インプレスの記事で申し訳ありませんが、以下を確認しましたか？
●WPA2脆弱性、国内無線LANベンダーの対応状況まとめ
https://internet.watch.impress.co.jp/docs/news/1086853.html
狙われるとまずいのは AP(アクセスポイント)側ではなくてむしろクライアント側です。つまりは「端末や PC側」のお話。
それらについては対策が比較的楽で「OS updateなどで対応可能」ですから。
但し APでも以下の場合はクライアント扱いになるので各社対策中です。
１．無線中継器：自分自身で鍵交換しないから。
２．モバイルルータの Pub WLAN(公衆無線 LAN)接続もーど：上記同様。
つまり、APを WLANルータ、または APとして使っている以上は今のところ対策の必要は無い、と言う状態です。
ですので送信出力を絞る、シールドを強化するのが暫定対応になりえたりします。
そもそも漏洩電波対策を考えるなら、開口部に金網(銅メッシュなど)を張るのが危急の対策でしょうけど、そこまで必要ですか？ってレベルだと思います。
追伸：
往々において、AP側の送信出力アップが製品で続けられてきたことも
傍受の可能性を引き上げてしまったという弊害なので、無線側対策と
して送信出力ダウン→カバーしきれないところは AP増設で対応が
一番管理が行き届く、というエンタープライズ製品と同じ考えを用いる
しかないって感じだと思います。
> 今回、結果的に修正のみで回避可能だったのは幸いでしたが、次回は分かりません。
> https://www.wi-fi.org/security-update-october-2017
論文のリンク先もご指摘のページから貼られていることと、802.11 std(WLANの標準である IEEE 802.11規格標準の意。以下同じ)は私も知っていたので「まあ、Key Refreshの間隔を AP側で短縮しておけばいいか」と思って、自宅の AP(Aterm WG800HP)はもともと以下対策をしていましたから、ひとまずの猶予は確保できた感じではいます。
・Key Refresh timeを 5min未満にしておく。
・AP側送信出力を最弱(Aterm WG800HPの場合は 12.5％)に設定。
・中継器モードは使用しない。
→もともと私は APモードしか使わない主義なので。
Key Rerfreshが発生しない中継器モードは「怖くて使えない」。
※なので WLAN関係は昔から「AP複数配置をする際の置局設計、
ネットワーク内部設計(ルーティング、L2セグメントなど含む)
および APまでの配線を考慮して有線での配線、電源を考慮する
なら PoEで配線すべし」と考えています。
・Key Refreshに対応できない WLAN ASICは使っていない。
(そんな古い機材が既に存在しない)
→OS(Supplicant)側問題が今回の主因。
OS対応がＮＧだとするとお手上げはおっしゃるとおりです。
エンタープライズ向け WLAN製品はもともと Key Refreshのインプリメントを拡張しているので、Cisco(Aironet)や HP Arubaを始めとして WLANコントローラに接続される APであれば、まだ安心とは考えているます。
WLANコントローラ側で 802.1x認証を要求しているものが標準かと思いますし、それを設定していないエンタープライズ向け WLAN APも珍しいとは考えているので。
(続きます)
私の理解ではアクセスポイントとクライアント間の通信を傍受すると、クライアント側に侵入可能になると読めたのですが間違いですか。
> 特にアプリ組込ブラウザについては証明書の確認が不適切な実装も多いと言われています。
ブラウザの証明書チェックについては 802.11 stdでインプリしてなかったと思いますが？。これって何か関連してましたっけ？。
KRACKsについては 802.11 std上の WPA Key No Refresh or Delay refreshインプリメント(仕様が定まっていなかった)に対するハイジャック可能の脆弱性なので、直接は関係していなかった様に思います。
> はい。Android 6.0”以降”で今回対応のセキュリティ修正ソフトが
> 出なかったものに関しては即死クラスの厄災です。
> 他の場合でも私もまだ細かい条件分けでの把握はしていませんが、
> 修正されていない端末の場合、成りすましAPへの誘導が可能になる
> という話もあるようです。従って同様に文鎮化は免れないでしょう。
Supplicant側の問題は OS updateをしなくなった(=EOL)ものについて、果たして updateが入るか否かですが.....。
Androidの場合だとは OSコアモジュールのように考えますので、Googleが updateするか、またはインプリメントベンダーが手を入れるか？、のいずれかになってしまうんでしょうね。
まあ「即死クラスの厄災」か否かは私も判断しかねますが「いままでむしろ 802.11 stdをそのまま守り続けていたベンダーもあるのか」と考えると、規格のインプリメントガイドラインを更新しない Wi-Fi Alliance側も時流に従っていないなあ、とは感じます。
> 私の理解ではアクセスポイントとクライアント間の通信を傍受すると、
> クライアント側に侵入可能になると読めたのですが間違いですか。
論文をさらっと読んだ限りですので査読出来ているわけではありませんが、そこまで書いておらず、むしろ「通信に暗号化を掛けているはずなのに、相手先(OS、クライアントなどの Supplicant)に対する通信をハイジャック(横取り)→解析可能となってしまう」事が一番の脆弱性とされているようですし、そう理解しました。
逆に Supplicant側へ侵入できてもデータが無ければ何ら意味は無いですし、VDIなど画像転送状態の通信は「画像データをコマごとに Decode→そこから通信内容を解析する前に、新しいデータがやってきてしまうので意味はない」と感じますね(ある意味さほど重要ではない、と言うのが私の考え)。
生データのやり取りをハイジャックされる方が問題は大きいですし、そこが脆弱性だ、と言うのであれば私自身も理解・同意できます。
＞ブラウザの証明書チェックについては 802.11 stdでインプリしてなかったと思いますが？。これって何か関連してましたっけ？。
＞KRACKsについては 802.11 std上の WPA Key No Refresh or Delay refreshインプリメント(仕様が定まっていなかった)に対するハイジャック可能の脆弱性なので、直接は関係していなかった様に思います。
本件報告者自身がこの件について懸念しています。
https://www.krackattacks.com/
Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.
(参考訳)
ウェブサイトもしくはアプリはHTTPSを追加の保護層として用いるかもしれない、しかしながら報告者としてはこの追加の保護は今だ悩ましいほど多数の条件下において機能しないことを警告する。例えば、HTTPSはこれまでにApple iOSやOSX、アンドロイドアプリにおけるブラウザでないアプリ、また銀行アプリやVPNアプリでさえも(証明書を適切に確認せず)機能しないケースがあった。
呼ばれていませんが参考までに。
報告者によると、端末側にアタックを掛けた場合のシナリオについては
下記のURLにある論文で議論されています。
https://papers.mathyvanhoef.com/ccs2017.pdf
6.2 Example Attack Scenarios
Among other things, our key reinstallation attacks allow an ad-
versary to decrypt a TCP packet, learn the sequence number, and
hijack the TCP stream to inject arbitrary data [37]. This enables
one of the most common attacks over Wi-Finetworks: injecting
malicious data into an unencrypted HTTP connection.
(文字数制限のため詳細後略)
例えば、DNSのレスポンスを偽装したものを一発投げ込むことができれば、
（他の脆弱性と併用して）ターゲット端末の乗っ取りは技術的に可能です。
なお、そこにデータがあるかないか、やる価値があるかどうか等は
アタッカーの考えることですから議論は差し控えます。
そういえばこんな話もありましたね。
感染の2/3は日本：ホテルのWi-Fiを標的にしたマルウェア攻撃「ダークホテル」
https://wired.jp/2014/11/12/darkhotel-uses-bogus-crypto-certificates-to-snare-wi-fi-connected-execs/
>> ブラウザの証明書チェックについては 802.11 stdでインプリして
>> なかったと思いますが？。これって何か関連してましたっけ？。
>
> 本件報告者自身がこの件について懸念しています。
(以下略)
情報ありがとうございます。
実際のところブラウザなりアプリケーションの通信については 802.11 std等の規格上タッチしていないと記憶していたので、ようやく趣旨が理解できました。
最終的にソケット通信なり生データの Sniffingで解析されたらＮＧなのは言うまでもないですが、どこまでそれを通信規格側で保護できるのか？と考えると「最終的にアプリケーションレイヤーで保護すべきはそっちで保護するのがより理想的なインプリメントじゃないか？」とも考えるんですけどね。
※要は「アプリケーションでそれだけ重要なデータを転送している
のであれば、他から横やりのごとく乗っ取られない様な作りも
検討していくのが定石ではないか」ってことですが。
次元が変わりますけど日本の場合だと LG-WAN接続機器に対する耐タンパー装置装着義務化なり、他に対策する方法はいくらでもあるので、通信規格標準であれもこれもと盛り込むより、その通信規格を有効利用しつつセキュリティ向上を図るにはどうしたら良いのか？を考慮するのが適切な気もするんですよね。
VPN等も結局はプロプライエタリな物でなければ解析の糸口がつかめてしまうと考えると、色々考慮すべき点が浮かび上がってくるのは、技術の進歩と関連して頭の痛いお話だと思います。