自身のモデムがハッキングされたことを契機に、モデムを運用しているプロバイダのシステムに脆弱(ぜいじゃく)性があることを突き止めたセキュリティエンジニアのサム・カリー氏が、「どのように突き止めたのか」についてブログに投稿しました。

Hacking Millions of Modems (and Investigating Who Hacked My Modem)

https://samcurry.net/hacking-millions-of-modems



事の発端は2年前で、カリー氏は自宅のPCからAWSのインスタンスにアクセスした際に「謎のIPアドレスから同じリクエストがリプレイされる」という奇妙な現象に遭遇しました。下のログファイルに残されている記録のうち、「98.161.24.100」はカリー氏のPCのIPアドレスですが、「159.65.76.209」という謎のIPアドレスから同じリクエストが飛んでいます。



カリー氏は念のためPCではなくスマートフォンからアクセスしてみたり、AWSではなくGCPにインスタンスを立てて検証してみたりしましたが、同様の現象が発生しました。



カリー氏が「159.65.76.209」について調べると、このIPではメールサーバーのほか、パラグアイのセキュリティ企業「ISG Latam」をターゲットにしたフィッシングサイトがホストされていた形跡があることが判明。



またURLスキャンの結果を見ても、当該IPアドレスがBeEFによるフィッシングに使用されていたのは明らかでした。



当該IPアドレスからの悪意のある活動の記録は3年以上続いており、ISG LatamのほかにもAdidasを対象にした攻撃や、カリー氏が受けているモデムのハッキングなどさまざまな攻撃が同じIPから行われていました。攻撃者の意図は不明なものの、カリー氏はモデムの電源を切り、モデムの所有者であるプロバイダへ交換するよう要求しました。



カリー氏は古いモデムを手元に残して攻撃者の活動を研究したかったものの、プロバイダ側の規則は「新しいモデムを渡す際は古いモデムを返却する」となっており、古いモデムは回収されてしまいました。新しいモデムをセットアップするとトラフィックのリプレイが停止したため、カリー氏は「問題は修正された」として攻撃の研究を辞めました。

2024年初頭にカリー氏はセキュリティエンジニアの友人と話す機会があり、その際にモデムの事件について話すとセキュリティエンジニアの友人たちの興味を強くひきました。カリー氏よりもずっと多くのマルウェアについて調査してきた友人たちはカリー氏がメールサーバーだと思っていたドメインに注目しました。

友人たちはメールサーバーらしきドメインの形式が他のマルウェアで使用されているドメインの形式と同じであり、攻撃者がマルウェアに指示を出すC＆Cサーバーのアドレスをローテーションするためのものであると推測。下図のように、マルウェアはドメインを解決してC＆CサーバーのIPアドレスを入手し、攻撃者から指示を受け取るというわけです。



カリー氏はかつてのモデムに対して攻撃者がどのように侵入したのかを調べることにしました。Googleで検索してもモデムに脆弱性は発見されておらず、もし脆弱性があったとすると攻撃者は数年にわたって隠し通すことに成功していることになります。

しばらくしてカリー氏は別の友人の引っ越しを手伝った際に、カリー氏と同じプロバイダのモデムを移行する作業を手伝いました。モデムを光ファイバーに接続した後、プロバイダのサポートに連絡するとWi-Fiパスワードの変更や接続されているデバイスの表示などを含め、デバイス設定をプロバイダがリモートで操作できることが判明。

プロバイダのリモートサポートは2004年に実装されたTR-069というプロトコルによって実現されていました。TR-069を使用するとプロバイダはポート7547を使用して自社ネットワーク内のモデムを管理できるようになります。プロトコル自体もセキュリティ研究の対象とされることがありましたが、カリー氏はプロバイダのサポートがモデムを管理するために使用していたツールに興味を持ちました。



カリー氏はまずCox Businessポータルを調査しました。Cox Businessポータルにはデバイスをリモート管理したり、ファイアウォールルールを設定したり、ネットワークトラフィックを監視したりするための機能が存在しています。カリー氏はアカウントを持っておらずログインすることはできませんが、ページのJavaScriptを解析することでAPIエンドポイントを見つけ出しました。



カリー氏はAPIの応答から内部で使用されているフレームワークが「Spring」であることを突き止め、Springで外部からアプリケーションを操作するのに使用されるアクチュエータライブラリのURLを探すことにしました。そしてさまざまなURLを推測して応答を確認する手法でアクチュエータらしきURLを突き止めることに成功。



ただし、ページにアクセスするとJavaScriptなどの静的リソースが読み込まれず機能しなかったとのこと。カリー氏は外部からの静的リソースのリクエストを止めるプロキシルールがあると突き止め、静的リソースの末尾に「％2f」とURLエンコードされたシンボルを追記することでルールを回避してロードすることに成功し、APIエンドポイントの一覧を表示することができました。



APIは認証が必要なものと不要なものが半分ずつ程度の割合で存在しており、重要なAPIは保護されているかのように見えましたが、カリー氏は同じリクエストを複数回行うことで認証が必要なAPIであっても認証せずにリクエストを通すことが可能であることを発見。実際にプロバイダと契約している顧客プロファイルを「FBI」で検索するとFBIのデータがヒットしました。



カリー氏は調査を進め、「名前を元にアカウントを検索して個人情報を取得する」「アカウントに接続されているハードウェアのMACアドレスを取得する」「API経由でMACアドレスに対してコマンドを実行できる」ことを実証。ただし、パスワードの更新などハードウェアを変更するコマンドについては「encryptedValue」という別のパラメーターを設定する必要がありました。



カリー氏はJavaScriptのコードを解読し、下記の2つの関数で「encryptedValue」が生成されていることを確認。下記2つの関数はともに実行時にのみ存在する変数を受け取る仕組みのため、カリー氏は実際に使用されている場所はないかを探しました。



そしてカリー氏はアカウント作成画面の4桁のPINコードが上記の2つの関数を使用して暗号化されていることを発見。



カリー氏は関数が呼び出されている場所にブレークポイントを設定することで、変数の状況を正しくした上でコンソールから関数を実行して任意のデータの暗号化・復号を行えるようになりました。



カリー氏は実際に自分の使用しているモデムをターゲットに、Wi-FiのSSID名を「Curry」に変更するようにAPIリクエストを送信し、実際に自分のモデムの設定が変更されていることを確認。同様の手順で同じプロバイダの何百万台ものモデムを自由に編集できてしまうことが明らかになりました。



カリー氏は2024年3月4日にプロバイダに今回の脆弱性を報告し、翌日の2024年3月5日には脆弱性が修正されて今回の手法は機能しなくなりました。なお、カリー氏が脆弱性を発見したAPI関連サービスは、カリー氏がモデムをハッキングされた出来事よりもあとの2023年にリリースされたものであるため、当該モデムには別の脆弱性の存在が懸念されます。