20ドルでRCEを狙ったら、偶然 `.mobi` の管理者になってしまった話
(labs.watchtowr.com)- watchTowr Labsは約20ドルで期限切れの dotmobiregistry.net ドメインを取得し、過去の
.mobiWHOISサーバーホスト名を制御して、古いWHOISクライアントやTLS/SSL証明書の検証フローがいまもそのアドレスを信頼していることを確認した .mobiの正式なWHOISサーバーはwhois.nic.mobiに移行済みだが、多くのツールが旧アドレスwhois.dotmobiregistry.netをハードコードしたまま問い合わせを続けていた- 2024年8月30日に一時的なWHOISサーバーを展開した後、9月4日までに13万5,000超のユニークシステムと250万件の問い合わせが到達し、放置されたレガシードメインが実際のインターネット基盤に広く結びついていることが明らかになった
- 一部のTLS/SSL認証局は
.mobiドメインの所有権確認にWHOISベースのメール検証を使っており、GlobalSignのテストではmicrosoft.mobiの検証メール候補としてwhois@watchtowr.comが表示された - 研究チームは悪意ある証明書を実際に発行させることはせず、その後、英国の NCSC と ShadowServer が当該ドメインをシンクホールへ向け、正当な
.mobiWHOIS応答をプロキシするよう対応した
20ドルの期限切れドメインがWHOISインフラとして蘇る
- watchTowr Labsの当初の狙いは、WHOISクライアントがサーバー応答を解析する過程で現実的に悪用可能なRCEを見つけることだった
- 初期実験ではWHOISサーバーを装って長い文字列を返し、一部クライアントが簡単にクラッシュすることを確認した
- ただし攻撃者がWHOIS応答を制御するには、通常は次のいずれかが必要だった
- ネットワーク層でWHOISトラフィックを傍受するMITM
- 実際のWHOISサーバーへのアクセス権
- 攻撃者が制御するサーバーへ向かうWHOIS referral
- こうした前提条件は現実の攻撃では高い障壁だったが、
.mobiの旧WHOISサーバードメインが期限切れになったことで状況が変わった .mobiのWHOISサーバーは以前whois.dotmobiregistry.netからwhois.nic.mobiへ移行しており、旧ドメインdotmobiregistry.netは2023年12月ごろに失効していた- watchTowrはこのドメインを取得したうえで、旧アドレスをハードコードしたWHOISクライアントがまだ問い合わせているか確認するため、
whois.dotmobiregistry.netの背後にWHOISサーバーを配置した
WHOISサーバーアドレスのハードコードが生んだ攻撃面
- WHOISはTLDごとに別サーバーを使うが、クライアントがそのサーバーをリアルタイムに見つける標準化メカニズムは弱い
- 実際には、IANAが公開するテキスト一覧を参照し、WHOISツール側でサーバーアドレスを開発時点でハードコードする方式が一般的だ
- サーバーアドレスが頻繁に変わらないうちは問題が表面化しにくいが、アドレスが変わって旧ドメインが失効すると、古いクライアントは廃止済みアドレスへ問い合わせ続ける可能性がある
- watchTowrは
lglassサーバーに届くWHOISリクエストへ応答し、すべての問い合わせ対象の所有者がwatchTowrであるかのように見える偽のWHOIS情報を返した - 応答にはASCIIアートと問い合わせ停止の依頼も含まれていた
観測された問い合わせ規模と発信元
- 2024年8月30日にWHOISサーバーを展開した後、数時間のうちに7万6,000超のユニーク送信元IPから問い合わせがあった
- 約2日間でSQLite DBに130万件の問い合わせが蓄積し、2024年9月4日時点では250万件の問い合わせと13万5,000超のユニークシステムが確認された
- 問い合わせ元には大手ドメインレジストラやWHOIS機能提供サイトが含まれていた
domain.comgodaddy.comwho.iswhois.rusmallseo.toolsseocheki.netcentralops.netname.comwebchart.org
- セキュリティ分析サービスも旧
.mobiWHOISサーバーを利用していた- urlscan.io は
.mobiドメインページでそのWHOIS結果を使用していた - VirusTotal はwatchTowrの一時WHOISサーバーへ問い合わせ、その結果を表示していた
- urlscan.io は
- メールサーバーやスパムフィルターも多数確認された
- スパムフィルターは送信元ドメインに対してWHOIS照会を実行することがある
cheapsender.emailからmail.bdcustoms.gov.bdのようなバングラデシュ政府インフラと思われるホストまで含まれていた
.gov関連アドレスは複数の国で確認された- Argentina, Pakistan, India, Bangladesh, Indonesia, Bhutan, Philippines, Israel, Ethiopia, Ukraine, USA
- ブラジル関連の例として
antispam.ap.gov.br,master.aneel.gov.brが含まれる
.mil発信元には Swedish Armed Forces の例が挙がっていた.eduやセキュリティ企業由来のものも確認され、Group-IB、Detectify、Censys などが言及された.govやメールサーバーが.mobiドメインからメールを受信するたびWHOISサーバーへ問い合わせるなら、誰が誰と通信しているかを受動的に観測できる可能性が生じる
古いWHOISクライアントの脆弱性とRCEの可能性
- watchTowrはWHOIS応答の解析脆弱性に関する先行事例を調べ、関連CVE 26件のうち、不正なWHOIS応答でトリガーされるバグは3件しか残らないと整理した
- このように事例が少ない理由は、実際の悪用にTLDのWHOISサーバー制御といった困難な前提条件が必要だという認識と結び付いている可能性がある
- phpWHOIS CVE-2015-5243 は、WHOISサーバーから受け取ったデータをPHPの
evalで実行してしまい、RCE が可能になる脆弱性だ- 脆弱なコードはWHOIS応答文字列中の
\"だけを不完全にエスケープしたうえでevalに渡していた - Netitudeの分析 は
”;phpinfo();//のようなサンプルペイロードを示している - 脆弱なphpWHOISバージョンは
whois.dotmobiregistry.netをハードコードしていた
- 脆弱なコードはWHOIS応答文字列中の
- Fail2Ban CVE-2021-32749 は、WHOIS出力が
mailツールに適切に整形されないまま渡され、コマンドインジェクションが可能になる脆弱性だ- Fail2BanはブロックしたIPの所有者情報をWHOISで照会し、管理者向けメールに含めることがある
- ただしこの脆弱性はIPアドレスに対するWHOIS照会で発生するため、watchTowrが確保した
.mobiドメインWHOISサーバーの制御だけでは直接は到達しない
- 実際のコード実行には、依然として古い
.mobiWHOISサーバーへ問い合わせるクライアントと、脆弱なクライアント実装の両方が必要になる
TLS/SSL証明書の検証フローにも影響
- 一部のTLS/SSL認証局はドメイン所有権確認のため、WHOISデータから管理連絡先メールを解析し、そのメールアドレスへ検証リンクを送る方式をサポートしている
- watchTowrが列挙した、WHOISベースの所有権検証をサポートする認証局またはリセラーの例は次の通り
- Trustico
- Comodo
- SSLS
- GoGetSSL
- GlobalSign
- DigiSign
- Sectigo
- GoGetSSLのテストでは、仮想の
watchTowr.mobiCSRをアップロードした際、watchTowrが設定したwhois@watchtowr.comは表示されず、WHOISが成功していない状態と思われるプレースホルダーメールだけが表示された - Entrustのテストでは、
microsoft.mobiの正当なWHOISレコードが解析され、microsoft.comドメインのメールだけが検証候補として表示され、watchTowr.mobiは解析されなかった - GlobalSignのテストでは、当初は
microsoft.mobiのWHOISレコードを解析できていないように見えたが、watchTowrが正当なWHOISサーバーのmicrosoft.mobi出力形式をコピーし、自身のWHOISサーバー向けに提供すると結果が変わった - GlobalSignはwatchTowrのWHOISサーバーへ問い合わせ、応答から
whois@watchtowr.comを解析し、microsoft.mobiの検証メールとして提示した - watchTowrはこの時点で中断しており、悪意あるTLS/SSL証明書を実際に発行させてはいない
- 理論上の攻撃フローは次の通り
- 過去に権威を持っていたホスト名へ悪意あるWHOISサーバーを配置する
- 標的
.mobiドメインのTLS/SSL証明書購入を試みる - 認証局がWHOISを照会し、実際の所有者ではない攻撃者のメールアドレスへ検証メールを送る
- 攻撃者がリンクをクリックすると、標的ドメインのTLS/SSL証明書を取得できる
- この能力があれば、トラフィックの傍受や標的サーバーのなりすましといった攻撃が理論上可能になる
事後対応と残る問題
- 公開前に英国の NCSC と ShadowServer Foundation が連携して対応した
dotmobiregistry.netドメインとwhois.dotmobiregistry.netホスト名は、ShadowServerが提供するシンクホールシステムへ向けられた- このシンクホールは
.mobiドメインに対する正当なWHOIS応答をプロキシする - 影響を受けた関係者へ通知する手順も整備された
- 今回の事例は、レガシーインフラ、放置されたドメイン、WHOISベースの処理、TLS/SSL認証局の検証手順が組み合わさったときに生じる構造的欠陥を示している
- MITMが可能な主体もWHOISデータを偽造して同種の攻撃を試みることができ、証明書透明性のような仕組みがあっても、大規模攻撃にはなお運用上の障壁が残る
1件のコメント
Hacker News の意見
この状況に至るまでには複数の人のミスが重なったのだろうが、この特定の攻撃を防げたことが一つあるのは明らかだ。ドメインを絶対に失効させないこと
.MOBI トップレベルドメインの WHOIS サーバーは数年前に
whois.dotmobiregistry.netからwhois.nic.mobiへ移行され、dotmobiregistry.netドメインは 2023 年 12 月ごろに失効したまま放置されていたようだ企業が年 10 ドルだからと新しいドメインを使い始めると、そのドメインは事実上、永遠に年 10 ドルを払い続ける資産になる。一度ビジネスと結びついたドメインは、その結びつきを完全に断ち切ることはできない
https://money.cnn.com/2016/01/29/technology/google-domain-pu...
結局、計算値そのものはあまり重要ではないと思った。失効したクレジットカードやスパムフィルタリングのせいで更新通知を見逃し、支払いを忘れる可能性の方が高いからだ
巨大企業はどうやってドメイン費用の支払いを忘れずにいるのだろうか？ 高価な登録代行業者に「無限」に近い期間の更新を任せているのだろうか？ かなり難しい事業運営上の問題に見える
ある朝起きたら、どこか人里離れたホテルの部屋で、誰かが近くのカフェの Wi-Fi ホットスポットにつないだ Raspberry Pi で何かをして、インターネット全体が消えたというニュースを目にしそうな気がする
.mobiに限られていた[0] https://xkcd.com/2347/
[1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
[1] https://news.ycombinator.com/item?id=41482087
なぜツールは WHOIS サーバー一覧をハードコードして使っているのだろうか？
DNS にこれを登録する標準的な方法があるようだが、簡単にテストしてみると、多くのトップレベルドメインでレコードが欠けている。動作する例は
dig _nicname._tcp.fr SRV +noall +answerで、_nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.が返るさらに、これに関する期限切れの Internet-Draft もある: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...
mobi.whois.arpa. CNAME whois.nic.mobiがあるだけでも、すでに問題は解決できていた。ただし、全員にこうした方式へ合意し採用してもらうのが難しい下で fanf2 が言っているように、IANA の WHOIS サーバーから問い合わせてもよさそうだ。https://www.iana.org/whois で
mobiを問い合わせると、応答の一部としてwhois: whois.nic.mobiが返ってくる開発者の力量不足も問題だが、AI の幻覚がこの状況をさらに悪化させるだろう
ドメインを意味のある形で一度使い始めたら、事実上、宇宙の熱的死まで、少なくともチームの熱的死までは更新し続けなければならないことに気づいていないチームをあまりにも多く見てきた
こういうケースであれ、どこかに残っている古いが重要な URL であれ、チームメンバーが昔のドメインのメールアドレスでサービスに登録した場合であれ、古いドメインを本当に手放してよい時点を知るのはあまりにも難しい
古い WHOIS サーバーの失効ドメイン 1 つを買うだけで生じる攻撃対象領域は、本当に途方もなく大きい
WHOIS の本当の解決策は RDAP だ
残念ながら国別コードトップレベルドメインでは必須ではなく、国別コードではないトップレベルドメインの中にも、まともに動作しないところが多い
https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
https://resolve.rs/domains/rdap-missing.html
とても見事な仕事
dotmobiregistry.netドメインとwhois.dotmobiregisry.netホスト名は、現在 ShadowServer が提供したシンクホールシステムを指しており、このシステムが.mobiドメインの正規の WHOIS 応答をプロキシしているとのことこれらのドメインを廃止する予定だったなら、404 のような応答を返すほうがよかったはず。正常に動き続けるようにしておくと、正式なドメインへ移行する動機が弱まる
Domain not found.>>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<コンピュータ全般におけるアプローチそのものが、失敗する運命にあると思う。完璧なセキュリティに依存しており、そのセキュリティは SBOM 検査と頻繁なアップデートで達成されると仮定している
しかし、絶対にそうはならない。log4j だけを見ても、全ダウンロードの 40% が脆弱なバージョンだ。サプライチェーン内の企業が廃業したり、コンポーネントのメンテナンスをやめたりした場合は言うまでもない
私たちの体が常に微生物との戦場であるように、あらゆるものは常にバグだらけ、穴だらけにならざるを得ない
おそらく数十年はかかるだろうが、道筋はかなり明確に見える。努力を重ね、あらゆる「教訓」から得た知識を適用し、止まらなければよい
全体として、「私たちはこれをやりたくなかったのに、状況がどんどん大きくなり、各段階で予想以上に大きなものを手にしてしまった」という雰囲気がよかった
反対していた人たちが話を聞いてパース処理を修正していたなら、筆者たちはこうした手間を省けたのかもしれない
これを逆に見ると、世界中のすべての WHOIS サーバーが常に本物で安全だと信じなければならないのだろうか？
特に TLS 検証を行う認証局の立場からすれば、
whois somethingarbitrary.ruを実行した結果、ロシアのサーバーのせいでリモートコード実行にさらされるという事実は知りたくないはずだ