By Jay Turla (Principal Security Researcher)
Pwn2Own Automotive 2025では、わずか3日間で49件の新たなゼロデイ脆弱性が発見されました。これらの発見の詳細は、自動車メーカー（OEM）およびサプライヤーが十分に対処できるよう、一定期間非公開としています。
今年の調査結果の公表を心待ちにしつつ、今回は公開となっている昨年の Pwn2Own Automotive コンテストで発見された2つのリモートコード実行（RCE）脆弱性について、再度取り上げたいと思います。NCC Groupの Exploit Development Groupに所属するセキュリティ・リサーチャーであるMcCaulay Hudson氏とAlex Plaskett氏は、Phoenix Contact社の車載/車両内充電コントローラCHARX SEC-3100に下記の脆弱性があることを発見しました。
- CVE-2024-25994：任意のファイルアップロードによるリモートコード実行の脆弱性
- CVE-2024-25995：コンフィグインジェクションによるリモートコード実行の脆弱性
これらの脆弱性についてリサーチャーは、昨年のRomHackおよび 44CONカンファレンスで調査結果を発表しました。本ブログでは、CVE-2024-25994 および CVE-2024-25995 を要約し、自動車サイバーセキュリティへのより広範な影響を喚起し、まとめとして可能な緩和策についても説明します。
Trend Zero Day Initiative™（ZDI）とVicOneは、Pwn2Own Automotiveの共同主催者であり、脆弱性の発見と開示におけるパートナーでもあります。Trend ZDIから、このふたつの脆弱性についてPhoenix Contact社に直ちに報告が行われ、以降、同社により脆弱性を修正するファームウェア アップデートが公開されました。
任意のファイルをアップロードできる脆弱性
Phoenix Contact EV充電コントローラを攻略検証するために、リサーチャーはまず、物理的インターフェース、デバイスの状態、外部サービスを含む攻撃対象領域をマッピングしました。評価中に、このデバイスがカスタムウェブサービスを実行していることが判明しました。
注目すべきサービスのひとつであるCharxUpdateAgentは、ポート9999で待ち受け、いくつかの主要なURLと機能を提供します。
- /get-update
- /return-database
- /return-logs
また、リサーチャーは、Cython（C言語で書かれたPython）を使用して構築されたカスタムサービスおよびバイナリのほとんどを独自に解析し、QEMUでのエミュレーションによる動的解析を行いました。このアプローチにより、構成ファイルの展開、デバッグオプションの修正、サービス実行の管理に関する考察が得られました。その結果、妥当性確認の不備による任意のファイルアップロード脆弱性であるCVE-2024-25994を発見しました。https://<charx-ip>:9999/return-databaseにPOSTリクエストを送信することで、システムコマンドを実行し、ローカルリソースにアクセスできることが証明されました。
コンフィグインジェクションの脆弱性
また、リサーチャーは、ポート5001/tcpで実行されている別のカスタムウェブサービス、CharxSystemConfigManagerを特定しました。このサービスにより、認証済みのリモート攻撃者は、/data/charx-system-config/manager/system-user-configuration.iniにコンフィグインジェクションを実行することができます。
CellularNetworkセクションの値は、/etc/ppp/peers/charx-providerにあるPPP（Point-to-Point Protocol）構成ファイルにコピーされます。攻撃者は、https://<charx-ip>:5001/api/v1.0/rebootでPOSTリクエストを発行してシステム再起動を呼び出す重要機能を利用し、その後EV充電コントローラの動作を妨害することも可能となります。
まとめ
CVE-2024-25994で確認されたような任意のファイルに対して制限のないアップロードは、ウェブサーバーやアプリケーションに重大なリスクをもたらします。この脆弱性を利用することで、リモート攻撃者はバックドアや悪意のあるスクリプトをアップロードし、不正な操作やコードの実行が可能になります。このリスクを軽減するには、特にアップロードされたコンテンツの処理と保存方法において、厳格なファイルおよび入力検証を実装する必要があります。
リモートコード実行（RCE）の脆弱性は、多くのウェブサービスで蔓延しており、その原因は多くの場合、不適切な入力検証にあります。Phoenix ContactのEV充電コントローラの場合、CVE-2024-25995は、入力検証と認証の両方が欠如していたことが指摘されました。このようなリスクを低減するため、開発者は重要なエンドポイントに堅牢なユーザー認証メカニズムを実装し、ユーザー入力の適切な無害化を確実に行う必要があります。
メーカーや開発者は、APIセキュリティのベストプラクティスを常に遵守し、特に自社のハードウェアにウェブサービスが頻繁に組み込まれている場合は、OWASP Top 10ガイドラインを参照すべきです。
協調した脆弱性開示の時間軸に関する背景
Pwn2OwnイベントでTrend ZDIが、或るチームがデバイスやソフトウェアを「ハックに成功」または「pwned」と発表してから、そのハックに使用されたテクニックが公表されるまで、しばしば遅延があることに疑問を持たれた方も多いでしょう。この遅延は、ゼロデイ脆弱性をより責任を持って管理するために設計された調整型脆弱性開示（CVD）プロセスの一部です。
1990年代には、脆弱性を積極的に探し出すハッカーはごくわずかであり、多くのベンダーは脆弱性への対処に備えていませんでした。ホワイトハッカーもベンダーも、「ハッカーは利益と引き換えに脆弱性を報告しているのではないか？」や「脆弱性は修正されるのか、それとも報告は時間の無駄になるのか？」といった懸念を抱えていました。そして、次のような譲歩案が採用されることになりました。まずハッカーが脆弱性をベンダーに報告し、その後、ベンダーがパッチをリリースし、ハッカーの発見を公に認めるというものです。
Trend ZDIの脆弱性開示ポリシーに基づき、提出された脆弱性は、パッチが利用可能になった時点で、またはベンダーが対応しない場合は一定期間経過後に開示されます。このアプローチにより、問題が解決されるか、または修正方法が知られていない脅威が公に認知されることで、脆弱性が悪用されるリスクが回避または抑止されます。これが、脆弱性が最初に提出されてから詳細が公表されるまでの時間差を説明するものです。
