IoTセキュリティ対策 診断・解析入門

本投稿記事は、当社の内定者である黒林檎氏にIoTの解析について調査してもらいました。IoTのセキュリティはまだまだ課題が山積みですが、解析入門ということで調査結果を公開いたします。

はじめに

日本でもIoTのハッキングが注目視されてきました。
IoTが"Internet of Things"の略称であり"モノのインターネット"というのは既知かと思います。
様々な"もの"がインターネットに接続され、情報交換することにより相互に制御する仕組みであり、スマートウォッチなどが想像されがちですがそれはIoTにおけるほんの一部であり、実際はインターネットなどにより通信する仕組みを備えた家電製品などもIoTの一種になります。
本稿では、今後重要性を増すIoT機器のセキュリティ診断・解析について具体的な解析手法にも触れながら入門編を寄稿いたします。

IoTのハッキング(診断)とは？

大まかにIoTの診断を分けると以下の3つになります。

未知の脆弱性診断

-> ファジングツールなどを利用して脆弱性診断

既知の脆弱性診断

-> 既存プロトコルに対する診断
-> サービスに対する診断

EDSA(制御システムに関する国際的なセキュリティ基準)

->国際的なセキュリティ基準を満たしているかなど調査

IoTの診断内容

■プロトコル

機器固有のプロトコルに沿って異常なリクエストや認証のバイパスを試みるリクエストを送る等のテストを行い、攻撃者の利益になるような挙動を起こさないか診断します。

■DoS

機器に対して異常な内容のリクエスト・異常な量のリクエストを送り、機器の動作に支障をきたさないか診断します。

■ファームウェア

機器のファームウェアアップデートファイルや、そのアップデート過程を調べ、 秘密のロジック・鍵が解析可能だったり、不正なアップデート(例えば改造ファームウェア)を適用可能かどうか調べます。

■その他

機器の特性を悪用した攻撃の存在しないか確認します。 また、基盤に通信線を繋いでデバッグログの観察などの「ハードウェア解析」が可能であれば実施します。

IoTの通信解析

IoT機器の解析において、通信解析から取り掛かるメリットは大きいです。
特に、IoT機器を操作する”Android / iPhone”のアプリが難読化されていた際の静的解析(ソースコードやバイナリファイルを直接読む作業)に対する時間ロスが生じますが通信解析から行う事で例えば、ドメイン名などを簡単に解析出来ない様に記述したり、ソースコード名をランダムな名称 (※”aa.java”や”jj.java”などの様なランダムな物)に変更するなどされていた際にも解析の目安になるため、最初に静的解析を行うより前の段階で通信解析で目安を作りその情報を元に解析する事が重要と思われます。

（図）IoT機器に関連したAndroidアプリを解析した際の流れ

それでは、IoT機器の通信をどう解析するのか？という疑問が生まれます。
ここで重要な事は、”どう通信をキャプチャするか？ ”という事でここでは2つの方法をご紹介させていただきます。

［1］AndroidやiPhoneの通信をキャプチャする。

基本的にIoT機器への命令を実行するのはスマートフォンなどのIoT機器につながっている端末なので命令実行時の通信を”OWASP ZAP”や”Brup Suite”といったウェブプロキシーを経由させる事で通信をキャプチャすることが可能で、前述の”（図）IoT機器に関連したAndroidアプリを解析した際の流れ”の中の[2]の方法がこれになります。

[この手法に関するメリットとデメリット]

• メリット：ノートPC１つで完結でき、解析が容易に可能。
• デメリット：IoT機器自体の通信を取り出すことが出来ない。

［2］ネットワークすべてをキャプチャする。

IoT機器もAndroidなどの操作する端末もすべて同一のネットワークに接続します。
下記の画像をその例とさせて頂きます。

（図）基本的なAndroidの通信

この方法は、WiFi部分の通信をキャプチャする事でIoT機器とAndroidの両方の通信をキャプチャする事が可能で、前者の方法であった” IoT機器”に対する通信解析だけでは見つけられない通信を解析する事が出来ます。

