数百万台のモデムのハッキングと、自分のモデム侵害の調査

 (samcurry.net)
2 ポイント 投稿者 GN⁺ 2024-06-05 | 1件のコメント | WhatsAppで共有
  • 自宅ネットワークのHTTPリクエストがDigitalOceanのIPから約10秒後にそのまま再生され、Cox Panoramic Wifiゲートウェイ配下の複数デバイスのトラフィックが外部に露出していた形跡が明らかになった
  • VirusTotal・URLscanで追跡した結果、このIPは過去にフィッシングドメインやword+6 digits+TLD形式の大量ドメインと関連しており、C&C用のドメイン生成アルゴリズムの可能性が浮上した
  • 2024年にCox Businessポータルを分析する過程で、/api/cbma/配下のSpringベースAPIとSwaggerドキュメントが露出しており、リクエストを繰り返すだけで権限検証の迂回が発生した
  • 露出したAPIは顧客検索、アカウントPII照会、機器MACアドレス照会、WiFi設定変更まで許可しており、encryptedValue生成ロジックもフロントエンドJavaScriptから呼び出し可能だった
  • Coxは報告後6時間以内に露出APIを停止したが、このサービスは2023年に始まったもので、2021年の最初のモデム侵害の原因は依然として別問題として残っている

自宅ネットワークで発見されたHTTPリクエストの再生

  • blind XXE脆弱性をテストするためAWSインスタンス上でPython HTTPサーバーを立ち上げた後、自宅のコンピューターから/test123リクエストを送信した
    • 元のリクエストは自宅IP 98.161.24.100から到着した
    • 約10秒後、不明なIP 159.65.76.209が同じパスへリクエストを再送した
  • iPhone Safariでも同じURLをリクエストすると、同じIPが再びリクエストを再生した
    • 自宅のコンピューターだけでなく、自宅ネットワーク内の別デバイスでも同じ現象が繰り返された
  • 新しいAWSインスタンスとNginx、GCPインスタンスでも同じIPがリクエストを再生したため、AWS自体の問題である可能性は低くなった
    • 残った可能性はISP、モデム、またはネットワーク経路の侵害だった
  • IP所有者を調べた結果、159.65.76.209はDigitalOceanのアドレスであり、ISPのアドレスではなかった

DigitalOceanのIPに結び付いた過去の悪性インフラ

  • VirusTotalの照会で、そのIPに過去に解決されていたドメインが確認された
    • 直近5つのドメインのうち3つはフィッシングサイトで、2つはメールサーバーのように見えた
    • 例のドメイン:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.onlineとisglatam.tkは、南米のサイバーセキュリティ企業isglatam.comを狙ったフィッシングサイトだった
    • 実際のISG LatamのWebサイトでは、同社がパラグアイ拠点の企業であり、Crowdstrike、AppGate、Acunetix、DarkTrace、ForcePointとパートナー関係にあることが確認された
  • URLscanには、この2つのドメインが一般的なBeEFフィッシングサイトをホストしていた痕跡が残っている
  • 同じIPがAdidas関連ドメイン、ISG Latamフィッシング、モデムトラフィック再生と思われる活動のすべてに結び付いていた
    • IPが複数の所有者間でローテーションされていた可能性もあったが、活動間の間隔が長く、すぐに別の悪性ユーザーへ再割り当てされた可能性は低そうだった

