総サイバーセキュリティLT大会のLT

1. IoT診断入門
村島 正浩(黒林檎)

2. [+] プロフィール
所属 : 株式会社 神戸デジタル・ラボ( kdl.co.jp )
ハンドルネーム : 黒林檎
Twitter : r00tapple
Facebook : 村島正浩
Mail : packr@packr.org
注意:試験的に行い考察した結果で
あるため実際とは異なる結果も含ま
れている可能性が存在します。
これの人です

3. LT時間延長
!w

4. 皆さんの思う
IoTのセキュリティって
何ですか?

5. [+] IoTセキュリティの範囲とは・・？

6. 簡単なアーキテクチャ図を作成したので、
これを元にIoT機器への攻撃経路を考えていき
ましょう。
■攻撃経路の決定
1)システムの把握・図式化
2)問題点をコンポーネント単位で切り分ける
3)攻撃箇所を一覧化し、手法・目的を決める

7. [+]各コンポーネントで起こり得る問題
[ 無線通信 ]
・平文通信
・リプレイ攻撃
・中間者攻撃
・認証(ペアリングなど)をキャプチャ
[ web/mobile/cloud ]
・認証/認可の欠陥
・安全でないネットワーク通信
・ロジックの欠陥
・その他考えられる脆弱性すべて
[ IoTデバイス ]
・ハードコードされた機密情報
・ファームウェアの改ざん
・物理的にシェルへのアクセス
REST
API

8. [+] 対象製品の攻撃経路を一覧化する
製品 攻撃経路 攻撃例 攻撃結果・成果物
IoT Device
Bluetooth LE
リプレイアタック
不正に命令を実行する(今回で
あれば鍵の開錠)
スニッフィング 鍵などの情報漏洩
Hardware
インターフェース
シェルにアクセスする、ログ情
報の表示
ファームウェア解析
悪用可能なファームウェアの脆
弱性を見つける
秘密鍵などの情報などを取得す
る
Cloud
リプレイアタック
不正に命令を実行する(今回で
あれば鍵の開錠)
スニッフィング なりすまし攻撃
IoTのセキュリティを考
える・診断する場合、対
象のIoTデバイスごとに、
どの経路からどのような
攻撃でどのような情報が
もっていかれるか？など
を考えることが重要。
おそらく実際にIoT製品
を攻撃する攻撃者であれ
ば製品マニュアルなどに
目を通して攻撃面のマッ
ピングをし攻撃の効率化
を図っている。
※最終的に、「IoTの何を守りますか?!」で出てきた図以上にプロトコルなどもマッピングして図式化する。
※会場時間短縮-要約必須

9. [+] セキュアだった BLE IoT事例紹介
・Android
・iPhone
・Bluetooth LE
今日は、シンプルに一番IoTらしい
Point-to-Pointデバイス
※機器の固有特定情報は、除いてい
ます。

10. [+] セキュアでは無いIoT製品例
IoT
 認証せずに、リクエストを通してしまう
簡単に不正な操作ができてしまう
 リプレイアタックが出来てしまう
正規ユーザーと同じ操作を不正に可能
 パケット盗聴で情報が漏洩する
電話帳などのデータが送信中に漏洩する可能性
BLE認証方式
確認なし - Just Works
６桁の認証コードを表示しての一致確認 - Numeric Comparison
６桁の認証コードを打ち込むことによる確認 - Passkey Entry
Bluetooth 以外の通信 (USB/NFC) による確認 - Out-Of-Band・OOB
Hack IoT !

11. [+] BLE IoT セキュア #とは？
IoT
ペアリング-暗号鍵の共有化(LTK)
接続デバイスを1台に制限
Bonded Device
Not Bonded Device
(1)ペアリング&ボンディング
アドバタイジングパケットを
コピーして、IoT機器より速い
速度でアドバタイズを流せば
正規ユーザーをだまして中間
者攻撃の要領でリプレイア
タックが可能では?
(3)Disconnect
[Memo]
リプレイアタックや未認証デバイス
からの命令にどうセキュアに保つか

