By Vit Sembera (Senior Threat Researcher, Automotive)
Pwn2Own Automotive 2024の最中にAutel Maxicharger電気自動車（EV）充電器で、さらに発見されたスタックベースのバッファ オーバーフロー脆弱性2件の深刻なコーディング セキュリティ上の欠陥について、改めて着目したいと思います。この脆弱性（CVE-2024-23967およびCVE-2024-23957）は修正済みですが、不適切な入力データの検証がEV充電器などの重要なシステムをリモートコード実行の危険にさらす可能性があることを改めて示しています。
CVE-2024-23967: Base64でのデコードに関する脆弱性
CVE-2024-23967は、Autel MaxiChargerファームウェアのバージョン1.32で、Computest Sector 7のリサーチャーによって発見されました。この脆弱性は、受信データのサイズを確認せずに固定サイズのスタックバッファにデコードされるBase64エンコードデータの不適切な処理に起因します。その結果、攻撃者はこの脆弱性を悪用してサイズの大きいデータを送信し、バッファオーバーフローを引き起こしてリモートコードを実行可能にすることができます。
こうした見落としは、入力データのサイズと内容の両方を検証しなかったという基本的なコーディングミスがあったことを示しています。適切な入力検証を実装していれば、デコードされたデータが割り当てられたバッファ内に収まるようにすることで、この脆弱性を防ぐことができたでしょう。
CVE-2024-23957: 16進文字列のデコードに関する脆弱性
2つ目の脆弱性、CVE-2024-23957は、同じバージョン1.32のファームウェアで、Midnight Blue/PHP Hooligansによって発見されました。この脆弱性は、攻撃者によって送信された大きな16進文字列をシステムが処理する際に発生します。この16進文字列は、境界チェックなしで固定サイズのスタックバッファにデコードされるため、バッファオーバーフローが発生し、同様にリモートコード実行とデバイスの完全な乗っ取りにつながる可能性があります。
ファームウェア パッチだけで十分か？
Autelは、Autel MaxiChargerファームウェアのバージョン1.35で、これらの脆弱性の両方に対応しました。
Autelがこれらの脆弱性を迅速に修正したことは評価に値しますが、その修正方法には懸念が残ります。 その場しのぎの修正は短期的には悪用を防ぐかもしれませんが、そもそもこれらの欠陥を許したコーディング慣行の抜本的な見直しを行わない限り、同様の問題が再び発生する可能性が高いでしょう。
両方の脆弱性には、共通の原因があります。適切な入力検証が欠如していることです。受信データのサイズと構造のチェックを実装しなかったため、Autelのファームウェアは古典的なバッファオーバーフロー攻撃に対して脆弱なままになっていました。これらの根本的なコーディングの問題は、ケースバイケースで修正するのではなく、システムのコアレベルで対処すべきでした。
リアクティブ型セキュリティ対応の問題点
CVE-2024-23967とCVE-2024-23957は、リアクティブ（事後対応）型のセキュリティ対策に依存する危険性を浮き彫りにしています。脆弱性が発見され、公表されるのを待ってから対応するのでは、持続可能でも安全でもありません。特にEV充電器やそれを支える接続インフラのような重要なシステムでは、その傾向が顕著です。
入力値の厳格な検証や徹底的なコードレビューなど、開発ライフサイクルにセキュリティをプロアクティブに組み込むことは、古典的なバッファオーバーフローの発生を防ぐためには不可欠です。自動車業界がより高度な接続性に向けて進化を続ける中、EV充電ステーションなどのコンポーネントに至るまで、そのインフラのセキュリティはますます重要性を増しています。
Pwn2Own Automotive 2024で発見されたAutel MaxiChargerの脆弱性から学んだ教訓は、ベンダーと開発者双方にとって警鐘と捉えるべきでしょう。セキュリティは後付けではなく、当初から設計に組み込むべきです。
これらの脆弱性に関する詳細情報、およびそれらの脆弱性を発見するために使用されたリバースエンジニアリング技術に関する洞察、およびAutelがそれらの脆弱性を修正した方法の詳細については、ゼロデイイニシアティブ（ZDI）による関連ブログ記事をお読みください。ZDIは、Pwn2Own Automotiveの共同主催者であり、脆弱性の発見と開示におけるパートナーです。
また、Pwn2Own Automotive 2024で発見された他のAutel MaxiChargerに関するi脆弱性であるCVE-2024-23959とCVE-2024-23958についても、以前のブログ記事でセキュリティ対策を提示しました。
責任ある情報開示の時間軸に関する背景
Pwn2OwnイベントでZDIが、或るチームがデバイスやソフトウェアを「ハックに成功」または「pwned」と発表してから、そのハックに使用されたテクニックが公表されるまで、しばしば遅延があることに疑問を持たれた方も多いでしょう。この遅延は、ゼロデイ脆弱性をより責任を持って管理するために設計された調整型脆弱性開示（CVD）プロセスの一部です。
1990年代には、脆弱性を積極的に探し出すハッカーはごくわずかであり、多くのベンダーは脆弱性への対処に備えていませんでした。ホワイトハッカーもベンダーも、「ハッカーは利益と引き換えに脆弱性を報告しているのではないか？」や「脆弱性は修正されるのか、それとも報告は時間の無駄になるのか？」といった懸念を抱えていました。そして、次のような譲歩案が採用されることになりました。まずハッカーが脆弱性をベンダーに報告し、その後、ベンダーがパッチをリリースし、ハッカーの発見を公に認めるというものです。
ZDIの情報開示ポリシーに基づき、提出された脆弱性は、パッチが利用可能になった時点で、またはベンダーが対応しない場合は一定期間経過後に開示されます。このアプローチにより、問題が解決されるか、または修正方法が知られていない脅威が公に認知されることで、脆弱性が悪用されるリスクが回避または抑止されます。これが、脆弱性が最初に提出されてから詳細が公表されるまでの時間差を説明するものです。
