Pwn2Own Automotiveより: JuiceBox 40スマートEV充電ステーションにおけるスタックベースのバッファオーバーフロー脆弱性

2024年9月18日
CyberThreat Research Lab
Pwn2Own Automotiveより: JuiceBox 40スマートEV充電ステーションにおけるスタックベースのバッファオーバーフロー脆弱性

By Omar Yang (Senior Threat Researcher, Automotive)

20241月にZero Day InitiativeZDI)と共同でVicOneが開催した初のPwn2Own Automotiveコンテストで発見した、さまざまな電気自動車(EV)充電器の脆弱性に関する調査結果を、BlackHat USA 2024Computest Sector 7のセキュリティ研究者が発表しました。本ブログでは、JuiceBox 40 スマートEV充電ステーションの脆弱性 CVE-2024-23938 の技術的な詳細と、自動車業界におけるセキュリティ上の影響に焦点を当てます。(Computest Sector 7 による CVE-2024-23938 の発見は、以前に別のチームである Synacktiv によって攻略されていたため、Pwn2Own Automotive では「collision(重複発見)」とされました。)

JuiceBox 40のハッキング

デバイスをハッキングする最初のステップは、常に標的に関する詳細情報の収集を伴う偵察です。アプローチのひとつは、デバイスを「分解」または物理的に開き、チップやインターフェイスの有無を確認することです。もうひとつの方法は、オープンソースインテリジェンス(OSINT)を利用して、オンラインで入手可能な関連情報を探すことです。

Computest Sector 7の研究者は、当初、JuiceBox 40のインターフェイス、つまり「攻撃対象領域」をサイバーセキュリティの観点から調査しました。これらは、ZDIPwn2Own Automotiveブログに投稿した事前記事でも特定されており、この投稿では、コンテストのEV充電器のターゲットについて詳細に説明しています。

JuiceBox 40の仕様によると、このデバイスにはWi-Fiが搭載されており、充電スケジュールの設定や使用状況の統計などのサービスを提供しています。また、Wi-Fi接続の設定にはBluetooth Low Energy BLE)も使用されています。

偵察中に、研究者はすでに誰かが Telnet ポート 2000 で、一見機能していないように見える JuiceBox 40 Telnet で共有していたことを発見しました。このデバイスが同じネットワーク上の他のデバイスからもアクセス可能なウェブ管理インターフェイスを公開していたため、研究者はさらに多くの情報を収集することができました。例えば、彼らは get system.version というコマンドを使用して、そのデバイスが Silicon Labs 社の Gecko オペレーティングシステム(OS)を実行していることを知り、図 1 に示すように、その特定のバージョンを識別しました。admin(管理者)インターフェイスは、システムログのフォーマットを設定する一連のコマンドも提供しており、これにより彼らは最初の脆弱性を発見しました。

図1. JuiceBox 40のウェブ管理インターフェイスと利用可能なコマンドセット

図1. JuiceBox 40のウェブ管理インターフェイスと利用可能なコマンドセット
出典: Computest Sector 7’s Black Hat USA 2024 presentation material

デバイスのOSとバージョンが判明した後、チームはファームウェアもダウンロード可能であることを発見しました。これは重要なステップでした。ファームウェアにアクセスすることで、バイナリを分解して重要な機能を探したり、ログイン認証をクラックするツールを使用したりするなど、さらなる分析を行うことが可能になったからです。

典型的なスタックベースのバッファオーバーフロー

Gecko OSは、タイムスタンプ、SSID、ホスト、ポート、MACアドレスなどのタグを含むログフォーマットの設定テンプレートを提供します。テンプレートは、終端用のNULLバイトを含めて32文字以内です。タイムスタンプ用の@tなどの各タグは2文字を使用し、テンプレートごとに最大15個のタグを使用できます。

@t タイムスタンプタグが使用されると、メッセージバッファに23バイトが出力され、タイムスタンプタグが15個の場合、345バイトが生成されることになります。しかし、バッファは192バイトしかありません。この脆弱性はファームウェアの分析により発見され、これにより、メッセージフォーマットの処理を担当する機能を特定することができました。

Setのテンプレート例を長方形で囲んだ中に示します。この例では、デバイスがWi-Fiから切断されると、「2024-08-08|12:35:00: : Bye for now」というメッセージが記録されます(図3参照)。(日付と時刻は例示目的でランダムに選択されています。)

図2. Gecko OSの技術参考資料からのタグの使用例

図2. Gecko OSの技術参考資料からのタグの使用例
出典: Silicon Labs’ Command API documentation

図3. メッセージフォーマットで複数のタグを使用することによって起こる典型的なバッファオーバーフロー

図3. メッセージフォーマットで複数のタグを使用することによって起こる典型的なバッファオーバーフロー

