AndroidでVPNトンネル外へDNSトラフィックが漏えいする可能性
(mullvad.net)- Androidの一部のアプリ・状態の組み合わせで、DNSクエリがVPNトンネルの外へ出る可能性があり、MullvadはVPNアプリではなくAndroid OSのバグが原因だと見ている
- 漏えいは、VPNがオンでもDNSサーバーが空の状態、トンネルの再構成、VPNアプリの強制終了・クラッシュのような短い遷移区間で発生する可能性がある
- 影響は
getaddrinfoを直接呼び出すアプリに集中しており、Android APIであるDnsResolverだけを使うアプリでは漏えいは見つかっていない - Always-on VPNと「VPNなしの接続をブロック」をオンにしても問題を完全には防げず、Android 14を含む複数のバージョンで確認されている
- Mullvadは一時的に偽のDNSサーバーを設定して一部の状況を緩和する予定だが、再接続中の漏えいはOS修正なしには完全な遮断が難しい
Androidで発生したDNS漏えいの条件
- Mullvadは4月22日、Redditユーザーからの報告を通じて、「VPNなしの接続をブロック」がオンの状態でVPNをオフにしてから再度オンにするとDNS漏えいが発生する可能性があることを確認した
- 内部調査では、Android OSがDNSトラフィックをVPNの外へ送る可能性のあるシナリオがさらに見つかった
- VPNは有効だがDNSサーバーが構成されていない場合
- VPNアプリがトンネルを再構成している間
- VPNアプリが強制終了またはクラッシュする短い時間
- この挙動はAndroid OSの期待される挙動ではなく、上位のOSレベルで修正される必要がある
影響を受けるアプリと名前解決経路
- 漏えいは、ドメイン名解決でC関数
getaddrinfoを直接呼び出すアプリで発生しているように見える - Android APIであるDnsResolverだけを使用するアプリでは漏えいを発見できなかった
- Chromeブラウザは、
getaddrinfoを直接使用し得るアプリの例である- 関連するChromiumコードの場所も公開されている
getaddrinfoの使用自体が間違っているわけではなく、すべてのAndroidユーザーを保護するにはOSレベルでの解決が必要である
Always-on VPNとブロック設定の限界
- 確認された漏えいは、Always-on VPNと「VPNなしの接続をブロック」の有効化の有無に関係なく発生する
- 「VPNなしの接続をブロック」がオンなら、暗号化されたWireGuardトラフィック以外はデバイス外へ出てはいけないはずだが、再現過程では平文DNSがルーターで観察された
- Mullvadは、この設定が名称や文書化された挙動を満たしておらず、複数の欠陥があると評価している
- 上記の条件でDNSトラフィックが漏えいする可能性がある
- 以前に報告したように、接続確認トラフィックも依然として漏えいする
Mullvadアプリの一時的な緩和策と残る問題
- Mullvadアプリは現在、ブロック状態ではDNSサーバーを設定しない
- 復旧不能な形でトンネル設定に失敗すると、アプリはブロック状態に入る
- この状態ではトラフィックがデバイス外へ出るのを防ぐが、DNSサーバーが空のため漏えい条件が生じる可能性がある
- MullvadはOSバグを回避するため、当面は偽のDNSサーバーを設定する方法で対応する予定で、この修正を含むリリースをまもなく提供する計画である
- トンネル再接続中に発生する漏えいは、アプリで緩和するのがより難しい
- Mullvadは解決策を探している
- トンネル再構成の回数を減らせる可能性はあるが、現時点ではこの漏えいを完全に防げるとは見ていない
- Mullvadは問題と改善提案をGoogleに報告した
WireGuardとChromeで再現した観察
- 2つ目のシナリオであるVPNトンネル構成変更中の漏えいは、WireGuardアプリとChromeを使って再現できる
- WireGuardはAndroid VPN実装の基準例として使われる
- Mullvadは他のAndroid VPNアプリでも再現される可能性があると見ている
- Chromeは
getaddrinfoの使用が確認されたアプリであるため、漏えいのトリガーに使われた
- 再現手順には次の要素が含まれる
- spam_get_requests.htmlをダウンロード
- WireGuardアプリとChromeをインストール
- wg1.conf、wg2.confをWireGuardにインポート
- WireGuardでwg1トンネルを有効化し、VPN権限を許可
- AndroidのVPN設定でWireGuardに対してAlways-on VPNと「VPNなしの接続をブロック」を有効化
- ルーターで
tcpdump -i <INTERFACE> host <IP of android device>によりキャプチャを開始 - WireGuardとChromeを分割画面で開き、Chromeで
spam_get_requests.htmlを実行した後、WireGuardでwg1とwg2を交互に切り替える
- ルーターでは、AndroidデバイスからOpenWrtルーターの53番ポートへ向かうAレコードクエリとNXDomain応答が観察された
- DNS漏えいは、ユーザーのおおよその位置や訪問するWebサイト・サービスを把握するために使われる可能性があり、プライバシーへの影響が大きい場合がある
- 脅威モデルによっては、機微な用途ではAndroidの使用を避けるか、漏えい防止のための別の緩和策を適用する必要があるかもしれない
- Mullvadアプリのユーザーは、部分的な緩和策が含まれる可能性があるため、アプリを最新状態に保つべきである
1件のコメント
Hacker Newsのコメント
Mullvadは使っていないが、本当に尊敬するようになった。問題の説明、短期的な回避策、他の人が使える可能性のある回避策、Androidで修正すべき箇所まで、情報密度が高くよく整理されている
欠点は、私の場合ping時間がquad9やcloudflareよりかなり高いこと
このスレッドにDNSレベルの広告ブロック方法とcloudflare関連情報を書いておいた: https://news.ycombinator.com/item?id=40056162
決済の問題はすぐに解決してくれ、iptablesについても複数の解決策の長所と短所まで含む詳しい回答をもらった。一言で言えば素晴らしい
rethinkdnsの開発者です
「これらの問題は、どのアプリを使っていてもすべてのAndroidユーザーを保護するにはOSで解決されるべきだ」という点について、Androidの偏執的なネットワーキングは常にシステムアプリとOEMアプリ、つまりGoogleアプリを含む例外を設けてきた
こうしたバグ修正の大半も、その中核的な前提を変えることはできない可能性が高い。関連コードはこちら: https://github.com/celzero/rethink-app/issues/224
「トンネル再接続中の漏えいはアプリ側で緩和するのがより難しい。まだ解決策を探している」という部分については、Androidは再構成時に2つのTUNデバイス間のシームレスな切り替えをサポートしている。正しく実装するのは厄介だが、可能ではある
Androidではかなり前からある問題だ。内部DNSサーバーだけを使わせたいと思っても、Androidは必要または望ましいと判断するとセルラーに切り替えて、そのDNSを使ってしまう
最近、無線接続がなぜ/いつ切れるのかを見ようとadbデバッグを観察していたが、結局、生存確認の過程で何かを見られない、または解釈できないと、セルラーデータをオンにして試していた
内部にしか存在しないDNSレコードを使うとき、スマートフォンで任意に動作しなくなるのが特に腹立たしい。端末はそのレコードを持つ内部DNSサーバーを提供するWi-Fiにつながっているのに、Androidの何らかの理由で外部から解決している
Appleがどうなのかは分からないが、基本的に自社の「privacy」VPN経由でDNSまでDoHでプロキシしようとしている点を見ると、競合製品と言えるものを使うときにより良いとは想像しにくいし、Appleがそうした製品をどう扱うかも分かっている
実例としては、このシステム全体の広告ブロッカーを見ればよい: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
私が経験した唯一の問題は、正常に動作する無線APに接続しているのに、端末がインターネットなしと表示したことだった。実際には動作していたが、ステータスバーのアイコンやその他の内部システムコードの目的上、Googleサーバーでインターネットの動作有無を確認しているようだった
プライバシーを重視するならAndroidは避けた方がよく、おそらく技術全般にも注意した方がよい
数年前、プロジェクト用に複数のVPN構成をテストしていたとき、コンピューターとメインルーターの間にMikroTikのファイアウォール機器を置いていた。目的は、PCが接続しようとしているVPNサーバーのIPアドレスが宛先でないすべてのトラフィックをブロックすることだけだった
この方式は、PCからVPNサーバーへの経路の外へトラフィックが漏れないよう保証するうえで非常にうまく機能した。使っているVPNサーバーのIPアドレスはほとんど変わらず、変わってもMikroTikのファイアウォールで変更しやすい
サーバーIPが分からない、または変わる場合は、VPNサーバーが使うポート/プロトコルの組み合わせでないすべてのトラフィックをブロックする方法もある。たとえばVPNの種類によっては、UDP 1194が宛先でないトラフィックを捨てる、といった具合だ
MikroTikルーターには、トラフィックをすばやく簡単に見られるtorchという小さなツールもあり、パケットキャプチャにも対応している。価格は30ドルから3000ドルまでさまざまで、ソフトウェアライセンスはなく、扱い方を知っていれば非常に強力で有能だ
厳密に言えば本当のslugはIPアドレスが定義されていない透過的なレイヤー2ファイアウォールだが、ここでその細部にこだわる必要はない
https://john.kozubik.com/pub/NetworkSlug/tip.html
送信元/宛先アドレスとポートに基づく外向きフィルタリングは、ファイアウォールの基本概念であり、あらゆるファイアウォール・ルーティングプラットフォームの標準的な構成です。ゲートウェイを基準にフィルタリングするポリシーベースルーティングも同じ文脈です: https://en.wikipedia.org/wiki/Policy-based_routing
一般に、デフォルトですべての外向きトラフィックを許可するのは、コンシューマー向けやセミプロ向け製品くらいです。この構成でいう「メインルーター」が何だったのか気になります。ISP提供の機器だったのでしょうか？
私たちもスマホアプリとモデムの間にファイアウォールを挟めるといいのですが
AndroidのDNS問題は、このプラットフォームで独自のIPv6 DNSサーバーを設定できない点にあります。Wi-Fiに何か変化が起きるたびに変わってしまいます
root化したAndroidでも、OSがそれを変えないようにするアプリはありません
常にIPv6アドレスを配布し、無効化できないルーターを使っているなら、単に詰むということです
そのルーターの背後にファイアウォール機器を設置して、ルーターが広告するIPv6 DNSサーバーを除去できるのかも分かりません
DNSリクエストの漏えいを気にするなら、いずれにせよDoTやDoHを使うべきです
Wi-Fiテザリングでも同じことが起きるのか気になります。スマホのWi-Fi経由で接続したノートPCでVPNを使うと、同じように漏れるのでしょうか？
最も安全な構成は、スマホのモバイルデータをオフにして、スマホの上流でVPNを処理するOpenWRTホットスポットを持ち歩くことのようです
「常時オンVPN」は、Appleが承認した組織のMDMソリューションで「supervised」状態になっているデバイスでしか設定できません。文書化された申請と、現在の従業員との電話でのやり取りが必要です
そうでなければ、MacでApple Configuratorアプリを使って「always-on VPN」キー入りの構成プロファイルを作るしかありません
通知もしばしば遅延しました
自分のネットワークでないなら、モバイルルーターなしで直接接続しないほうがよいです
The Grugqが10年前にこの目的のツールを作っていました。残念ながら今はメンテナンスされていません: https://github.com/grugq/portal
ハッカー向けのオペレーションセキュリティに関する発表の一部で、有名または悪名高い複数のハッカーが安全だと思っていたのに結局捕まった事例に興味があるなら見る価値があります: https://www.youtube.com/watch?v=9XaYdCdwiWU
rootアクセス権がないシステムは、定義上安全ではありません。AndroidとiOSは笑ってしまうほどです
コンピューターといえば、主にメディア消費と個人データ収集のために設計された機器しか持たずに育った、あるいはこれから育つ子どもたちが気の毒です
https://en.wikipedia.org/wiki/PinePhone_Pro
そうしたデバイス上にある私のSSH秘密鍵のコピーを手に入れられるなら、問答無用で現金10万ドルを払います
その定義には意味がなく、推論にもコミュニケーションにも役立ちません
「VPNなしの接続をブロック」は、ビュッフェでの私の自制心と同じくらい信用できないものだと分かりつつあります。勘違いでなければ、この種のDNS漏えいは訪問したサイトや位置情報までかなり明らかにし得るので、VPNの目的そのものを台無しにします
AndroidはVPNをオンにしていてもDNS情報を漏らす可能性があるため、プライバシーに本当に敏感なら、Androidの使用自体を見直すか、機密性の高い作業をスマホから外すほうがよいです
ときどき、こうした「バグ」が意図的にうまく配置されたものではないかと疑ってしまいます。特に大手テック企業が複数の情報機関と協力してきた事実があるので、なおさらです
Androidでこの種のバグを聞いたのは今回が初めてでもないので、これほど多くのバグが「意図せず」入り込んだとは、もはや信じがたいです
以前からこうなっているのではないかと、ある程度疑っていました。AndroidでVPNをオンにしても、MMSとVisual Voicemailは相変わらず動作します
どちらも直接のモバイルアクセスが必要だったり、そうでないと拒否されたりする場合があります。モバイルネットワーク上にある場合だけ、またはリクエストがモバイルネットワーク内部から来たものでないと拒否されることもあります。VoLTEも同じだろうと疑っています。VPNがあると、こうした機能がややこしくなる可能性があります
Mobile Linuxでは、VPNをオンにするとこれらの機能がすべて壊れるので分かります
Androidで期待される機能の多くを壊さずにこれを修正する明確な方法はなさそうです
VPNをオンにした iOS で、AT&T の高度サポートチームと VVS の問題に取り組んだことがあるため、この問題が Android だけに限らないことは確認できます
異なる bearer は、異なる優先度/QCI、つまりサービス品質を持つことがあります。混雑した LTE ネットワークでは、VoLTE は低優先度 bearer の VOIP よりも良い体験を提供するべきです