それを画像で表すと下記になります。

（図）WiFi部分の通信キャプチャ

そして、その際のネットワーク環境を簡単に構築する場合以下の様な構成が簡単です。

（図）ネットワーク構成

この構成であれば、無線LAN(※無線LANアダプタ)の通信をキャプチャする事でIoT機器とそのIoT機器を操作するAndroid端末のパケットをすべて調べる事が出来ます。
この構成は前述の手法[1]”AndroidやiPhoneの通信をキャプチャする”とは違い、IoTの通信も含めてすべてキャプチャする事が可能になりました、これでIoT機器のバイナリなどを解析する際にその通信を元に解析の目安を作る事が出来ます。
ネットワーク環境を作らなければなら無いですが、この解析方法が一番手軽にIoT機器自体の通信解析が出来ます。

[この手法に関するメリットとデメリット]

• メリット：IoT機器とAndroidなどの通信を一括で解析出来る。
• デメリット：ネットワーク環境の構築と通信量が増えるため解析コストが上がる。

［3］IoT機器の既存デバッグサービスを使う。

IoT機器の通信解析に関して簡単に説明させて頂きましたが、IoT機器はハッキングの情報が少なくハードウェアまで下がれば難易度が高いハッキングになります。
しかし、それは開発側にも言える事でIoT機器の開発メーカーは増えてきましたが、開発ノウハウや品質テストなどが曖昧な場合がありAdmin APIの未認証などが多く騒がれています。
今回は開発者により作成され製品リリース後も防がれず残されたデバッグポートについて説明させて頂きます。

今回のデバッグポートは”製品開発時に正常に動作・通信しているか”や”機器開発時の簡易デバッグサービス”などを指します。

考え方ですがIoT機器は通信を行うので、IPアドレスも割り当てられます。
センサーであれば温度の情報を送信し、カメラであれば画像や映像を送信します。
そして、”送信”を行うという事は”受信”も行います。
“送信と受信”は切っても切れない関係であり、IoT機器は単純に機能を省略化したパソコンと考えるべきです。
中でOSが動いているのであれば通常のウェブサーバの様にサービスのポートが空いている可能性があるためポートスキャナを行います。
他にも、HTTP経由のウェブ管理コンソールなどのログイン機構があればセッションハイジャックが可能かもしれません。
IoT機器は便利ですが、システム自体が複雑で多くの機能を持っているため狙われる脆弱性は通常のウェブサービスなどより多くなります。

下記の画像では、デバッグポートを見つけそこにtelnetでアクセスを試みブラウザでそこにアクセスするという一連の流れを表しています。

（図）デバッグポートの発見簡易図

この流れは、サーバに対する攻撃と似ているので理解しやすいと思います。
IoT機器はIPアドレスが割り振られているので、そのIPアドレスに対して全ポートのスキャンを行います。(※IoT機器のIPアドレスがわからない場合、ルーターの管理コンソールなどから接続中のIPアドレスを列挙し接続端末などのIPアドレスと比較してください。)
全ポートのスキャンを行う理由ですが、nmapはデフォルトですべてのポートをスキャンしないため今回の様な”port:54321”をデフォルトのスキャンでは見つけてくれません。
今回もし全ポートに対してスキャンを実行していなければ、見落としが起っていました。
何かサービスを提供しているのであれば、ポートが1つも空いていない場合は疑い再度調べなおす事をお勧めします。
より多くの情報を持っている方が診断作業を行う上で有利に働くからです。

[この手法に関するメリットとデメリット]

• メリット：攻撃に使用出来れば、すべての機器に共通する問題になる
• デメリット：リリース時に削除されていれば見つけることが不可能

IoTのファームウェアの解析

ファームウェア解析

IoTの解析において、ファームウェアの解析は重要な手段です。ファームウェアの分析で得れる結果として、”バグ・脆弱性・GPL違反”などが挙げられます。
それでは、ファームウェアの分析をどの様に行えばいいのか見ていきましょう。
ハッキング全般で言える事ですが、”対象から何を得たいか”という目的が重要になります。今回は、ファームウェアを以下の様な形式にデコンプレスする事を目的とします。

