いろんな技術に触れたい

日頃色々触れた技術を自分なりにまとめておきたいと思ってます。難しいものほどブログ書く時間がかかるのが問題・・・

SecHack365 @2017のまとめをアーキテクチャとともに振り返る!

SecHack365@2017を振り返ろう

こんにちは。 遅くなりましたが、昨年2017年度に参加していたSecHack365ですが、先月無事に卒業することができました。今回はそのまとめについて書いていきたいと思います。

まず、私達のグループが最終報告回で発表した資料(一部修正)はこちらになります。忙しい方はこちらの資料に目を通して「ふーん」と思ってくれるだけでありがたいです!



改めまして、私は現在電気通信大学の大学院生をやっていますtokina(ひみつ)です。昔はネットワーク系の研究室に所属しており、自動車のセキュリティについての研究をしていました。現在は電通大のネットワーク系の研究室に移籍し、IoTに関する研究をしております。昨年からパブリッククラウド技術に興味を持ち始め、今回SecHack365の私のチームの中でもクラウド部分をメインに担当しています。

SecHack365について詳しくは以下のページをご参照下さい。

sechack365.nict.go.jp

また、日程が非常に近いですが、SECCON×SecHackのセチャコンというイベントが開催予定です。皆さんよければ足を運んでみて下さい。秋葉原行きましょう! 2017.seccon.jp

