HEMSのローカルデータストレージの漏洩
黒林檎です。
IoT機器の脆弱性診断の報告対象に「ローカルデータストレージの漏洩」というものがあります。
これは、IoT機器などから資格情報やPII(個人を特定できる情報)・PHI(健康情報)などの情報を抽出できる場合に指摘されるものです。
そこで今日は、IoT機器として注目を良く浴びるようになったHEMS(Home Energy Management System)を見ていきます。
この脆弱性の範囲として、ユーザーが廃棄したIoT機器を攻撃者が拾った場合に上記の情報を攻撃者が取得し悪用できる可能性がある場合なども含むこともあると思います。(Trash can attackっていう名前で呼ばれているらしいですが、ここは日本なのでゴミ箱攻撃と呼んでいきます。)
[+]Trash can attack 参考
攻撃までの流れを図解していくと・・・
(図)ゴミ箱攻撃の流れ
名前の通り、ユーザーがー故障などでIoT機器(ここではHEMS)を廃棄した際にOther work(ゴミ収集など)が回収する前に悪意ある攻撃者が回収してしまう事が始まりです。
ゴミ箱攻撃の現実性でいえば、「まぼろし博覧会」の”村崎百郎の部屋”という展示場所に村崎氏がゴミから拾い上げた手紙や写真などがそのまま展示されていたりしました。
同じように会社が廃棄した物を集めているコレクターもいるかもしれません。
余談を含みましたが、ゴミ箱から回収した想定で基板を取り出していきます。
(図)HEMSの基板取り出し
電子機器に詳しい方であれば一目瞭然であると思いますが、赤外線を用いて家電操作を行うHEMSです。(※LED電球に見えるものは赤外線送信機で、黒く四角いものは赤外線受信機になります。)
基板からハッキングに使える箇所がないか見ていきます。
(図)HEMS基板
RX・TXでUARTがあるのと、TRST・TCKなどでJTAGがあることがわかります。
難易度でいうと、UARTの方が容易であるため接続するインターフェースとしてUARTを今回選択しました。
今回、デバッグピン用に基板に穴が既に空いていたためはんだ付け作業はする必要性が無かったためPCに接続してどの様な情報が出力されるか見ていきます。。
(図)UART接続
実際にUART経由で正常に接続が成功し、文字列が表示されました。
出力された文字列を精査していきます。
※問題点を明確化するために、HEMSがWiFiなどに繋がらない環境でUART接続を行いました。
===========表示された文字列===========
# python baudrate.py -p /dev/ttyUSB1
Starting baudrate detection on /dev/ttyUSB1, turn on your serial device now.
Press Ctl+C to quit.
@@@@ Baudrate: 115200 @@@@@
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Passive
[wscan] Channel: 8 Type: Passive
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
app_wifi_connect Timer out.
ssid r00tapple psk wifi-password-is-password need broad 0
type 3
ssid r00tapple psk wifi-password-is-password psklen 8, type 5 special 0
[af] Error: network_mgr: failed to remove network
[af] Warn: network_mgr: valid network already loaded
app_network_status_set to status. 6.....
[af] Warn: app_ctrl: Ignored event 6 in state 12
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] rescan limit exceeded, giving up
[wlcm] Warn: connecting to "default" failed
[af] Warn: network_mgr: WLAN: network not found
[wlcm] got wifi message: 32 0 0x00000000
[wlcm] starting connection to network: 0
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
===========表示された文字列===========
HEMSから出力された情報の一部に、WiFiのSSID(r00tapple)とパスワード(wifi-password-is-password)が出力されていることがわかります。
今回の場合、接続していたWiFiがHEMS周辺に無い場合(HEMSが接続していない)でもデバッグ情報に表示されていました。
====該当箇所====
app_wifi_connect Timer out.
ssid r00tapple psk wifi-password-is-password need broad 0
type 3
ssid r00tapple psk wifi-password-is-password psklen 8, type 5 special 0
[af] Error: network_mgr: failed to remove network
[af] Warn: network_mgr: valid network already loaded
===============
さて、IoTの流れに伴い会社のWiFiに接続しているIoTも増えていることでしょう。
そのIoTが故障し廃棄する際に、一般家電のように廃棄するリスクも検討する必要性がありそうです。
今回はWiFiのパスワードを抽出できたため、下記のような流れで社内ネットワークを侵害される可能性もあります。
(図)廃棄したIoTから漏洩した資格情報で社内ネットワークを侵害
IoTが普及し故障などで廃棄されていく未来で、廃棄機器を利用した資格情報の漏洩は問題視されて来るかと思います。
[+]関連する黒林檎ドキュメント
黒林檎のお部屋-IoTハッキング編-
http://ruffnex.net/kuroringo/pdf/IoTHack.pdf
IoTセキュリティ対策 診断・解析入門(※社員ではありません。)
IoTセキュリティ対策 診断・解析入門 ｜ SECURITY BLOG by Ierae Security, Inc.
『 IoT診断入門 』について
黒林檎です。
総関西サイバーセキュリティＬＴ大会（第3回）で話していたIoT診断入門について、話忘れた内容をブログに記述していきます。
総関西サイバーセキュリティＬＴ大会（第3回） - connpass
上記のslideshareに、発表資料を載せています。
microsoftがIoTセキュリティアーキテクチャの資料で、セキュリティ上の脅威の評価である『脅威モデル STRIDE』を提示しています。
STRIDEに関しては、以下の資料を参照してください。
IoT のセキュリティ アーキテクチャ | Microsoft Docs
まず、ペネトレーションにしても難しい所はIoT機器のセキュリティ診断の見積もり作業であると思います。
このSTRIDEのモデル化を行う事で、攻撃経路の選定と診断箇所を洗い出す事ができコストも明確になるかと思います。
アーキテクチャ図を作成した事で、対象のIoT機器の構成は見えてきました。
攻撃経路を決めるファーストステップに移れます。
攻撃経路の決定を行いますが、書くコンポーネントでどのような問題が生じるかアーキテクチャ図で考えてみましょう。
今回は、「IoTデバイス」 「無線通信」 「Web/Mobile/Cloud」で分類しました。
この作業で、各コンポーネントで生じる問題を洗い出す事が出来ました。
IoTデバイスであれば、シェルに不正に入られる可能性やファームウェアの抽出による鍵の盗難などの危険性があがります。
また、無線通信であればリプレイ攻撃により「電子錠であれば開錠」など不正にシステムを動作させる事ができるかもしれません。
それでは、最後にそれらをエクセル表形式に直し攻撃経路と攻撃のゴールを決めます。
※実際は、攻撃に関してももっと詳細な記述ができると思いますが、サンプルケースな資料なので細かい箇所は割愛しました。
対象機器の攻撃経路を一覧化します。
電子錠であれば、criticalな脆弱性は不正開錠であるため、対象のIoT機器の特製に合わせた診断をする事が可能になります。
また、不正開錠に関係がある攻撃経路を明確化しておく事で診断の時間を圧倒的に短縮化する事ができます。
単純にBluetoothのPoint-to-Pointデバイスを例に、リプレイアタックなどに脆弱であるIoTシステムは脆弱であるというお話です。
では、リプレイアタックなどに脆弱でないIoTとはなんでしょうか？
１つの例として、正規ユーザーがペアリング済みでコネクションが成立している際に、攻撃者が中間者攻撃を行うためIoT機器にコネクションを張った際にIoT機器が正規ユーザーのコネクションを切断してしまう事でリプレイアタックを防ぐ事が出来ます。
これは、先ほどの説明をスライド文で記述しているものです。
実際に幾つかのIoT機器を覗いてみました。
それぞれPoint-to-Pointで動作するBluetoothのIoT機器です。
１つ面白かった機器があります。
体温計で、iOSとAndroidで通信経路を変更するシステムです。
この機器のBluetoothは、同時コネクションは１つのみで単一接続なもので一般的なBLE攻撃に対してセキュアであり、NFCにしても改ざんなどのリスクが低い作り方をしていました。
診断の観点で３つの機器をみた結果、それぞれ同じような対策を取られておりセキュアに作られていました。
１つの問題点をここであげると、３つの機器はそれぞれコンシューマが違います。
コンシューマが違うという事は、機器も目的も変わります。
・体温計 - 同時使用はありえない、使用人数は一人
・電子錠 - 複数のユーザーがいていいが、開け閉めの処理は複数ユーザーが同時に一斉ノーで数回する事は考えられにくい
・コーヒーメーカー - 需要と供給がかなり高い機器である。
それぞれの機器は同じ様な仕組みであっても、顧客層は違います。
なので、その顧客層に合わせた機能を攻撃する事で初期に決めた目的を達成する事ができる場合もあります。
IoT用のOWASP Top 10があります。
https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf
これを元に、練習として診断報告書を書いてみましたがIoTであれば以下のような問題点が考えられます。
外注した製品がmaliciousであるというパターンです。
納品されたサーバーがボットネットのC&Cであるといったパターンです。
私がみたケースでは、脆弱なサーバープログラムをクラッカーが攻撃しC&Cサーバーにしたのか、外注したメーカーが初期から仕込んだのかは不明ですが、これは興味深い話です。
これは、IoTあるあるだと思います。
不正に電子錠などを開けても報告書でどう記述すれば良いかわからないという問題です。
また、外注されている製品であった場合報告と回収でかなりの時間を取られる可能性があります。
IoTのセキュリティ担保では、OTA(Over-The-Update)が重要になります。
OTAにより、脆弱性がIoT機器に見つかっても回収することができるわけですが、このOTAをすべて信用していいか？という問題点もあります。
悪意ある攻撃者がIoT機器のファームウェアを改ざん出来た場合、OTAを無効化しファームウェアをアップデートできなくすることが可能です。
この問題点の解決のためには、IoT機器を監視する仕組みが必要になりますが、IoT機器に対するSoC(セキュリティ オペレーション センター)などが整備されていないなどの問題点があります。
IoT機器の権限確認です。
これはAndroidなどがIoT機器にペアリングする際に表示されるデバイス名で、「WRITE権限」が不可されているので、不正に名前を変更する事ができます。
実際に不正に書き込んだ値がペアリング時に表示されている事がわかります。
過去に同様の問題でCVE(CVE-2016-6549)が割り当てられていました。
※NRFというアプリを使用していますが、iPhone版ではなくAndroid版を使用する事を強くおすすめします。(表示される情報量がAndroid版の方が多い)
変わったBluetoothの攻撃として、DirtyToothという攻撃の紹介です。
iPhoneやAndroidなどがA2DPプロファイル(オーディオ機器)と認識してペアリングしたものが、実は攻撃者の攻撃で攻撃者がペアリング成立後にPBAPプロファイルに強制的に変更する事で電話帳や通話履歴など盗み取るという攻撃です。
これはZigBee電球にワームを感染させ連鎖的に乗っ取るというお話でした。
メッシュネットワークに対する攻撃では、危険性として一番わかりやすいお話でした。
また、適切な周波数で光を点滅することで「てんかん発作」を引き起こせるというのは
興味があるお話です。
Bluetoothもメッシュネットワークのような仕組みを発表しました。
既知の攻撃(スニッフィングやリプレイアタック)に対してセキュアであるという記事もありますが、これに関していえば脆弱性の本質が変わるというお話なのかな？と個人的に思います。
例えば、先ほどのZigbeeの連鎖反応攻撃のような脆弱性は生まれるのか？など思います。
[+]最後に
関西で面白いコミュニティを作りたいと考えています。
我こそはという方のお声お待ちしております。
[追記]
IoTの議題点
・IoTのネットワークを監視するSoCの必要性
・クラウドファンディングなどで出来るIoT製品のセキュリティ
5分で言えなかった言いたい事だと、「IoTネットワークを監視するSOCみたいな物が無いという事」と「クラウドファンディングなどで出来るIoT製品のセキュリティ」ですかね。 https://t.co/GOa5t3FGSw
— 黒林檎 (@r00tapple) 2017年6月15日