メッセージのフォーマットを複数のタグを使用して設定する場合、例えば、コマンド「Set system.msg wlan_leave “[@t@t@t@t@t@t…]”」を入力すると、メッセージが出力バッファをオーバーフローします。これは、スタックベースのバッファオーバーフローの典型的な例です。

この脆弱性は、特定のメッセージを作成することで、任意のコード実行を達成するためにさらに悪用される可能性があります。オーバーフローが隣接するメモリに影響を与える場合、関数呼び出しのリターン アドレスが変更される可能性があります。攻撃者は、注入した命令がある場所にその処理をリダイレクトすることができます。プログラム カウンタを制御し、悪意のあるコードを注入することで、任意のコマンドを実行することができます。

CVE-2024-23938 の詳細

CVE-2024-23938 は、以下のように細分化できます。

  • この脆弱性を利用することで、ネットワークに接続した攻撃者はSilicon LabsGecko OSがインストールされた感染したシステム上で任意のコードを実行することができます。攻撃者がこの脆弱性を悪用し、標的のマシン上で任意のコードの実行を可能にするには、攻撃者がJuiceBox 40と同じネットワーク上に存在している必要があります。
  • この脆弱性を悪用するのに認証は必要ありません。ログインに何らかの認証が必要なほとんどのシステムとは異なり、この脆弱性は認証情報なしで悪用することができます。
  • この脆弱性はデバッグ インターフェイス上に存在します。通常、デバイスのデバッグ インターフェイスに接続するには、デバイスのIPアドレスのポート2000からユーザー認証が必要となります。
  • この脆弱性は、スタックベースのバッファにコピーする前に、ユーザーが提供したデータの長さを適切に検証する処理が欠如していたために生じます。具体的には、タイムスタンプタグが事前に定義されたバッファの長さを超える可能性があり、これがスタックベースのバッファオーバーフローにつながります。
  • 攻撃者はこの脆弱性を悪用して、デバイスの制御下でコードを実行することができます。バッファオーバーフローを悪用することで、攻撃者は徐々に任意のコードを実行する能力を獲得することができます。

Deauth(ディオーソ)攻撃で何が起きるのか

Pwn2own Automotive競技では、参加者がネットワーク環境をセットアップする際に、「ネットワークに接続された」攻撃チェーンが想定されていました。しかし、現実の世界では、攻撃者がターゲットデバイスと同じネットワーク上にいない場合、このような攻撃は実行できません。そこで、登場するのがdeauthentication即ち、認証解除(またはディオーソ)攻撃です。

ディオーソ攻撃では、攻撃者がステーションになりすまして「オフラインになります」というメッセージをアクセスポイントに送信します。攻撃者はターゲットデバイスのBSSID(基本サービスセット識別子)を偽装し、アクセスポイント(AP)にディオーソフレームを送信します。これにより、デバイスはアクセスポイントとの接続を切断し、再接続を試みます。

OSI Open Systems Interconnection) ネットワークスタックでは、パケットは暗号化されますが、暗号化されるのはレイヤー3以上です。レイヤー2にあるMACアドレスは暗号化されません。そのため、ワイヤレスパケット スニッフィングを行うと、これらのアドレスが簡単に明らかになり、ディオーソ攻撃が可能になります。

図4. ディオーソ シーケンス ダイアグラム:ある攻撃者が被害者のMACアドレスを偽装し、被害者のデバイスを強制的にオフラインに移行させることができる

図4. ディオーソ シーケンス ダイアグラム:ある攻撃者が被害者のMACアドレスを偽装し、被害者のデバイスを強制的にオフラインに移行させることができる

ターゲットのデバイスがアクセスポイントへの再接続を試みている間に、攻撃者はそのデバイスから送信される安全な接続を確立するためのパケット、いわゆる「シード(種)」を傍受することができます。この情報とレインボーテーブルなどのツールがあれば、攻撃者はアクセスポイントのパスワードを解読し、同じネットワークにアクセスすることができてしまいます。

図5 認証情報を入手すると、攻撃者はWLANに接続し、EV充電器を標的にすることができる。さらに、攻撃者は同じネットワーク上の他のデバイスにもアクセスできる

図5 認証情報を入手すると、攻撃者はWLANに接続し、EV充電器を標的にすることができる。さらに、攻撃者は同じネットワーク上の他のデバイスにもアクセスできる

別のシナリオでは、攻撃者がAPの情報を知っている場合、攻撃者は偽のAPを設定し、標的デバイスをその偽のAPに接続させることができます。これにより、攻撃者は中間者(MITM)攻撃を実行できます。

図6. 攻撃者は、複製APを設定したり、BLEサービスを利用してデバイスを接続させることで、デバイスとクラウド間でやり取りされるメッセージを傍受し、改ざんすることが可能となる