12. [+] なぜ、セキュア?
[リプレイアタックに対して]
前提としてIoT機器はコネクションを単一接続しか許可しないため、”図(2)”のように2台目が接続してきた場合
に”図(3)”の通りIoT機器は既に接続していたユーザーとの通信を切断します。
よって、攻撃者はリプレイアタック(BLEのリプレイアタックは、攻撃者がIoT機器になりすまして正規ユーザー
の通信をプロキシのように経由してコピーする事)の待ち受けのためにIoT機器に接続しても、正規ユーザーのコ
ネクションが切断されてしまうためパケットが取得できないという事になります。
[不正な命令送信に対して]
また、攻撃者が通信解析により命令の送信値など
を解析しIoT機器に直接不正に命令を送信しても
命令が実行されないように”図(1)”のペアリング&
ボンディングの際に正規ユーザーとして認証を行
いLTKを生成する。
※会場時間短縮-要約必須

13. 体温計 電子錠 コーヒーマシン
[+] Secure made in Japan
Bluetooth IoT Series・・・
・・・みたいな機械
・・・みたいな機械・・・みたいな機械

14. [1] 体温計みたいな機械
[仕様]
NFC通信とBluetooth LE通信を持っている。
Androidは、NFC通信限定
iPhoneは、Bluetooth LE限定
※Androidには、デフォルトでBLEのパケットをとる機能があるの
で、それを避けるためにBLE非対応にした可能性あり
[結果]
・コネクション数を1台に制限
・BLEビーコン含み、パケットは体温を測って機器をフタにしまわ
ないと飛ばない。
※会場時間短縮-要約必須

15. [解説] 体温計みたいな機械
…興味深いつくり方だったので
iPhone
Apple
NFCが対応していない端末が多い
ので、Bluetooth LEのみに対応
基本的なBluetooth LEのセキュリ
ティ対策施しとけば出荷後問題起
き無さそう。
NFCに対応してる端末は割と多い、
BluetoothのパケットをHCIス
ヌープログという機能で簡単にと
られ解析されるので、NFCのみの
対応(※個人的見解)
IoT機器として出荷するけど、
改ざんとか怖すぎ、でも顧客層
として各デバイスに対応したい。
後、自社開発したアプリ以外でも
データを扱えるような設計にした
い(NFC)
※会場時間短縮-要約必須

16. [2] 電子錠みたいな機械
[仕様]
Bluetooth LE通信
拡張機能でWiFi経由も出来る(今回対象外)
[結果]
・コネクション数を1台に制限
・ペアリング(LTK)
・Bluetooth LEのコネクションを常に張っているわけでなくアプリ
側で開錠命令などを実行する際にコネクションを張ります。
※会場時間短縮-要約必須

17. [3] コーヒーマシンみたいな機械
[仕様]
Bluetooth LE通信
[結果]
・コネクション数を1台に制限
・ペアリング(LTK)
・Bluetooth LEのコネクションを常に張っているわけでなくアプリ
側で抽出命令などを実行する際にコネクションを張ります。
※会場時間短縮-要約必須

18. 体温計 電子錠 コーヒーマシン
[+] Secure BLE IoT Series・・
・・・みたいな機械
・・・みたいな機械・・・みたいな機械

19. [+]BLE Connection Intervalについて
※会場時間短縮-要約必須
Slave
Master
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
T
X
Slave
latency
Connection
Interval
Connection
Interval
Connection
Interval
電源消費量を下げるために
コネクションの持続時間を
適切に制御する作り方して
いる。
無駄なコネクションを張ら
ずに最低時間で通信を終わ
らすことはセキュリティの
欠陥を探す側としてはリア
ルタイム性を求められて攻
撃がしにくいなど感じまし
た。

20. 診断対象・診断報告書
の問題点

21. OWASP Internet of Things Project
■OWASP TOP 10
脆弱性診断でIoTデバイスとアプリケーションを評価す
るための手助けをする目的で作成された網羅的に基本
を書かれたガイドライン。
実際に、IoT診断報告書を試験的に書いてみて思ったこ
とを2点に絞って今回はお話しします。

