20180914 security iotlt#1_ほんとうにあった怖い話_aws_iot編

1. ほんとにあった怖い話－デバイスセキュリティ診断 AWS IoT編－ 2018.09.14 SecurityIoTLT#1 @ DEJIMA Tatsuya Katsuhara

2. 本日のトピック • みなさんも出会うかもしれない「IoTにありがちな」とてもシンプルだけれど怖い脆弱性の話をします。 • エッジデバイスも含めて一番弱いところが、システム全体の攻撃起点になります。 • AWS IoTを例に、デバイスが侵害される前提でのポリシー設定ベスプラ(だと思う)を紹介します。

3. 自己紹介勝原達也 @kthrtty 某SIer→某セキュリティ企業デジタル・アイデンティティ(2007～2016) 認証、OIDC、OAuth、SSO、IAM Web／プラットフォーム脆弱性診断(2016～2017) IoT ／ハードウェア／重要インフラセキュリティ(2017～) 事業推進、営業、マネジメント、合間にペンテスター

4. とある「よくできた」IoTシステム IoT Gateway ホームセキュリティエアコンライトスマートフォン Zigbee MQTT over TLS AWS IoT 課金

5. デバイス侵害を起点とするアプローチプロセッサ記憶装置/ROM （EEPROM/FLASH）デバッグ端子／シリアル端子・・・単体の機器・モジュールに対してペネトレする結合環境でペネトレするシステムファーム抽出・解析セキュリティ設定の不備秘匿情報の漏えいデータ改竄デバッグロック解除ログからの情報漏えい通信モジュール上位システムへの干渉通信先の差し替え接続時の仕様ギャップによる問題単体の問題を組み合わせ生じる攻撃情報をあつめる攻撃シナリオを考える

6. よくある仮説「記憶媒体に証明書と秘密鍵が保存されていそう」

7. 大容量記憶媒体の代表格「eMMC」 https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader.pdf NANDコントローラのおかげで、（低速で良いなら）少ない信号線で容易に読み書き可能

8. 楽勝じゃん？

9. 実際には解析はそんなに簡単ではない普通のファイルシステム抽出結果のバリエーション eMMCは基本的にBGAパッケージであるため、ピンに直接アクセスできない。抽出したデータに平文で鍵が入っているとは限らない。 https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader.pdf 様々なアプローチ組合せマイコンプログラム保護されたキーストア暗号化パーティション暗号化ボリューム etc…

10. 非破壊検査へのあこがれ https://www.flickr.com/photos/micahdowty/3732858713

11. なんやかんや苦労して

12. クライアント証明書と秘密鍵を抽出できた注：鍵はイメージです

13. AWS IoTへ接続 • 対応プロトコル • MQTT、MQTT(over WebSocket)、HTTP • 特徴 • デバイスシャドウ • カスタムオーソライザ（Congnitoで認証＆トークン発行/バックエンド検証） • AWS IoTポリシー（トピックレベルでデバイス毎にアクセス可否を制御） • MQTTのセマンティクスへバインドされているRESTful API

14. 30秒MQTT講座 • 元々IBMで開発され、OASIS Standardで標準化。 • 軽量プロトコルとしてIoT時代に注目されるようになった。 • Pub-Subメッセージ配信モデル。 Broker Subscriber Publisher Publish (事前に)Subscribe Topic Subscriber (事前に)Subscribe 登場人物概要 Broker メッセージの受信・配信を行うハブ的サービス Topic メッセージの話題、受信／配信用のハコ Publisher あるトピックに対してメッセージをPublishするエンティティ Subscriber あるトピックに対してPublishされたメッセージを購読するエンティティ

15. 情報窃取 Device “ZZZ”を所有する悪意あるユーザが、”ZZZ”から抽出した証明書を使って、正当なユーザが所有するDevice “AAA”に関するトピックを Subscribeし、情報を窃取する。ライト MQTT AWS IoT 悪意のあるユーザ ②Subscribe中のトピックへ通知 Topic: device/AAA/light ③IoT GatewayがライトをONにする制御実施証明書 ZZZ ⓪Subscribe Topic: #(すべて) スマートフォン ①API経由でAAAのライトをON ②Subscribe中のトピックへ通知 Topic: device/AAA/light Device “AAA” Device “ZZZ”

16. ライト AWS IoT 悪意のあるユーザ ②Subscribe中のトピックへ通知 Topic: device/AAA/light ③IoT GatewayがライトをONにする制御実施スマートフォン MQTT Device “AAA” Device “ZZZ” 不正操作 Device “ZZZ”を所有する悪意あるユーザが、”ZZZ”から抽出した証明書を使って、正当なユーザが所有するDevice “AAA”に関するトピックに Publishし、不正な操作を行う。証明書 ZZZ ①Publish Topic: device/AAA/light

17. こんなことで気合いれて作ったサービスが台無しになろうものなら超怖い

