WPA2 key reinstallation attacks
10/16 に公開された WPA2 key reinstallation attacks についてのまとめ
- 10/18 9:00に追記・更新しました(主として、はっきりしていることを断定調にしたのと、最後に参照リンクを追記)
- この内容は、学内事務職員や非情報系のひとを想定して、細かい枝葉を切った説明になっています。学生や技術職の方は末尾リンクを参照下さい
何がされるか?
データ暗号化において使われる鍵を交換するフェーズに割り込んで一度使った鍵を再度使わせるという replay 攻撃の一種です。この鍵は、事前共有鍵(PSK、所謂 WiFi パスワード)や 1X 認証の証明書ではなく、認証が終わった後に通信の秘密状態の維持のために(ユーザの知らないところで)自動更新されているものです。したがって、この攻撃で事前共有鍵とか 1X の証明書が窃取されることはありません。
どこに問題があるか
クライアントのドライバで鍵交換をしている部分の実装の問題です。そのため、修正のためには各クライアントのドライバが更新される必要があります。技術まとめをしているサイトを見ると、この鍵管理は chip vendor のドライバより上の層で行われていて、Windows や macOS は OS で処理されています。したがって、各OSベンダが出すセキュリティ update を確実に当てることが必要です。
一点、よくわかっていない点があって、intelのPROSetように、WiFi management software を出している vendor の場合、この処理が OSの機能を使っているのか vendor 実装しているのかが不明です。OS本来の機能以外のツールを使っている場合は、それも更新した方が安全でしょう。
AP側に対処がいるか
APとclientの通信は非対称で、今回の攻撃はclient側が受け取ったメッセージの処理の問題に起因しています。このprotocol attackの性質を考えると、基本は client 側の対処が必要です。そのためAP側の対処は必須ではありません。
一方で、この脆弱性を使った攻撃をする場合には MAC address 偽装をしてMan-in-the-middle attack (MITM) を仕掛けます。したがって、AP自身の MAC addressの偽装を検知して遮断する機能があると、側面的な対応は可能です。CISCO の AP は SSID の偽装(管理外のAPが自分のSSIDを騙るとかした場合)は検知する機能があるので、もしかしたら MAC 偽装も見ているかもしれません。このあたりは vendor に確認しないとわからないです。
すぐに何らかの対処が要るか?
NO
すぐにWiFi停止とか暗号方式を変えるとかのhardな対応が必要な話ではありません。現状は各 vendor の様子を watch して、update が出たら更新を強く勧める程度でしょう。Krackattacks.com にも「WEPに戻す?」みたいな FAQがありますが、著者は NO と答えています。
脆弱性といっても、現実的に割り込むのは簡単ではないですし、AES を使っている限りは盗み見られるだけなので、通常の WPA-PSK の同一 NW に参加している他の client から見えているのと同程度の状況になっているだけです。したがって、更に弱いものに degrade するとかは悪手です。*1
各社の対応状況は?
github にまとめができています。
https://github.com/kristate/krackinfo
もう少し詳しい説明はない?
いくつか良くまとまった情報が提供されています。
- https://dev.classmethod.jp/security/wpa2-vulnerability-krack/
- http://d.hatena.ne.jp/Kango/20171016/1488907259
- http://nanashi0x.hatenablog.com/entry/2017/10/16/121139
学生や技術職のひとは本家を…