20180914 security iotlt#1_ほんとうにあった怖い話_aws_iot編
5 likes3,061 views
"A True Scary Story for AWS IoT" IoTデバイスとAWS IoTを連携したシステムにおいて、デバイスからクライアント証明書と秘密鍵を抽出し、AWS IoTに接続して情報摂取・不正操作を行う脆弱性と、その対策について簡単に紹介します。
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～) 事業推進、営業、マネジメント、合間にペンテスター
- 8. 楽勝じゃん？
- 11. なんやかんや苦労して
- 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
- 19. AWS IoT Policy • ${iot:ClientId}のように変数を用いてポリシーを定義できる。 • ポリシーは、クライアント証明書や、デバイスのグループ単位 で割り当てることができる。
- 20. AWS IoT Policy • ${iot:ClientId}のように変数を用いてポリシーを定義できる。 • ポリシーは、クライアント証明書や、デバイスのグループ単位 で割り当てることができる。 テストだから、、、デバッグのために、、、 中途半端な設定のまま本番リリースしていませんか？
- 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のときの話は省略
- 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. お終い