(図)firmware.binをデコンプレスしファイルを抽出

ファームウェアの解析は難しい様に見えますが、解析・抽出といった作業は対象のファームウェアさえ取得すれば多くの場合容易に行う事が可能です。
最初に、このファームウェアが通常の圧縮ファイル(ZIPなど)でない事を確認します、この段階でファームウェアがZIP圧縮であると判明すれば今回ご紹介する抽出作業などを必要としません。
また、そのファームウェアが実際に私たちが欲しているファイルなのかどうかを抽出前に確認したい場合があると思います。
その際は、hexdumpやstringsコマンドを併用し、特定文字列(ブートローダ)などの文字列を探します。
例1)strings –n 10 firmware.bin > strings.txt
例2)hexdump –C firmware.bin > hex.txt

それでは、binwalkを使用してファームウェアの分析を行います。
今回は、squashfsを調べたいのでオプションなど使用しません。
binwalkの結果から必要な箇所を下記画像に抜き出しました。

(図)binwalkを使用してファームウェアのヘッダを分析

また、binwalkではオプションをつける事でより多くの情報を得ることが出来ます。
図にも説明を載せていますが、”-e”はファイルタイプの抽出で”-M”は再帰的スキャンです。
2つのオプションを併用する事でファームウェアの解析で情報の見落としを無くす事が出来ます。

下記画像と先ほどの画像を見比べると一目瞭然かと思います。

(図)binwalkを使用した再帰的スキャン

それでは、本題に戻ります。
squashfsの抽出をddコマンドで行ってみます。
簡単ですが、ddコマンドについて説明を図解してみました。

(図)ddコマンドの書式と説明

skipとcountの値が何を指しているのかわからない方もいると思いますが、各値は先ほどのbinwalkの分析結果から得たsquashfsのDESIMAL値とsize値です、結果としof＝firmware.squashfsでファームウェアから指定した名前でsquashfsファイルを抽出しています。

(図)unsquashfs(Firmware Modification Kit)を使用してファイル抽出を試みる

『Can't find a SQUASHFS superblock on firmware.squashfs(squashfsのスーパーブロックを見つける事ができません)』というエラーが出て、うまくファイルを抽出する事が出来ません。
適切に抽出出来ない原因ですが、抽出したファイルサイズなども問題無い(勿論、binwalkの分析結果自体が違うと疑問に思う事も重要ですが)ため、LZMAヘッダが開発ベンダーによって書き換えられていると考えるのが妥当です。

それでは、LZMAヘッダを書き換えるとはどういう事でしょうか?
簡単に例えるなら、ファームウェア用の難読化と考えてもらって構いません。
ファームウェアでは簡単にデコンプレス(ファームウェアのファイルを抽出する作業)を行われないためにLZMAのヘッダなどを書き換えてunsquashfsなどで簡単にファイル抽出を出来ない様にしています。

(図)LZMAヘッダの変更

では、この様にLZMAヘッダなどを書き換えられている場合(標準の圧縮で無い場合)どの様に抽出をすれば良いのでしょうか?
前に紹介した、sasquatchというツールはこの問題を簡単に解決してくれます。
sasquatchの主な特徴をご紹介させて頂きます。

• squashfsのマジックバイトを気にしない
• 圧縮ヘッダフィールドを信頼しない
• ベンダー固有のLZMAの実装を追加

などファームウェアからファイルの抽出を行う際に役に立つ機能が多数あります。

それでは、sasquatchを使用してファイルを抽出してみましょう。

(図)sasquatchでfirmware.binからファイルを抽出

firmware.binから正しくファイルが抽出された様に見えるので、どの様なファイルが抽出されたかを確認してみます。

(図)firmware.binから抽出されたファイル

幾つか見慣れたコマンドとbusyboxという文字列が見えます、このbusyboxとはなんでしょうか?