モデム交換と3年後の再調査

  • 使用していた機器はCox Panoramic Wifi gatewayで、Cox店舗で新しいモデムに交換した
    • 既存機器はISPからのレンタル機器だったため返却する必要があった
    • ファームウェアのダンプやリバースエンジニアリングは実施できなかった
  • 新しいモデムを設置した後、HTTPリクエスト再生の現象は完全に止まった
    • ログに他のIPが現れなくなった
    • 当時は、既存モデムが侵害されていたという結論以上の追加調査は難しかった
  • 2024年初め、約3年後にセキュリティ業界の知人たちと再び調査し、limit742921.tokyo、jingoism44769.xyzのようなドメイン形式に注目した
    • 関連IPに対してreverse IP検索を行うと、同じパターンのドメインが1,000件以上確認された
  • ドメイン形式はいずれもword + 6 numbers + TLDという構造だった
    • 大量登録とアルゴリズム的な構造から、悪性運用者がC&Cサーバーのアドレスを隠すために使うドメイン生成アルゴリズムのように見えた
    • 最後に観測されたドメインは2023年3月17日に登録され、それ以降は解決されるホストが存在しなかった
  • 交換後の新しいモデムも同一モデルだったが、Google検索の範囲ではそのモデルの公開脆弱性は確認されなかった

ISPサポートツールとTR-069から出発した仮説

  • Coxモデムを新しい場所へ移す過程で、ISPのサポート担当者がリモートで機器設定を変更できることを確認した
    • サポート担当者は機器設定の更新、WiFiパスワード変更、接続デバイスの確認が可能だった
  • このようなリモート管理は、2004年に実装されたTR-069プロトコルを通じて行われる
    • ISPがポート7547で自社ネットワーク内の機器を管理する方式である
    • このプロトコルはDEF CONの発表でも取り上げられたが、外部に露出した攻撃面ではなかった
  • 調査の焦点はプロトコル自体ではなく、サポート担当者が使う内部の機器管理Webサイトと、その背後のAPIへ移った
    • こうしたAPIが顧客機器設定を照会・変更したりコマンドを実行できるなら、モデム侵害経路になり得る

Cox BusinessポータルのAPI構造

  • Cox Businessポータルは機器のリモート管理、ファイアウォールルール設定、ネットワークトラフィック監視機能を提供する
  • ログインページのフロントエンドJavaScriptファイルmain.36624ed36fb0ff5b.jsからルートを抽出した
    • /api/cbma/ベースのAPI呼び出しが100件以上確認された
    • 例:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/は通常のフロントエンドとは異なる応答を示し、別のバックエンドへ向かうリバースプロキシのように見えた
    • /api/anything_else/exampleリクエストは301リダイレクトを返す
    • /api/cbma/exampleリクエストは500 Internal Server Errorを返す
  • 登録リクエストには複数の認証関連ヘッダーが含まれていた
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • HTTPメソッドを変えてみるとSpring形式のエラーレスポンスが返り、バックエンドがSpringベースであることを確認した

Swaggerドキュメントと静的リソースの迂回

  • Spring actuatorのパスは見つからなかったが、Swagger UIパスの一部にはアクセスできた
    • /api/cbma/userauthorization/swagger-ui/index.htmlパスが応答した
  • 最初に読み込んだSwaggerページは空だった
    • .png、.js、.cssのような静的リソースがAPIプロキシではなく元のホストパスへルーティングされ、無限リダイレクトが発生していた
  • Burp IntruderでURL末尾に%00から%FFまでを付けてテストした結果、URLエンコードされた/である%2fを.jsの後ろに付けると200 OKが返った
    • 例: /swagger-initializer.js%2f
  • Burpのmatch-and-replaceですべての静的リソースに%2fを付けると、Swaggerドキュメントが正常にロードされた
  • 全体で約700件のAPI呼び出しが確認された
    • account: 115件
    • voiceutilities: 73件
    • user: 70件
    • datainternetgateway: 57件
    • accountequipment: 55件
    • billing: 53件
    • ticket: 52件
    • その他profile、voicecallmanagement、voicemail、userauthorization、csrなど
  • 機器と顧客アカウントに直接関係するAPIは、accountequipment、datainternetgateway、accountが最も重要そうだった