22. ※会場時間短縮-要約必須
実際に、いくつかの検
証を行った上で診断報
告書の練習をしてみた
りしましたが、結果
(鍵であれば不正開錠
に成功した)などの例
を文字と画像で表すの
は大変難しい。
開発者が「あ～、その
プロファイルか～。な
るほど、そのUUIDで
すね～。」ぐらいじゃ
ないと脆弱性が伝えて
理解して貰うことがそ
もそも難しい。

23. 外注した製品が最初からmaliciousな場合
IoT機器が通信するAPIサーバーにウイルスを仕込まれている
※会場時間短縮-要約必須
販売
メーカー
外注のIoT
製作会社
クラウドAPI使う、
カメラIoT制作して～
畏まりました
(1)セキュリティ気に掛けるほど単価高くないは、
ウェブサーバーとかも管理せんでええやろ
-> [結果]クラックされAPIサーバーがマルウェア
のC&Cサーバーになる
(2)この会社単価も低いし知識無さそうやな、
maliciousな機器作ってバラまいてもらうで～(笑)
※ここでいう外注(委託先)は海外を含み
ます。

24. IoT診断入門
-vol2-
村島 正浩

25. 脆弱性の回収

26. [+]OTAという考え方

27. [+] Over The Airの重要性
無線ネットワークを用いてシステム更新(ファームウェアアップデー
ト)が出来る仕様がIoTでは重要になります。
コンシューマ製品のセキュリティはとても大切だと思われます。
脆弱性など情報などが掲載されて、回収できないシステムであった場
合最悪製品の回収騒ぎになり、結果として、会社の信頼性が低下する
と容易に考えられます。
しかし、OTAでファームウェアアップデートができる場合、脆弱性を
指摘されても「OTA経由でファームウェアアップデートは可能」と返
答し修正することができます。(実際、セキュリティの欠陥を指摘さ
れた企業は返答として「回収可能」という文字を強調します。)
※会場時間短縮-要約必須

28. [+] OTAに頼りすぎて良い？
幾つかの侵入経路を用いて、悪意あるファームウェアを攻撃者が
入れることができた場合、OTA経由でファームウェアアップデー
トができないようなマルウェアを侵入させることも可能だといわ
れています。
気になった方は、「IoT Goes Nuclear Creating a ZigBee
Chain Reaction」という論文・関連記事を読んでみてください。
https://eprint.iacr.org/2016/1047.pdf
※会場時間短縮-要約必須

29. IoT Goes Nuclear
Creating a ZigBee Chain Reaction
「都市全体のbricking攻撃」と表現されるコンセプトの証
明ワームを発表した論文を発表。
この論文で使われた連鎖反応を引き起こすワームであり、
Zigbeeの無線通信プロトコルの脆弱性(今回は、そのデバ
イスの暗号化の弱点)を利用して、連鎖反応攻撃を実行す
ることで、結果として内蔵のZigBeeワイヤレス接続と物
理的近接性を使い、ランプからその隣のランプに広がって
いく。
「Causing epileptic seizures」として、適切な周波数で
光を繰り返し点滅させる事で光感受性発作を誘発し大規模
なてんかん発作を引き起こすことが可能であるという指摘
が個人的にIoTの都市化という問題らしく興味が湧きまし
た。
※会場時間短縮-要約必須

30. 手軽なBLE
Hacking紹介

31. [+] 3分で出来る、BLE診断入門-!
nRF
Android(推奨:iPhoneでもアプリはありますが..)
**今回は、Androidで改ざん/iPhoneで確認してます。**
一般的な開発で、書き込み権限を気にして開発することは多
いと思います。
今回は、Bluetooth LEの書き込み権限の不備を確認してみ
たいと思います。

32. [1] IoT機器の権限確認
Device NameがRead権限Onlyでなく、Write権限が許可されて
いるので、不正な値を挿入してみる。
Click!

33. [2] 不正な値が挿入されたか確認
デバイスのアドバタイズされた名前(hacked)は、
BLEを介して変更できました。
一応過去の例で、同様の問題でCVEが割り当てられ
ていました。
(参考 CVE-2016-6549 )