busyBox は、Coreutilsなど標準UNIXコマンドで重要な多数のプログラムを単一の実行ファイルに「詰め込んで」提供する、特殊な方式のプログラムである（その詰め込み方法を指して呼ぶこともある）。なおかつ、その実行ファイルはLinux上で最小の実行ファイルとなるよう設計されており、各コマンドの実行ファイルをインストールするのに比べディスクの使用量を大幅に削減することができる。そのため、特定用途のLinuxディストリビューションや組み込みシステムに最適である。「組み込みLinuxの十徳ナイフ」と呼ばれている。GPLv2 でリリースされているフリーソフトウェアである。

参照：https://ja.wikipedia.org/wiki/BusyBox

簡単にまとめると、組み込みシステムのような使用可能ディスクサイズに制限がある環境において最小実行ファイルになる様に単一実行ファイルに多数の重要なプログラムを詰め込んだ物の様です。
組み込みシステムのファームウェアをここまで解析できれば、何か面白い物を見つけて見たいと思います。深刻度が高い例えをご紹介させて頂くと、TLS証明書が存在すればその秘密鍵を見つける事が可能です。これらの証明書を盗む事で、同じ機器に対する攻撃(中間者攻撃)で役に立ちます。

下記の幾つかの証明書があります。

(図)ファームウェアに含まれていた3つの証明書

cert.pemは公開鍵で、key.pemとprivkey.pemは秘密鍵です。
これらの証明書のうち秘密鍵がすべての同一機器で同じ物を使用されていれば中間者攻撃の標的になり、これは2015年に

多数のメーカーが組み込み機器に同一の秘密鍵使用

として問題視されています。
参照：http://www.itmedia.co.jp/enterprise/articles/1511/26/news046.html

IoTは、”物がインターネットに繋がっただけ”に聞こえますが、IoTでは攻撃者の攻撃出来る箇所が通常のウェブサービスなどより多くなり単純に思いつく攻撃箇所を挙げます。

• IoTを操作するスマートフォンアプリなどのセキュリティ
• IoTのファームウェアのセキュリティ
• IoT機器固有のセキュリティリスク
• IoT本体に使用されているオペレーションシステム固有の脆弱性

これらの脆弱性を見つけるためにはより多くの脆弱性に対する攻撃方法を把握していなければなりません。

IoTのセキュリティ関連資料として2016年5月12日にIPAが”IoT開発におけるセキュリティ設計の手引き”を公開しました、是非お読みください。

UART通信ケーブルからのハッキング

IoTをUART通信ケーブル経由でハッキングする。

ここまで、IoTの”ソフトウェア”に関する攻撃を紹介しました。しかし、IoT機器の一番難易度が高いと思われる攻撃が基盤から直接情報を取得する攻撃です。

以下は、あるルーターの外枠を外し基盤を取り出した物です。

(画像)ルーターの基盤

一見、どこをハッキングの糸口に狙えばいいのかわかりません。
ICチップの型を調べてICE(インサーキット・エミュレータ)と呼ばれる機器を使用し直接デバッグピンからアクセスするといった方法は、専門的な知識と専用機器を購入する資金が無ければ出来ません。
それでは、ICEなどを使用せずどの様に基盤からIoTのハッキングする事は可能でしょうか？
BlackHatで発表されていたIoTのスコープをハッキングした発表内容を例に見てみましょう。

参照：https://www.blackhat.com/docs/us-15/materials/us-15-Sandvik-When-IoT-Attacks-Hacking-A-Linux-Powered-Rifle.pdf

技術的に色々試行しているのは置いておいて、簡単にこのハッキングのステップは以下です。

(図)IoTスコープへのハッキング内容の簡易化

上記画像の簡易説明

• スコープの基盤を剥き出しにする(Tearing it open)
• UART通信ケーブルを基盤に接続しコンソール接続する(UART)
• 接続が成功すればスコープのシステムに接続できる(Woot!)

