ハクソク

世界を動かす技術を、日本語で。

AirSnitch: Wi-Fiネットワークにおけるクライアントの隔離を解明し、打破する [pdf]

88日前原文(ndss-symposium.org)

概要

  • 入力された内容は PDFファイルのバイナリデータ であり、テキスト情報ではありません。
  • PDFの生データ は直接的な内容把握や要約ができません。
  • テキスト化や内容確認には PDFリーダーや変換ツール が必要です。
  • 必要な場合は PDFからテキスト抽出 を行ってください。
  • 変換後のテキストを再度ご提供いただければ、 要約や解説 が可能です。

PDFファイルデータの取り扱いについて

  • 入力されたデータは %PDF-1.5 から始まるバイナリ形式のPDFファイル情報。
  • このままでは 内容の確認や要約が不可能。
  • PDFリーダー や オンライン変換ツール （例：Adobe Acrobat、Googleドライブ、Smallpdf など）を使い、テキストデータに変換する必要。
  • テキスト化した内容を 再度ご入力 いただければ、詳細な要約や解説が可能。
  • 機密情報や個人情報 が含まれている場合は、取り扱いに十分ご注意ください。

今後の対応方法

  • PDFファイルの内容を知りたい場合 ：
    • ファイルを テキストに変換 する
    • 変換後の内容を コピーして再入力 する
  • 技術的な質問や要約 については、テキストデータをもとに対応
  • PDF加工・編集方法 についてのご相談も可能

ご不明点があれば、 具体的なご要望 をお知らせください。

Hackerたちの意見

この記事で話題にされている論文: https://www.ndss-symposium.org/ndss-paper/airsnitch-demystif...

macOS用の良いファイアウォール知ってる人いる？内蔵のファイアウォールはほとんど使えないし、クライアントの隔離がバイパスされる可能性があるから、ローカルのファイアウォールがますます重要になってる。家のLANでデバッグしやすいように、よく0.0.0.0にバインドした開発サーバーを動かしてるんだけど、公共のWiFiに接続したときは安全でポートが閉じてるか確認したいんだ。「すべての受信接続をブロック」は、以前テストしたときに失敗したことがある。

└

Little Snitchが多分一番人気だね。macOSのファイアウォールアーキテクチャを深く理解している開発者たちが作ったやつだよ。https://obdev.at/products/littlesnitch/index.html

└

LittleSnitch

└

https://objective-see.org/products/lulu.html

ちょっとセンセーショナルなタイトルじゃない？これって「WiFiの暗号を破る」わけじゃなくて、攻撃者が同じネットワークにいる場合のデバイス隔離だけだよ。

└

多くの企業や大学、そしておそらくいくつかの政府機関も、ネットワークをセグメント化するためにクライアントの隔離に依存してるんだ。これは大事なことだよ。

└

私はその論文の共著者なんだけど、「破る」という言葉は使わず、「バイパスする」と言った方がいいと思う。そうすることで、どんなネットワークでも「破れる」わけじゃないことを明確にできるからね。私たちは特にクライアントアイソレーションをターゲットにしていて、最近よく使われているんだ。それをバイパスできることが証明されたんだ。クライアントやネットワークのアイソレーションに依存しなければ、安全だよ。

私が見た限りでは、これらの攻撃はすべて攻撃者がすでに被害者のネットワークに接続されている必要があるみたい。これらの攻撃は、しばらく前から知られている共有WiFi（空港やカフェ）で予想されるものと似ているように思える。新しい攻撃は、ゲストネットワークと通常のネットワークのトラフィックを実際に分離していない特定のルーター実装の弱点を突いているようだ。何か見落としているのかな？それだと、最悪の攻撃、例えばキーを割らずにAPに接続できないドライブバイ攻撃を許すようには思えないんだけど。

└

それも私の見解だね。悪いけど、見出しが言ってるほどひどくはないよ。

└