リクエストの繰り返しで発生した権限検証の迂回

  • すべてのGETエンドポイントを対象に、認証なしでアクセス可能か確認したところ、一部は認証エラーを返し、一部は200 OKを返した
  • profilesearchエンドポイントは最初、空の検索結果を含む成功レスポンスを返した
    • 同じリクエストが、ある時はAuthorization Error-Invalid User Tokenを返し、再送すると成功するという挙動をした
  • 同じリクエストを何度も再送すると権限エラーが消え、顧客検索結果が返された
    • cox検索では10000+ hitsが返された
    • fbi検索では、Coxのビジネス顧客であるFBI現地事務所の物理住所を含む結果が返された
  • APIリクエストを繰り返すだけで権限迂回が可能で、同じ問題が700件以上のAPI全体に影響しているように見えた

顧客機器へのアクセスとアカウント照会

  • Cox Business APIが住宅向けネットワーク機器にもアクセス可能か確認するため、MACアドレスを受け取る単純なAPIをテストした
    • エンドポイント: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • 自分のCoxアカウントでMACアドレスを確認した後にリクエストを繰り返すと、自分のモデムのIPv4アドレスが返された
    • このAPIが実際のCox機器と通信できることを確認した
  • アカウントIDを使う機器一覧APIも動作した
    • エンドポイント: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • レスポンスにはインターネット機器、音声機器、TV機器の情報が含まれた
    • 機器モデル、機器種別、MACアドレス、ポート一覧、シリアル番号が返された
  • メールベースのユーザー照会APIもビジネスアカウント情報を返した
    • 例のリクエスト: /api/cbma/user/services/user/admin@cox.net
    • メール、氏名、電話番号、状態、権限、プロフィール所有者かどうか、代替メールなどが含まれた
  • 類似のPOSTアカウント更新リクエストも動作し、ビジネスアカウントの読み取りと書き込みが可能であることを確認した

encryptedValueと機器設定の変更

  • ハードウェア設定変更リクエストにはencryptedValueというパラメーターが必要だった
    • 例: 機器パスワード変更、WiFi設定変更
  • フロントエンドJavaScriptでencryptedValueの生成・復号ロジックを追跡した
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • アカウント登録時に設定する4桁PINも同じ関数で暗号化されていたため、ブラウザデバッガーでその関数が呼び出される箇所にブレークポイントを置き、コンソールから直接呼び出せた
  • 実際のアカウントレスポンスから得たencryptedValueを復号すると、次の形式の値が確認された
    • Coxアカウント番号
    • 機器名
    • 機器ID
    • 不明な値
    • MACアドレス
    • ラベル
  • アカウント番号などの大半を任意の値で埋め、MACアドレスだけを有効にして新しいencryptedValueを生成してもリクエストは成功した
    • サーバーはアカウントIDとMACアドレスの一致を検証していなかった

任意のモデム設定を変更できる可能性

  • 自分の機器を対象に、WiFi SSIDをCurryへ変更するPOSTリクエストを送信した
    • エンドポイント: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • リクエスト本文にはwifiSettings、additionalProperties、encryptedValueが含まれた
  • レスポンスは{"message": "Success"}で、その後ネットワークが一時的に切断され、約5分後に再起動した
    • SSIDは実際にCurryへ変更された
  • この挙動は、API経由の機器構成変更が実機に適用されることを示している
    • 攻撃者は顧客検索でアカウントUUIDを取得し
    • 接続機器のMACアドレスを照会し
    • MACアドレスベースで機器設定を読み取ったり変更したりできる
  • この権限はISPサポートチームに近いレベルのアクセスで、Cox機器数百万台に影響し得る経路だった