この3つの説明だけ見れば簡単に思えます。
実際にその通りでUART経由の組み込みシステムへのハッキングは思ったより簡単で2つを把握すれば、電子回路に対する知識を有しない方でもハードルは低く組込みシステムにハッキングを行えると言えます。

[1]基盤のUARTピンの識別

 

[2]シリアル通信のボーレート値の推測

 

この2つの知識でUARTに対応した組み込みシステムへの攻撃(ログイン機構へのアクセス)が実行出来るのでシステムを攻略しようと考える攻撃者は必ず実行すると思われます。
ここまでUARTという単語が何回かでてきましたが、UARTとは一体何でしょうか?
簡単ですがUARTについての説明をご紹介させて頂きます。

UART (Universal Asynchronous Receiver Transmitter)は、調歩同期方式によるシリアル信号をパラレル信号に変換したり、その逆方向の変換を行うための集積回路である。本機能のみがパッケージングされたICで供給されるものと、マイクロプロセッサのペリフェラルの一部として内蔵されるものとがある。マキシムのMAX232のような、RS-232C規格に準拠する信号レベルに変換するICと組み合わせて、外部機器とのインタフェースとして利用されるのが一般的である。UARTに、同期方式のシリアル信号を変換するための回路を追加したものを、USART (Universal Synchronous Asynchronous Receiver Transmitter) と呼ぶ。

参照：https://ja.wikipedia.org/wiki/UART

色々難しい説明が記述されていますが、重要な部分は赤線部です。
”外部機器とのインターフェースとして利用出来る”のでそこに直接繋ぎ組み込みのシステムにアクセスを試みるという流れになります。

(図)UARTの接続

各ピンの判別の仕方です、以下はUART基板ですが、一体どの様に判別すれば良いのでしょうか?

目安ですが、各ピンの特徴をご紹介致します。
VCC-(定常電圧3.3ボルト / 判別難易度:低い)
TX-(プルアップ 0ボルトから3.3ボルト変動へ /判別難易度:低)
Rx-(フローティング 3.3ボルト,数百ミリボルト変動 /判別難易度:高)

このシリアル通信の仕組みを知るには、ボーレートという言葉を知らなければなりません。
ボーレートとは、シリアル通信において転送速度を設定するパラメータとして”baud(ボー)”または” baudrate(ボーレート)”を単位として用いることがあり、単位は転送速度の単位である”bps”を用いることもあります。
ボーレートとbpsを同じにしてしまいがちですが、以下の違いがあります。

それでは、どこでその単位が必要になるのかも含めUARTを使用した組み込みシステムのハッキングを例に簡単に触れてみます、ここでは対象の組み込み機器と解析PCにUARTにシリアル通信経由で接続する必要があるので専用のアダプタが必要になります。
専用アダプタ 例：http://www.amazon.co.jp/

前述した様に、UARTケーブルはクロスになる様に繋ぎます、GNDピンはGNDピンと接続しますが、それ以外のRX(受信)ピンとTX(送信)ピンをお互いが一つになる様に繋げます。

次に、UART経由で接続するためにシリアルポートのボーレート値を調べる必要があります。
ボーレートの推測ですが、プロトコルアナライザーを使用する方法もありますが、ボーレートを推測するオープンソース(boudrate.py)があるので今回はそれを利用する事にします。

boudrate.pyを使用し、シリアルポートのボーレート値を推測します。

(図)baudrate.pyでボーレート値を調べる

推測された値は、”57600”というボーレート値です。
この値をもとに、UART経由で組み込みシステムへ接続を試みます。
$miniterm.py /dev/tty.SLAB_USBtoUART 57600

(図)UART経由でminitermを使用しシェルへ接続

接続がうまく行われ、ログイン画面までアクセス出来ればUART経由のアクセスに成功です。
ログイン機構にアクセス出来ればログインの資格情報が必要になりますが、多くの場合予測可能文字列である場合が多いです。

(図)ログイン機構へのアクセス