それも私の見解だね。クライアントの隔離に依存している場所には悪いけど、一般的なケースではそれほどでもないと思う。この「認証クッキーを盗む」という点も過大評価されてる気がする。ほとんどの人のクッキーは物理層の保護ではなく、TLSによって守られてるからね。それでも、面白い攻撃ではあるけど。

└

攻撃者は被害者のネットワークに接続する必要はなく、同じハードウェアに接続していればいい。ハードウェアの隔離が失われるのが予想外の問題なんだ。大学の例は関連性があるね。被害者はEduroamのユーザーで、攻撃者はEduroamの資格情報を持っていないけど、同じWi-FiハードウェアがEduroamとローカルゲスト用のプロビジョニングを提供していて、かなり簡素なものになるから、攻撃者はその手段を使ってEduroamユーザー向けのパケットを受け取ることができるんだ。もし適切に認証されたWi-Fiネットワークが一つしかなければ、隔離の喪失は問題にならない。ウェブブラウザでのサンドボックスの脱出が、信頼できるウェブサイトにしか訪れないなら問題にならないのと同じだね。

└

XFinityはどうなの？デフォルトで、あなたが支払ったWi-Fiを他人と共有して、街中にアクセスポイントを作るんだよね？

└

アクセスポイントは、2.4GHzと5GHzの同時ブロードキャストのために複数のBSSIDを持っていることが多いよ。複数のAPがあるシナリオでは、必ずそうなるしね。さらに、弱い重複MACチェックと共有GTK（WPA2-PSK）を組み合わせると、攻撃が簡単になっちゃう。古いハードウェアは永遠に壊れたままだと思う。特に802.11w以前のやつはね。

└

私はその論文の共著者なんだけど、「Wi-Fiの暗号を破れる」とは言わない方がいいと思う。そう言うと、どんなWi-Fiネットワークでも破れると誤解されるかもしれないからね。実際には、敵が共存するオープンネットワークに接続しているか、悪意のある内部者であれば、他のクライアントに攻撃できるってことなんだ。もっと技術的には、クライアントアイソレーションをバイパスできるってこと。大学のオープンWi-Fiネットワークのおかげで、共存するネットワークのトラフィックをすべて傍受できた興味深いケースもあったよ。プライベートなエンタープライズSSIDも含めてね。この意味では、暗号を破るわけじゃなくて、暗号をバイパスするんだ。クライアントやネットワークのアイソレーションに依存しなければ、安全だよ。もっと重要なのは、あなたが使っている唯一のSSIDをブロードキャストしているルーターがあれば、私たちはそれを破れないってこと。

従来のWi-Fi攻撃とは異なり、AirSnitchはレイヤー1と2のコア機能を利用し、これらのレイヤーや上位レイヤー、他のノード、SSID（サービスセット識別子）などのネットワーク名間でクライアントをバインドし同期させることに失敗しています。このクロスレイヤーのアイデンティティ非同期化がAirSnitch攻撃の主要な要因です。 >最も強力な攻撃は、完全な双方向の中間者攻撃（MitM）で、攻撃者はデータが意図された受取人に届く前にそれを閲覧・変更できるというものです。攻撃者は同じSSID上でも、別のSSIDでも、同じAPに結びついた別のネットワークセグメントでも存在できます。これは家庭やオフィスの小規模Wi-Fiネットワーク、そして企業の大規模ネットワークに対しても機能します。 ---- 2000年代初頭にウォードライブしてたよ（¡WEP 笑！）。数年間データセンターで働いてた。今はかなりのパラノイア。私の個人ネットワークはWi-Fiを使ってないし、携帯は外線電話だし、ノートパソコンのカメラにはテープ貼ってるし、アンテナも外してる。何年も前からメールも使ってない…テクノロジーは本当に面白いけど、無線EMFがもたらすすべての脆弱性から自分を守れる人なんているの？銅線や光ファイバーのネットワークが欲しいな、お願い。 ---- >次のステップは[AirSnitch]を歴史的文脈に置き、実際の世界でどれほどの脅威をもたらすかを評価することです。ある意味では、2007年のPTW攻撃に似ています…それはWEPを完全に、即座に破壊し、Wi-Fiユーザーは近くの敵から自分を守る手段がなくなりました。今のところ、クライアントの隔離も同様にほぼ完全に、そして一夜にして破られており、即時の対策はありません。

