ファームウェア分析
Reading time: 21 minutes
tip
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。
はじめに
関連リソース
Synology Encrypted Archive Decryption
ファームウェアは、デバイスが正しく動作するために必要なソフトウェアであり、ハードウェアコンポーネントとユーザーが対話するソフトウェア間の通信を管理し促進します。これは永続メモリに保存されており、デバイスが電源を入れた瞬間から重要な指示にアクセスできるようにし、オペレーティングシステムの起動につながります。ファームウェアを調査し、潜在的に修正することは、セキュリティの脆弱性を特定するための重要なステップです。
情報収集
情報収集は、デバイスの構成や使用されている技術を理解するための重要な初期ステップです。このプロセスには、以下のデータを収集することが含まれます:
- CPUアーキテクチャと実行されているオペレーティングシステム
- ブートローダーの詳細
- ハードウェアレイアウトとデータシート
- コードベースのメトリクスとソースの場所
- 外部ライブラリとライセンスの種類
- 更新履歴と規制認証
- アーキテクチャ図とフローダイアグラム
- セキュリティ評価と特定された脆弱性
この目的のために、**オープンソースインテリジェンス(OSINT)**ツールは非常に貴重であり、手動および自動レビュープロセスを通じて利用可能なオープンソースソフトウェアコンポーネントの分析も重要です。Coverity ScanやSemmle’s LGTMのようなツールは、潜在的な問題を見つけるために活用できる無料の静的分析を提供します。
ファームウェアの取得
ファームウェアを取得する方法はいくつかあり、それぞれ異なる複雑さがあります:
- 直接ソース(開発者、製造業者)から
- 提供された指示から構築する
- 公式サポートサイトからダウンロードする
- ホストされたファームウェアファイルを見つけるためにGoogle dorkクエリを利用する
- S3Scannerのようなツールを使ってクラウドストレージに直接アクセスする
- 中間者攻撃技術を介して更新を傍受する
- UART、JTAG、またはPICitのような接続を通じてデバイスから抽出する
- デバイス通信内での更新要求をスニッフィングする
- ハードコーディングされた更新エンドポイントを特定して使用する
- ブートローダーまたはネットワークからダンプする
- すべてが失敗した場合、適切なハードウェアツールを使用してストレージチップを取り外して読み取る
ファームウェアの分析
ファームウェアを取得したので、それに関する情報を抽出してどのように扱うかを知る必要があります。そのために使用できるさまざまなツールがあります:
file <bin>
strings -n8 <bin>
strings -tx <bin> #print offsets in hex
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple
画像のエントロピーをbinwalk -E <bin>
で確認し、エントロピーが低ければ暗号化されていない可能性が高いです。エントロピーが高ければ、暗号化されている(または何らかの方法で圧縮されている)可能性があります。
さらに、これらのツールを使用してファームウェア内に埋め込まれたファイルを抽出できます:
File/Data Carving & Recovery Tools
またはbinvis.io(code)を使用してファイルを検査します。
ファイルシステムの取得
前述のツールbinwalk -ev <bin>
を使用してファイルシステムを抽出できたはずです。
Binwalkは通常、ファイルシステムのタイプに名前を付けたフォルダー内に抽出します。通常、以下のいずれかです:squashfs、ubifs、romfs、rootfs、jffs2、yaffs2、cramfs、initramfs。
手動ファイルシステム抽出
場合によっては、binwalkがファイルシステムのマジックバイトをシグネチャに持っていないことがあります。このような場合は、binwalkを使用してファイルシステムのオフセットを見つけ、バイナリから圧縮されたファイルシステムを切り出し、以下の手順に従ってそのタイプに応じて手動でファイルシステムを抽出します。
$ binwalk DIR850L_REVB.bin
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------- ---
0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1""""
10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41
次のddコマンドを実行して、Squashfsファイルシステムを切り出します。
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
8257536+0 records in
8257536+0 records out
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s
代わりに、次のコマンドを実行することもできます。
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
- squashfs(上記の例で使用)
$ unsquashfs dir.squashfs
ファイルはその後"squashfs-root
"ディレクトリにあります。
- CPIOアーカイブファイル
$ cpio -ivd --no-absolute-filenames -F <bin>
- jffs2ファイルシステムの場合
$ jefferson rootfsfile.jffs2
- NANDフラッシュを使用したubifsファイルシステムの場合
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
ファームウェアの分析
ファームウェアが取得されたら、その構造と潜在的な脆弱性を理解するために解剖することが重要です。このプロセスでは、ファームウェアイメージから貴重なデータを分析し抽出するためにさまざまなツールを利用します。
初期分析ツール
バイナリファイル(<bin>
と呼ばれる)の初期検査のためのコマンドセットが提供されています。これらのコマンドは、ファイルタイプの特定、文字列の抽出、バイナリデータの分析、およびパーティションとファイルシステムの詳細の理解に役立ちます:
file <bin>
strings -n8 <bin>
strings -tx <bin> #prints offsets in hexadecimal
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head #useful for finding signatures in the header
fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
画像の暗号化状態を評価するために、entropyはbinwalk -E <bin>
でチェックされます。低いエントロピーは暗号化の欠如を示唆し、高いエントロピーは暗号化または圧縮の可能性を示します。
埋め込まれたファイルを抽出するために、file-data-carving-recovery-toolsのドキュメントやファイル検査のためのbinvis.ioなどのツールとリソースが推奨されます。
ファイルシステムの抽出
binwalk -ev <bin>
を使用することで、通常はファイルシステムを抽出でき、しばしばファイルシステムタイプ(例:squashfs、ubifs)にちなんだ名前のディレクトリに抽出されます。しかし、binwalkがマジックバイトの欠如によりファイルシステムタイプを認識できない場合、手動抽出が必要です。これには、binwalk
を使用してファイルシステムのオフセットを特定し、その後dd
コマンドを使用してファイルシステムを切り出します。
$ binwalk DIR850L_REVB.bin
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
その後、ファイルシステムのタイプ(例:squashfs、cpio、jffs2、ubifs)に応じて、異なるコマンドが使用されて手動で内容を抽出します。
ファイルシステム分析
ファイルシステムが抽出されると、セキュリティの欠陥を探す作業が始まります。注意が払われるのは、安全でないネットワークデーモン、ハードコーディングされた認証情報、APIエンドポイント、更新サーバーの機能、未コンパイルのコード、スタートアップスクリプト、オフライン分析用のコンパイル済みバイナリです。
検査すべき主要な場所と項目には以下が含まれます:
- etc/shadow と etc/passwd のユーザー認証情報
- etc/ssl のSSL証明書とキー
- 潜在的な脆弱性のための設定ファイルとスクリプトファイル
- さらなる分析のための埋め込まれたバイナリ
- 一般的なIoTデバイスのウェブサーバーとバイナリ
いくつかのツールがファイルシステム内の機密情報や脆弱性を明らかにするのを助けます:
- LinPEAS と Firmwalker の機密情報検索
- The Firmware Analysis and Comparison Tool (FACT) の包括的なファームウェア分析
- FwAnalyzer、ByteSweep、ByteSweep-go、および EMBA の静的および動的分析
コンパイル済みバイナリのセキュリティチェック
ファイルシステム内で見つかったソースコードとコンパイル済みバイナリは、脆弱性のために精査されなければなりません。Unixバイナリ用のchecksec.shやWindowsバイナリ用のPESecurityのようなツールは、悪用される可能性のある保護されていないバイナリを特定するのに役立ちます。
動的分析のためのファームウェアのエミュレーション
ファームウェアをエミュレートするプロセスは、デバイスの動作または個々のプログラムの動的分析を可能にします。このアプローチは、ハードウェアやアーキテクチャの依存関係に関する課題に直面することがありますが、ルートファイルシステムや特定のバイナリを、Raspberry Piのような一致するアーキテクチャとエンディアンネスを持つデバイスや、事前構築された仮想マシンに転送することで、さらなるテストが容易になります。
個々のバイナリのエミュレーション
単一のプログラムを調べるためには、プログラムのエンディアンネスとCPUアーキテクチャを特定することが重要です。
MIPSアーキテクチャの例
MIPSアーキテクチャのバイナリをエミュレートするには、次のコマンドを使用できます:
file ./squashfs-root/bin/busybox
必要なエミュレーションツールをインストールするには:
sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils
MIPS(ビッグエンディアン)用には qemu-mips
が使用され、リトルエンディアンバイナリ用には qemu-mipsel
が選択されます。
ARMアーキテクチャエミュレーション
ARMバイナリの場合、プロセスは似ており、エミュレーションには qemu-arm
エミュレーターが利用されます。
フルシステムエミュレーション
Firmadyne、Firmware Analysis Toolkit などのツールは、フルファームウェアエミュレーションを容易にし、プロセスを自動化し、動的分析を支援します。
実践における動的分析
この段階では、実際のデバイス環境またはエミュレートされたデバイス環境が分析に使用されます。OSおよびファイルシステムへのシェルアクセスを維持することが重要です。エミュレーションはハードウェアの相互作用を完全に模倣できない場合があるため、時折エミュレーションを再起動する必要があります。分析はファイルシステムを再訪し、公開されたウェブページやネットワークサービスを悪用し、ブートローダーの脆弱性を探るべきです。ファームウェアの整合性テストは、潜在的なバックドアの脆弱性を特定するために重要です。
実行時分析技術
実行時分析は、gdb-multiarch、Frida、Ghidraなどのツールを使用して、プロセスまたはバイナリとその動作環境で相互作用し、ブレークポイントを設定し、ファジングやその他の技術を通じて脆弱性を特定します。
バイナリの悪用と概念実証
特定された脆弱性のPoCを開発するには、ターゲットアーキテクチャと低レベル言語でのプログラミングに関する深い理解が必要です。組み込みシステムにおけるバイナリ実行時保護は稀ですが、存在する場合は、リターン指向プログラミング(ROP)などの技術が必要になることがあります。
ファームウェア分析のための準備されたオペレーティングシステム
AttifyOS や EmbedOS のようなオペレーティングシステムは、必要なツールを備えたファームウェアセキュリティテストのための事前構成された環境を提供します。
ファームウェアを分析するための準備されたOS
- AttifyOS: AttifyOSは、IoTデバイスのセキュリティ評価とペネトレーションテストを行うためのディストリビューションです。必要なツールがすべてロードされた事前構成された環境を提供することで、多くの時間を節約します。
- EmbedOS: ファームウェアセキュリティテストツールがプリロードされたUbuntu 18.04に基づく組み込みセキュリティテストオペレーティングシステムです。
ファームウェアダウングレード攻撃と安全でない更新メカニズム
ベンダーがファームウェアイメージの暗号署名チェックを実装しても、バージョンロールバック(ダウングレード)保護はしばしば省略されます。ブートローダーまたはリカバリーローダーが埋め込まれた公開鍵で署名を検証するだけで、フラッシュされるイメージのバージョン(または単調カウンター)を比較しない場合、攻撃者は有効な署名を持つ古い脆弱なファームウェアを正当にインストールでき、修正された脆弱性を再導入することができます。
典型的な攻撃ワークフロー:
- 古い署名済みイメージを取得
- ベンダーの公開ダウンロードポータル、CDN、またはサポートサイトから取得します。
- 付属のモバイル/デスクトップアプリケーションから抽出します(例:Android APKの
assets/firmware/
内)。 - VirusTotal、インターネットアーカイブ、フォーラムなどのサードパーティリポジトリから取得します。
- イメージをデバイスにアップロードまたは提供 します:
- Web UI、モバイルアプリAPI、USB、TFTP、MQTTなど。
- 多くの消費者向けIoTデバイスは、Base64エンコードされたファームウェアブロブを受け入れる認証されていない HTTP(S) エンドポイントを公開し、サーバー側でデコードし、リカバリ/アップグレードをトリガーします。
- ダウングレード後、最新のリリースで修正された脆弱性を悪用します(例えば、後で追加されたコマンドインジェクションフィルターなど)。
- オプションで、最新のイメージを再フラッシュするか、持続性を得た後に検出を避けるために更新を無効にします。
例:ダウングレード後のコマンドインジェクション
POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1
Host: 192.168.0.1
Content-Type: application/octet-stream
Content-Length: 0
脆弱な(ダウングレードされた)ファームウェアでは、md5
パラメータがサニタイズされることなくシェルコマンドに直接連結されており、任意のコマンドの注入を可能にしています(ここでは、SSHキーによるルートアクセスの有効化)。後のファームウェアバージョンでは基本的な文字フィルタが導入されましたが、ダウングレード保護が欠如しているため、修正は無意味です。
モバイルアプリからのファームウェアの抽出
多くのベンダーは、アプリがBluetooth/Wi-Fi経由でデバイスを更新できるように、完全なファームウェアイメージをそのコンパニオンモバイルアプリケーション内にバンドルしています。これらのパッケージは、一般的にassets/fw/
やres/raw/
のようなパスの下に暗号化されずに保存されています。apktool
、ghidra
、または単純なunzip
などのツールを使用すると、物理ハードウェアに触れることなく署名されたイメージを抽出できます。
$ apktool d vendor-app.apk -o vendor-app
$ ls vendor-app/assets/firmware
firmware_v1.3.11.490_signed.bin
アップデートロジック評価のチェックリスト
- アップデートエンドポイントの輸送/認証は適切に保護されていますか(TLS + 認証)?
- デバイスはフラッシングの前にバージョン番号または単調なアンチロールバックカウンターを比較しますか?
- 画像はセキュアブートチェーン内で検証されていますか(例:ROMコードによる署名の確認)?
- ユーザーランドコードは追加のサニティチェックを行いますか(例:許可されたパーティションマップ、モデル番号)?
- 部分的またはバックアップのアップデートフローは同じ検証ロジックを再利用していますか?
💡 上記のいずれかが欠けている場合、プラットフォームはロールバック攻撃に対して脆弱である可能性があります。
実践用の脆弱なファームウェア
ファームウェアの脆弱性を発見する練習をするために、以下の脆弱なファームウェアプロジェクトを出発点として使用してください。
- OWASP IoTGoat
- https://github.com/OWASP/IoTGoat
- The Damn Vulnerable Router Firmware Project
- https://github.com/praetorian-code/DVRF
- Damn Vulnerable ARM Router (DVAR)
- https://blog.exploitlab.net/2018/01/dvar-damn-vulnerable-arm-router.html
- ARM-X
- https://github.com/therealsaumil/armx#downloads
- Azeria Labs VM 2.0
- https://azeria-labs.com/lab-vm-2-0/
- Damn Vulnerable IoT Device (DVID)
- https://github.com/Vulcainreo/DVID
参考文献
- https://scriptingxss.gitbook.io/firmware-security-testing-methodology/
- Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things
- Exploiting zero days in abandoned hardware – Trail of Bits blog
トレーニングと認証
tip
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricksをサポートする
- サブスクリプションプランを確認してください!
- **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
- HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。