ASUSのプリインストール済みドライバーソフトウェアにおけるワンクリックRCE脆弱性

 (mrbruh.com)
2 ポイント 投稿者 GN⁺ 2025-05-12 | 1件のコメント | WhatsAppで共有
  • Windowsログイン直後にインストールされうるASUS DriverHubは、Webサイトとローカルサービスを接続する方式のため、ユーザーが特定のWebサイトを訪問するだけで管理者権限でのコード実行に至る可能性があった
  • DriverHubはGUIなしでバックグラウンド動作し、driverhub.asus.comが127.0.0.1:53000のローカルHTTP/WebSocketサービスにリクエストを送る構造だったが、Originチェックがdriverhub.asus.com.*形式のドメインを許可していた
  • UpdateAppエンドポイントはURLに.asus.com文字列さえ含まれていればファイルをダウンロードし、ASUS署名済み実行ファイルは管理者権限で実行する一方、署名検証に失敗したファイルは削除しなかった
  • 最終的なエクスプロイトは、署名されていないcalc.exe、細工されたAsusSetup.ini、署名済みのAsusSetup.exeを順番にダウンロードさせた後、SilentInstallRun=calc.exeで管理者権限RCEを達成した
  • ASUSは2025年4月に修正版の配布を確認し、2025年5月9日にCVE-2025-3462とCVE-2025-3463が公開された。証明書透明性ログの基準では、公開前に活発な悪用の痕跡は見られなかった

Webサイトと連携したDriverHubローカルRPC

  • ASUSマザーボード購入後、Windowsログイン直後にASUS DriverHubのインストール完了のため管理者権限を求める通知が表示される
  • DriverHubは独立したGUIではなくバックグラウンドプロセスとして動作し、driverhub.asus.comで必要なドライバーや更新対象を案内する
  • Webサイトはローカルで実行中のDriverHubプロセスとRPCで通信する
    • ローカルサービスは127.0.0.1の固定ポート53000で動作する
    • WebサイトまたはサービスがこのローカルポートへAPIリクエストを送る構造である
  • この構造でRPC保護が不十分だと、攻撃者に悪意あるアプリケーションのインストールへ悪用される可能性がある

緩いOriginチェックの回避

  • DriverHubはあらゆるWebサイトのリクエストを受け付けるわけではなく、Originヘッダーがdriverhub.asus.comのリクエストに応答するよう設計されていた
  • 問題は、チェックが厳密な比較ではなく文字列包含またはワイルドカードに近い方式だった点にある
    • origin == driverhub.asus.comのような直接比較ではなかった
    • driverhub.asus.com.mrbruh.comをOriginに設定するとリクエストが許可された
  • 攻撃者はこの挙動を利用し、driverhub.asus.com.*形式のドメインからローカルDriverHub RPCへアクセスできた

露出していたRPCエンドポイント

  • WebサイトのJavaScriptと実行ファイルの逆コンパイルにより、複数のRPCエンドポイントが確認された
  • 主なエンドポイントは次のとおり
    • Initialize: ソフトウェアのインストール有無と基本的なインストール情報を返す
    • DeviceInfo: インストール済みASUSソフトウェア、インストール済み.sysドライバー、ハードウェア構成要素、MACアドレスを返す
    • Reboot: 確認なしに対象デバイスを即座に再起動する
    • Log: DriverHubログ全体の圧縮版を返す
    • InstallApp: アプリまたはドライバーIDによってインストールを実行し、アプリIDはDriverHubインストーラーが提供するXMLファイルにハードコードされている
    • UpdateApp: 指定されたファイルURLをダウンロードして実行し、DriverHubを自己更新する

UpdateAppがRCE条件を生んだ仕組み

  • UpdateAppリクエストは次の形で動作する
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • UpdateAppで観察された挙動は、RCEチェーンに必要な条件を複数提供していた
    • Urlパラメータには.asus.com文字列が含まれている必要があったが、example.com/payload.exe?foo=.asus.comのような形式も許可された
    • ファイルはURL末尾で指定されたファイル名で保存される
    • 拡張子に関係なくファイルをダウンロードできる
    • ファイルがASUS署名済み実行ファイルなら管理者権限で自動実行される
    • ASUSが署名した実行ファイルであれば、DriverHubインストーラーでなくても実行される
    • ダウンロードしたファイルが署名チェックに失敗しても削除されない
  • 当初は署名検証のためRCEは難しく見えたが、署名失敗ファイルが残る挙動とASUS署名済み実行ファイルのインストール動作が組み合わさり、回避経路が生まれた

