続・IoT診断

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

3. 前回からの変化
事業パートナー参加 SEO取り戻し

4. Hackの日

5. 会場ではオフレコでハックの動作を
流したのですが、都合により非公開
にします

6. IoT とは

7. IoTとサーバーの違いって何でしょう?
Web Server IP Camera
今日は、これを「疑問」を持ちつつ話を聞いていただけると幸いです。
＋ この疑問のネタに酒がのめると最高です。

8. 参照
http://wiki.reecam.cn/CGI/Params
IPカメラ(開発プラットフォームを用い
た)によっては、コンシューマが知ら
ないAPIセットが提供されており、
telnetがAPIリクエストにより立ち上が
る可能性があります。

9. ウェブサーバーより酷い場合もある
http://IPカメラ/cgi-bin/param.cgi?cmd=telnet
telnet IPカメラ
Hacked

10. このIoTシステムの脅威って何?
スマートペット
フィーダー
AWS SmartPhone
WiFi LTE

11. このIoTシステムの脅威って何?
スマートペット
フィーダー
AWS SmartPhone
WiFi LTE
ここだけ？

12. IoTの趣旨を考える
趣旨は「任意のタイミン
グでペットに餌を与える
こと・・」
AndroidアプリのWeb
ViewにあるXSSより
「通信の安定性」こそが
一番重要だと思われる。

13. スマートペット
フィーダー
AWS SmartPhone
WiFi LTE
Cracker
DDoS
WiFi
Down
(1) APIをホストしているサーバーが障害によりダウン
(2) DDoSなどによるサーバーのダウン
(3) APIサーバーの不備によるシステムダウン
(1) aireplayなどによる負荷でダウン
(2) たまたまクラッキングされダウン
(3) 故障によるダウン

14. Internet of Things
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・
ざわ・・

15. 診断手法の選定

16. [+] 診断対象の構成
電子錠
近距離無線通信
(NFC・Bluetooth)
クラウド・APIサーバー
(AWS・Azure・etc..)
デバイス
(Android・iPhone)
ハードウェア
(UART・JTAG・SPI・etc..)

17. [+]IoTを診断サービスに当てはめる

18. ■攻撃経路の「選定」と「決定」
1)システムの把握・図式化
2)問題点をコンポーネント単位で切り分ける
3)攻撃箇所を一覧化し、手法・目的を決める

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

20. コストとのミスマッチ

21. 全体を見る必要性はあるのか？
「デバイス」と「ハードウェア」の診断はいらん！

23. 電子錠 root端末
root化された端末で、アプリ内の設
定ファイルやデータを改ざんする事
で想定されていない処理が実行され
る可能性がある。
スマホアプリである以上、悪用され
るリスクを考える必要性がある。

24. 事例紹介(社会性によるオフレコ)
※フィクション

26. 診断業者
送信値の改ざんで
不正な命令の実行
がでました。
メーカー
(請負)スマホアプリ開発者 (請負)ハードウェア開発者 (請負)クラウドAPI開発者
脆弱なもん作ったのは、
お前か？！
うちの問題っぽいけど、
これアプリの問題やろ
センサーは、うち
ちゃうで
うち、関係ないや
ん？
※フィクション

27. 脆弱性報告時事例紹介
(社会性によるオフレコ)
バグハント
送信値の改ざんで
不正な命令の実行
がでました。
マネジメント(偉い人)
セキュリティ担当者
貴方が言ってる脆弱性は脆弱性では
なく仕様です。
うちの製品の何が悪いんや?!(怒)
君は、セキュリティ
担当だよね？
報告ありがとう！
問題は深刻だ！
対応するよ！
１
２
３
※フィクション

28. 単一接続の実装不備(答え)
(オフレコではない)
(1)接続
(2)接続
(3)切断
正しいと言われた実装
(黒林檎観点:脆弱)
ハックしまくってわかった実装
(黒林檎観点:セキュア)
(1)接続
(2)接続のためにBLEを検
索するが、非公開のため
接続できない。
(3)持続
※フィクション

29. BLEをめっちゃ見て他社実装をつかんだ
今から言える理由(オフレコではない)
(1)接続
(2)接続
(3)切断
例えば、BLEをバイタルデータ(血圧と
か)の転送に用いている場合に「データ
の改ざん」を阻止するために中間者攻撃
の対策として左の実装をしたとする。
中間者攻撃は阻止できますが、この実装
では、バイタルデータの転送中に第三者
がコネクションを作成すると転送中の端
末のコネクションが切断されるため
「データが破損」してしまいます。
本当に「セキュアな単一接続」であれば
実装をかえるべき。
医療機器

