SecHack365 @2017のまとめをアーキテクチャとともに振り返る！
SecHack365@2017を振り返ろう
こんにちは。 遅くなりましたが、昨年2017年度に参加していたSecHack365ですが、先月無事に卒業することができました。今回はそのまとめについて書いていきたいと思います。
まず、私達のグループが最終報告回で発表した資料（一部修正）はこちらになります。忙しい方はこちらの資料に目を通して「ふーん」と思ってくれるだけでありがたいです！
改めまして、私は現在電気通信大学の大学院生をやっていますtokina(ひみつ)です。昔はネットワーク系の研究室に所属しており、自動車のセキュリティについての研究をしていました。現在は電通大のネットワーク系の研究室に移籍し、IoTに関する研究をしております。昨年からパブリッククラウド技術に興味を持ち始め、今回SecHack365の私のチームの中でもクラウド部分をメインに担当しています。
SecHack365について詳しくは以下のページをご参照下さい。
また、日程が非常に近いですが、SECCON×SecHackのセチャコンというイベントが開催予定です。皆さんよければ足を運んでみて下さい。秋葉原行きましょう！ 2017.seccon.jp
現在('18.04.09執筆時)には2018年度生を募集しています。課題申し込みと提出申し込み締切が異なるので注意して下さい。 学生の方は無料で参加できます。ただし自己管理は徹底して下さいね。
今回、一年の総轄としてまとめました。SecHack365参加を目指す方の参考になれば幸いです。
私にとってのSecHack365（SecHack367）とは
私にとって、振り返ってみるとSecHack365とは技術的交流はもちろん、自身のモチベーションをしてくれる環境でした。
しかし、この機会で出会うことが出来た人や、今後の指針が見えてきたこともあり、私にとってはとても大切な一年だったことは間違いないと思っています。
ちなみに就職活動とかでも役に立つと思います！
え、 SecHack367 ですか？気になる方は参加して見ましょう！
応募のキッカケ
キッカケとは些細なものだと思います。私はセキュリティ・キャンプに参加していたので、サイボウズで情報が流れてきており、耳にはしていました。しかし、私はギリギリまで申し込んではいなかったのです。
申し込み期限前日、私はそういえばと思いサイボウズを開き、このSecHack365に応募しました。ちなみに応募課題は非公開だそうです。
最初、SecHack365を見たときに、「キャンプ関連なんだろうか・・・」くらいに漠然と考えていました。
実際に参加するとキャンプの講師やTAレベルの人が沢山おり、最初は不安でいっぱいでした。。。
ちなみに選考の基準ですが、「参加してともにイノベーションを起こせるか（なにか新しいことをひらめけるか）」だそうです（たしかそういっていた）。
学歴や大学、住んでいる場所とかは一切選考に関係ないそうです。また、名前も伏せて選考されます。つまり、応募者が何を考えているかの本質が見られるのだと思います。
プログラミング能力は必須でしょうか？
私は”必須”だと思います。無いと困るとかではなく、少なくとも「アイデアを実現する力」のタネが必要だと思います。まぁハッカソンだからとも言えるでしょうか。
ちなみに私のプログラミング能力はそんなに高くない...と思っています。
チームメンバーの紹介
私のチームは４人チームでした。チームメイトは私を含め以下の方たちでした。
@o_hi_rangosta, @kiyoooo44,@_tokina23 (私), @Balius1064
また、途中で（私が勝手にお願いして）特別顧問として協力してくれた
@Shi_ma715, @sm_nz_gk
みなさん、ありがとうございました！
SecHack365でなにをつくっていたのか？
私のグループでハッカソンしていたのは、一言で言うと 『自動車の情報を収集し、自動車情報を利活用するプラットフォーム』 です。最初の着眼点は「パブリッククラウドを使って自動車の情報を収集した例って聞いたこと無いよね？」「簡単にできそうだけど、実際に作ってみたらなにか見えてこないかな？」というところからでした。そこから見えてきたのが 「自動運転のための運転者データの収集」 でした。
全体の概要図は下図のようになります。こちらは実際の成果発表会で使用した資料を一部修正したものです。
実際にこのハッカソンでは 自動車に搭載する車載器から、フロントエンドの可視化まで一貫して作成 しています。これにより、自動車を完全に”IoT”化できました（たぶｎ）。
最終的にハッカソンで出来上がったアーキテクチャですが、もともとこのような最終形を想定していませんでした。今回は折角なので、そのアーキテクチャとともに振り返ってみたいと思います。
アーキテクチャと若干詳しい解説
私達グループメンバーはこの概要図にある通り、全体のうちの一部をそれぞれを担当していました。私はこの中で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 東京 秋葉原 最終成果報告、ポスター展示
最後に、最終成果報告会と題して秋葉原にて一般向けのパネル展示と一部のグループ及び個人がプレゼンを行いました。この時行ったプレゼンの資料が冒頭のスライド資料になります。ここまで一年走りきれて本当に良かったと思っています。皆さんいろいろ思うことや悩んだことも合ったと思いますが、それも含めて成長できたのではないでしょうか。
デモしたい！
デモ用に撮影していた動画を貼っておきます。※一応許可をもらっています。
まず、このように実際に自動車に乗って実験を行います（車種は分かる人にはわかるかもしれないですね、、）。ダッシュボード上のラズパイが今回作成した車載器になります。ここからSORACOM回線でクラウドにデータをアップロードしています。
Kibana上ではこのようにデータが可視化されます。管理者は複数ユーザが存在する場合は一つにデータを絞ることができます。また警告データなどの絞り込みや、過去のデータの検索を比較的簡単に行うことが出来ます。ちなみにKibanaにはAWS ElasticsearchにProxyを利用してアクセスしています。
Unityのアプリケーションは再帰的にS3に更新データがないか問い合わせにいきます。AWS LambdaでデータがS3に保存されると、更新したデータがUnityアプリケーションに表示されます。Alertフラグが立っていた場合、動画のように警告が流れるようになっています。
最後に
最終成果報告会の様子について、アスキーさんの記事に取り上げていただきました！
SecHack365を通してパブリッククラウド技術を実際に利用することができて非常に私としても楽しんで取り組むことができました。この一年、就活や勉強、研究といろいろありました。またいつか皆と会えることを楽しみにしています!
と、ここまでこんなに長々と文章を書いておいて一体誰が読むんだ、、と自問自答しておりますｗ
いやしかし本当はまだ技術てきなレベルの記事をQiitaに書きたいのです、、
来年度からもSecHack365という取り組みがうまくいくように私も少しでもお手伝いできれば良いですね。私も社会人に向けて研究を頑張りたいと思います！
バスオフ攻撃(bus-off attack)について解説します
こんにちは。
どうも、（バーチャル）論文読みおじさんです（適当）。
突然ですが、今回は自動車への攻撃手法の一つであるバスオフ攻撃（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）とそのエラー処理について理解をしなければなりません。
ここではその理解を助けるための補足のリンクを紹介しておきます。
上記記事にて、バスオフについての記載があります。（以下、引用です）
送信エラーカウンタの値
•0～96：警告リミット以下の『アクティブ』。エラーカウンタ値が「96」を超えるとCANコントローラは警告（エラーフラグのセット、割り込み）を発する。
•97～127：ノードは『アクティブ』。エラーカウンタ値がこのエリアにある場合、バスは重度の障害を持っていることになる。
•128～255：ノードは『パッシブ』（ほとんどのCANコントローラはこの領域への変化についてマイコンに報告しない）。また、送信待機を行う。
•255：エラーカウンタがこの値への到達後、ノードは『バスオフ』となりバスから切り離される(バスへの送信アクセスが不可となる)。マイコンはこの領域への移行を知ることができる。
これが大事です。
各ECUは通常Active Error modeにいるのですが、送信エラーカウンタ（TEC）が127を超えるとPassive Error modeになります。
さらにエラーカウンタが255を超えるとバスオフ状態になってしまうのです。
このバスオフ状態になると、ネットワークから切断され、ECUのシャットダウンなどにつながってしまいます。
これを強制的に引き起こすのがバスオフ攻撃です。
この論文の攻撃手法 / The new method to bus-off attack
実際、このバスオフ攻撃の実現の可能性はもともと考えられていました。
この論文の”新規性”はバスオフ攻撃を実現するための新しい手法を提案していることにあります。
それはバスオフ攻撃を行う際のメッセージ衝突のタイミングです。
私のスライドの34ページ目（4.3 Tx Synchronization）からがそれに該当します。
簡単に言うと、強制的にノードのメッセージ送信をバッファさせ、アイドル状態になるのを待たせます。
バスがアイドルになると同時に攻撃者もメッセージを送信することでエラーを起こします。
これにより、攻撃対象のノードの送信エラーカウンタ（TEC）を増加させ、バスオフ状態にします。
実車での評価について / Evaluation using Actually Car
こちらの論文ではOBDポートから実際にバスオフ攻撃を行った評価まで行っています。
実車は以下の２台です。
- 2013 Honda Accord
- 2016 Hyundai Sonata
実車トラフィックは流れているメッセージの周期などが複雑であるため、プロトタイプほどうまくはいっていません。
しかしそれでもかなり実用性（？）のある結果となっています。
おまけ（その他バスオフ攻撃に関する論文について）
- SCIS 2016 1E2-2
ラズベリーパイからのスタッフエラー注入によるCAN ECUへのバスオフ攻撃
◎亀岡 良太(立命館大学)、久保田 貴也(立命館大学)、汐崎 充(立命館大学)、白畑 正芳(立命館大学)、倉地 亮(名古屋大学)、藤野 毅(立命館大学)
プログラム｜SCIS2017 暗号と情報セキュリティシンポジウム
- マルチメディア，分散，協調とモバイル(DICOMO2017)シンポジウム 2017 pp. 1163-1168
特定のCANメッセージを送信するECUに対するバスオフ攻撃を利用したなりすまし攻撃
◎家平 和輝 (広島市立大学情報科学部), 井上 博之 (広島市立大学大学院情報科学研究科/CCDS), 石田 賢治 (広島市立大学大学院情報科学研究科)
以上が自動車の攻撃手法の一つであるバスオフ攻撃についての紹介になります。
スライドが長いですが、興味のある方は目を通して見てください。
参考になれば幸いです。
自動車ってどうやってハッキングするんですか？ [IoTSecJP #2 振り返り]
こんにちは。
本記事は主にIoTSecJP #2でお話させて頂いたスライドを補足したいと思います。
まずは、今回の機会を頂いた黒林檎氏に感謝します！ありがとうございました。
さて、早速ですが、私のスライドを貼っておきます。 ※表示がちょっと崩れてしまっています
公開用に一部秘匿しています。
補足
Jeepのハッキング例について
2015年にJeepがハッキングされ、自動車のハッキング事例が脚光を浴びたのが記憶に新しいと思います。
ハッキングを成功させたのはチャーリー・ミラー（Charlie Miller）氏とクリス・ヴァラセク（Chris Valasek）氏です。
Jeepに搭載されているインフォテインメントシステム（ナビ）には３G回線と接続する機能が搭載されていました。しかし、最初から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として公開されてしまっているので、これは結構やばいのでは・・・？
openpilotはオートクルーズを模擬するようなものなのですが、そのためには実際にCANメッセージなりすますことで、実際のECUをなりすまします。
しかし、各社搭載しているECUが異なる、乃ちCAN IDが異なるため、その各社同士の違いを吸収するのがopendbcになります。
openpilotは変換されたメッセージを解釈することで、自動運転を実現します。
※追記
こんにちは、素晴らしい資料拝見させて頂きました。comma.aiのODBドングルのpandaはUSB接続かwi-fiのアクセスポイントになるのでそれで接続出来ますよ
— ユベ (@yubedrums) 2018年1月9日
@yubedrumsさんより、OBDドングルとの接続方法について補足頂きました。ありがとうございます！
実践！自動車ミニハックについて
例の脆弱そうなOBDドングルを実際に使ってみた例です。
コマンドを実行して、実際にCANメッセージをモニタできている様子の動画を添付しておきます。
シミュレータとアナライザについて
最後に少し質問を頂いたので、メモとして残しておきます。
実際の自動車でなくても、CANの応答を確認するためのツールとしてECUシミュレータというものがあります。
少しお高いですが、、、
また、アナライザ（OBDからCANをモニタするツールとして）は下から上まで様々あります。
送信/受信バッファがある程度あるものですと、なかなか高価なものになると思います。
恐らくRasperry Pi + PiCANのセットが一番安く上がるのではないのかと思います。
ソフトウェアとしてはcan-utilsが利用できます。