実際のIoTの診断では、このログインの資格情報などが簡単に攻撃者に推測されない物を使用しているか?なども診断項目にあります。
勿論、組み込み機器ではUART以外のシリアル通信(JTAGなど)も多くの機器で使用されているのでその都度方法や必要な知識も変わってきます。

参考サイト とIoTハッキングまとめ

IoTハッキング技術的感想

今回は、IoTのハッキングについて書かせて頂きました。
IoTのハッキングをまとめる上で多数の機器に対する攻撃手法を見て面白かったドローンのハッキング手法と自分でハッキングしていて感じた機器固有の問題についてご紹介させて頂きます。

SamyKamkar氏が行ったドローンのハッキングについてです、参考サイトは下記になります。
参考サイト：http://samy.pl/skyjack/

多くのドローンはWiFi経由で接続されていると思います、それを簡単に図解すると下記図のような接続になります。

(図)通常のドローの接続時

攻撃者はドローンを乗っ取りたいと考えているので、ドローンとユーザーの接続を遮断する必要があります。
WPA-PSKの解析で必要なハンドシェイクを得るために無線LANに対して大量にトラフィックを送るツールでaireplay-ngというツールがあります。
そのツールを使用し無線LANの接続を切る事で、ドローンとユーザー間の接続を強制的に遮断し再認証の瞬間にドローンを乗っ取るという物です。

(図)ドローンの接続を乗っ取る流れ

対象はドローンですが、方法は無線LANに対する攻撃と変わりがありません。
そして、現状のIoTはすべての同一機器で同じ認証鍵を使用している可能性が高いです。
例えば、無線LAN認証を用いたIoT機器であれば専用のアプリ内に無線LANの認証鍵を保持しているという事になります。

(図)IoT機器が発するアクセスポイントをサーチするAndroidソースコード

よって、攻撃者は対象IoTを保有していれば鍵解析の手間が無くなります。
アプリケーションによっては、ソースコードが難読化されていますが、一度Android端末などで認証を行ってしまうので過去に接続したWiFiのパスワードなどは端末に残っているので難読化されているソースコードを解読せずに攻撃者は簡単にIoTに接続できるWiFiのパスワードを得る事が出来ます。

(図)IoT操作アプリでのWiFi接続画面

曖昧だった”機器固有の脆弱性”が見えてきました。
今回の例で言えば、IoT操作アプリから生成されるWiFiパスワードは1つなのですべての機器で同一の鍵が使用できると言えます。

それでは最後に、参考にさせて頂いたウェブサイトをまとめさせて頂きます。

参考にさせて頂いたウェブサイト等

• /dev/ttyS0 Embedded Device Hacking
• 懒得折腾
• The World
• pentestpartners
• Jailbreaking the Microsoft fitness band
• [PDF]The Internet of Things: An Overview

執筆者コメント

IoTの解析は初めて行いました、解析は色々な技術が必要で楽しかったです。
今回のドキュメントもIoT解析の１つの方法として受け取って頂ければと思います。

解析を行う上でセキュリティ的な欠陥がある箇所も多少見受けられましたが、Androidのアプリケーションや使用してる無線LANの暗号化などは安全性が無いと言えば嘘になる作りでした。

例えば、外部にファイルをアップロードする際にワンタイムパスワードの様な文字列を生成する仕組みを持ち合わせていたり(しかし、POSTリクエストで無くGETリクエスト)、無線LANの暗号化がWPA2であったり、ソースコード自体を難読化して解析を妨害する様な作り方をしていたりしました。

これは個人的な感想ですが、製品単価や生じているセキュリティ的欠陥とそれらのセキュアな箇所を見比べると既にセキュリティなどを気にしたAndroidなどのソースコードを部品として用意している、またはIoT機器とAndroidなどのアプリは別の会社が請け負っているなどの感想が出ました。
最後になりますが、IoTの解析についてこのドキュメントをまとめる事が出来て良かったです。
----

※本文書における留意事項
本文書の利用はすべて自己責任でお願い致します。本文書の記述を利用した結果、生じるいかなる損失についても弊社含む関係者は責任を負いかねます。