Write Up - Practical CAN bus hacking
こんにちわ。
ライトアップ書きます書きました！忘れないうちに・・・
分かる人には分かるレベルで書こうと思います。
書いていたらまた来年も出たくなってきました。
さて、皆さんもごぞんじCODE BLUEに参加してきました。
今回学生スタッフの応募をしていたのは知っていたのですが、CAN HackのCTFに出てみないかとお声掛けいただいたので、折角の機会なのでチャレンジした次第です。
SecHack365の人や、その他の知り合いの人がたくさんいて楽しい限りでした。皆さんお疲れ様でしたー！
CODE BLUEでは複数のCTFが同時に開催されています。
私が参加したのは、Practical CAN bus hackingというCTFです。
みなさんは実際のCANバスをハッキングしたことがありますか？CANバスのハッキングとは、どんなものだと思いますか？難しい？高価なデバイスが必要？答えを知るために、ぜひ私達のCTFに参加し、あなた自身の手で私達のラジコンカーをハッキングしてみて下さい！
え、CANなのにCTF？
私も初めての参加なのでそう思いました。だってCANは16進数との格闘ですし・・・
それでは、ぬるっとらいとあっぷかきます
参加メンバー
今回、広島市立大学が主体で協力していただきました
そこで、某I先生の働きかけにより、Trillium 株式会社さんと協力して挑みました。
もうひとり、筑波大学の友人と合わせて2チーム結成しました。
私のチームは、「私、広島市立大学学部生、Trilliumさん」です。
ちなみに、Trilliumさんの社員さんは外国の方が多くおられるので、皆さん英語でコミュニケーションをとります。
もちろん、CTFも英語でした・・・
私英語そんなとくいではないです。
CTFの環境
「CANのCTFって一体どんな感じでやるんだ？？？」
参加したことないので、何が必要か、どんな環境かわからずに参加しました。
当日行って、初めて目にしたことになりますね
こんな感じでした。
なるほど、なるほど・・・
Raspberry PiにPiCANシールドを載せ、そのRaspPiが実際のラジコンカーのような動作を実現しているようです。
このPiCANボードは私もよく触っていたので懐かしかったですね。
わかりやすく図にするとこんな感じです。CANレベルでしかアクセスできません！※解析用ラズパイにはSSHできます。
解析対象もラズパイなのですが、挙動から察するに何かと通信しているみたいでした。
解析対象はCAN以外でアクセスすることが（当たり前ですが）禁止されていました。
使用機器
解析に使用した機器についても簡単にまとめておきます。
- neo VI Fire （またはValueCAN）& Vehicle Spy
アナライズに最適なツールです。CANoeよりアナライズに適しているのは間違いないです。
得意なのはリアルタイム解析です。
スクリプトは書けますが不便です。あと一つのメッセージ送るのも面倒です。
- MicroPecker
ログ分析に最適です。
ログエディターが超優秀なのです。今回はあまりその機能は使いませんでしたが。
スクリプトは作れません。簡単なトリガのみなら設定可能です。
- CANtact
持っていきましたが使えませんでした。（ケーブルが足りず）
MacでPythonスクリプトが使えますし、VMのLinuxで通常のCAN-utilsを走らせることができます。
まぁ次のラズパイにSSHすれば良いのですが、SSH環境がないときのためでもありました。
解析対象のラズパイに接続されていた参加者共通の解析機器です。基本的にこのラズパイを利用して解析を進めていく形になります。
標準的なCAN-utilsが使用可能でした。
個人的に本当はCANoeを使いたかったのですが、てにはいりませんでした！ｗ
え、きゃんぬーしらない？
とても高いらしいですよ。私も某自動車会社でしか触ったことないです。
ただ、とてもとても便利です。手に入る方は是非使ってみてね。
CANoeが得意なのは（CAPLと呼ばれる）スクリプトです。
事前知識
CANについては皆さんご存知だと思います（ということにしておきます）
今回の環境ではCAN IDとしてExt. IDが使用されていました。通常よりも長い宛先アドレスIDを持つものです。
このExt. IDでは通常のCAN IDの２倍、乃ち４byteが利用可能です。
今回開催者が用意したCAN IDの定義は以下でした。
0xYYYYZZZZ
YYYY - 送信元アドレス
ZZZZ - 送信先アドレス
0000 - ブロードキャスト
通常CAN IDには送信元は存在しないはずなのですが、このような使い方も十分想定できますね。
また、データ部については以下のように定義されていました。
data[0]: データ長(data[0]以降の読み取ってほしいデータ長)
data[1]: コマンド
data[2-7]: コマンドの変数など
例えば
0x01010123#0101
はID: 0101からID: 0123に向けて、コマンド01を送信すると言った感じです。
01コマンドは確かSHUTDOWNでした。
ちなみにこんな感じでやってました。
Problem - Capture the Flag
解けたのだけあっぷします！
もっと解けた人のWriteUpよみたい、、、
ちなみにcandump –d –x –e –a can0 | grep 01240101
のように0101でメッセージを送信し、返信のみを取り出すと以下のようにFlagが降ってきます。以降、Flagが降ってくるというときはこんな感じだと思ってください。
拡大したものなのでぼやけてしまっていますね
CTF work shop 1
これは超簡単です。確かハートビートを書けでした。
例えば解析用ラズパイでcandumpコマンドをASCII表示つきで見ればわかりやすいかと思います。
写真を取っていなかったのですが、、
現在流れているメッセージを何らかのアナライザでモニタすると、以下のようなメッセージを見つけることが出来ました。
0x12340000#4D55474944455355
4d 55 47 49 44 45 53 55はASCIIでMUGIDESU、ですね？
これからID: 1234はMUGIDESUをブロードキャストしていることがわかります。
定期的にブロードキャストしているのでハートビートですね。
CTF work shop 2
MUGIDESUさんにHiMugiと送ります。
何故か割りとつまりましたが、一度対象のECUを再起動するとうまくいきました
あるIDに対して、以下のようなメッセージを送信する。
The data must contain the following string
'\x07\x08HiMugi' . Don't forget to read the answer from the ECU for the flag!
MUGIDESUといっているIDに対してHiMugiと送りたいので、以下をcansendすればOKです。自分をID: 0101とします。
01011234#48694d756769
これでFlagが降ってきます。
CTF work shop 3
コマンドを理解した上で、MUGIDESUをシャットダウンします。
つまり、以下を送信します。
01011234#0101
これでFlagが降ってきます。
CTF-1
各ECUの情報を取り出せるか、というものでした。
EngineとSteeringのECUに対して情報取得コマンドを投げると、分割されたFlagっぽいものが返ってきます。
例えば0121と0124に対して情報取得を意味する03を投げます。※0101を自身のIDだとします
01010121#0103
01010124#0103
Flagが降ってくるのでデータの読む所に注意してくっつけます。
CTF-2
これはなんか全然覚えていません。
ブロードキャストをなりすませ！というものでした。
たしかブロードキャストID: 0000を上手くつかってEngineの値を増やすことが出来たらFlagが降ってきました。
一度成功するとFlagが降ってくるので、それを見落とさないようにしましょう。
CTF-3
ここから２日目に突入するので一度問題を持ち帰りました。
CTF-3はユーロビートでした。ちょっとよくわからなかったですが、他の問題をやっていくうちにわかりました。
車内に音楽再生のユーロビートがあるので、乗っ取っていじってやろう、というものでした。
結局解かなかったですが。。
CTF-4
これ、２日目に一番つまりました。
EngineのECUとのセキュアなセッションを開く際のやり取りをSniffしたので、これを基にセキュアセッションを確立せよ、というものです。
ちなみにCAN界隈ではSecurity Accessと呼んでいます。
１日目の夜に色々調べたりしたのですが、他のチームが解く速度を察するにそこまで難しいものではないはずです。
ヒントを使ったのですが、使う意味があまりありませんでした。
そして何も出来ない午前を過ごし、MiroPeckerで大量にロギングし、ログ分析をしていて気づきました。
そう、同じシード値が使いまわされていたのです。
シード値は問い合わせる度に変更されるので、そこに注意しつつSniffしたものと同じシード値が返ってきたらSniffしたものと同じ鍵を送信する、それだけでした。
このためのPythonスクリプトを後輩に書いてもらって、どうにかなりました。
SecurityAccessを取得し、この状態じゃないと実行できないコマンドを送ればFlagが降ってきます。
CTF-5
「例」としてSteeringのECUとSecurity Accessのやりとりを示すので、どうですか？みたいなやつです
そう、例なので、CTF-4と同じやり方ではありません。
また、その他のチームの解く速度から察するにBrute Forceではなさそうでした。
ヒントを使いました。（あとから考えると、これも使わなくてよかったとは思うのですが）
ヒントは「ビットシフト」
例を見ると、どうやらシードを右にあるビットだけシフトさせると鍵になっていることが分かりました。
これをもとに、シード値を問い合わせる➔鍵を送信する
これでSuccessし、CTF-4と同じようにこの状態のみ有効なコマンドでFlagが降ってきます。
ちなみに残り７分のところでFlagが降ってきました笑
CTF-6
これがあとちょっとだったはずなのに、解けませんでした。
問題はFirmwareをdumpせよ、というものです。ヒントもありません。
通常、CANでDumpといえばOBDのISOTP標準、もしくは物理的にアクセスを試みてFirmwareをdumpするはずなのに、、
うーんうーんと悩んだ結果、やっぱりCTF-4で取得したSecurity Accessの状態でREAD BY ADDRESSしたアドレスを何かするんだと思います。
これをTrilliumさんが挑んでくれていたのですが、どうにもなりませんでした。
CTF-7~
これ以降解くことが出来たチームはいなかったと思います。あまり覚えていませんが、、
これ以降はFirmwareをDumpすることが必須となっているので、まったくわかりません。
もっと勉強します！
結果
私達のチームはTrilliumとUMR with Tです。私はTrillium側なので残念ながら５位でした。
一位はイエラエセキュリティさんです。強すぎます・・・。次回は勝ちたい。。。！
あとヒントを使わなければチームUMRに勝てたのに。。。
最後に
CTFということで、実際の自動車の解析と直結しているわけではなかったのですが、とてもおもしろいものでした。
普段（？）は実車でリバースエンジニアリングしたり、ふにゃふにゃしたりしているので、正直今回のCTFは別物でした。
そもそも送信元アドレスあるなんて。。。
また、某自動車会社に行った際の経験を少しでも活かすことができたと思います。
その自動車会社の人も来られていたので、世界は狭いなあと実感しましたね。
結構自動車関連で知ってる人がちらほらと増えてきているような気がします。そうでもない？
また、今回協力していただいたTrilliumさんにも非常に感謝です！実は日曜日に英検の二次試験があったのでとてもちょうどよかったです！
今後とも機会があれば一緒にお仕事などさせてもらいたいです。
実はCANtactという面白いCANツールをお借りする機会があったので、そちらについても記事をかきたい！
あとCBで講演してる方で、Toyota Crypto 300といってToyotaの鍵生成の仕組みを知りたいと言ってる方がいたようですね。
それにもチャレンジしてみたいですね。