34. [3] 最終確認
機器によっては、CompleteLocalNameではなくク
ライアントディバイス名使う事もあるので問題性は
高いと思われます。

35. 特殊なBluetooth
経由の攻撃

36. [+] Hacking Bluetooth deeply
既に日本の情報モラルとして、「知らないWiFiに接続
してはいけない」というのは既知です。
それでは、「知らないBluetooth」に接続するリスク
はあるのでしょうか？

37. [1] DirtyTooth
[※漏洩する情報]
•ユーザーが関係する人物。
•ユーザーの電話番号。
•ユーザーが関連する会社。
•カード所有者の連絡先情報。
•通話履歴。
•連絡先カードに関連付けられている人の物理アドレス。
被害者がA2DPプロファイル(音楽再生)のBluetooth LEに接続した際に、
被害者に通知せずに攻撃者がA2DPプロファイルをPBAPプロファイ
(電話帳伝送)に切り替えることができる問題。
参考
https://www.slideshare.net/elevenpaths/dirtytooth

38. [解説] DirtyTooth
(1)携帯「オーディオ機器さんですね、接続し
てください。]
(2)Dirtytooth「(今は)オーディオです。接続要
求受理しました。 データの送受信可能です。」
A2DPプロファイル
PBAPプロファイ
(3)DirtyTooth「私は、オーディオプロファイ
ルではなく電話帳伝送プロファイルです。
電話帳をください。」
(4)携帯電話「そうなんですね。これでいいです
か？(っ電話帳」

39. https://youtu.be/nxxFySuKYpg
※会場時間短縮-要約必須

40. Bluetoothの新しい仕様

41. Bluetooth Mesh
Hub-and-Spoke
Mesh Network
Bluetooth Meshでは、中間者攻撃やリプレイアタックなどに対し
てセキュアなやり取りが可能になるらしい。
Mesh networkにはMesh networkらしい脆弱性があると思ってい
るので、あまり期待せず脆弱性の質が変わると考えたほうがよさ
そう。(次ページの紹介内容は、「都市全体のbricking攻撃」とし
て対象がZigbeeプロトコルでMeshネットワーク)
※会場時間短縮-要約必須

42. 最後に・・

43. [+] IoT面白いことがしたい
・数ある日本製のIoT製品で、どんなセキュア実
装してるか？
・機器に対してコンシューマは違うわけで、コ
ンシューマが違うと生まれやすい脆弱性って何
でしょうか？
・IoTの攻撃って実用的なの何と何があるの？
-----などなど、気になりませんか？-----

44. [募集A] 興味ある方一緒にどうですか?

45. [募集B] IoT機器
「募集A」のセキュリティエンジニア36%とIoT開発者
8％に実際にペネトレーションのような形式でテストす
る機器を募集しています。
脆弱性などに関するNDAなどを交わした上で、実際に
IoT機器を提供していただける会社を募集しています。
連絡先
packr@packr.org

46. [+] IoTの問題はどこにあるのか?
IoT機器を委託で作成している場合など、セキュリティ不備は起
こり得る可能性が高いと考えられます。(1日あたり100個のIoT
が生まれるらしいですが、セキュアな製品って何割・・?)
※設計の段階でシステムの脅威を洗い出し対応すべき
(プログラムと違い改修に手間とコストが掛かるIoTは、リリー
ス・製造前に確認する事が望ましいです。)
[一例]
委託製造したシステムのセキュリティをチェックする必要性として、製造したスマートカメラが脆
弱だったり、そもそもカメラの通信先サーバーがZeusコントロールサーバーだった例があり、
Amazonページが荒れたことなどがありました。

47. おすすめの本
第6章のセキュリティの説明方法がいい！
[例]実際に第1~第5章でIoTシステムを作り、そのシステムのセ
キュリティについてMicrosoftのSTRIDEなどを元に考えている。
(Microsoft Azure IoTでは、STRIDEモデルが推奨されていて、
本著でAzure IoT Hub使ってるのでSTRIDE紹介してる？）
最高におすすめなので是非一度手に取ってみてください。