└

映画『会話』（1974年）が好きになると思うよ。

└

このアプローチに反対するのは難しいね。私もWiFiを使ってるけど、別のサブネットで、ホワイトリストに載ってるMACだけが使えるようにしてる。カメラやマイクは使ってないときは常に抜いてるし、スマホはGrapheneOSを使ってる。車のハンズフリーのマイクとセルラーモデムも取り外したよ。

これは一つのSSIDにしか効果がないよ。それでも、これを軽減する方法の一つは、WPA2でPrivate-PSK/Dynamic-PSKを使ったり、EAP/Radius VLANプロパティを使ったりすることだね。WPA3/SAEではもっと複雑で、標準はパスワード識別子をサポートしてるけど、私が知ってる限りでは、Linuxのwpa_supplicant以外に代替パスワードを選択できるデバイスはないよ。

└

Hostapdは今、マルチパスSAE/WPA3パスワードにも対応してるよ。私たちはWPA3で動的VLANとデバイスごとのPSKの実装をしていて、数年前から使ってるんだ。（https://github.com/spr-networks/super）皮肉なことに、主な問題の一つはAppleなんだ。キーチェーンの同期で、同じアカウントのAppleデバイスは無線用のパスワードを共有しなきゃいけないからね。さらに、MACのランダム化タイムアウトが再割り当てを必要とするし。デバイスごとのSAEパスワードの問題は、コミットがあるとペアリングごとに複数のパスワードを評価するのが難しくなることなんだ。デバイスのアイデンティティ（MAC）を事前に知らないといけないから、実際の運用でこれを見つけるのが難しいんだよね。APが数回試行することは可能だけど、あまり多くはできない。一方、WPA2ではAPがすべてのパスワードをコミットなしで回せたから、標準は適応が必要だね。

すべての余計な部分を読まないといけなかったけど、「ネットワークが適切に保護されている場合—つまり、認可されたユーザーだけが知っている強力なパスワードで保護されている場合—AirSnitchは攻撃者にとってあまり価値がないかもしれない。」ってことがわかったよ。

└

確かに、問題は「セキュア」なネットワークとゲストネットワークが同じAPを共有している場合、ゲストネットワークがセキュアネットワークのクライアントにアクセスできるってことだよね。誰かがxfinityの自動ゲストネットワークについて言及してたけど、無効にするのが面倒かも？家のネットワークなら一つだけなら大した問題じゃないけど、企業の設定だとかなり厄介だと思う。

これは大問題だよ：一つのWi-Fiネットワークのクライアントが、同じAPでホストされている他のWi-Fiネットワークの何でもMITMできるってことだからね。他のWi-Fiネットワークが異なる認証情報を持っていても関係ない。俺が見た企業のWi-Fi導入は、ほぼ全てその隔離に依存してセキュリティを確保してる。こういう攻撃は新しいわけじゃないけど、驚くべきことに多くの企業ハードウェアがこういう単純な攻撃を軽減する手段を持ってないってことだ！

└

つまり、ビジネスのゲストネットワークにいる私がコーポレートネットワークのトラフィックを読めるってこと？

