VPNはKRACKから守るのか？パッチが直すもの

KRACKがWi-Fi暗号化を破ると見出しで読み、その対策としてVPNを買うのなら、直すべき層を間違えている。2017年の公表が説明したのは、WPA2のフォーウェイハンドシェイクに対する鍵再設置攻撃の一群であり、修正はOSの更新、無線ドライバのパッチ、ルータのファームウェアとして届いた。トンネルはローカルネットワークから通信を隠せるが、その下で完了するハンドシェイクを修復することはできない。したがって最初の問いはどのVPNを買うかではなく、どの端末がまだ未修正の無線スタックを動かしているかである。

同じ区別は予算の心配にも答える。購読料を払えない人が本来の対処から締め出されたことはない、対処は無料の更新だったからだ。金がかかるのは、更新を受け取らなくなった機器を買い替えることである。

攻撃が実際に操作したもの

WPA2は接続時にフォーウェイハンドシェイクを通じて新しいペア鍵を導出する。アクセスポイントはナンスを送り、クライアントは自身のナンスで応答し、双方がペア一時鍵を計算し、アクセスポイントはクライアントが確認するメッセージで確定する。鍵再設置攻撃はパスフレーズを推測するのではなくこの手順に介入し、すでに設置した鍵をクライアントに再設置させる。再設置のたびに、その鍵に結び付いた送信ナンスと受信リプレイカウンタが戻り得る。

カウンタが後退すると、本来は拒否されるはずの通信の一部が再び受け入れられる。変種と実装によって、電波の届く範囲の攻撃者はフレームを再生し、復号し、または注入できた。グループ鍵のハンドシェイクと高速遷移のハンドシェイクにもそれぞれ変種があり、勧告が一つではなく複数の攻撃名を挙げたのはそのためである。

Android 6.0以降が最悪の例だった。そのwpa_supplicantの版は全ゼロの鍵を設置させられ、再設置がカウンタを戻すだけの環境より復号がはるかに容易になった。この違いが、当時もっとも普及していた携帯電話プラットフォームで、理論上の弱点と現実の弱点を分けた。

修正は無線スタックの中にある

上流の修正は、鍵がすでに設置されていれば再送されたハンドシェイクメッセージを無視するようサプリカントとアクセスポイントに指示した。パッチを当てたwpa_supplicantとhostapdのビルドがそれを含み、各ディストリビューションは古いブランチへバックポートしたので、wpa_supplicant -v が出力する文字列は判断ではなく出発点である。ディストリビューションのセキュリティ勧告を読み、版番号だけでなく具体的なパッチを確認すること。古い版を名乗るビルドでも修正済みのことがあり、新しい版を名乗るビルドでもベンダーのバックポートを欠くことがある。

リンクの両端に注意が必要だ。修復したルータはそれに接続するノートPCをパッチせず、修復したノートPCはルータをパッチしない。ベンダーは製品ごとに勧告を出し、ルータの修正は各モデルに固有のファームウェアビルドが要るため、電話の更新より遅れるのが常だった。機器の最終リリースが勧告より前なら、ベンダーが否定するまで未修正として扱うこと。

更新できない機器について、選択肢は狭く地味である。退役させるか、機密性の高い通信を運ぶネットワークから離すか、同程度に捨てられる相手だけがいるセグメントに閉じ込めるかだ。どの選択肢も購読を必要とせず、別のトンネル事業者を選んでも改善しない。

トンネルが覆うもの

VPNは境界を動かし、端末は各パケットを暗号化してVPNサーバへ送り、サーバはそれを復号して転送する。Wi-Fiリンクを操作する者に見えるのは外側のトンネルパケットであり、中のペイロードではない。したがってリンク層のフレームを露出させる再設置攻撃は、トンネル化された接続の中身を自動的に露出させない。この保護は下の無線スタックが脆弱なまでも続き、二つの対策が混同されるのはまさにそのためである。

条件は「トンネル化された」場合だ。分割トンネリング、バイパスリスト、キャプティブポータルの例外は一部の通信をトンネルの外へ出し、その通信は恩恵を受けない。同じネットワーク上の、クライアントを入れたことのない他の端末の通信も同じだ。トンネルは端末ごと、経路ごとの判断であって部屋の性質ではなく、ルータ段階のVPNは実際にルータを通るものだけを覆う。

トンネルにできないのは、ドライバを修復すること、認証解除の洪水を止めること、攻撃者によるチャネル妨害を防ぐことだ。一度も中に入らない接続を守ることもできない。これらは可用性とリンク層の問題であり、トンネルの暗号スイートがどれほど強くても無線スタック側に残る。

HTTPSとトンネルは別の区間を守る

一度のページ読み込みに三つの別々の保護が関わり得る。Wi-Fiリンク、VPNサーバへのトンネル、ウェブサイトへのTLSセッションである、それぞれ独立に交渉される。有効な証明書と現代的なプロトコル版を備えたTLSは、最初の区間が敵対的でもブラウザとサイトの間に認証済みの暗号化を与える、偽装者が自分の鍵を差し込むのを止めるのは証明書の検査だからだ。

その検査には端に弱い点がある。HTTPSからHTTPへのリダイレクト、平文HTTPでスクリプトを読むページ、証明書警告をクリックして進む利用者は、いずれも通信を保護されたセッションの外へ移す。HSTSやブラウザの中間ページがあるのは、そうした誤りがよくあるためであり、TLSが脆いからではない。

HTTPSとトンネルを保つことは、無線の実装が脆弱でなくなることを意味しない。フレームは今も欠陥のあるドライバに復号され、違いは、攻撃者がその中に見つけるものと、その内容がすでに別の何かで守られていたかどうかである。

混在ネットワークの修復順序

アクセスポイントから始めるのは、自分が管理でき、すべてのクライアントが依存する機器だからだ。次にクライアントのOSを古い順に見るのは、更新を受け取らなくなったプラットフォームこそ永遠にパッチされないからだ。その棚卸しが終わって初めてVPNの判断が意味を持ち、それは修復ではなく露出についての判断である。逆の順序で、先にトンネル、後でファームウェアにすると、購読が続く限り実際の欠陥はその場に残る。

何を確認したかを、ファームウェアの版と日付を含めて書き残す。「更新済み」は後から誰も監査できない状態である。

三つの確認で作業の大半は覆え、順序はこのとおりだ。最初の二つがきれいだったからといって三つ目を飛ばさないこと。

• ルータのファームウェア：更新ボタンではなく、ベンダーの勧告ページと導入済みの版を比べる。
• クライアントOS：各電話、ノートPC、タブレットについて、無線の修正を含むパッチ水準を確認する。
• 残り：パッチの道がない機器を列挙し、退役、隔離、受容のいずれかを決める。

残りの一覧が長ければ、クライアント分離付きのゲストネットワークが機器の入れ替えまでの時間を稼ぐ。次に各バンドで既知のクライアントを一つ試し、結果を記録し、次のファームウェア公開後に再確認する。次の勧告を速くするのは機器の棚卸しであり、その間の隙間を覆うのはトンネルである。