18. デバイス毎にクライアント証明書を分けたうえで、証明書ごとに、アクセスできるトピック階層を制限できれば、あるデバイスの証明書・秘密鍵が漏洩してしまったとしても他のユーザには影響が及ばない

19. AWS IoT Policy • ${iot:ClientId}のように変数を用いてポリシーを定義できる。 • ポリシーは、クライアント証明書や、デバイスのグループ単位で割り当てることができる。

20. AWS IoT Policy • ${iot:ClientId}のように変数を用いてポリシーを定義できる。 • ポリシーは、クライアント証明書や、デバイスのグループ単位で割り当てることができる。テストだから、、、デバッグのために、、、中途半端な設定のまま本番リリースしていませんか？

21. でも、実際やろうとすると AWSのドキュメントが正直分かりづらい

22. 最も重要（だと思う）変数 iot:Connection.Thing.IsAttached ポリシーが評価されているモノに、証明書または Amazon Cognito IDがアタッチされている場合は、trueに解決されます。 https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/thing-policy-variables.html

23. iot:Connection.Thing.IsAttached Device “AAA” MQTT over TLS AWS IoT MQTT接続パラメータ(AWS IoTへの伝達) クライアントID＝”AAA” クライアント証明書=“111” デバイス内部の設定値モノ識別子＝”AAA” クライアント証明書=“111” AWS IoTの「モノ」の設定状態モノ識別子＝”AAA” クライアント証明書=“111”＝ならば true ※Cognitoのときの話は省略

24. iot:Connection.Thing.IsAttached Device “AAA” MQTT over TLS AWS IoT MQTT接続パラメータ(AWS IoTへの伝達) クライアントID＝”AAA” クライアント証明書=“111” デバイス内部の設定値モノ識別子＝”AAA” クライアント証明書=“111” AWS IoTの「モノ」の設定状態モノ識別子＝”AAA” クライアント証明書=“111” 証明書とモノ識別子を厳密に結びつける＝ならば true ※Cognitoのときの話は省略

25. 開発者が情報を正しく得られる状態？コミュニティでちょろっと言及 SlideShareで唐突に紹介条件を取り除くと、同じ証明書で複数デバイスが Pub-Subできたよ。（やばいセキュリティホールだけどね。）レジストリ変数を用いて細粒度アクセスするときのIoTポリシーはこちら。 https://www.slideshare.net/AmazonWebServices/3-easy-steps- to-building-largescale-iot-architectures https://forums.aws.amazon.com/thread.jspa?threadID=247362 Google検索 “iot:Connection.Thing.IsAttached”

26. モノ識別子をトピック階層に含めアクセス制限 ${iot:ClientId}※ ${iot:Connection.Thing.ThingName}※ ※MQTT接続時は同じ値に解決

27. ${iot:ClientId}※ ${iot:Connection.Thing.ThingName}※ モノ識別子をトピック階層に含めアクセス制限単一ポリシーで複数のモノに対応できる ※MQTT接続時は同じ値に解決

28. 情報窃取が防止できるライト MQTT AWS IoT Core 悪意のあるユーザ ⓪Subscribe Topic: #(すべて) スマートフォン Subscribeするトピック文字列”#”がポリシーに違反しており強制切断。 Subscribeできるのはポリシーで許可された Topic: device/ZZZ/light など、悪意のあるユーザの Device “ZZZ”に限定される Device “AAA” Device “ZZZ” 証明書 ZZZ

29. 不正操作が防止できるライト AWS IoT Core 悪意のあるユーザスマートフォン MQTT Publishするトピック文字列”AAA”がポリシーに違反したので強制切断。 Device “AAA” Device “ZZZ” 証明書 ZZZ ①Publish Topic: device/AAA/light Publishできるのはポリシーで許可された Topic: device/ZZZ/light など、悪意のあるユーザの Device “ZZZ”に限定される

30. 補足 • トピック階層にモノ識別子を含まない設計の場合は要注意。 • Policyでやれることは少ない（”#”とか”+”とかワイルドカードを除外するぐらい） • アプリレベル制御をすることになる • 証明書CNにトピック文字列の一部(モノ識別子)を含める手法もアリ。 • CSR作るときにCNにモノ識別子を予め指定しておく。 • AWS IoT Policyにリテラルとしてモノ識別子を含める手法は微妙。 • 理解しやすいが、ポリシーを「モノ」の数だけ作成することになる。

31. まとめ • 全てのデバイスがセキュアであるとは限りません。 • サーバ側はデバイスがセキュアであることに依存しすぎず、デバイス侵害時も影響を最小化する設計を意識しましょう。 • Pub-Subモデルはユーザやデバイスを「跨いだ」アクセスが起こりがち。ちゃんと設定してサービスを守りましょう。

32. お終い

20180914 security iotlt#1_ほんとうにあった怖い話_aws_iot編

Tatsuya (達也) Katsuhara (勝原)

20180914 security iotlt#1_ほんとうにあった怖い話_aws_iot編