図6. 攻撃者は、複製APを設定したり、BLEサービスを利用してデバイスを接続させることで、デバイスとクラウド間でやり取りされるメッセージを傍受し、改ざんすることが可能となる

JuiceBox 40BLEを搭載しており、デバイスがWi-Fiに接続されていない場合でも、Wi-FiプロビジョニングのためにBLEはアクティブな状態を維持します。このBLEサービスにより、攻撃者は保存された認証情報を取得したり、新しいSSID(サービスセット識別子)を設定したりすることができます。この機能はEV充電器をセットアップするユーザーにとっては便利なものですが、一方で、攻撃者がデバイスにアクセスするために悪用できる脆弱性も生じます。

セキュリティへの潜在的な影響

Silicon Labs社は、CVE-2024-23938に関連するセキュリティ勧告を発表し、Gecko OSはサポート終了(EOL)に達したため、修正プログラムは提供されないと述べています。

このアプローチは、脆弱性管理では比較的よく見られるものです。ベンダーは、ソフトウェアにアクティブなサポートが提供されなくなった時点で、そのソフトウェアは広く使用されなくなると想定することが多いからです。ソフトウェアのEOLを宣言することで、ベンダーはユーザーに、その製品はセキュリティパッチを含むアップデートを受けられなくなることを知らせ、サポート対象のバージョン、あるいは代替ソリューションへの移行を促します。この慣行は、一般的に、アクティブなサポート対象製品の維持とセキュリティ確保にリソースを優先的に割り当てることを目的としています。

もしCVE-2024-23938が発見されていなかったら、攻撃者はWi-Fiディオーソ攻撃を仕掛けてEV充電器を乗っ取ることも可能だったかもしれません。 意図的に過充電したり充電パラメータを調整したりすることで、充電器や車両内にも潜在的な被害をもたらした可能性があります。また、攻撃者はデバイスへのアクセスを暗号化し、身代金を要求したり、被害者のローカルネットワークにアクセスして他のデバイスを侵害したりすることすら可能でした。さらに大規模な被害としては、特定のエリアにある複数の充電器が侵害された場合、攻撃者は充電器を同時に起動させることで電力網に過負荷をかけることも可能です。

CVE-2024-23938の発見は、自動車業界におけるより広範なセキュリティ上の影響を浮き彫りにしています。

  • ほとんどのエンドユーザーは、EVやその充電ステーションなどの新しいテクノロジーは、本質的により安全であると考える傾向にありますが、Pwn2Own Automotiveで発見された他のEV充電器の脆弱性と同様に、この脆弱性はそれほど巧妙な攻略技術を必要としません
  • 電気自動車給電設備(EVSE)ベンダーにとって、製造段階で脆弱性を発見することは、設計および開発段階で発見するよりもコストがかかります。そのため、現存する問題への対処が先決となり、新製品の開発が遅れる可能性があります。
  • この脆弱性のより広範な影響を理解することは、適用可能な規制や基準の進歩を促し、より安全なEV充電器それを支えるインフラの実現につながるでしょう。

責任ある情報開示の時間軸に関する背景

Pwn2OwnイベントでZDIが、或るチームがデバイスやソフトウェアを「ハックに成功」または「pwned」と発表してから、そのハックに使用されたテクニックが公表されるまで、しばしば遅延があることに疑問を持たれた方も多いでしょう。この遅延は、ゼロデイ脆弱性をより責任を持って管理するために設計された調整型脆弱性開示(CVD)プロセスの一部です。

1990年代には、脆弱性を積極的に探し出すハッカーはごくわずかであり、多くのベンダーは脆弱性への対処に備えていませんでした。ホワイトハッカーもベンダーも、「ハッカーは利益と引き換えに脆弱性を報告しているのではないか?」や「脆弱性は修正されるのか、それとも報告は時間の無駄になるのか?」といった懸念を抱えていました。そして、次のような譲歩案が採用されることになりました。まずハッカーが脆弱性をベンダーに報告し、その後、ベンダーがパッチをリリースし、ハッカーの発見を公に認めるというものです。

ZDIの情報開示ポリシーに基づき、提出された脆弱性は、パッチが利用可能になった時点で、またはベンダーが対応しない場合は一定期間経過後に開示されます。このアプローチにより、問題が解決されるか、または修正方法が知られていない脅威が公に認知されることで、脆弱性が悪用されるリスクが回避または抑止されます。これが、脆弱性が最初に提出されてから詳細が公表されるまでの時間差を説明するものです。

リソースからもっと知る

自動車サイバーセキュリティの理解を深める

ブログを読む

自動車業界のお客さまのサイバーセキュリティを加速させるために

デモの依頼