影響範囲と攻撃シナリオ

  • 脆弱性の組み合わせにより、外部攻撃者が事前条件なしに以下を実行できることが示された
    • 数百万台のモデムでのコマンド実行と設定変更
    • Cox Business顧客のPIIへのアクセス
    • ISPサポートチームに近い権限の取得
  • Coxは米国最大の民間ブロードバンドプロバイダー、3番目に大きいケーブルテレビプロバイダー、7番目に大きい電話事業者であり、10州で最も人気のあるISPである
  • 攻撃フローの例:
    • 氏名、電話番号、メール、アカウント番号でCox Businessの対象を検索
    • 返されたUUIDで全アカウントPIIと機器MACアドレス、メール、電話番号、住所を照会
    • ハードウェアMACアドレスでWiFiパスワードと接続デバイスを照会
    • 任意コマンド実行、機器属性の変更、被害者アカウントの乗っ取り
  • 700件以上の露出APIの多くが管理者機能を提供しており、リクエストの繰り返しで同じ権限問題が発生した

Coxへの報告と修正

  • 脆弱性はCoxのresponsible disclosure programを通じて報告された
  • Coxは報告後6時間以内に露出API呼び出しを停止し、権限脆弱性の修正作業を開始した
    • 翌日には、脆弱性を再現できなくなっていた
  • 公開タイムライン:
    • 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と共有

残る疑問

  • Coxは特定の脆弱性経路が過去に悪用されたかどうかを調査し、悪用履歴はないと確認した
    • このサービスは2023年に運用を開始した
    • 最初のモデム侵害は2021年に発生したため、公開されたCox Business API脆弱性が当時の侵害原因ではなかった
  • CoxはDigitalOceanのIPとは一切関係がないと伝えた
    • 機器が実際にハッキングされたことは確かだが、公開されたAPI脆弱性とは別の方法だった
  • モデムは外部からアクセス可能に設定しておらず、自宅ネットワークから機器にログインしたこともなかった
    • 可能な別経路として、ローカルCSRFからRCEへつながる0dayのような方式が挙げられる
  • 最大の疑問は、攻撃者がなぜHTTPリクエストを再生したのかである
    • ネットワーク内にいたなら、発覚せずにアクセスできたはずなのに、すべてのHTTPリクエストを再生した理由は確認されていない

関連記事