さっき論文を読んだんだけど、ほとんどの家庭用Wi-Fiユーザーが今ややられちゃうって感じだね。大抵のWi-Fiルーターが同じSSIDと2.4GHz、5GHzを使ってるから。Radius認証を使ってる人でも負けちゃうかもしれないけど、その点については深く掘り下げてなかった。トラフィックを読むのにEAPのタイプが関係あるのか気になるな。要するに、複数のアクセスポイントのMACアドレスで同じSSIDを使ってると、誰でもやられちゃう。数年前に近所のハッカーにEAP TLSに追い込まれたけど、今は一つの周波数だけで使ってるから攻撃は通用しない。対策としては、接続できるAPのMACを一つだけにすることだね。攻撃は二つの間を行き来することに依存してるから。ゲストと通常、または2.4と5とか。EAP TLSでそれを成功させた場合、パケットを全部読めるかどうかもっと調べる必要がある。これは大惨事だよ、20年前の最先端のものを使ってない限りは。もしサービス拒否が発生してることに気づかなければ、単一のSSID MACでもやられちゃうかも。Radiusの影響についてももっと調べないと。TLSは他のようにチャンネル上で認証情報を送信しないからね。EAP TLSの間に完全な復号鍵を取得できるか調査が必要だ。彼らはRadiusとクライアントの認証情報を送信するテストをしてたからTLSを使ってなかったみたい。EAP TLSの証明書が役に立たない場合、鍵を考案されると大惨事だね。それが俺の見解だ。

└

でも、どちらかのネットワークに接続できる必要があるんじゃない？だから、ゲストがない家庭用ネットワークなら大丈夫って理解で合ってる？

└

要するに、複数のアクセスポイントのMACアドレスで同じSSIDを使ってると、誰でもやられちゃう でも、どこかのネットワークに認証できる必要があるよね。スプーフィングは、一つのネットワークにアクセスできるユーザーが他のネットワークをMITMできるだけで、アクセスできない人には何もできない。実際、多くの企業は公開パスワードのゲストネットワークを持ってるから、脆弱だよ。でも、家庭用ユーザーはそんなことしないよね。

└

EAP TLSは強力な認証を提供して、他の企業認証オプションよりずっと優れてるけど、他の認証済みデバイスからの横の攻撃を防ぐことはできない。導入の後半は、各アイデンティティをVLANに入れて、発生する可能性のあるL2/L3の切断から守ることだよ。俺はhttps://supernetworks.org/で働いてる。デバイスごとのVLANでこの欠陥に対する解決策を提案して、デバイスごとのパスワードも推奨してる。もっと実際的に言うと、これらの攻撃のリスクは次のようになる。ゲストネットワークで簡単に設定できるようにするためにシンプルなパスワードは意味があるけど、それは信頼されていないものとして扱われる。これらのパスワードはWPA2の鍵交換を嗅ぎ取ることでおそらく破られるだろうけど、脅威モデルからすると、ネットワークは信頼されてないから誰も気にしない。でも、この攻撃は不安定なネットワークがセキュアなネットワークにピボットすることを可能にするんだ。

ちなみに、このクライアント隔離のやつは、自分が管理してないネットワークではめっちゃ面倒だよ。ハードウェアメーカーは、すべてが「一つの大きなWi-Fiネットワーク」にあると仮定して、全てのデバイスが他のデバイスと話せて、火のそばで「クムバヤ」を歌えると思ってるんだよね。だけど、ネットワークの隔離が来ると、ElgatoのWi-Fi制御ライトをオンにしたり、Boseスピーカーと話したり、Chromecastを使ったりできなくなる。

└

特定のプロトコルやIP範囲（マルチキャストとかも含めて）に例外を追加するのは確かに手段だけど、何かを許可するために穴を開けるたびに、データが漏れるリスクも増えると思う。

└

クライアントアイソレーションを使っていなくても、WiFiじゃなくてEthernetで接続しているコンピュータが原因で似たような問題に遭遇したことがあるよ。ガジェットが発見のために使うブロードキャスト方式が、有線と無線の間でブリッジされてなかったんだ。（余談だけど、WiFiのブロードキャストトラフィックは、全てのクライアントが受信できるように最低限の速度で送信しなきゃいけないから、問題が大きくなりがちなんだよね。確か6Mbpsだったはず。）

└

そうだよね、クライアントアイソレーションの主な目的ってそれじゃない？大学の寮みたいに制限されたネットワークにいるとイライラするけど、他の人が勝手にライトを点けたり、もっと悪いことに、ちゃんと設計されてないIoTデバイスにエクスプロイトを仕掛けてマルウェアで攻撃されるのを防いでくれるからね。