AsusSetup.iniを利用したエクスプロイトチェーン

  • ASUS WiFiドライバーパッケージにはAsusSetup.exe、AsusSetup.ini、SilentInstall.cmdが含まれていた
  • AsusSetup.exeは実行時にAsusSetup.iniからドライバーメタデータを読み取る
  • AsusSetup.exeを-sフラグ付きで実行すると、GUIなしのサイレントインストールを行い、AsusSetup.iniのSilentInstallRunで指定された項目を実行する
    • DriverHubはサイレントインストールのため-sフラグを使用する
    • 元のINIファイルは自動無人インストール用のcmdスクリプトを指定していた
    • SilentInstallRunには別の実行ファイルも指定できた

  • 完成した攻撃手順

    • ユーザーがdriverhub.asus.com.*形式のドメインを持つWebサイトを訪問する
    • サイトがUpdateAppでPoC実行ファイルcalc.exeを要求する
    • calc.exeはダウンロードされるが署名チェックに失敗し、実行されない
    • ファイルは削除されず残る
    • サイトがUpdateAppで細工されたAsusSetup.iniを要求する
    • このファイルもダウンロードされるが実行はされない
    [InstallInfo]
SilentInstallPath=.\\
SilentInstallRun=calc.exe
    • サイトがUpdateAppでASUS署名済みバイナリAsusSetup.exeを要求する
    • AsusSetup.exeはダウンロード後、管理者権限で実行される
    • DriverHubが-sで実行するため、AsusSetup.iniを読み取る
    • SilentInstallRun=calc.exeに従い、calc.exeが管理者権限で実行される

報告からCVE公開まで

  • 脆弱性対応のタイムラインは次のとおり
    • 2025-04-07: 初期脆弱性を発見
    • 2025-04-08: RCEへの拡大を確認
    • 2025-04-08: ASUSへ脆弱性を報告
    • 2025-04-09: ASUSの自動応答を受信
    • 2025-04-17: 追跡連絡後、ASUSがパッチ完了と検証用ビルドを送付
    • 2025-04-18: ASUSが修正版の配布を確認
    • 2025-05-09: CVE-2025-3462 スコア8.4とCVE-2025-3463 スコア9.4が公開

悪用可能性と観察された痕跡

  • 報告直後、VPS上でcertificate transparencyの更新を追跡するスクリプトを実行し、driverhub.asus.com.*ドメインの登録有無を確認した
  • 他の証明書透明性ログサイト基準では、ドメインとサブドメインは通常1か月以内にログへ現れていた
  • 1か月後に確認した結果、正規表現に一致するWebサイトはテストドメインだけだった
  • この基準では、報告前に活発に悪用されていた可能性は低かった

ASUSの対応と残る問題

  • ASUSはバグバウンティを提供しておらず、代わりにhall of fameへ名前を掲載すると回答した
  • その後、別のセキュリティ研究者leonjzaが同じOriginチェックの問題を2025年2月にすでに報告しており、ASUSは今回の修正時点までにこれを直していたことが判明した
    • ASUSはこの事実を別途通知しなかった
    • cve.orgページでは当該研究者のみがクレジットに掲載され、追加クレジットは反映しないと回答した
  • ASUSのSecurity Advisory formで脆弱性レポートを提出する際、Amazon CloudFrontが添付したPoCを悪性リクエストとして検知し、提出を遮断した
    • 一部のPoCコードを削除し、代わりに録画映像のリンクを提出しなければならなかった
  • DriverHubでは各推奨ドライバーを個別にインストールせず「Install All」を押すと、ArmouryCrate、ASUSのカスタムCPU-Z、Norton360、WinRARも一緒にインストールされる
  • ASUSのCVE説明はRCEの範囲と影響を狭く表現している
    • 説明には「motherboardsに限定され、laptops, desktop computersには影響しない」という趣旨の文言があった
    • 実際にはDriverHubがインストールされたdesktop/laptopを含むすべてのコンピューターに影響する
    • 任意またはリモートコード実行ではなく、「untrusted sourcesがsystem behaviourに影響を与える可能性がある」といった表現になっていた

関連記事

