ASUSのプリインストール済みドライバーソフトウェアでワンクリックRCE脆弱性が発見

• ASUSのDriverHubソフトウェアでワンクリックのリモートコード実行（RCE）脆弱性が発見された
• ローカルでのorigin検証の甘さにより、悪意あるWebサイトがRPC経由で管理者権限での実行を可能にしていた
• UpdateAppエンドポイントを悪用すると、ASUS署名済み実行ファイルと細工されたiniファイルの組み合わせで悪性コードを実行できた
• この脆弱性はCVE-2025-3462、CVE-2025-3463として公開され、ASUSは迅速にパッチを配布した
• 脆弱性報告時点で実際の悪用事例はないことが確認され、ASUSはバグバウンティの代わりに殿堂入りで報いた

---

Introduction

• 新しいPC部品の購入に関する話から始まる
• ASUSマザーボード購入時、BIOSの自動ソフトウェアインストールオプションがデフォルトで有効になっていた
• 誤ってオプションを無効にしなかったため、Windowsログイン後にDriverHubのインストール権限要求を受けた
• WiFiドライバーが必要だったこともあり、興味本位でDriverHubをインストールした

DriverHub

• DriverHubはGUIなしで動作するバックグラウンドプロセスである
• driverhub.asus.comと通信し、インストールや更新が必要なドライバー一覧を知らせる
• ローカルで**HTTP API（ポート53000）**をRPCとして提供する
• WebサイトがこのローカルサービスにAPIリクエストを送り、直接ドライバー管理を行える
• セキュリティが不十分だと攻撃者が任意のリクエストを送れることを認識した

Finding the Vulnerability

• WebサイトがDriverHubバックエンドに任意のRPCリクエストを送れるか実験した
• Originが“driverhub.asus.com”のときだけ応答するよう設計されていた
• Originチェックがorigin.includes("driverhub.asus.com")のようなワイルドカードマッチで行われているか確認した
• Originを“driverhub.asus.com.mrbruh.com”に変更するとリクエストが許可されることを発見した
• この方法により、攻撃者が悪意あるサイトからRPC呼び出しを行える深刻なリスクであることを確認した

The Extent of the Damage

• リバースエンジニアリングとJavaScript分析を通じて、バックグラウンドで利用可能なAPIエンドポイント一覧を把握した
• 主なエンドポイント:
  • Initialize: インストール状態と情報を返す
  • DeviceInfo: インストール済みのASUSソフトウェア／ドライバー／ハードウェア／MACアドレスを返す
  • Reboot: 即時に再起動を実行する
  • Log: ログファイルの一式を返す
  • InstallApp: 指定したIDのアプリまたはドライバーをインストールする
  • UpdateApp: 指定URLの実行ファイルをダウンロード後に実行する（ASUS署名済みなら自動実行）
• 特にUpdateAppが悪用可能である点に注目した

Achieving RCE

• UpdateAppエンドポイントを詳細に分析した
• “Url”パラメータには.asus.comを含む条件があるものの、回避の可能性が存在し、ファイル名はURL末尾に従う
• ASUS署名済み実行ファイルのみ自動実行されるが、未署名ファイルもダウンロード後に削除されず残る
• 署名検証通過後、実行直前にファイルを差し替えるタイミング攻撃の可能性を検討したが、実用的ではなかった
• ASUS WiFiドライバーパッケージの構造を分析する中で、AsusSetup.iniのSilentInstallRunプロパティが任意コマンド実行に使えることを把握した
• 最終的な攻撃チェーン:
  1. 攻撃者がdriverhub.asus.com. * サブドメインのWebサイトへ誘導する
  2. サイトが悪意あるcalc.exeをUpdateAppで要求する（ダウンロードのみで実行されない）
  3. カスタムAsusSetup.iniを要求する（SilentInstallRun=calc.exeを指定、これも実行されない）
  4. 署名済みのAsusSetup.exeを要求する（管理者権限で自動実行され、“-s”フラグでiniを読み込みcalc.exeを実行する）
• 結果としてワンクリックでリモートから管理者権限の任意コード実行（RCE）が発生した

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: 最初の脆弱性を発見
• 08/04/2025: RCEの実証と脆弱性報告を実施
• 09/04/2025: ASUSから自動返信を受信
• 17/04/2025: パッチ配布およびパッチ済みビルドを受領
• 18/04/2025: パッチが本番反映されたことを確認
• 09/05/2025: **CVE-2025-3462（8.4点）、CVE-2025-3463（9.4点）**が公開