現在('18.04.09執筆時)には2018年度生を募集しています。課題申し込みと提出申し込み締切が異なるので注意して下さい。 学生の方は無料で参加できます。ただし自己管理は徹底して下さいね。

sechack365.nict.go.jp


今回、一年の総轄としてまとめました。SecHack365参加を目指す方の参考になれば幸いです。

私にとってのSecHack365(SecHack367)とは

私にとって、振り返ってみるとSecHack365とは技術的交流はもちろん、自身のモチベーションをしてくれる環境でした。

しかし、この機会で出会うことが出来た人や、今後の指針が見えてきたこともあり、私にとってはとても大切な一年だったことは間違いないと思っています。

ちなみに就職活動とかでも役に立つと思います!

え、 SecHack367 ですか?気になる方は参加して見ましょう!

応募のキッカケ

キッカケとは些細なものだと思います。私はセキュリティ・キャンプに参加していたので、サイボウズで情報が流れてきており、耳にはしていました。しかし、私はギリギリまで申し込んではいなかったのです。

申し込み期限前日、私はそういえばと思いサイボウズを開き、このSecHack365に応募しました。ちなみに応募課題は非公開だそうです。

最初、SecHack365を見たときに、「キャンプ関連なんだろうか・・・」くらいに漠然と考えていました。

実際に参加するとキャンプの講師やTAレベルの人が沢山おり、最初は不安でいっぱいでした。。。

ちなみに選考の基準ですが、「参加してともにイノベーションを起こせるか(なにか新しいことをひらめけるか)」だそうです(たしかそういっていた)。

学歴や大学、住んでいる場所とかは一切選考に関係ないそうです。また、名前も伏せて選考されます。つまり、応募者が何を考えているかの本質が見られるのだと思います。

プログラミング能力は必須でしょうか?

私は”必須”だと思います。無いと困るとかではなく、少なくとも「アイデアを実現する力」のタネが必要だと思います。まぁハッカソンだからとも言えるでしょうか。

ちなみに私のプログラミング能力はそんなに高くない...と思っています。

チームメンバーの紹介

私のチームは4人チームでした。チームメイトは私を含め以下の方たちでした。

@o_hi_rangosta, @kiyoooo44,@_tokina23 (私), @Balius1064

また、途中で(私が勝手にお願いして)特別顧問として協力してくれた

@Shi_ma715, @sm_nz_gk

みなさん、ありがとうございました!

SecHack365でなにをつくっていたのか?

私のグループでハッカソンしていたのは、一言で言うと 『自動車の情報を収集し、自動車情報を利活用するプラットフォーム』 です。最初の着眼点は「パブリッククラウドを使って自動車の情報を収集した例って聞いたこと無いよね?」「簡単にできそうだけど、実際に作ってみたらなにか見えてこないかな?」というところからでした。そこから見えてきたのが 「自動運転のための運転者データの収集」 でした。

全体の概要図は下図のようになります。こちらは実際の成果発表会で使用した資料を一部修正したものです。



実際にこのハッカソンでは 自動車に搭載する車載器から、フロントエンドの可視化まで一貫して作成 しています。これにより、自動車を完全に”IoT”化できました(たぶn)。

最終的にハッカソンで出来上がったアーキテクチャですが、もともとこのような最終形を想定していませんでした。今回は折角なので、そのアーキテクチャとともに振り返ってみたいと思います。

アーキテクチャと若干詳しい解説

私達グループメンバーはこの概要図にある通り、全体のうちの一部をそれぞれを担当していました。私はこの中でAWSやその周辺を主に担当しています。最初に掲載した資料にもありますが、最終的なアーキテクチャは以下になります。

データの流れに注目しましょう。まず、自動車に搭載された車載器からSORACOMへとデータが転送されます。ちなみにこの時データはSORACOMの専用回線を利用してアップロードされます。

そののち、SORACOM Funnelというサービスを利用して、AWS Kinesis Streamへとデータをストリーム転送します。このFunnelとはアップロードのみに特化したサービスです。一度AWS Kinesis Streamに流れてきたデータは少しポーリングされるため、厳密にはリアルタイムではありません。

次にKinesis StreamのデータがポーリングされるとAWS Lambdaのメインとなるプログラムがキックされ、Base64でデコード、JSONを取り出します。その後、異常値検出(ここでは簡単に閾値を決め打ちしています)、ElasticsearchにPOST、AWS SNSのキック、S3にデータをPOSTします。

管理者向けの利用を想定した可視化として、AWSに用意されているElasticsearc ServiceのKibanaを利用しています。ここで可視化されるデータとその型は以下です。

  • 位置情報(GPS)
    • geo_point
  • 速度
    • double
  • エンジン回転数(RPM, rotation per minutes)
    • int
  • ステアリング
    • double
  • CANの使用帯域(bandwidth)
    • double
  • 自動車情報(自動車ID)
    • Text
  • エラーメッセージ
    • Text

AWS SNSは通知サービスです。SNSで一括管理する通知先をLambdaで指定することで、複数の宛先(Slack, e-mail, LINEなど)へ一度に通知します。ここで、SlackやLINE(+IFTTT)はweb hookを噛ませないといけないので、スケーラビリティのため別のLambdaで実行しています。

S3に保存したデータは自動車情報毎に分けられ、全て生のテキストファイルとして置かれており、運転評価を行うEC2サーバ(今回はFlaskを利用してwebアプリを構築している)からデータを取得しに行きます。

EC2サーバで行う運転評価については@Balius1064が作成してくれました。

また、同じように@kiyoooo44さんが作成してくれたUnityアプリケーションはS3へデータを取りに行くのですが、AWS SDKを利用してデータにアクセスするための認証にCognitoとIAMを利用して承認を行っています。

以上が全体のデータの流れになります。

振り返り

SecHack365は(昨年度は)全部で7回のオフラインハッカソンと、その間のオンラインハッカソンで行われます。昨年度の日程は以下でした。

  • 2017 05 東京 NICT(国立) 顔合わせ
  • 2017 06 東京 蒲田 アイデアソン
  • 2017 08 福岡 LINE福岡/志賀島 縁日(ワークショップ)、ハッカソン
  • 2017 10 北海道 札幌 縁日(ワークショップ)、さくらのデータセンター見学、ハッカソン
  • 2017 12 大阪 ハッカソン
  • 2018 02 沖縄 糸満 成果報告
  • 2018 03 東京 秋葉原 最終成果報告、ポスター展示

最初は運営の方々も手探り状態で、私達が最初の卒業生になるということもあり、一期生としての”責任”のようなものを感じていました。私達のグループメンバーは、蒲田回のアイデアソンのときから一貫して変わりませんでしたが、多くのひとはソロプレイヤーになったりするなど、悩んでいる人も多かったかな、という印象です。

今年は最後のブラッシュアップを鑑みて、12月と1月を空けて最終報告回になっていますね。

それではここからアーキテクチャとともに振り返ってみたいと思います。

2017 08 福岡 LINE福岡/志賀島 縁日(ワークショップ)、ハッカソン

8月当時、私は丁度AWSインターンシップに参加したばかりで、パブリッククラウド初心者でした。そこで、インターンシップで利用したKinesis、Lambda、RDSを利用しようと考えたのです。

福岡回の最初はLINEさんのオフィスにて縁日という名前のワークショップをして頂きました。そこでnekoruriさんのワークショップにあったSORACOMを利用すればいいのでは?とヒントをいただきました。

自動車のデータはストリームデータですので、Kinesisを利用するのはわかっていました。また、その簡単な処理にはサーバレスファンクションであるLambdaが適していることもわかっていました。しかし、そこから先は正直当時はかじった程度しか理解できていなかったため、このような簡単な仕組みになっていました。結局8月回の最後にはSORACOMから送られてきたデータをKinesisで受け取るところまで進みました。

この8月で実際に作りたいモノがぼんやりと決まってきました。

8月回は非常に暑く、海辺での照りつける日差しを今でも覚えています。大自然発想法 ですね。ここは完全にリゾート地で、海が最高でした!

2017 10 北海道 札幌 縁日(ワークショップ)、さくらのデータセンター見学、ハッカソン

10月では、縁日は一部任意になり、ハッカソンがメインとなっていました。8月から10月までSlackでやり取りしながら少しずつ進めていきました。実は9月はトヨタ自動車インターンシップに行ったり・・・

10月にはElasticsearchとLamndaの連携がどうしても上手く行かず、データの視覚化は出来ていませんでした。S3に保存は出来ていたような気がしますが、、

私達のチームはこの10月回から自動車の利用を申請しており、特別に外で実験させてもらいましたv

上の図は北海道回の最初のアーキテクチャで、この回の最後には下図のようになりました。

北海道回のハッカソンおかげで、かなり実際のものに近づいてきました。私は当時Elasticsearchにデータをどうしても格納できませんでした。もともとLambda一つでS3とElasticsearch両方にデータを流そうと考えていたのです。そこで、nekoruriさんにElasticsearchに格納する部分はNode.jsにすればよいのでは?とのアドバイスを頂いたのです。

私としては人生で修学旅行以来の2回めの北海道でした。案外寒くもなく、ホテルの屋内プールと屋上の露天風呂が最高だったのを覚えています。また紅葉が最高でした。空港では雪ミクを見れたり、時計台や電波塔にも行くことが出来ました。

2017 12 大阪 ハッカソン

「12月回でハッカソンは一通りおわりなので」とのことだったので、12月回までいろいろ頑張ってどうにか形にしようと奮闘しました。調べていてわかったのですが、どうやらPythonでElasticsearchにデータを流す例があまりないことがわかりました。それでもどうにかLambda一つでS3とElasticsearchにデータを流すことに成功し、大阪回で簡単な視覚化をできるところまで持っていくことが出来ました。これで、だいたいの形は決まりました。

ここまでがいわゆるインフラの部分であり、成果報告会まで、残るは”視覚化”部分となったのです。私が残る課題としていたのは付加価値である”通知”の部分です。AWS SNSの利用は決定していたのですが、時間が足りず当時はそこまで完成していませんでした。

大阪は以前から行く機会が多かったので特に何もありませんでしたね。個人的にモダン焼きが美味しくて良かったです。広島焼きとは違うのでしょうか?

2018 02 沖縄 糸満 成果報告

2月になるまで約1〜2週間に一度Slackでミーティングを行いながらどうにかみんなで形にできました。

私もAWS SNSを使った通知を実現し、それに合わせてこのような最後のアーキテクチャになりました。しかし、これはスケーラビリティや負荷などが考慮されていないため、実際の稼働の際にはさらに改良しないといけないのは明白ですが、去年全く知らない状態からここまで作り上げることが出来たので私としては一区切り出来たかなと考えています。

さて、この最終回の沖縄ですが、今年度の最終回も沖縄で開催される予定みたいですね。といってもホテルが豪華ですが、この時期の沖縄の天気は例年曇りで貼れることは珍しいのです。私は沖縄が大好きなので最終回が沖縄でとても嬉しかったです。ソーキそばおいしい!また国際通りに行きたいですね。

2018 03 東京 秋葉原 最終成果報告、ポスター展示

最後に、最終成果報告会と題して秋葉原にて一般向けのパネル展示と一部のグループ及び個人がプレゼンを行いました。この時行ったプレゼンの資料が冒頭のスライド資料になります。ここまで一年走りきれて本当に良かったと思っています。皆さんいろいろ思うことや悩んだことも合ったと思いますが、それも含めて成長できたのではないでしょうか。

デモしたい!

デモ用に撮影していた動画を貼っておきます。※一応許可をもらっています。

http://himitu23.tumblr.com/post/172795012478/sechack365-17においての自動車セキュリティチームの実験の様子です

まず、このように実際に自動車に乗って実験を行います(車種は分かる人にはわかるかもしれないですね、、)。ダッシュボード上のラズパイが今回作成した車載器になります。ここからSORACOM回線でクラウドにデータをアップロードしています。



http://himitu23.tumblr.com/post/172795105698/sechack365-17-自動車セキュリティチーム管理者向け可視化①

http://himitu23.tumblr.com/post/172818568519/sechack365-17-自動車セキュリティチーム管理者向け可視化②

Kibana上ではこのようにデータが可視化されます。管理者は複数ユーザが存在する場合は一つにデータを絞ることができます。また警告データなどの絞り込みや、過去のデータの検索を比較的簡単に行うことが出来ます。ちなみにKibanaにはAWS ElasticsearchにProxyを利用してアクセスしています。


http://himitu23.tumblr.com/post/172795341171/sechack365-17

Unityのアプリケーションは再帰的にS3に更新データがないか問い合わせにいきます。AWS LambdaでデータがS3に保存されると、更新したデータがUnityアプリケーションに表示されます。Alertフラグが立っていた場合、動画のように警告が流れるようになっています。

最後に

最終成果報告会の様子について、アスキーさんの記事に取り上げていただきました!

ascii.jp


SecHack365を通してパブリッククラウド技術を実際に利用することができて非常に私としても楽しんで取り組むことができました。この一年、就活や勉強、研究といろいろありました。またいつか皆と会えることを楽しみにしています!

と、ここまでこんなに長々と文章を書いておいて一体誰が読むんだ、、と自問自答しておりますw

いやしかし本当はまだ技術てきなレベルの記事をQiitaに書きたいのです、、

来年度からもSecHack365という取り組みがうまくいくように私も少しでもお手伝いできれば良いですね。私も社会人に向けて研究を頑張りたいと思います!

バスオフ攻撃(bus-off attack)について解説します

f:id:Tokina:20180119033302p:plain

こんにちは。

どうも、(バーチャル)論文読みおじさんです(適当)。

突然ですが、今回は自動車への攻撃手法の一つであるバスオフ攻撃(bus-off attack)についての解説をします。


といっても、バスオフ攻撃を初めて発表した論文についてまとめたので、そちらのスライドとその補足といった形になります。

この論文についてまとめている人がいないようでしたので、もしかしたら誰かの参考になると期待して・・・



早速ですが、バスオフ攻撃についてまとめたスライドを貼っておきます。


バスオフ攻撃の論文について / Where does it available?

バスオフ攻撃についての論文ですが、(ACM) CCSというセキュリティに関するカンファレンスの2016年にて発表されたError handling of in-vehicle networks makes them vulnerableがそれになります。


下記リンクのAgendaより参照できます。
ACM CCS 2016 | ACM CCS 2016 Website

Cho, Kyong-Tak, and Kang G. Shin, "Error handling of in-vehicle networks makes them vulnerable," Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, 2016.


また、以下でその論文のPDFを入手することが可能です。
Error Handling of In-vehicle Networks Makes Them Vulnerable


アブスト / Abstract

Contemporary vehicles are getting equipped with an increasing number of Electronic Control Units (ECUs) and wireless connectivities. Although these have enhanced vehicle safety and efficiency, they are accompanied with new vulnerabilities. In this paper, we unveil a new important vulnerability applicable to several in-vehicle networks including Control Area Network (CAN), the de facto standard in-vehicle network protocol. Specifically, we propose a new type of Denial-of-Service (DoS), called the bus-off attack, which exploits the error-handling scheme of in-vehicle networks to disconnect or shut down good/uncompromised ECUs. This is an important attack that must be thwarted, since the attack, once an ECU is compromised, is easy to be mounted on safety-critical ECUs while its prevention is very difficult. In addition to the discovery of this new vulnerability, we analyze its feasibility using actual in-vehicle network traffic, and demonstrate the attack on a CAN bus prototype as well as on two real vehicles. Based on our analysis and experimental results, we also propose and evaluate a mechanism to detect and prevent the bus-off attack.

つまり、私達は新しい攻撃可能性であるバスオフ攻撃を発見したよ、実際に実験してその防御の手法を考えてみたよ、ということです。

バスオフ攻撃ってなんですか? / What's the bus-off attack on vehicle?

バスオフ攻撃を理解する前に、CAN(Controller Area Network)とそのエラー処理について理解をしなければなりません。

ここではその理解を助けるための補足のリンクを紹介しておきます。

monoist.atmarkit.co.jp


上記記事にて、バスオフについての記載があります。(以下、引用です)

送信エラーカウンタの値
•0~96:警告リミット以下の『アクティブ』。エラーカウンタ値が「96」を超えるとCANコントローラは警告(エラーフラグのセット、割り込み)を発する。
•97~127:ノードは『アクティブ』。エラーカウンタ値がこのエリアにある場合、バスは重度の障害を持っていることになる。
•128~255:ノードは『パッシブ』(ほとんどのCANコントローラはこの領域への変化についてマイコンに報告しない)。また、送信待機を行う。
•255:エラーカウンタがこの値への到達後、ノードは『バスオフ』となりバスから切り離される(バスへの送信アクセスが不可となる)。マイコンはこの領域への移行を知ることができる。


これが大事です。
ECUは通常Active Error modeにいるのですが、送信エラーカウンタ(TEC)が127を超えるとPassive Error modeになります。
さらにエラーカウンタが255を超えるとバスオフ状態になってしまうのです。

f:id:Tokina:20180119032900p:plain
ECUの送信エラーカウンタによる状態遷移

このバスオフ状態になると、ネットワークから切断され、ECUのシャットダウンなどにつながってしまいます。

これを強制的に引き起こすのがバスオフ攻撃です。

この論文の攻撃手法 / The new method to bus-off attack


実際、このバスオフ攻撃の実現の可能性はもともと考えられていました。

この論文の”新規性”はバスオフ攻撃を実現するための新しい手法を提案していることにあります。

それはバスオフ攻撃を行う際のメッセージ衝突のタイミングです。
私のスライドの34ページ目(4.3 Tx Synchronization)からがそれに該当します。


簡単に言うと、強制的にノードのメッセージ送信をバッファさせ、アイドル状態になるのを待たせます。
バスがアイドルになると同時に攻撃者もメッセージを送信することでエラーを起こします。

これにより、攻撃対象のノードの送信エラーカウンタ(TEC)を増加させ、バスオフ状態にします。

実車での評価について / Evaluation using Actually Car

こちらの論文ではOBDポートから実際にバスオフ攻撃を行った評価まで行っています。

実車は以下の2台です。

  • 2013 Honda Accord
  • 2016 Hyundai Sonata

実車トラフィックは流れているメッセージの周期などが複雑であるため、プロトタイプほどうまくはいっていません。

しかしそれでもかなり実用性(?)のある結果となっています。



おまけ(その他バスオフ攻撃に関する論文について)

  • SCIS 2016 1E2-2

ラズベリーパイからのスタッフエラー注入によるCAN ECUへのバスオフ攻撃
◎亀岡 良太(立命館大学)、久保田 貴也(立命館大学)、汐崎 充(立命館大学)、白畑 正芳(立命館大学)、倉地 亮(名古屋大学)、藤野 毅(立命館大学)

プログラム|SCIS2017 暗号と情報セキュリティシンポジウム

  • マルチメディア,分散,協調とモバイル(DICOMO2017)シンポジウム 2017 pp. 1163-1168

特定のCANメッセージを送信するECUに対するバスオフ攻撃を利用したなりすまし攻撃
◎家平 和輝 (広島市立大学情報科学部), 井上 博之 (広島市立大学大学院情報科学研究科/CCDS), 石田 賢治 (広島市立大学大学院情報科学研究科)

DICOMO2017 プログラム





以上が自動車の攻撃手法の一つであるバスオフ攻撃についての紹介になります。

スライドが長いですが、興味のある方は目を通して見てください。

参考になれば幸いです。

自動車ってどうやってハッキングするんですか? [IoTSecJP #2 振り返り]

f:id:Tokina:20180108153711p:plain

こんにちは。

本記事は主にIoTSecJP #2でお話させて頂いたスライドを補足したいと思います。

まずは、今回の機会を頂いた黒林檎氏に感謝します!ありがとうございました。


さて、早速ですが、私のスライドを貼っておきます。 ※表示がちょっと崩れてしまっています



公開用に一部秘匿しています。

補足

Jeepのハッキング例について

2015年にJeepがハッキングされ、自動車のハッキング事例が脚光を浴びたのが記憶に新しいと思います。
ハッキングを成功させたのはチャーリー・ミラー(Charlie Miller)氏とクリス・ヴァラセク(Chris Valasek)氏です。
Jeepに搭載されているインフォテインメントシステム(ナビ)には3G回線と接続する機能が搭載されていました。しかし、最初からSSH可能なポートが開いていたそうです。
そこで、その脆弱性をついて遠隔操作を可能にしました。

彼らをレビューした動画がYoutubeにありました。


Hackers Remotely Kill a Jeep on the Highway—With Me in It

実際に遠隔から、実際に走行している自動車のホーンを鳴らすなど、遠隔操作を実現しています。

ジョージ・ホッツ (george Hotz)氏のCODE BLUEでの登壇内容について

今回、攻撃にターゲットを据えた話をするにあたって、折角の機会なのでジョージ氏が公開しているopenpilotについて調べてみました。
openpilotは実際にGithubに公開されています。

GitHub - commaai/openpilot: open source driving agent

彼の開発したシステムの内容をまとめますと、以下のようになると思います。
これから分かるように、各社のCANIDの解析結果がopendbcとして公開されてしまっているので、これは結構やばいのでは・・・?

f:id:Tokina:20180111031118p:plain
Geoge Hotz氏のopenpilot関係性まとめ

openpilotはオートクルーズを模擬するようなものなのですが、そのためには実際にCANメッセージなりすますことで、実際のECUをなりすまします。
しかし、各社搭載しているECUが異なる、乃ちCAN IDが異なるため、その各社同士の違いを吸収するのがopendbcになります。
openpilotは変換されたメッセージを解釈することで、自動運転を実現します。

※追記


@yubedrumsさんより、OBDドングルとの接続方法について補足頂きました。ありがとうございます!

実践!自動車ミニハックについて

例の脆弱そうなOBDドングルを実際に使ってみた例です。
コマンドを実行して、実際にCANメッセージをモニタできている様子の動画を添付しておきます。

http://himitu23-blog.tumblr.com/post/169458387666/obdドングルで自動車のcanメッセージを覗いたりする様子です

シミュレータとアナライザについて

最後に少し質問を頂いたので、メモとして残しておきます。

実際の自動車でなくても、CANの応答を確認するためのツールとしてECUシミュレータというものがあります。
少しお高いですが、、、

www.opsoc.co.jp


また、アナライザ(OBDからCANをモニタするツールとして)は下から上まで様々あります。
送信/受信バッファがある程度あるものですと、なかなか高価なものになると思います。

恐らくRasperry Pi + PiCANのセットが一番安く上がるのではないのかと思います。
ソフトウェアとしてはcan-utilsが利用できます。

skpang.co.uk

github.com

最後に

今回はBus PiratesやBluetoothハックなど、今アツイところの話をたくさん聞けたので大満足です

秋葉原にいっていろいろとあさりたいと思います!笑

自動車セキュリティの今について自分なりにまとめてみる

f:id:Tokina:20171208133818j:plain
東京モーターショー2017より

こんにちわ。
メリークリスマスまであと2週間とちょっとですね。(この記事は2017年12月8日のものです)

この記事は私の研究室のアドベントカレンダーの第三回目の記事にあたります。


皆さんはお車をお持ちでしょうか?
運転免許はお持ちでしょうか?
運転経験はいかほどでしょうか?

「自動車のセキュリティって聞いてどう感じますか?」

たぶんそんなのずっと先のことだよ、とか
そんなの実際に起こるわけないよ、など感じる方がほとんどだと思います。

そこで、自分の経験から自動車セキュリティについて、それが一体どんなものかまとめてみたいと思います。

今回はとても長いので「続きから読む」機能をつけておきます!

続きを読む

Write Up - Practical CAN bus hacking

f:id:Tokina:20171113184354p:plain

こんにちわ。

ライトアップ書きます書きました!忘れないうちに・・・
分かる人には分かるレベルで書こうと思います。
書いていたらまた来年も出たくなってきました。


さて、皆さんもごぞんじCODE BLUEに参加してきました。
今回学生スタッフの応募をしていたのは知っていたのですが、CAN HackのCTFに出てみないかとお声掛けいただいたので、折角の機会なのでチャレンジした次第です。
SecHack365の人や、その他の知り合いの人がたくさんいて楽しい限りでした。皆さんお疲れ様でしたー!


codeblue.jp


CODE BLUEでは複数のCTFが同時に開催されています。
私が参加したのは、Practical CAN bus hackingというCTFです。

f:id:Tokina:20171113184930g:plain

みなさんは実際のCANバスをハッキングしたことがありますか?CANバスのハッキングとは、どんなものだと思いますか?難しい?高価なデバイスが必要?答えを知るために、ぜひ私達のCTFに参加し、あなた自身の手で私達のラジコンカーをハッキングしてみて下さい!


え、CANなのにCTF?

私も初めての参加なのでそう思いました。だってCANは16進数との格闘ですし・・・

それでは、ぬるっとらいとあっぷかきます

参加メンバー

今回、広島市立大学が主体で協力していただきました
そこで、某I先生の働きかけにより、Trillium 株式会社さんと協力して挑みました。

www.trillium.co.jp


もうひとり、筑波大学の友人と合わせて2チーム結成しました。
私のチームは、「私、広島市立大学学部生、Trilliumさん」です。

ちなみに、Trilliumさんの社員さんは外国の方が多くおられるので、皆さん英語でコミュニケーションをとります。
もちろん、CTFも英語でした・・・
私英語そんなとくいではないです。

CTFの環境

「CANのCTFって一体どんな感じでやるんだ???」

参加したことないので、何が必要か、どんな環境かわからずに参加しました。

当日行って、初めて目にしたことになりますね

f:id:Tokina:20171114135454j:plain
Practical CAN bus hacking のCTF環境

こんな感じでした。
なるほど、なるほど・・・

Raspberry PiにPiCANシールドを載せ、そのRaspPiが実際のラジコンカーのような動作を実現しているようです。
このPiCANボードは私もよく触っていたので懐かしかったですね。

わかりやすく図にするとこんな感じです。CANレベルでしかアクセスできません!※解析用ラズパイにはSSHできます。


f:id:Tokina:20171114140911p:plain
CTF環境のイメージ

解析対象もラズパイなのですが、挙動から察するに何かと通信しているみたいでした。
解析対象はCAN以外でアクセスすることが(当たり前ですが)禁止されていました。

使用機器

解析に使用した機器についても簡単にまとめておきます。

  • neo VI Fire (またはValueCAN)& Vehicle Spy 

アナライズに最適なツールです。CANoeよりアナライズに適しているのは間違いないです。
得意なのはリアルタイム解析です。
スクリプトは書けますが不便です。あと一つのメッセージ送るのも面倒です。

  • MicroPecker

ログ分析に最適です。
ログエディターが超優秀なのです。今回はあまりその機能は使いませんでしたが。
スクリプトは作れません。簡単なトリガのみなら設定可能です。

  • CANtact

持っていきましたが使えませんでした。(ケーブルが足りず)
MacPythonスクリプトが使えますし、VMLinuxで通常のCAN-utilsを走らせることができます。
まぁ次のラズパイにSSHすれば良いのですが、SSH環境がないときのためでもありました。

解析対象のラズパイに接続されていた参加者共通の解析機器です。基本的にこのラズパイを利用して解析を進めていく形になります。
標準的なCAN-utilsが使用可能でした。


個人的に本当はCANoeを使いたかったのですが、てにはいりませんでした!w
え、きゃんぬーしらない?

jp.vector.com


とても高いらしいですよ。私も某自動車会社でしか触ったことないです。
ただ、とてもとても便利です。手に入る方は是非使ってみてね。
CANoeが得意なのは(CAPLと呼ばれる)スクリプトです。

事前知識

CANについては皆さんご存知だと思います(ということにしておきます)

今回の環境ではCAN IDとしてExt. IDが使用されていました。通常よりも長い宛先アドレスIDを持つものです。
このExt. IDでは通常のCAN IDの2倍、乃ち4byteが利用可能です。
今回開催者が用意した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でした。


ちなみにこんな感じでやってました。

f:id:Tokina:20171114141656j:plain
共通解析器のラズパイでモニタしている様子

Problem - Capture the Flag

f:id:Tokina:20171114144426p:plain

解けたのだけあっぷします!
もっと解けた人のWriteUpよみたい、、、

ちなみにcandump –d –x –e –a can0 | grep 01240101
のように0101でメッセージを送信し、返信のみを取り出すと以下のようにFlagが降ってきます。以降、Flagが降ってくるというときはこんな感じだと思ってください。


f:id:Tokina:20171114151656p:plain

拡大したものなのでぼやけてしまっていますね

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

ここから2日目に突入するので一度問題を持ち帰りました。
CTF-3はユーロビートでした。ちょっとよくわからなかったですが、他の問題をやっていくうちにわかりました。
車内に音楽再生のユーロビートがあるので、乗っ取っていじってやろう、というものでした。
結局解かなかったですが。。

CTF-4

これ、2日目に一番つまりました。
EngineのECUとのセキュアなセッションを開く際のやり取りをSniffしたので、これを基にセキュアセッションを確立せよ、というものです。
ちなみにCAN界隈ではSecurity Accessと呼んでいます。
1日目の夜に色々調べたりしたのですが、他のチームが解く速度を察するにそこまで難しいものではないはずです。
ヒントを使ったのですが、使う意味があまりありませんでした。

そして何も出来ない午前を過ごし、MiroPeckerで大量にロギングし、ログ分析をしていて気づきました。
そう、同じシード値が使いまわされていたのです。
シード値は問い合わせる度に変更されるので、そこに注意しつつSniffしたものと同じシード値が返ってきたらSniffしたものと同じ鍵を送信する、それだけでした。
このためのPythonスクリプトを後輩に書いてもらって、どうにかなりました。

SecurityAccessを取得し、この状態じゃないと実行できないコマンドを送ればFlagが降ってきます。

CTF-5

「例」としてSteeringのECUとSecurity Accessのやりとりを示すので、どうですか?みたいなやつです
そう、例なので、CTF-4と同じやり方ではありません。
また、その他のチームの解く速度から察するにBrute Forceではなさそうでした。

ヒントを使いました。(あとから考えると、これも使わなくてよかったとは思うのですが)
ヒントは「ビットシフト」

例を見ると、どうやらシードを右にあるビットだけシフトさせると鍵になっていることが分かりました。
これをもとに、シード値を問い合わせる➔鍵を送信する
これでSuccessし、CTF-4と同じようにこの状態のみ有効なコマンドでFlagが降ってきます。

ちなみに残り7分のところでFlagが降ってきました笑

CTF-6

これがあとちょっとだったはずなのに、解けませんでした。
問題はFirmwareをdumpせよ、というものです。ヒントもありません。

通常、CANでDumpといえばOBDのISOTP標準、もしくは物理的にアクセスを試みてFirmwareをdumpするはずなのに、、
うーんうーんと悩んだ結果、やっぱりCTF-4で取得したSecurity Accessの状態でREAD BY ADDRESSしたアドレスを何かするんだと思います。
これをTrilliumさんが挑んでくれていたのですが、どうにもなりませんでした。

CTF-7~

これ以降解くことが出来たチームはいなかったと思います。あまり覚えていませんが、、
これ以降はFirmwareをDumpすることが必須となっているので、まったくわかりません。
もっと勉強します!

結果

f:id:Tokina:20171114151805p:plain
チームTrilliumの最終的なChallengeの画面

f:id:Tokina:20171114141343j:plain

私達のチームはTrilliumとUMR with Tです。私はTrillium側なので残念ながら5位でした。
一位はイエラエセキュリティさんです。強すぎます・・・。次回は勝ちたい。。。!
あとヒントを使わなければチームUMRに勝てたのに。。。

最後に

CTFということで、実際の自動車の解析と直結しているわけではなかったのですが、とてもおもしろいものでした。
普段(?)は実車リバースエンジニアリングしたり、ふにゃふにゃしたりしているので、正直今回のCTFは別物でした。
そもそも送信元アドレスあるなんて。。。

また、某自動車会社に行った際の経験を少しでも活かすことができたと思います。
その自動車会社の人も来られていたので、世界は狭いなあと実感しましたね。
結構自動車関連で知ってる人がちらほらと増えてきているような気がします。そうでもない?

また、今回協力していただいたTrilliumさんにも非常に感謝です!実は日曜日に英検の二次試験があったのでとてもちょうどよかったです!
今後とも機会があれば一緒にお仕事などさせてもらいたいです。


実はCANtactという面白いCANツールをお借りする機会があったので、そちらについても記事をかきたい!


あとCBで講演してる方で、Toyota Crypto 300といってToyotaの鍵生成の仕組みを知りたいと言ってる方がいたようですね。
それにもチャレンジしてみたいですね。

SecHack365の紹介(トレーニーより)

sechack365.nict.go.jp


こんにちわ。

(実は)私は2017年度からスタートしたSecHack365という年間を通したハッカソンに参加しています。

SecHack365 は高度な技術力を持つセキュリティ研究者や開発者を育成することで、我が国のセキュリティ技術力、産業競争力を高めることを目的としています。


というわけで、今回LTをする機会があり、SecHack365の紹介をしてきましたので、せっかくなのでその資料をUploadしておこうと思います。

遠くないうちに第一回からの備忘録を書きたいと思うのですが。。



おまけ

SecHack365はたくさんのスタッフさんや著名な方々がバックアップしてくれています。
そこで、スタッフとしてお手伝いしてくれる方のことをトレーナー、参加者のことをトレーニーと呼んでいます。

次回は大阪なのですが、クリスマスイブが・・・!

MacでopenSUSEのLiveUSBを作成してMacでブートできるようにしたよ

f:id:Tokina:20171024144618p:plain

 

とてつもなく久しぶりにブログを書きます

どうも、Tokinaです

 

さすがにブログは誰も見ていないとは思いますが、せっかくの残りの大学院生の生活でできるだけ多くのことを残していきたいと思います。

 

実は私は電気通信大学の学生で、本学にてopenSUSE.Asia Summit 2017が開催され、そこで学生ボランティアとしてお手伝いさせて頂きました。そちらについては別の記事として書きます!

そこでいろいろお話を聞くことができ、「openSUSEのカメレオンかわいい!」となったので、MacopenSUSEを使ってみたいと思い、久しぶりに記事をかきかきしていているのです

(えっ、カメレオンじゃなくてヤモリなんですか。。。)

 

さて、本題に入りましょう。

 

アジェンダ

 

 

 

openSUSEについて

openSUSEは誰もがご存知(たぶん)と思います。知ってます?

簡単に説明しますと、世界的オープンソースディストリビューションです。そこには多くのその思想に共感したディストリビューターたちがテクノロジーを高めあっています。詳しくは割愛しますが、ギーコ(Geeko)ちゃんが目印です。詳しくは日本のWikiを参照してください。Have a lot of fun ...

無料でインストールディスクとか配っていたので、それを今回は利用しました。

 

 

f:id:Tokina:20171024144308j:plain

 

このLEAPというのは安定バージョン(いわゆるLTS)です。

あとTumbleweedtとはどんどんアップロードされているローリング版です(不安定っちゃ不安定、開発者向け)。

今回はこのLEAP 42.3を入れることにしました。

 

※裏面には熱い気持ちが書かれています

f:id:Tokina:20171024144303j:plain

 

LiveUSB作成までの流れ

  1. ISOイメージを持ってくる
    今回はもらったDVDディスクをImageBurnでばーんしました
  2. ブータブルUSBを作る(意味は後述)
    Windowsでもなんでもいいのですが、今回はMacだけでも完結できます
  3. 何かしらのPCでブータブルUSBを起動し、LiveUSBにしたいUSBメモリに書き込む
    これもなんでもいいのですが、Macでやりました
  4. 起動確認
    どこでも起動できるLiveUSBの完成です

 

用意したUSBメモリ

8Gあれば足りるよ!と聞いていたのですが、openSUSEの標準デスクトップのKDEを入れようとするとちょっと足りないので、できれば16GBより大きいものを推奨します

 

私は8GBより大きなUSBメモリはメイン使用の32GBのものしかもったいませんでしたw

あと、もしブータブルUSBメモリ(インストールするためのUSBメモリ)を作る人がいたら、その人はUSBメモリを二つ用意してください。

ブータブルディスクとかの人はLiveUSBに書き込むところまで飛ばしてください。

 

 

 

MacでブータブルUSBを作成する

この手順は超かんたんです。間違えると死にます。

間違えるとデータが消えます。

 1.Macに接続されたUSBメモリを確認する

 $ diskutil list

ここでブータブルUSBを作成したいUSBメモリを見つけます

 2.半マウント状態にする

$ diskutil unmountDisk /disk/disk???

???はさっき見つけたUSBメモリです。普通disk2以降です。これで見えないのにマウントされた状態になります。

 3.ddコマンドを使ってISOファイルを書き込む

$ dd if='path of your ISO file's directly' of=/dev/rdisk??? bs=4k

 

これで何も出ないですが、ちょっと待ちます。終わるとなんか出ます。

ちなみにddはすごいコピーのコマンドです。bsは書き込みサイズ指定してます。

終わったらエラーと怒られ、Finderさんにもエラーと怒られましたが、普通に引っこ抜きました。

 

これでブータブルUSBがたぶんできました

WindowsでブータブルUSBを作成する

これもいくつか試しました。 最近脆弱性が発表された気がするRufusをつかうのがやはり安定でしょう。ちなみに、他のLinux Live USB Creatorとかでは上手く行きませんでした。unetbootinはつかわないようにと警告されているそうですので、やめておくのが無難でしょう。FATですよ

 

LiveUSBとブータブルUSBの違い

いろいろ調べていて思いましたが、あんまり区別されていないので私自身よくわかっていません

 

どうやら

  • LiveUSB➔PCからUSBメモリ本体をホストとして起動する
  • ブータブルUSB➔OSイメージを入れたインストールディスクとして利用する

こんな認識で調べていくと、大体うまくいくことがわかりましたよ(超いまさら)

最後LiveUSBを作成したのは6年ほどまえにBackTrackのLiveUSBを作った以来ですから。。。新しくKaliさんのLiveUSBも作りたいです

 

ブータブルUSBを起動してLiveUSBを作成する

Macで起動する際にAltを長押ししてブートメディアを選択します

Bootcampを使ってる人は分かるかと思います

 

f:id:Tokina:20171024001745p:plain

 

ここでinstallationを選択してそこそこ進みますと、パーティションの提案を行ってきます。ここで、デフォルトではMacのメインパーティション全てを上書きする設定になっているので、慎重にLiveUSBにする予定のUSBを選択する。パーティション設定の作成から選択できるはずです。

f:id:Tokina:20171024002314p:plain

※上記の例はVirtualBoxでインストールするときのものです

 

あとは少し時間がかかりますがインストールを待つのみです。

 

openSUSEの起動

USBハブから起動出来ない場合もあるので、マシンに直接LiveUSBを挿入する必要があるかも。一瞬welcome to GRUB!と表示されたりされなかったりして起動します。

f:id:Tokina:20171024003026p:plain

もしインストールの画面がでたらboot from hard diskを選択すればOKでした

 

 

可視化が面白いので皆さん試してみてください。 

f:id:Tokina:20171024144236j:plain

 

久しぶりに真面目に大した事ない記事を書きました。

書きたいことは色々在るのですが・・・

AWS関連のことやインターンについてまとめたいと思っています