『 IoT診断入門 』について
黒林檎です。
総関西サイバーセキュリティLT大会(第3回)で話していたIoT診断入門について、話忘れた内容をブログに記述していきます。
総関西サイバーセキュリティLT大会(第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とはなんでしょうか?
1つの例として、正規ユーザーがペアリング済みでコネクションが成立している際に、攻撃者が中間者攻撃を行うためIoT機器にコネクションを張った際にIoT機器が正規ユーザーのコネクションを切断してしまう事でリプレイアタックを防ぐ事が出来ます。
これは、先ほどの説明をスライド文で記述しているものです。
実際に幾つかのIoT機器を覗いてみました。
それぞれPoint-to-Pointで動作するBluetoothのIoT機器です。
1つ面白かった機器があります。
体温計で、iOSとAndroidで通信経路を変更するシステムです。
この機器のBluetoothは、同時コネクションは1つのみで単一接続なもので一般的なBLE攻撃に対してセキュアであり、NFCにしても改ざんなどのリスクが低い作り方をしていました。
診断の観点で3つの機器をみた結果、それぞれ同じような対策を取られておりセキュアに作られていました。
1つの問題点をここであげると、3つの機器はそれぞれコンシューマが違います。
コンシューマが違うという事は、機器も目的も変わります。
・体温計 - 同時使用はありえない、使用人数は一人
・電子錠 - 複数のユーザーがいていいが、開け閉めの処理は複数ユーザーが同時に一斉ノーで数回する事は考えられにくい
・コーヒーメーカー - 需要と供給がかなり高い機器である。
それぞれの機器は同じ様な仕組みであっても、顧客層は違います。
なので、その顧客層に合わせた機能を攻撃する事で初期に決めた目的を達成する事ができる場合もあります。
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日