Assessing the Damage

• 脆弱性報告直後にcertificate transparency追跡スクリプトを作成した
• driverhub.asus.com.* サブドメインの証明書発行履歴を監視した
• 1か月の監視結果では、フィルタにかかったサイトは自身のテスト以外に存在しなかった
• 事前の悪用の兆候はないことが確認された

Bug Bounty

• ASUSにバグバウンティ支払いの有無を問い合わせたが、拒否された
• 代わりに殿堂入り（hall of fame）掲載によって報われた
• ASUSが大企業であるにもかかわらず、バウンティ方針が未整備であるとの説明が加えられた

Fun Notes

• ASUSのSecurity Advisoryフォーム送信時、PoCがAmazon CloudFrontによって悪意あるリクエストとして遮断された
• DriverHubで“Install All”をクリックすると、その他のソフトウェア（Norton360、WinRARなど）も強制インストールされた
• CVEの説明が事実と異なる曖昧さを持ち、「デスクトップ／ノートPCには影響しない」と誤解されるおそれがある（実際にはDriverHubがインストールされたすべての機器が影響を受ける）
• WiFiはいまも動作せず、外付けUSB WiFiアダプターを購入する必要があった
• 問い合わせ先としてSignal: paul19.84、メール contact [at] mrbruh.com が案内されている

[GN⁺]

Hacker Newsの意見

• Responsible Disclosureの結果が人類にとって災厄のように感じられる。企業が顧客のセキュリティを深刻に受け止めるには、もっと頻繁に、もっと大きな痛みを味わう必要がある。問題を見つけて1か月で直せるよう解決策を伝えても、企業にとっては単なるバックログのチケット1枚にすぎない。しかしオンラインで話題になってCEOまで対応せざるを得なくなれば、数時間で対処法を見つけるだろう。もちろん最終的に最も大きな被害を受けるのはユーザーだが、どうせASUSを買う時点で彼らはすでに苦しんでいる。
  • ASUSの今回の対応は比較的速いほうだ。問題を否定せず、リバースエンジニアリングした人物を訴えもせず、すぐにパッチも出した。以前ならこうした問題に何か月もかかったり、警察が介入していた可能性すらある。一般の人は脆弱性など気にもしていない。3年間アップデートされていないスマホで金融取引をしているような世界だからだ。CVEの話題でメディアを埋め尽くしても、皆がただ感覚を麻痺させるだけだ。ヨーロッパでは新しい規制により、既知の脆弱性がある製品は販売自体が禁止される。だからASUSがこの調子を続ければ、マザーボードの在庫が倉庫に積み上がり、流通業者も売りたがらなくなるだろう。これは家電にも当てはまる。たとえば食洗機に脆弱性があれば、その業界も大きな打撃を受けうる。
  • "Responsible" Disclosureという名称自体が皮肉にも完全に無責任な行為だ。大半の企業は1週間以内にパッチも出さず、功績も認めず、ユーザーへの通知もせず、失敗から学びもしない。遅く限定的な公開は、むしろそうした行動を助長している。本当に責任ある行動とは、即時に、完全に、そして公に公開することだ。そして企業が適切に対応するという信頼が積み上がっているなら、5営業日程度の事前通知を与えることを検討してもよい。遅く部分的な公開を"responsible disclosure"と呼ぶこと自体、言葉遊びにすぎない。
  • 問題の根源は製品責任に関する立法の欠如だ。自動車メーカーにはリコール義務があるが、ソフトウェア／ハードウェア企業への圧力はあまりにも弱い。脆弱性（CVE）が修正されていない製品について、顧客は全額返金を受けられるべきだと思う。
  • CGPGreyの言葉を借りれば、最初に思いつく解決策の大半はろくでもなく、効果もない。良いセキュリティ文化は、内部問題を隠さないことを奨励すべきだ。企業は強欲なので、セキュリティ問題をすべて隠してしまう。発見次第ただちに公開すれば、1か月あれば十分に修正できる問題まで全員の目にさらされ、悪用可能性が大きく高まる。
  • ビジネスアイデアがある。すでに存在するかもしれないが、公開・仲介プラットフォームとして、報告者のプライバシー保護、脆弱性の実際の悪用可能性の検証、定められたスケジュールごとの公開発表、そして企業が自社に影響する事前フィードを購読して料金を支払い、その収益を報告者への報奨、運営費、利益分配に充てるモデルだ。これはバグバウンティのマーケットプレイスに似ているが、企業側から見るとやや敵対的だ。これが合法なのか、恐喝と見なされるのか気になる。
  • 繰り返しになるが、他の産業と同じように製品の欠陥に対する法的責任が必要だ。大半の人は安さ以外の理由で不良品を許容しないのだから、ソフトウェアだけが例外である理由はない。
  • 脆弱性を翌日にそのまま公開してしまうのが、本当の意味での動機付けになる。恥をかくことも次のセキュリティ改善に役立つ。
  • 「人類にとって災厄」というような誇張は、論点を壊す典型例だ。
