AndroidでVPNトンネル外へDNSトラフィックが流出する可能性
(mullvad.net)AndroidでVPNトンネル外へDNSトラフィックが流出する可能性
DNS流出の複数シナリオを確認
- 最近、AndroidでDNS流出の複数シナリオを確認
- Android固有のバグに起因し、特定のアプリにのみ影響
- 4月22日（月）にRedditユーザーの報告でDNS流出が判明
- ユーザーは「VPNなしで接続をブロック」設定をオンにしたままVPNを無効化し、再度有効化した際にDNSクエリが流出しているのを発見
- 速やかに内部調査を開始し、問題を確認できた
- 調査の結果、AndroidでDNS流出を引き起こすさらなるシナリオを確認できた
発見事項
Android OSでDNSトラフィックが流出する可能性のあるシナリオを特定:
- DNSサーバーが設定されていない状態でVPNが有効な場合
- VPNアプリがトンネルを再構築するか、強制停止/クラッシュする間の短時間
漏洩はC関数getaddrinfoへの直接呼び出しに限られるようだ:
- 上記シナリオで、ドメイン名解決にこの方法を使うアプリが漏洩を引き起こす
DnsResolverのようなAndroid APIのみを使うアプリでは漏洩は確認されなかった- Chromeブラウザは
getaddrinfoを直接利用するアプリの例
_Always-on VPN_と_Block connections without VPN_が有効かどうかにかかわらず上記は適用される:
- これは想定されるOSの動作ではないため、OSの上流で修正される必要がある
複数のAndroidバージョンでこの流出を確認できた（最新のAndroid 14を含む）
対応
現在、アプリはブロック状態でDNSサーバーを設定しない:
- アプリが復旧不能な状態でトンネルをセットできない場合、ブロック状態に切り替わる
- この状態ではトラフィックのデバイスからの送出を停止する
- しかしこの状態ではDNSサーバーが設定されないため、上で説明したDNS流出が発生する可能性がある
- 当分の間、偽のDNSサーバーを設定してOSバグを対処する予定
- この修正を含むリリースはまもなく公開される予定
トンネル再接続時の流出をアプリ側で緩和するのはさらに難しい:
- 依然として解決策を模索中
- トンネル再構築の発生回数を最小化できるが、現時点ではこの流出を完全に防げないと考えている
どのVPNアプリでもこの種の回避策を必要としないべきだということを明確にすべき:
- ドメイン名を解決するためにアプリが
getaddrinfoを使うこと自体は不適切ではない - 代わりに、使用するアプリに関係なく、すべてのAndroidユーザーを保護するためにOS側でこの問題を解決すべき
Googleへ問題を報告し、改善提案を提示した。できるだけ早く解決してくれることを願う
再現手順
以下の手順は上記第2のシナリオを再現するもので、ここではVPNユーザーがトンネル構成を変更する（例: 別サーバーへ切り替える、DNSサーバー変更）:
- WireGuardアプリを使用する。これはAndroid VPNのリファレンス実装となったため
- 漏洩はおそらく他のAndroid VPNアプリでも再現可能であることに注意
getaddrinfoを使用していることが確認されたアプリの一例として、Chromeを使用
-
spam_get_requests.htmlをダウンロード -
WireGuardアプリとChromeをインストール
-
WireGuardに
wg1.conf、wg2.confをインポート -
WireGuardアプリで
wg1トンネルを有効化し、VPN権限を許可 -
AndroidのVPN設定でWireGuardの「Always-on VPN」と「Block connections without VPN」を有効化
-
ルーターで
tcpdumpを使ってデータキャプチャを開始$ tcpdump -i <INTERFACE> host <IP of android device> -
WireGuardとChromeを画面分割して並べて表示
-
Chromeで
spam_get_requests.htmlを開き、「Start」を押す -
WireGuardアプリでwg1とwg2の間を切り替え、次の段階で流出が見えるまで繰り返す
-
ルーターで次のようなDNSトラフィックを観測:
11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65) 11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61) 11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65) 11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61) 11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61) 11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)
"Block connections without VPN"が有効だったため、暗号化されたWireGuardトラフィックを除いてはデバイスから何も外部へ出てはならないが、ここでは平文DNSがデバイスから外部へ出ていることが確認できる
結論と推奨
DNS漏洩はユーザーのプライバシーへ重大な影響を与え、ユーザーの大まかな位置情報を特定したり、ユーザーが使っているウェブサイトやサービスを調べるために使われる可能性がある
このような発見は、
- 「Block connections without VPN」の名称（またはドキュメント）に一致しておらず、複数の欠陥があることを再度示している:
- 上記条件下でアプリが依然としてDNSトラフィックを流出させる可能性がある
- 以前報告されたとおり、引き続き接続確認トラフィックが流出している
脅威モデルに応じて、センシティブな作業のためにAndroidを使わないか、流出防止のため別の緩和策を取る必要があるかもしれない:
- この問題をアプリで部分的に緩和することを目標としているため、アプリを最新の状態に保つこと
GN⁺の意見
- この問題は根本的にAndroid OSのバグであるため、Googleができるだけ早く修正するべきである。VPN機能を提供するアプリ開発者がみなこの問題解決に努めるのは望ましくない
- 「Block connections without VPN」オプションがドキュメントどおりに動作せずDNS流出があることはユーザーにとって大きな問題である。VPNを利用する主たる理由の一つはプライバシー保護であるが、DNS漏洩によりユーザーの閲覧履歴などが露出してしまう可能性がある
- VPNトンネリング技術自体のセキュリティはなお高いと考えられるが、OSで意図せず流出が起きないようにするために、VPN以外の追加的なセキュリティ／プライバシーソリューションを併用することも検討する価値がある
- アプリ開発者の立場では、OSバグを回避するためにアプリ側で暫定的に補完を図っているが、長期的には根本的問題解決のためOS改善が必要と思われる
- VPN技術が高度化・普及するにつれ、この種のセキュリティ問題が新たに顕在化している。今後もモバイルOSのネットワークとVPN機能のセキュリティ監査と継続的改善が必要だろう
1件のコメント
Hacker Newsコメント