1件のコメント

 
GN⁺ 2025-05-12
Hacker News の意見

  • 責任ある開示とその結果は、人類にとって災厄に近いものだった。企業が顧客のセキュリティをもっと真剣に受け止めるには、はるかに頻繁に、はるかに大きな痛みを感じる必要がある
    1か月の猶予を与え、解決策までお膳立てしてやれば、単なるバックログのチケット1件になるだけだ。セキュリティ問題が起きるたびにオンラインで十分大きなニュースになり、CEOまで関与して、数か月ではなく数時間以内に解決策を見つけなければならない状況になれば、はるかに先手を打つようになるだろう。もちろん最終ユーザーが最も大きな被害を受けるだろうが、ASUSを買った時点ですでに苦しんでいるとも言える

    • 今回のASUSの対応速度はかなりよく、ここに大きな問題は見当たらない。ASUSはバグを否定せず、ソフトウェアのリバースエンジニアリングを理由に訴えると脅すこともなく、迅速にパッチを出した
      責任ある開示以前の時代なら、このプロセスには数か月かかり、警察まで関わっていた可能性が高い。一般ユーザーは脆弱性に関心がなく、3年間アップデートが止まっている携帯電話で金融取引をしている。ニュースでCVEを流し続ければ、「どの会社もひどい」という話にうんざりし、実際の脅威が来ても麻痺してしまうだろう
      EUは別の解決策を進めている。新しいサイバーセキュリティ規則では、既知の脆弱性がある製品を店頭で販売できなくする。ASUSが失敗を続ければ、マザーボードは不良在庫となり、店舗もASUSのハードウェアを売りたがらなくなる。コンピューターハードウェアだけでなく、スマート冷蔵庫や洗濯機も対象になる。食器洗い機の脆弱性を見つけた場合、メーカーがファームウェア更新手段を入れていなければ、業界に数百万ドル規模の使えない在庫を生み出すことにもなり得る
    • 「責任ある開示」という名前は皮肉だ。実際には、ほとんど完全に無責任な方式に近いからだ
      大多数の企業は開示への対応がひどい。期限内、たとえば1週間以内に修正せず、功績の表示もまともにせず、ユーザーにも知らせず、失敗から学ぶこともない。無責任に遅延された限定開示は、そうした行動を助長する
      本当に責任ある方法とは、即時に、完全に、公に明らかにすることだ。必要なら自分を守るため匿名で行ってもよい。影響を受ける企業が繰り返し適切に対応すると証明した後に初めて、たとえば5営業日程度のごく短い事前通知の権利を得られる
      このような無責任な遅延限定開示が「責任ある開示」と呼ばれていること自体が、ニュースピークの一例だ
    • 核心は責任の法制化の問題だ。自動車メーカーはリコールと修理を命じられるが、ソフトウェア・ハードウェア企業が受ける圧力はあまりに弱い
      顧客は、たとえば未修正のCVEがある故障した機器について、全額返金を受けられるべきだ
    • CGPGreyを引用すれば、最初に思いつく解決策はたいていひどく、効果がない
      良い安全・セキュリティ文化は、参加者が問題を隠さないよう促す。企業は貪欲な存在なので、セキュリティ上のミスを隠すためには何でもするだろう
      1か月以内に修正できる合法的で修正可能な問題を全員に公開すれば、悪用される可能性も大きく高まる
    • こういう事業アイデアもあり得る。すでにあるかもしれないが、開示の仲介・集約サービスを作るというものだ
      情報提供者のプライバシーを保護し、セキュリティ脆弱性を検証し、公開するすべての脆弱性が実際に悪用可能かを確認する。定期的に公開し、企業には自社に影響する公開内容を事前に受け取れる「早期フィード」の購読料を請求する。その資金で情報提供者に報酬を支払い、運営費を賄い、一部を利益として残す
      いわば企業に対してやや敵対的なバグバウンティ市場だ。これが合法なのか、それとも恐喝と見なされるのか気になる

  • ASUSにバグバウンティがあるのか尋ねたところ、ないと答え、代わりに「殿堂」に名前を載せると言われたくだりが苦々しい
    ASUSは小さなスタートアップだから、バウンティを払う資本がないのだろう、という皮肉だ

    • Ciscoのような小さな会社でも理解できる話だ。Ciscoも長年、買収した多数のオンラインサービスについて同じようなことをしてきた
      Ciscoはさらにセキュリティアドバイザリページまで忘れてしまい、どんなクレジットも今では虚空に消えてしまった
    • バグバウンティがなければ、エクスプロイトは闇市場に行くか、あるいは全面公開に向かうことになる
    • こういう対応を見ると、二度とASUS製品を買いたくなくなる
    • 「Asusは小さなスタートアップ」という表現がどこから出てきたのか分からない。Asusは少なくとも90年代からマザーボードとPC部品を作ってきた

  • 驚きはない。ASUSのソフトウェアはひどく、セキュリティ面でも予防が不十分な常習問題企業に近い
    https://www.techspot.com/news/95425-years-gigabyte-asus-moth...
    https://www.reddit.com/r/ASUS/comments/tg3u2n/removing_bloat...
    https://www.reddit.com/r/ASUS/comments/ojsq80/nahimic_servic...

  • 証明書透明性ログを見たところ、driverhub.asus.com.* に一致するドメインは自己テスト用ドメインだけだったため、報告前には積極的に悪用されていなかった可能性が高いと判断した部分は、ワイルドカード証明書がない場合にのみ成り立つ
    ワイルドカードを持つ誰かであれば、証明書透明性に現れないままこれを悪用できたはず

    • ワイルドカード証明書は単一ラベルの階層にしか適用されない。*.example.com. は test.test.example.com. には使えず、test.example.com. には使える
      誰かが *.asus.com.example.com. のワイルドカードを発行してもらっていれば、driverhub.asus.com.example.com. 配下でWebサーバーを立て、有効に見せかけることができた
    • 良いアイデアだったので今確認してみたところ、ワイルドカードレコードには怪しいものがなかったことを確認した
    • ワイルドカード証明書の死角であることは確か。攻撃者が .example.com のワイルドカード証明書を持っていたなら、driverhub.asus.com. ドメインとして証明書透明性ログに具体的に現れないまま悪用できた
      そのため、証明書透明性ログの監視だけでは、この種のサブドメイン乗っ取り脆弱性を検出するには十分ではない
    • さらに、自己署名証明書でも動作したのか気になる。そうした証明書は透明性ログに入らない
      それに、そもそもHTTPSである必要があったのかも疑問

  • 「僕のオンボードWiFiはいまだに動かず、外付けUSB WiFiアダプターを買う羽目になった。DriverHubありがとう」という結末とは、この一連の流れは文字通り骨折り損だった

    • ブログ記事自体は良かった
    • 最新のWiFiドライバーは動作しないので、以前のバージョンを使う必要がある

  • ASUSのセキュリティ報告フォームに脆弱性レポートを提出した際、Amazon CloudFrontが添付されたPoCを悪意あるリクエストと判断してブロックしたという部分は、Webアプリケーションファイアウォールがアンチパターンだという警告のようだ: https://thedailywtf.com/articles/Injection_Rejection

  • 「ASUSは小さなスタートアップだから理解できる」とは、時価総額がわずか150億ドルの小さなスタートアップという話である
    本当に理解しがたいのは、ひどい製品だけでなく、顧客のために大変な仕事をした研究者にまでこのように接する点だ
    こうしたことをしても無視されたり、けなされたりする研究者たちが気の毒だ。あまりに不公平だ
    できることはASUS製品を買わないことだけだ

  • ASUSにバグバウンティがあるか尋ねたところ、ASUSはないが代わりに「Hall of Fame」に名前を載せると答えた。ASUSは小さなスタートアップなので、バウンティを払う資本がないのだろうから理解できる、という皮肉である
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • あるいは sarcasm.com かもしれない ;)

  • お約束のScumbag Asus動画リンク
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    「ASUSは先週、今週オフィスに来て問題について『オープンな対話』をしたいとメールしてきた。私たちはいいですよと答えたが、対話は録画する必要があると返した。何しろ彼らはオープンな対話を望むと言っていたのだから。その後5日間、返事はなかった。つまりASUSにはこれを正す機会があった。私たちはその機会を与えるために動画の公開を保留していた。だが『いいですよ、ただし約束した内容を記録に残すため撮影します』と言った途端、沈黙が返ってきた」

    • それでも「基本的にはまともな」マザーボードメーカーは存在するのか？ それとも主要メーカーごとに似たような話があるのか？
      近く新しいPCを組もうとしている友人のために聞いている
    • これは腹が立つのだが、ASUS側を最もそれらしく強く擁護するとしたら、どんな主張になるのか気になる
      現実に合っているのはおそらくこちらだろう。利益を追っており、それでも通ってしまうので、記録に残って悪く見える理由はなく、その時間でマーケティングでもしたほうがましだと考えているのだ

  • バグバウンティなしはあり得ない。今後ASUS製品は買わない

    • 「小さなスタートアップ」だからなのだろう
    • Asusのソフトウェアとカスタマーサポートはひどく、ずっとそうだった