30. 診断経路の選定

31. [+] 対象製品の攻撃経路を一覧化する
製品 攻撃経路 攻撃例 攻撃結果・成果物
IoT Device
Bluetooth LE
リプレイアタック
不正に命令を実行する(今回で
あれば鍵の開錠)
スニッフィング 鍵などの情報漏洩
Hardware
インターフェース
シェルにアクセスする、ログ情
報の表示
ファームウェア解析
悪用可能なファームウェアの脆
弱性を見つける
秘密鍵などの情報などを取得す
る
Cloud
リプレイアタック
不正に命令を実行する(今回で
あれば鍵の開錠)
スニッフィング なりすまし攻撃
IoTセキュリティは広す
ぎるため、すべてのコン
ポーネントを診断するこ
とは現実的ではない。
そのため、「攻撃経路」
と「攻撃の目的・ゴー
ル」を決めることで効率
化を図る。
これにより、診断開始時
に攻撃ベクターの選定に
時間をかける必要性がな
くなり、サービス品質が
あがる。
※最終的に、「IoTの何を守りますか?!」で出てきた図以上にプロトコルなどもマッピングして図式化する。

32. [+] 対象製品の攻撃経路を決定
製品 攻撃経路 攻撃例 攻撃結果・成果物
IoT Device
Bluetooth LE
リプレイアタック
不正に命令を実行する(今回であ
れば鍵の開錠)
スニッフィング 鍵などの情報漏洩
Hardware
インターフェース
シェルにアクセスする、ログ情
報の表示
ファームウェア解析
悪用可能なファームウェアの脆
弱性を見つける
秘密鍵などの情報などを取得す
る
Cloud
リプレイアタック
不正に命令を実行する(今回であ
れば鍵の開錠)
スニッフィング なりすまし攻撃
※最終的に、「IoTの何を守りますか?!」で出てきた図以上にプロトコルなどもマッピングして図式化する。
セキュリティ診断は安価
なサービスではなく、
IoT製品の単価とのミス
マッチで診断ができない
可能性がある。
製品の改良にコストをか
けてしまう場合が多く考
えられるため、攻撃経路
の一覧化と攻撃のゴール
を決めることでピンポイ
ントの診断を行う事がで
きます。

33. [+]BLEのリプレイアタックへの診断
IoT
ペアリング-暗号鍵の共有化(LTK)
接続デバイスを1台に制限
Bonded Device
Not Bonded Device
(1)ペアリング&ボンディング
アドバタイジングパケットを
コピーして、IoT機器より速い
速度でアドバタイズを流せば
正規ユーザーをだまして中間
者攻撃の要領でリプレイア
タックが可能では?
(3)Disconnect

34. IoT診断はノウハウの蓄積や診断士の
育成が大変です。
「ペネトレーションテスト」と違い、
「診断」である以上は、診断士による
結果の違いを起こさなくさせるために
診断ノウハウなどの共有化をさければ
なりません。
弊社の場合、社内wikiを生成して日々
診断の最適化を行っています。
※脆弱性に関する価値観まで共有できると
なお良し

35. 脆弱性の修正

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

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

38. [+]安全なfirmware updateとは？
• セキュアブート
• 署名付きファームウェアアップデート
• 暗号化通信チャネル
• コード署名
• デュアルファームウェアイメージ
・・これらすべてを機器に適用することは困難です。

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

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

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

42. 呑みながら覚えるBLE診断

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

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

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

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

47. Let's hack BLE. Today is the day of Hack
参考資料
http://ruffnex.net/kuroringo/pdf/IoTHack.pdf

48. 最後

49. 未認証ICSを手軽に確認
#shodansafari

51. ご清聴
ありがとうございました。

52. 時間が余ったとき様に・・

53. [啓発]
コンシューマのIoTのセキュリティ確保
・デフォルトのユーザー名とパスワードを変更し、誰とも共有しない。
=Mirai・HajimeといったIoTマルウェアの二の舞にならないでください。
・公開された更新プログラムをインストールしてください。
=製品品質とセキュリティの欠陥をアップデートしてくれる可能性が高い
・開いているネットワーク(Open Wifiなど)には接続しない。
=パケットをキャプチャされて「鍵」が盗まれる可能性が高い。
・ウイルス感染する可能性が高いため、使用済みまたは改装済みの製品を使用しないでください。
= USB給電タイプのデバイスは特に危険です。
・信頼できる情報源から購入して、使用していないときはデバイスの電源を切る。
= (これは良く言われるけど「おまじない」レベルですね。)