VCC 2025 Write-up

Transcript

4. 4 年 大会名 備考 2023 BlockHarbor Automotive CTF オンライン大会のみ 2024 BlockHarbor VicOne Automotive CTF - Season 2 予選@オンライン 日本決勝@東京 (日本勢のみ) 国際決勝@デトロイト 2025 Vehicle Cybersecurity Competition 2025 オンライン大会のみ 但し日本勢のみこれを入口とした招待制大会あり
6. 6 No. カテゴリ 問題名 点数 概要 1 - Agreement 0 ルールを読んだかの確認 2 Blue Team Challenges #1 Red Alert 700 xNexus(SIEMみたいなサービス)で、怪しいCAN検知ログを探してフラグ抽出 3 Blue Team Challenges #2 SAE EAS 400 xNexus(SIEMみたいなサービス)で、怪しいCAN検知ログを探してフラグ抽出 4 Blue Team Challenges #3 Firmware Reveal 800 暗号化パスワードのブルートフォース 5 Blue Team Challenges #4 TARA Challenge 100 TARAを埋めて設問に答える 6 Red Team Challenges #1 Wired Keyless Entry [PowerPC] 400 セキュリティアクセスの突破→FWダンプ&解析→セキュリティアクセスの突破 7 Red Team Challenges #2 Tune-Up Trouble [PowerPC] 800 改造ファームウェアへの更新で任意コード実行 8 Red Team Challenges #3 Password Change Policy [RAMN] 600 FWダンプ&解析→セキュリティアクセスの突破 9 Red Team Challenges #4 AutoGraph [RAMN] 300 ECDSAを使った署名の偽造
10. 10 ダッシュボード
11. 11 ここはクリックで 詳細を見ることがきる ダッシュボード
12. 12 ダッシュボードにある エントリ1つの詳細画面
13. 13 資産
14. 14 ネットワーク検出
15. 15 脅威インテリジェンス
16. 16 インシデント検出 - 侵害イベント
17. 17 インシデント検出 - OAT検出
18. 18 最終的には「OAT検出」 から見られるログにあった インシデント検出 - OAT検出 検知数が多かったので、 直近10日程度で絞り込み
19. 19 インシデント検出 - OAT検出 大量に検知されている infoレベルを除外すると、怪しい ログが見つかる
20. 20 インシデント検出 - OAT検出 メニューバーを 折りたたむと 各エントリの 詳細確認ボタンが現れる
21. 21 ここにCAN通信の キャプチャデータがある インシデント検出 - OAT検出 のエントリ詳細
22. 22 discordの発言をAIで和訳
23. 23 F12で開発者コンソール を開き、ページ再読込
24. 24 Searchタブを出して
25. 25 "payload_"で検索すると引っかかる
26. 26 ①見つかった通信ログを ダブルクリックして ②全データをコピペし、 query.txtに保存
29. 29 問題文再掲 定期的な車両内通信の検査中に、我々はCANバス上で不 審なメッセージを傍受しました。フレームには「BEGIN」とラベル 付けされたブロードキャストとデータシーケンスが含まれています。
30. 30 問題文のヒント再掲 "backdoor"という言葉に注目して考えてみましょう。また、情 報機関は彼らがAESを使用していることを確認しています。
32. 32 問題文再掲 我々の情報源によれば、これは仲間に向けたブロードキャスト メッセージのヒントだということです。MHz単位での周波数を特 定し、それをフラグとして提出してください。 フラグ形式ヒント: bh{6MHz}
37. 37 参考: Write-upを書いていて気付きましたが、フラグらしき文字が出てくる よう、先頭から1ブロックずつ確定させれば、こんなにたくさん試す必 要はありません。最大8+7+...+2 = 35通り試せばOKです
40. 40 zipには全てパスワードが かかっている ELFファイル
41. 41 Pyinstallerは、pythonスクリプトをスタンドアロンな 実行ファイルに変換するツール。CTFではたまに見かける
42. 42 本家のpyinstxtractorは、一部ファイルを展開してくれないので注意 (エラーが起きてもサイレントに処理を続けるので、気づくことも困難) pyinstxtractor-ngじゃないとダメ 出てきた これらが怪しい
43. 43 https://pylingual.io/view_chimera?identifier=6623b6b49934113 df14e3543eb74bd2ae46e6dec85478b0feeaea8901ce74744
50. 50 TARA (Threat Analysis and Risk Assessment): サイバーセキュリティにおいて、製品やシステ ムに存在するサイバー脅威を特定し、それによって引き起こされるリスクを分析・評価するプロセスのこと。 実務では、業界のガイドラインに対して、仕様書や設計書などその製品固有のドキュメントの記載を突き合わ せて、脅威をExcelにまとめる、といったやり方が一般的(だと思う)。目を通すべきドキュメントがたくさんあって、 めっちゃ大変。
63. 63 ttyd (https://github.com/tsl0922/ttyd) を使っているのだと思います
66. 66 caringcaribouはエラーの詳細を表示しませんが、別画面で isotpdump -s 7e0 -d 7e8 -u -c -a vcan0 すればエラー応答の詳細も見ることができます
69. 69 ファンクション サブファンクション 備考 0x10 DIAGNOSTIC_SESSION_CONTROL 0x01 デフォルトセッション - 0x02 プログラミングセッション 要セキュリティアクセス突破 (一般的に0x03から遷移) 0x03 拡張セッション 要セキュリティアクセス突破 (一般的に0x01から遷移) 0x11 ECU_RESET 0x01 Hard reset セキュリティアクセス不要 0x02 Off/On keying reset セキュリティアクセス不要 0x22 READ_DATA_BY_IDENTIFIER 0xf186 Active diagnostic session 01 0xf187 Manufacturer spare part number 'PN_B0NN3T¥x00' 0xf18a Identifier of system supplier 'AUDI' 0xf18b ECU manufacturing date '01292009' 0xf18c ECU serial number 'AUDI2009' 0xf190 Vehicle Identification Number '1BHCM82633A004527' 0x27 SECURITY_ACCESS 0x01/0x02 レベル0x01 デフォルトセッションから呼出可能 0x11/0x12 レベル0x11 デフォルトセッションでは未サポート 0x2C DYNAMICALLY_DEFINE_DATA_IDENTIFIER デフォルトセッションでは未サポート 0x3E TESTER_PRESENT 定期ping的な機能なので省略 0x22 RDBIで入手した情報を使って セキュリティアクセスレベル0x01 を突破する方針しかなさそう
71. 71 https://flaviodgarcia.com/publications/BtB.pdf より
72. 72 私はistopモジュールを使いましたが、 socketpanda.pyとuds.pyを使うのも良さそうです https://icanhack.nl/blog/blockharbor-ctf-2025-writeup/
73. 73 エラーメッセージが変わった
74. 74 ファンクション サブファンクション 備考 0x10 DIAGNOSTIC_SESSION_CONTROL 0x01 デフォルトセッション - 0x02 プログラミングセッション 要セキュリティアクセス突破 (一般的に0x03から遷移) 0x03 拡張セッション - 0x11 ECU_RESET 0x01 Hard reset セキュリティアクセス不要 0x02 Off/On keying reset セキュリティアクセス不要 0x22 READ_DATA_BY_IDENTIFIER 0xf186 Active diagnostic session 01 0xf187 Manufacturer spare part number 'PN_B0NN3T¥x00' 0xf18a Identifier of system supplier 'AUDI' 0xf18b ECU manufacturing date '01292009' 0xf18c ECU serial number 'AUDI2009' 0xf190 Vehicle Identification Number '1BHCM82633A004527' 0x27 SECURITY_ACCESS 0x01/0x02 レベル0x01 デフォルトセッションから呼出可能 0x11/0x12 レベル0x11 拡張セッションから呼出可能 0x2C DYNAMICALLY_DEFINE_DATA_IDENTIFIER 利用可能 0x3E TESTER_PRESENT 定期ping的な機能なので省略 0x2C DDDI + 0x22 RDBIを使って、 ファームウェアをダンプ → 解析 して突破するっぽい
77. 77 ファームウェアのヘッダ？データはあるがコードはなさそう ブートローダとプログラミングセッションの処理 (オールゼロ) (オールゼロ) アプリA面; デフォルトセッション/拡張セッションの処理 アプリB面; デフォルトセッション/拡張セッションの処理 0x0 0x10000 0x20000 0x30000 0x40000 0x50000 0x60000
78. 78 … … …
93. 93 おそらくこの当たりに脆弱性があって、 ファームウェアを任意に更新できる？ (任意コード実行に持ち込んで特殊レジスタ改変)
94. 94 … 特定したUDS関連の構造体
99. 99 0x34 Request Download 0x36 Transfer Data 0x34 Routine Control 署名 検証
100. 100 0x34 Request Download 0x36 Transfer Data 0x34 Routine Control 署名 検証 0x36 Transfer Data 署名検証 0x36 Transfer Data 署名検証 署名検証 0x34 Routine Control
101. 101 更新用ファームウェア (=fw) 128バイト署名(=s) 0x0 N N+0x80 SHA256(fw) 送るべきデータの構成 se mod N'を計算 (N'は先程のNとは別。アドレス0x1e0にある) 一致するか判定 このN'は素因数分解 できないため、暗号学 的には多分安全 この署名のついた構造は、 ダンプしたファームウェアの 0x40000～0x50000 がまさに該当
103. 103 0x34 Request Download 0x36 Transfer Data 0x34 Request Download 0x36 Transfer Data 0x34 Routine Control 正しいファームウェアイメージを転送 (最後まで送り切ることで、署名チェックを行わせ、 Signature Validフラグを立てる) 偽造したファームウェアイメージを転送 (最初から送り直すことで、更新用データを溜めておくバッファを上書き可能、 かつ最後まで送り切らなければ、署名チェックは行われない) 署名 検証
104. 104 0x34 Request Download 0x36 Transfer Data 0x34 Request Download 0x36 Transfer Data 0x34 Routine Control ここで書き込むべきデータは？ 署名 検証
105. 105 0x34 Request Download 0x36 Transfer Data 0x34 Request Download 0x36 Transfer Data 0x34 Routine Control ここで書き込むべきコードは？ 署名 検証 アセンブリ→バイトコードの変換は、自作のGEFの機能を使いました
107. 107 VM上のUbuntu24.04(x64)で、 qemu-userを使ってpowerpcを エミュレーションします。 メモリ上にファームウェアをロードし、更に 必要なバッファ領域を用意しています (0x40000000は既にqemuがマップ しているので、パーミッションを変えて使う)
108. 108 署名の計算をエミュレートして値を確かめているところ https://github.com/bata24/gef を利用してGDBの機能を拡張しています
111. 111 先頭付近 7E2がたくさん出てくるところ
114. 114 ファームウェアをロードしたら メモリマップを作っておきます
115. 115 https://github.com/ToyotaInfoTech/RAMN/blob/main/firmware/RAMNV1/Core/Startup/startup_stm32l552cetx.s
116. 116 https://github.com/ToyotaInfoTech/RAMN/blob/main/firmware/RAMNV1/Core/Src/main.c
117. 117 https://github.com/ToyotaInfoTech/RAMN/blob/main/firmware/RAMNV1/Core/Src/main.c
118. 118 https://github.com/ToyotaInfoTech/RAMN/blob/main/firmware/RAMNV1/Core/Src/ramn_uds.c
119. 119 https://github.com/ToyotaInfoTech/RAMN/blob/main/firmware/RAMNV1/Core/Src/ramn_uds.c
120. 120 解析済み
125. 125 先頭付近 抽出すると4つのファイルが転送されていた
126. 126 opensslで公開鍵の中身を見る それぞれのダンプ
127. 127 HEXファイル:マイコンに書き込む際に使われる、 バイナリデータをASCIIで表現したファイル形式
128. 128 公開鍵 署名 検証対象
129. 129 r s r s
131. 131 乱数kを使い回した2つの署名があると、秘密 鍵dを求められてしまうことが知られている
132. 132 右辺はすべて既知の値 kが求まればdが得られる 署名 𝑟𝑟, 𝑠𝑠 は 𝑟𝑟 = 𝑥𝑥 mod 𝑁𝑁 𝑠𝑠 = 𝑘𝑘−1 Hash 𝑚𝑚 + 𝑟𝑟𝑟𝑟 mod 𝑁𝑁
133. 133 計算のコア部分。除算はそのまま計算できないので、 「-1乗」した値を求めて掛ける必要があることに注意