• ASUSにバグバウンティはあるのかと尋ねたところ、その代わりに自分の名前をHall of Fameに載せると言われた。ASUSがまるで小さなスタートアップで、バウンティを払う資本がないかのような冗談に聞こえて、苦い気分になる。
  • Ciscoのような小さな会社も同じように報酬なしで名前を載せるだけだ。Ciscoはセキュリティ告知ページの掲載自体を忘れてしまい、認められる機会すら消えた。
  • バグバウンティがないなら、エクスプロイトをブラックマーケットに流すか、あるいは完全公開するかの二択になってしまう。
  • こういう状況を見ると、ASUS製品はもう二度と買いたくなくなる。
• ASUSはソフトウェア品質も良くなく、セキュリティ面でも繰り返し問題を起こしている企業だ。以前にもマザーボードでUEFIマルウェアの問題があり、不要なソフトウェアがプリインストールされていて削除も面倒だ。苦情の事例は多く、参考になる。
  • こうしたことは今回が初めてではない。以前にも似た事例があり、自分の昔のブログにも記録を残してある。
• 自分たちのテスト用ドメイン（driverhub.asus.com.*）だけが条件に当てはまるので悪用されたことはない、と言っていたが、これは誰かがdriverhubのサブドメインだけを別途登録していない場合に限る。ワイルドカードを使えば証明書透明性ログに現れず、悪用できる可能性がある。
  • ワイルドカード証明書は1階層下のサブドメインしかカバーしない。たとえば *.example.com は test.example.com には有効だが、test.test.example.com には有効ではない。もし誰かが *.asus.com.example.com のワイルドカードを使っていれば、driverhub.asus.com.example.com は有効になり得る。
  • 良い指摘なので、すぐ確認してみた。現時点でワイルドカード証明書による不審なものは見当たらない。
  • ワイルドカード証明書の盲点という指摘はその通りだ。攻撃者が .example.com のワイルドカード証明書を持っていれば、実際の driverhub.asus.com ではない場所からでも悪用できた可能性がある。この点のため、CTログの監視だけではこの種のサブドメイン乗っ取り脆弱性を完全には捉えられない。
• ASUSにバグバウンティについて尋ねたら、"私たちは小さなスタートアップだからバウンティはなく、Hall of Fameに名前を載せるよ"と返されたくだりが印象的だ。実際には時価総額150億ドル超の巨大企業だが。
  • 皮肉の練習用に sarcasm.com を勧める。
• オンボードWi‑Fiが使えなかったのでUSBの外付けWi‑Fiを使ったが、DriverHubのせいで何の助けにもならなかった。ソリューションだと言っておきながら失望した。
  • ブログ記事自体は面白く読めた。
  • 最新のWi‑Fiドライバーが動作せず、古いバージョンを使わざるを得なかった。
• ASUSは時価総額150億ドルに達する大企業でありながら、まともな報酬も出さず、顧客や研究者の労力も軽視しているように見える。こうした扱いを見ると研究者がどれほどやるせないか共感する。結論としては、ASUS製品を買わないのが最善だ。
• バグレポート提出時、PoCファイルがAmazon CloudFrontに悪意あるリクエストと認識され、提出自体がブロックされた。この種のWAF（Web Application Firewall）は、むしろ悪いパターンや事例だ。
• オンボードWi‑Fiの問題に関する不満には共感する。実際、チップセットの型番だけ確認して station-drivers のような場所から別途ダウンロードすれば数秒で済む。この手の煩わしさのせいでASUSは好きになれない。OSと直接相互作用するBIOSオプションは特に嫌いだ。
• ASUS製品自体は好きだが、UEFIで自動インストールされるサポートアプリは必ず無効化している。以前は完全版のROG Armory Crateがインストールされ、削除が面倒だった。ASUSがIntelからNUC事業を引き継いだ後もBIOSアップデートは維持されたが、MyASUS のようなインストールアプリがデフォルトで追加された。幸い無効化オプションがあり、Intel NUC BIOSから更新した場合はデフォルトでオフになっているようだ。