数百万台のモデムをハッキングし、自分のモデムをハッキングした人物を調査する

• 2年前、自宅で脆弱性テストをしていたときに奇妙な出来事を経験した
• AWSのボックスでHTTPサーバーを立ち上げ、脆弱なサーバーからファイルを取得しようとしていた
• すべての設定はうまくいっているように見えたが、脆弱性テストに戻ろうとした瞬間、予想外のログが現れた
• 誰かが自宅ネットワークとAWSのボックスの間で、10秒後に同じHTTPリクエストを傍受して再送していた
• このトラフィックは到達不能であるはずで、中継者が存在してはならなかった
• まず思ったのは、自分のコンピュータがハッキングされ、ハッカーがトラフィックを積極的に監視しているということだった
• iPhoneでも同じ現象が起きるか確認したところ、不明なIPアドレスがコンピュータとiPhoneのHTTPリクエストをどちらも傍受して再送していた
• 侵害されている可能性が高いのは、ISP、モデム、AWSのいずれかに見えた
• AWSがハッキングされたという突飛な考えを排除するためにGCPでボックスを起動したが、同じ現象が発生した
• 残る可能性はモデムがハッキングされたことだけだったが、攻撃者は誰なのか。IPアドレスの所有者を調べるとDigitalOceanに属していた
• そのIPはここ数年、複数のフィッシングサイトやメールサーバーに使われていた
• 侵害された機器は動作し続けていたため、電源を抜いて箱にしまっておいた
• Coxの店舗へ行き、ハッキングされたモデムを返却して新しいものを受け取った
• 新しいモデムを設置すると異常な挙動は止まったが、モデムが具体的にどう侵害されたのかは分からなかった
• 3年後、セキュリティ専門家の友人たちと休暇中にこの出来事を話すことになり、彼らが興味を持って調査を始めた
• IPアドレスが登録していたドメインを調べると、大量のアルゴリズム生成ドメインがあった。C&Cサーバーであることを示唆していた
• 攻撃者は同じIPで複数の悪意ある活動を行っていたが、3年間停止されておらず、意図を把握しにくかった
• 新しいモデムも同じモデルだったため、攻撃者が再侵入した可能性も考慮した
• TR-069プロトコルを通じてISPが機器を管理できる点に注目した。サポートツールのインフラを攻撃すればモデムを掌握できるはずだった
• CoxビジネスポータルのJavaScriptを分析し、700件以上のAPIパスを発見した。その中で機器や顧客アカウントへのアクセス機能が最も多かったAPIはaccountequipment、datainternetgateway、accountだった
• 認証回避が可能な脆弱性を発見した。HTTPリクエストを繰り返し送信すると、権限なしでコマンドを実行できた
• MACアドレスによって誰の機器であっても直接通信できることを確認した。Coxは数百万人の顧客にサービスを提供している
• 機器設定の上書き、ルーターへのアクセス、機器上でのコマンド実行など、ISPの技術サポートチームに近い権限を取得できることを実証した
• これは事前条件なしで数百万台のモデム設定を変更し、顧客のPIIにアクセスし、ISPサポートチーム相当の権限を得られる脆弱性だった
• 想定される事故シナリオは次の通り
  1. APIでCoxのビジネス顧客を検索
  2. UUIDにより、機器のMACアドレス、メールアドレス、電話番号、住所などの顧客PIIを取得
  3. MACアドレスでWiFiパスワードと接続済みデバイスを照会
  4. 任意コマンド実行、機器属性の変更、アカウント乗っ取り
• 脆弱性をCoxに報告したところ、6時間以内にAPIを遮断し、認証問題の修正を開始した
• 700件以上の露出したAPIのうちかなりの数が管理者機能を提供しており、すべて同じ権限問題を抱えていた
• 今回の事例は、ISPと顧客機器の間にある信頼レイヤーの脆弱性を示している
• 自分のモデムが正確にどうハッキングされたのかは今でも気になっている。攻撃者がなぜトラフィックを再送していたのかも理解できない
• 関連する理論や意見は歓迎する

GN⁺の見解

• セキュリティ脆弱性: この記事は、ISPのセキュリティ脆弱性がどれほど深刻な影響を及ぼし得るかを示している。特に、遠隔で機器設定を変更できる機能が悪用されうる。
• APIセキュリティ: APIセキュリティの重要性を強調している。認証回避のような脆弱性は、深刻なセキュリティ問題を引き起こしかねない。
• ユーザーデータ保護: 顧客の個人情報や機器設定が容易に露出しうる危険性を警告している。ISPはこれらのデータを保護するため、より強力なセキュリティ対策を講じる必要がある。
• 技術的理解: 初級ソフトウェアエンジニアでも理解できるよう技術的詳細を説明することで、セキュリティ脆弱性を検出し解決する方法を学べる。
• 代替案の提示: このような問題を解決するには、より安全なネットワーク機器とセキュリティプロトコルを使用することが重要である。他のISPやセキュリティソリューションを検討することもできる。

[GN⁺]

Hacker Newsのコメント

• Coxが問題を否定したり、告発者を攻撃したりせず、責任ある対応を取ったのは印象的。バグの内容が何だったのか、続報を読みたい。
• ISPが自社製モデムやルーターの使用を強制する状況は不快。AT&Tのルーターも侵害される可能性はあるが、HTTPSのおかげでまだ救いがある。
• 素晴らしい記事と調査だった。Nokiaルーターのローカル管理インターフェースは、適切に認証されていないように見える。特定の設定は変更できなかったが、ページをハックして変更できた。
• 多くのルーターではファームウェアの手動更新が必要。GL.iNetルーターには最近RCEの脆弱性があった。ファームウェアの更新やSSHアクセスの無効化などの対策を勧める。
• 攻撃者がHTTPトラフィックをどうやって傍受したのか、依然として疑問。Coxはファームウェアのバージョンを確認し、自動更新で問題を解決できるはず。
• Coxは過去にこの脆弱性が悪用されたことはないと主張しているが、信じがたい。ネットワークの管理は甘い。
• 大手テック企業で大きな脆弱性が見つかったのは衝撃的。記事は素晴らしいが、この脆弱性は許されない。
• 脆弱性を報告した人に報奨があったのか気になる。彼は大きく貢献したのに、何の報酬も受け取っていないように見える。これは非常に侮辱的だ。
• Coxが過去に悪用されたことはないと主張するのは、ログや監査データが不足していたからだろう。
• 記事の内容は素晴らしいが、本気の攻撃者ならCoxの技術者を装ってアクセスできる。ISPはリモートアクセスをデフォルトで無効化する設定を実装すべきだ。