1件のコメント

 
GN⁺ 2024-06-05
Hacker News のコメント

  • 良い記事で、追いやすかった。特に Cox が通報者を攻撃したり問題を否定したりせず、こうした状況で期待される責任あるセキュリティ対応の模範のように振る舞った点が良かった。
    認可されていない API アクセスが断続的に許可されたバグが何だったのか、続報で読みたい。こういうエラーは浅いテストでは簡単に見落とされるし、原因によってはテスト環境ではそもそも再現しないこともある。

    • Cox が責任を持って対応したのは確かだが、最初に感染した機器を持って訪ねてきた時点で、その機会をもっと活かせたらよかったと思う。
      以前、従来型の通信会社で重大な脆弱性を偶然見つけたことがあるが、一般のカスタマーサポート窓口だけでは担当者にたどり着くまでほぼ 1 週間かかり、サポート組織はまったくエスカレーションできなかった。Cox も情報セキュリティの専門家が感染した機器を直接持ち込んだのに、サポート組織はそれを適切に処理できなかった。
    • 記事も読みやすく、Cox の対応も良かった。発見の経緯やバグ自体を否定的だったり見下したりする形で伝えていなかった点も気に入った。
    • 企業はこういうものを見つけた人を「ハッキング」したとして訴えるのではなく、報奨すべきだ。
    • 認可されていない API アクセスを断続的に許可していたバグが何だったのか、私も気になる。おそらく最後まで分からないかもしれないが、認可チェックを行わないテスト用バックエンドがロードバランサーの設定に誤って含まれていたケースかもしれない。
    • 記事は良かったが、「super curious」「super interesting」「super interested」のように super を繰り返し使っているのは少し気になった。

  • こういう状況で腹立たしいのは、ISP が自社のモデムやルーターを強制的に使わせる場合だ。たとえば AT&T fiber はネットワーク接続に証明書ベースの 802.1X 認証を使っているが、これがなければ ONT にどんな機器でも挿せたはずだ。
    回避方法はある、またはあったが、インターネットを使うためにそんな手順を踏みたくはないので、AT&T ルーターの機能をすべてオフにして、最新状態に保っている自分のルーターをその後ろに接続して使っている。AT&T ルーターがハッキングされても、サービスに悪影響が出るまでは気づかないかもしれない。最近はほとんどが HTTPS を使っているのが幸いだ。

    • ONT がモデムと分離されている AT&T fiber なら、802.1X の回避はかなり簡単だ。モデムと ONT の間にアンマネージドスイッチを挿し、モデムに認証させてからモデムを抜けばいい。
      ONT が再起動したらやり直す必要がある可能性は高いが、私の場合 AT&T が ONT 用の UPS を提供してくれたので、再起動の頻度は低いはずだ。個人的には、ファイアウォールがオフまたは再起動中のときはトラフィックが AT&T モデムを通り、オンになっているときは自分のファイアウォールがトラフィックを受け取り、選択的にモデム経由で渡すという、バイパス NIC ベースの複雑な構成を作ったが、実際にはアンマネージドスイッチだけでも十分だ。
    • AT&T の CPE ルーターがハッキングされる可能性は、自分のネットワークと AT&T のネットワークの間に自分のルーターがあるなら大きな違いにはならない。AT&T の CPE ルーターを取り除いても、結局は自分が制御していないブラックボックスに接続することになり、その機器もハッキングされているか、トラフィックをさまざまな方法で検査できる可能性がある。
    • 幸い Cox はそういう ISP ではない。契約している速度に合った十分に近代的なDOCSIS モデムなら受け入れてくれる。
      ただし Cox を褒められるのはそこまでだ。2 年間、断続的なパケットロスに悩まされているが、特定のノードがおそらく過剰契約状態だというデータを集めても、それを理解できる人に届くサポートのエスカレーション経路はなさそうだ。
    • 参考までに、xgspon では今や回避手順が自動化されている。「SFP+ を挿す、Web インターフェースでファームウェアを上げる、機器のシリアル番号を入力する」程度で、使う SFP モジュールによっては 2 段階目も省略できる。
      実際には 802.1X の状態はサーバー側で検証されていない。標準では 802.1X が要求されているのに実行されない場合、モデムはトラフィックを通してはならないとされているが、ほとんどはそのまま通すか、そうするよう変更できる。AT&T 側は検証せず常にトラフィックを通過させており、内部的にはそれが起きている。
    • AT&T ゲートウェイなしで接続する方法はいくつかあり、複数の方式が https://pon.wiki/ にまとめられている。

  • 読みやすい記事で、調査も素晴らしい。大企業がセキュリティ研究者に核爆弾を落とさない例を見られるのも良い。
    確信はないが、この Nokia ルーターのローカル管理者インターフェースへのリクエストが適切に認証されているのか疑わしい。最近同じ機器を支給されたが、一般管理者権限では変更できない設定があり、ISP はスーパー管理者アカウントをくれなかった。ところがページインスペクターで無効化されているフィールドを再び有効にして値を変えると、API はそのまま受け付けた。この状態で内部ネットワーク内でアプリケーションを実行できるなら、このようにルーターを乗っ取るのは難しくなさそうだが、かなり特定の条件に見える。

    • Cox が米国最大の民間ブロードバンド事業者であり、3 位のケーブル TV 事業者、7 位の電話事業者で、10 州で最も人気のある ISP だという点は、ISP はここまで大きくなるべきではないと思わせる。
      Cox は明らかに魅力的な攻撃対象であり、記事の例のように単一の脆弱性で FBI の現地事務所まで危険にさらされ得る。「Cox が過去の悪用の有無を調査し、記録は見つからなかった」ではなく、「調査したと主張した」と書くほうがより適切だったと思う。

  • 「過去の悪用履歴はなかった」という言葉を信じられるのか？ ネットワーク全体がスイスチーズのように穴だらけに見える。

    • だからこそ、すべてのログを書き込み権限だけを持つ AWS アカウントの S3 バケットに送り、そのバケットに対して他の操作ができるアカウントに入るには 3 人が必要、という形にするのだ。Cox がそうしていたかは分からないが、「悪用履歴はない」と言えるように設計するなら、そういう構造になる。
    • 対話を始めた側なら、最後まで不参加でいることはできない。どこかの時点で「我々が持っている情報はこの程度で、以前よりは良い」と言わなければならない。
    • 「ない」と言うなら、すでに感染した機器が見つかっている状況で、Cox が知っているかもしれないし知らないかもしれない別の攻撃経路がある、という意味かもしれない。

  • 多くのルーターはファームウェアを手動で更新する必要がある。GL.iNet ルーターには直近6か月で複数のリモートコード実行脆弱性があったので、自分のルーターがハッキングされていないか早めに確認し、可能ならファームウェアを上げたほうがよい。
    一般ユーザーの立場で見えた症状は、インターネット速度の低下、Wi-Fi 信号の途切れや機器の接続失敗、ルーター自体はインターネットに接続されているのに内部管理ページ（192.168.8.1）が応答しないことだった。私の場合、攻撃者は IPRoyal の Pawns アプリをインストールしてルーターをプロキシサーバーにし、収益を得ていたうえ、使用時間や NAS 接続の有無が含まれるシステムログも盗み、リバースシェルも持っていた。対処は、ファームウェア更新、ルーター初期化によるマルウェア除去、SSH の無効化、動的 DNS のようなリモートアクセスの無効化、という順がよい。リモートアクセスが必要なら Cloudflare Tunnel、Zero Trust、GoodCloud、ZeroTier、Tailscale などを検討できるが、どれが適しているかはよく分からない。GL.iNet は最小権限の原則に従っておらず、デフォルトで root としてプロセスを実行し、SSH も root アクセスでデフォルト有効になっているので、避けたほうがよさそうだ。

  • 「悪用された履歴はなかった」というのは、最初からログや監査資料が十分でなかったか、ハッキング後にログが残っていなかったためかもしれない。

    • 記事で見た限り、「未認可リクエストを通るまでリトライする」という特定の攻撃経路は、ログ上では非常に見つけやすい。パス、IP、ステータスコードだけを残す基本的なログポリシーでも十分で、ほとんどの Web サーバーやフレームワークのデフォルトに近い。
    • 「証拠がないことは、不在の証拠ではない」がここには当てはまる。
    • あるいは、嘘をついていたのかもしれない。Cox の立場で考えると、過去に悪用された履歴があったとして、なぜ社外の人間に公開するだろうか？ 実際、何であれ公開する理由はない。

  • どんな認証システムが呼び出しをたまにランダムに通してしまうのか？ 本当に無能に見える。

    • ベンダー API でこういうものを見つけたことがある。現在ユーザープロバイダーをリクエスト単位ではなくシングルトンとして登録していたため、たまに認証済みユーザーに便乗できてしまった。
    • 似たような大きなバグを見たことがある。API がきっかり10分間は未認証リクエストを拒否し、その後きっかり1分間だけ許可し、この周期が延々と繰り返されていた。バックエンドで何が起きていたのか本当に気になる。
    • 私の経験では、こういうことはロードバランサーが原因で起きることがある。たとえば、プール内のサーバーへ正しくルーティングできていない、あるいはサーバー間で設定やパッチレベルが異なる場合だ。
    • リクエストがルーティングされるオリジンサーバーの一部が誤設定されていた可能性もある。
    • API がリバースプロキシの背後にあったなら、キャッシュ問題だった可能性もある。

  • 金は払われたのか？ この人は Cox を事実上救ったし、見つけるのも容易ではないセキュリティインフラの完全掌握を知らせた。
    「正しいこと」をした見返りに何も受け取っていないように見えるが、かなり侮辱的だ。重要な情報を持ってオフィスまで訪ねてきた人を会社がどう見ていたか、本人の自己認識と会社側の認識はかなり違っていただろう。こういう事例は、0day を絶対に報告すべきではない理由をよく示している。

    • Cox なら、自分たちのミスを直してくれた人を訴えないだけでも運がいいほうかもしれない。
    • Sam は非常に有名なセキュリティ研究者なので、年35万ドル以上稼いでいても驚かない。こうした記事は評判向上を通じて相当なお金になる。
    • Cox はバグバウンティを支払わない。

  • まだ残っている疑問は、攻撃者たちがどうやって彼のHTTP トラフィックを捕まえたのかだ。
    一部の CPE には、デバッグ用のクラウド版 Wireshark のような機能がある。Cox の本番ファームウェアイメージにそうした機能が入っているのかは分からない。通常、本番用ファームウェアとテスト用ファームウェアは別なので、本番環境の問題をテストするのはさらに難しくなる。Cox は現場にどのファームウェアバージョンがあるか確認できるはずだが、ISP は特定バージョンと合わないファームウェアを自動アップグレードできるし、これは Cox のモデムなのでファームウェアも持っている可能性が高い。もしデバッグ用ファームウェアだったなら、どうやって載せられ、どうやって残り続けたのかが気になる。

    • Linux で PF_PACKET を使ってソケットを作れば、すべてのインターフェースのトラフィックを横取りできる。低レベルの tcpdump のようなものだと思えばよい。
      80番ポートのすべてのデータを横取りし、HTTP ヘッダーをパースして必要な処理をすれば簡単だ。ただ、なぜ誰かがリクエストを再生したのかはよく分からない。
    • HTTPS ではなく HTTP なら、経路上の誰でも、どんな機器でもリクエストを見ることができる。
    • ISP 提供機器を信用せず使わない、もう一つの理由だ。ISP のリモート管理などお断りだ。

  • Wi-Fi 機能付きの ISP 提供ケーブルモデムを歓迎すべきではなく、LAN 内のエンドポイントとサービスのセキュリティをきちんと確保すべき理由の一つだ。少なくともモデム/ISP 区間では TLS と DNS over TLS が必要だ。
    私は単にブリッジモードにして Wi-Fi を切り、すべてのネットワーク機能を自分の機器に任せている。最後に ISP から借りたモデムは、ISP が10年近くファームウェア更新をしていなかったが、そのおかげで非常に安定してはいた。

    • 反論もある。顧客が100万人を超える ISP には、設備投資コストを下げるためにホームゲートウェイを「永遠に」アップグレードする動機がある。
      私が働いている Free はフランスの ISP で、Iliad としてイタリアにもホームゲートウェイを提供しているが、2011年に発売した機器もいまだに更新している。最新の Linux 6.4 が動作し、airtime QoS のような現代的機能やモバイルアプリ更新、複数のソフトウェア機能も提供されている。
    • ルーターは地球上で最も多く悪用されるIoT 機器であり、エンドユーザーがパッチを当てないためにファームウェア脆弱性が何年も残ることが多い。ISP がルーターにパッチを押し込み、パッチ不能な機器を回収できるなら、所有権が ISP にある点も含めて、サイバーセキュリティには純利益だ。
    • 私もブリッジモードにして Wi-Fi を切っている。たまたまルーター機能とアクセスポイント機能のない単純なモデムを設置してもらったのだが、そういう単一目的の機器がまだあるとは知らなかった。
      比較的まともなルーターを買って OpenWrt を入れ、ISP 機器経由でネットワークにブリッジ接続したところ、うまく動いている。今では LAN 内でも HTTPS を使っている。
    • ISP に自分のルーターを使わせてくれないなら、別の ISP に乗り換えると言った。