- Sam Curryは、自宅ネットワークから送ったHTTPリクエストが10秒後にDigitalOceanのIPからそのまま再生される現象を発見し、Cox Panoramic Wifiゲートウェイを交換した後に問題が消えたため、元のモデム侵害を疑った
- 再生トラフィックのIP
159.65.76.209 は、Adidas関連ドメイン、ISG Latamのフィッシングドメイン、アルゴリズム的に生成されたようなC&C用ドメインと結び付いていたが、実際の侵害経路は特定されなかった
- 2024年、Cox Businessポータルの分析中に
/api/cbma/ 配下のSpringベースAPIとSwaggerドキュメントが見つかり、約700個のAPIの一部で認証エラーと 200 OK が交互に返る権限回避の問題が見つかった
- この権限回避により、顧客検索、アカウントPIIの参照、機器のMACアドレス参照、モデムIPの参照、Cox Businessアカウントの読み書き、WiFi SSID変更などの機器設定変更が可能で、PoCでは自分のSSIDが
Curry に変更された
- Coxは報告から6時間以内に公開されていたAPIを停止し、翌日には再現不能になったとし、該当APIサービスは2023年に開始されたもので、2021年のモデム侵害とは別件であり、過去の悪用履歴もなかったと説明した
自宅モデムから始まった異常トラフィック
- 自宅ネットワークでblind XXE脆弱性をテストするため、AWSインスタンス上に簡単なPython HTTPサーバーを立て、外部リクエストの受信有無を確認していた
- 自宅PCから
curl で送ったリクエストが正常に記録された直後、正体不明のIP 159.65.76.209 が同じパスを10秒後に再度リクエストした
- iPhone Safariで別のパスをリクエストした時も同じIPが同一リクエストを再生し、特定のコンピューターではなく自宅ネットワーク全体のトラフィックが観測されているように見えた
- 新しいAWSインスタンスとNginx、その後のGCPインスタンスでも同じ現象が繰り返され、AWS侵害の可能性は除外された
- 既存のCox Panoramic Wifiゲートウェイを店舗に返却して新しい機器に交換したところ、再生トラフィックは消え、ログに「別のIP」は現れなくなった
159.65.76.209 の調査
- このIPはDigitalOcean所有と確認され、Cox ISPのアドレスではなかった
- VirusTotalの記録では、最近関連付けられた5つのドメインのうち3つはフィッシングサイト、2つはメールサーバーのように見えた
regional.adidas.com.pyisglatam.onlineisglatam.tkmx12.limit742921.tokyomx12.jingoism44769.xyz
isglatam.online と isglatam.tk は、かつて南米のサイバーセキュリティ企業 isglatam.com を狙ったフィッシングWebサイトだった- URLscanの記録によると、2つのISG Latam関連ドメインは一般的なBeEFフィッシングサイトをホストしており、関連記録は urlscan.ioの結果 で確認できる
- 同じIPがAdidas、ISG Latam、モデムトラフィック再生と結び付いていたが、そのIPが複数の所有者間で再割り当てされた可能性も完全には否定できなかった
3年後に再びつながった分析
- 2024年初頭、セキュリティ分野の友人たちが
limit742921.tokyo と jingoism44769.xyz の形式に注目した
limit742921.tokyo の mx1 サブドメインIPを基準に逆引きIP検索を行うと、同じパターンのドメインが1,000個以上見つかった- ドメイン名はすべて
[word][6 numbers].[TLD] 形式だった
- 例:
acquire543225.biz
- 例:
battery935904.biz
- 例:
grocery634272.biz
- 大量登録とアルゴリズム的な構造から、マルウェア運用者がC&Cサーバーのアドレスを隠すために使うドメイン生成アルゴリズムのように見えた
- 最後に観測されたドメインは2023年3月17日に登録されており、その時点ではすでにホストが解決されず、同じIPに登録された類似ドメインも見つからなかった
ISP管理機能とTR-069から始まった仮説
- Coxのサポート担当者は、モデムをリモート更新し、WiFiパスワードを変更し、接続された機器を確認できた
- このリモート管理は、2004年に実装されたTR-069プロトコルを通じて、ISPがポート
7547 でネットワーク内機器を管理する仕組みと結び付いている
- TR-069自体は外部に公開されておらず、すでにDEF CONの発表でも扱われていたため、関心は担当者が使うサポートツールと内部APIへ移った
- 攻撃者がモデムを侵害しようとするなら、サポートツールの基盤インフラ、特に顧客機器の設定変更や任意コマンド実行が可能なAPIを狙うだろうと判断した
- この調査は、2021年の実際の侵害経路を特定するというより、ISPと顧客機器の間にある信頼レイヤーを確認する方向へ進んだ
Cox BusinessポータルのAPI構造
- Cox BusinessポータルのフロントエンドJavaScriptファイル
main.36624ed36fb0ff5b.js から、/api/cbma/ ベースのAPI呼び出しが100件以上確認された
/api/cbma/ パスは他の /api/ パスと応答挙動が異なり、フロントエンドとは別のバックエンドへプロキシされるAPIのように見えた
/api/anything_else/example はリダイレクト応答を返す/api/cbma/example は 500 Internal Server Error を返す
- 登録リクエストには
clientid, Apikey, Cb_session, Authorization などのヘッダーが含まれており、応答形式はSpringベースのバックエンドのように見えた
- HTTPメソッドを変更するとSpringのエラー応答が現れ、APIバックエンドがSpringベースであることを確認した
- actuatorパスは見つからなかったが、Swagger UIのパスは発見された
Swaggerドキュメントの回避読み込みと700個のAPI
- Swagger UIは読み込まれたが、静的リソースがリダイレクトループに入り、ドキュメントは空に見えた
.js, .css, .png などの静的リソース要求が、APIプロキシではなくデフォルトホストへルーティングされているようだった- URL末尾にエンコード済みの
/ である %2f を付けると、静的JavaScriptリソースをAPIプロキシ経由で読み込めるようになった
- Burpのmatch-and-replaceで静的リソース要求に
%2f を付けると、Swaggerドキュメントが正常表示された
- 全体で約700個のAPI呼び出しが確認され、そのうち機器およびアカウント機能と特に関係が深い領域は
accountequipment, datainternetgateway, account だった
認証回避と顧客データへのアクセス
- すべてのGETエンドポイントを対象にリクエストを繰り返すと、一部は認証エラーを返し、一部は
200 OK を返し、同じリクエストでも繰り返すと結果が変わる現象があった
profilesearch エンドポイントは最初は空の検索結果を返し、その後同じリクエストで認証エラーと成功応答が交互に現れた- 検索語
cox でリクエストを繰り返すと、Cox Business顧客プロフィールと思われる結果と profileGuid が返された
- 検索語
fbi では、Cox Business顧客である複数のFBI現地事務所の物理住所を含む結果が返された
- 同じ権限問題は他のAPIにも影響し、リクエストを何度も再生すると未認証状態でも管理者機能にアクセスできた
機器MACアドレスとアカウント情報の参照
- 自分のモデムMACアドレスをCoxアカウントから取得し、
macAddress パラメータを持つAPIに入れると、その機器のIPv4アドレスが返された
- この結果により、Cox Business WebサイトAPIが実際の機器と通信できることが確認された
- アカウントIDを使う機器一覧APIは、アカウントに紐付く機器情報を返した
- 機器カテゴリ
- モデル名
- MACアドレス
- ポート情報
- シリアル番号
- メールアドレスベースのユーザー参照APIは、氏名、電話番号、状態、ユーザー種別、プロフィール所有者かどうか、代替メールアドレスなどのビジネスアカウント情報を返した
- 類似のPOSTアカウント更新リクエストも機能し、ビジネスアカウントに対して読み取りと書き込みが可能であることが確認された
encryptedValue と機器設定変更
- 機器設定変更リクエストには
encryptedValue パラメータが必要だった
- JavaScript内の
encryptWithSaltandPadding と decryptWithSaltandPadding 関数が、AESベースで値の暗号化・復号に使われていた
- アカウント登録時に設定する4桁PINも同じ関数で暗号化されており、ブラウザデバッガーでその関数の実行コンテキストを取得できた
- Cox Businessを使う知人のアカウントで、機器応答に含まれる
encryptedValue を復号すると、次の要素が含まれていた
- Coxアカウント番号
- 機器名
- 機器ID
- 不明な値
- MACアドレス
- ラベル
- アカウント番号と機器IDを任意の値にし、MACアドレスだけを有効にした文字列を再暗号化してもリクエストが成功したことから、サーバーがMACアドレスとアカウントの整合性を検証していないことが確認された
任意のモデム設定変更の可能性
- 自分の機器MACアドレスに対してWiFi SSIDを変更するPOSTリクエストを送信した
- 応答は
200 OK と Success で、その後ネットワークは一時的にオフラインになった
- 約5分後にネットワークが再起動し、SSIDが
Curry に変更された
- このPoCは、機器構成更新APIが実際に機能し、攻撃者がAPI経由で機器設定を上書きできることを示した
- この権限はISPテクニカルサポートに近い水準で、APIにアクセス可能な数百万台のCox機器に影響を与え得た
影響範囲と想定される攻撃フロー
- 脆弱性の組み合わせにより、事前条件のない外部攻撃者が数百万台のモデム設定変更、ビジネス顧客PIIへのアクセス、ISPサポートチーム級の権限取得を行える経路が生まれていた
- Coxは米国最大の民間ブロードバンド事業者で、ケーブルテレビでは第3位、電話事業では第7位であり、数百万の顧客を抱え、10州で最も人気のあるISPだった
- 想定される攻撃フローは次の通りだった
- 氏名、電話番号、メールアドレス、アカウント番号でCox Businessの対象を検索
- 返されたUUIDでアカウントPII、機器MACアドレス、メール、電話番号、住所を参照
- 機器MACアドレスでWiFiパスワードと接続機器を参照
- 任意コマンド実行、機器プロパティ更新、被害者アカウント乗っ取り
- 公開されていたAPIは700個以上あり、多くはモデム接続機器の参照など管理者機能を提供していた
- 各APIは、繰り返しリクエストにより未認可コマンドを実行できる同じ権限問題を抱えていた
報告、パッチ、そして残る疑問
- 脆弱性はCoxの responsible disclosure program を通じて報告された
- Coxは6時間以内に公開API呼び出しを停止し、翌日には脆弱性を再現できなくなっていた
- Coxの調査では、このベクトルの過去の悪用履歴はなく、脆弱性のあったサービスは2023年に開始されたもので、2021年のモデム侵害には使われ得なかった
- CoxはDigitalOceanのIPとは一切関係がないと伝えており、そのため元のモデムはこの記事で公開された方法ではなく、別の手段で侵害されたままだと考えられる
- 元のモデムは返却済みだったため、ファームウェアダンプやフォレンジック分析はできず、なぜわざわざトラフィックを再生していたのかも確認できなかった
公開タイムライン
- 2024-03-04: Coxの責任ある開示プログラムに脆弱性を報告
- 2024-03-05: ホットパッチを適用、必須ではないビジネスエンドポイントが
403 を返して停止
- 2024-03-06: 脆弱性がもはや再現不可能であるとCoxにメール送信
- 2024-03-07: Coxが包括的なセキュリティレビューを開始すると返信
- 2024-04-10: 報告から90日後に公開する意向をCoxに伝達
- 2024-04-29: ブログ草案のリンクをCoxと共有
1件のコメント
Hacker News のコメント
xrayarx が快く受け止めてくれることを願っています。こうした場合のために カルマ共有 をきちんと実装する予定はありますが、それまでは時々、このような不格好な手作業に頼っています