Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

続・IoT診断

10,967 views

Published on

続・IoT診断

Published in: Engineering
  • Be the first to comment

続・IoT診断

  1. 1. [+] プロフィール 所属 : 株式会社 神戸デジタル・ラボ( kdl.co.jp ) セキュリティソリューション事業部 ハンドルネーム : 黒林檎 Twitter : r00tapple Facebook : 村島正浩 Mail : packr@packr.org 注意:試験的に行い考察した結果で あるため実際とは異なる結果も含ま れている可能性が存在します。
  2. 2. 前回からの変化 事業パートナー参加 SEO取り戻し
  3. 3. Hackの日
  4. 4. 会場ではオフレコでハックの動作を 流したのですが、都合により非公開 にします
  5. 5. IoT とは
  6. 6. IoTとサーバーの違いって何でしょう? Web Server IP Camera 今日は、これを「疑問」を持ちつつ話を聞いていただけると幸いです。 + この疑問のネタに酒がのめると最高です。
  7. 7. 参照 http://wiki.reecam.cn/CGI/Params IPカメラ(開発プラットフォームを用い た)によっては、コンシューマが知ら ないAPIセットが提供されており、 telnetがAPIリクエストにより立ち上が る可能性があります。
  8. 8. ウェブサーバーより酷い場合もある http://IPカメラ/cgi-bin/param.cgi?cmd=telnet telnet IPカメラ Hacked
  9. 9. このIoTシステムの脅威って何? スマートペット フィーダー AWS SmartPhone WiFi LTE
  10. 10. このIoTシステムの脅威って何? スマートペット フィーダー AWS SmartPhone WiFi LTE ここだけ?
  11. 11. IoTの趣旨を考える 趣旨は「任意のタイミン グでペットに餌を与える こと・・」 AndroidアプリのWeb ViewにあるXSSより 「通信の安定性」こそが 一番重要だと思われる。
  12. 12. スマートペット フィーダー AWS SmartPhone WiFi LTE Cracker DDoS WiFi Down (1) APIをホストしているサーバーが障害によりダウン (2) DDoSなどによるサーバーのダウン (3) APIサーバーの不備によるシステムダウン (1) aireplayなどによる負荷でダウン (2) たまたまクラッキングされダウン (3) 故障によるダウン
  13. 13. Internet of Things ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・ ざわ・・
  14. 14. 診断手法の選定
  15. 15. [+] 診断対象の構成 電子錠 近距離無線通信 (NFC・Bluetooth) クラウド・APIサーバー (AWS・Azure・etc..) デバイス (Android・iPhone) ハードウェア (UART・JTAG・SPI・etc..)
  16. 16. [+]IoTを診断サービスに当てはめる
  17. 17. ■攻撃経路の「選定」と「決定」 1)システムの把握・図式化 2)問題点をコンポーネント単位で切り分ける 3)攻撃箇所を一覧化し、手法・目的を決める
  18. 18. [+]各コンポーネントで起こり得る問題 [ 近距離無線通信 ] ・平文通信 ・リプレイ攻撃 ・中間者攻撃 ・認証(ペアリングなど)をキャプチャ [ クラウド・APIサーバー ] ・認証/認可の欠陥 ・安全でないネットワーク通信 ・ロジックの欠陥 ・その他考えられる脆弱性すべて [ ハードウェア ] ・ハードコードされた機密情報 ・ファームウェアの改ざん ・物理的にシェルへのアクセス REST API
  19. 19. コストとのミスマッチ
  20. 20. 全体を見る必要性はあるのか? 「デバイス」と「ハードウェア」の診断はいらん!
  21. 21. 電子錠 root端末 root化された端末で、アプリ内の設 定ファイルやデータを改ざんする事 で想定されていない処理が実行され る可能性がある。 スマホアプリである以上、悪用され るリスクを考える必要性がある。
  22. 22. 事例紹介(社会性によるオフレコ) ※フィクション
  23. 23. 診断業者 送信値の改ざんで 不正な命令の実行 がでました。 メーカー (請負)スマホアプリ開発者 (請負)ハードウェア開発者 (請負)クラウドAPI開発者 脆弱なもん作ったのは、 お前か?! うちの問題っぽいけど、 これアプリの問題やろ センサーは、うち ちゃうで うち、関係ないや ん? ※フィクション
  24. 24. 脆弱性報告時事例紹介 (社会性によるオフレコ) バグハント 送信値の改ざんで 不正な命令の実行 がでました。 マネジメント(偉い人) セキュリティ担当者 貴方が言ってる脆弱性は脆弱性では なく仕様です。 うちの製品の何が悪いんや?!(怒) 君は、セキュリティ 担当だよね? 報告ありがとう! 問題は深刻だ! 対応するよ! 1 2 3 ※フィクション
  25. 25. 単一接続の実装不備(答え) (オフレコではない) (1)接続 (2)接続 (3)切断 正しいと言われた実装 (黒林檎観点:脆弱) ハックしまくってわかった実装 (黒林檎観点:セキュア) (1)接続 (2)接続のためにBLEを検 索するが、非公開のため 接続できない。 (3)持続 ※フィクション
  26. 26. BLEをめっちゃ見て他社実装をつかんだ 今から言える理由(オフレコではない) (1)接続 (2)接続 (3)切断 例えば、BLEをバイタルデータ(血圧と か)の転送に用いている場合に「データ の改ざん」を阻止するために中間者攻撃 の対策として左の実装をしたとする。 中間者攻撃は阻止できますが、この実装 では、バイタルデータの転送中に第三者 がコネクションを作成すると転送中の端 末のコネクションが切断されるため 「データが破損」してしまいます。 本当に「セキュアな単一接続」であれば 実装をかえるべき。 医療機器
  27. 27. 診断経路の選定
  28. 28. [+] 対象製品の攻撃経路を一覧化する 製品 攻撃経路 攻撃例 攻撃結果・成果物 IoT Device Bluetooth LE リプレイアタック 不正に命令を実行する(今回で あれば鍵の開錠) スニッフィング 鍵などの情報漏洩 Hardware インターフェース シェルにアクセスする、ログ情 報の表示 ファームウェア解析 悪用可能なファームウェアの脆 弱性を見つける 秘密鍵などの情報などを取得す る Cloud リプレイアタック 不正に命令を実行する(今回で あれば鍵の開錠) スニッフィング なりすまし攻撃 IoTセキュリティは広す ぎるため、すべてのコン ポーネントを診断するこ とは現実的ではない。 そのため、「攻撃経路」 と「攻撃の目的・ゴー ル」を決めることで効率 化を図る。 これにより、診断開始時 に攻撃ベクターの選定に 時間をかける必要性がな くなり、サービス品質が あがる。 ※最終的に、「IoTの何を守りますか?!」で出てきた図以上にプロトコルなどもマッピングして図式化する。
  29. 29. [+] 対象製品の攻撃経路を決定 製品 攻撃経路 攻撃例 攻撃結果・成果物 IoT Device Bluetooth LE リプレイアタック 不正に命令を実行する(今回であ れば鍵の開錠) スニッフィング 鍵などの情報漏洩 Hardware インターフェース シェルにアクセスする、ログ情 報の表示 ファームウェア解析 悪用可能なファームウェアの脆 弱性を見つける 秘密鍵などの情報などを取得す る Cloud リプレイアタック 不正に命令を実行する(今回であ れば鍵の開錠) スニッフィング なりすまし攻撃 ※最終的に、「IoTの何を守りますか?!」で出てきた図以上にプロトコルなどもマッピングして図式化する。 セキュリティ診断は安価 なサービスではなく、 IoT製品の単価とのミス マッチで診断ができない 可能性がある。 製品の改良にコストをか けてしまう場合が多く考 えられるため、攻撃経路 の一覧化と攻撃のゴール を決めることでピンポイ ントの診断を行う事がで きます。
  30. 30. [+]BLEのリプレイアタックへの診断 IoT ペアリング-暗号鍵の共有化(LTK) 接続デバイスを1台に制限 Bonded Device Not Bonded Device (1)ペアリング&ボンディング アドバタイジングパケットを コピーして、IoT機器より速い 速度でアドバタイズを流せば 正規ユーザーをだまして中間 者攻撃の要領でリプレイア タックが可能では? (3)Disconnect
  31. 31. IoT診断はノウハウの蓄積や診断士の 育成が大変です。 「ペネトレーションテスト」と違い、 「診断」である以上は、診断士による 結果の違いを起こさなくさせるために 診断ノウハウなどの共有化をさければ なりません。 弊社の場合、社内wikiを生成して日々 診断の最適化を行っています。 ※脆弱性に関する価値観まで共有できると なお良し
  32. 32. 脆弱性の修正
  33. 33. [+]OTAという考え方
  34. 34. [+] Over The Airの重要性 無線ネットワークを用いてシステム更新(ファームウェアアップデー ト)が出来る仕様がIoTでは重要になります。 コンシューマ製品のセキュリティはとても大切だと思われます。 脆弱性など情報などが掲載されて、回収できないシステムであった場 合最悪製品の回収騒ぎになり、結果として、会社の信頼性が低下する と容易に考えられます。 しかし、OTAでファームウェアアップデートができる場合、脆弱性を 指摘されても「OTA経由でファームウェアアップデートは可能」と返 答し修正することができます。(実際、セキュリティの欠陥を指摘さ れた企業は返答として「回収可能」という文字を強調します。)
  35. 35. [+]安全なfirmware updateとは? • セキュアブート • 署名付きファームウェアアップデート • 暗号化通信チャネル • コード署名 • デュアルファームウェアイメージ ・・これらすべてを機器に適用することは困難です。
  36. 36. [+] OTAに頼りすぎて良い? 幾つかの侵入経路を用いて、悪意あるファームウェアを攻撃者が 入れることができた場合、OTA経由でファームウェアアップデー トができないようなマルウェアを侵入させることも可能だといわ れています。 気になった方は、「IoT Goes Nuclear Creating a ZigBee Chain Reaction」という論文・関連記事を読んでみてください。 https://eprint.iacr.org/2016/1047.pdf
  37. 37. IoT Goes Nuclear Creating a ZigBee Chain Reaction 「都市全体のbricking攻撃」と表現されるコンセプトの証 明ワームを発表した論文を発表。 この論文で使われた連鎖反応を引き起こすワームであり、 Zigbeeの無線通信プロトコルの脆弱性(今回は、そのデバ イスの暗号化の弱点)を利用して、連鎖反応攻撃を実行す ることで、結果として内蔵のZigBeeワイヤレス接続と物 理的近接性を使い、ランプからその隣のランプに広がって いく。 「Causing epileptic seizures」として、適切な周波数で 光を繰り返し点滅させる事で光感受性発作を誘発し大規模 なてんかん発作を引き起こすことが可能であるという指摘 が個人的にIoTの都市化という問題らしく興味が湧きまし た。
  38. 38. Bluetooth Mesh Point-to-Point Mesh Network Bluetooth Meshでは、中間者攻撃やリプレイアタックなどに対し てセキュアなやり取りが可能になるらしい。 Mesh networkにはMesh networkらしい脆弱性があると思ってい るので、あまり期待せず脆弱性の質が変わると考えたほうがよさ そう。(次ページの紹介内容は、「都市全体のbricking攻撃」とし て対象がZigbeeプロトコルでMeshネットワーク)
  39. 39. 呑みながら覚えるBLE診断
  40. 40. [+] 3分で出来る、BLE診断入門-! nRF Android(推奨:iPhoneでもアプリはありますが..) **今回は、Androidで改ざん/iPhoneで確認してます。** 一般的な開発で、書き込み権限を気にして開発することは多 いと思います。 今回は、Bluetooth LEの書き込み権限の不備を確認してみ たいと思います。
  41. 41. [1] IoT機器の権限確認 Device NameがRead権限Onlyでなく、Write権限が許可されて いるので、不正な値を挿入してみる。 Click!
  42. 42. [2] 不正な値が挿入されたか確認 デバイスのアドバタイズされた名前(hacked)は、 BLEを介して変更できました。 一応過去の例で、同様の問題でCVEが割り当てられ ていました。 (参考 CVE-2016-6549 )
  43. 43. [3] 最終確認 機器によっては、CompleteLocalNameではなくク ライアントディバイス名使う事もあるので問題性は 高いと思われます。
  44. 44. Let's hack BLE. Today is the day of Hack 参考資料 http://ruffnex.net/kuroringo/pdf/IoTHack.pdf
  45. 45. 最後
  46. 46. 未認証ICSを手軽に確認 #shodansafari
  47. 47. ご清聴 ありがとうございました。
  48. 48. 時間が余ったとき様に・・
  49. 49. [啓発] コンシューマのIoTのセキュリティ確保 ・デフォルトのユーザー名とパスワードを変更し、誰とも共有しない。 =Mirai・HajimeといったIoTマルウェアの二の舞にならないでください。 ・公開された更新プログラムをインストールしてください。 =製品品質とセキュリティの欠陥をアップデートしてくれる可能性が高い ・開いているネットワーク(Open Wifiなど)には接続しない。 =パケットをキャプチャされて「鍵」が盗まれる可能性が高い。 ・ウイルス感染する可能性が高いため、使用済みまたは改装済みの製品を使用しないでください。 = USB給電タイプのデバイスは特に危険です。 ・信頼できる情報源から購入して、使用していないときはデバイスの電源を切る。 = (これは良く言われるけど「おまじない」レベルですね。)

×