前言

前面幾個case的漏洞位置主要集中在http相關模組上，而韌體上還有一部分的自製 daemon、protocol 也是依大攻擊面可以探討。

0x01 WAN/LAN 攻擊面枚舉

在 rootfs 下，以 router 為例，不只是 httpd，可能同時會有多個 daemon 在不同介面與 port 上監聽。

分析時可以先粗略分成：

• WAN 側可能接觸到的服務
• LAN 側才可達的服務
• 僅 localhost / internal IPC 使用的服務

先找到有哪些 binary 可能在收網路資料，再往下追 protocol。

tips: 列出 rootfs 內所有 ELF

# 找出所有 ELF 執行檔
find "$ROOTFS" -type f -exec file {} \; | grep -i 'ELF.*executable' | wc -l

# 依大小排序，先看看較大的 daemon / service binary
find "$ROOTFS" -type f -exec file {} \; | grep -i ELF | awk -F: '{print $1}' | xargs ls -l 2>/dev/null | sort -k5 -n -r | head -n 30

tips: 從 init script 找出會被啟動的 daemon

從啟動腳本開始看也是一個方法，如 /etc/init.d/、rcS、rc.local 等啟動程式，可以看看裡面實際執行內容。

部分 SysV-style init script 會使用 Sxxname 的形式，表示 boot 過程中啟動的 service，可以優先看看其中和 network、config、discover、upnp、cloud 相關的項目。

# 列出 init script
ls -la "$ROOTFS/etc/init.d/" "$ROOTFS/etc/rc.d/" 2>/dev/null

# 抓出被啟動的 binary 名稱
grep -rhoE '[a-zA-Z0-9_.-]+' "$ROOTFS/etc/init.d/" 2>/dev/null \
  | sort -u > ./init_candidates.txt

tips: 從 binary 本身找出網路相關的證據

如果啟動腳本不好追，也可以直接從 binary 找 socket 使用痕跡。

# 字串中找 address / port / network API
   strings -a ./cfg_server | grep -iE 'bind|listen|accept|sockaddr|INADDR|7788'
   strings -a ./cfg_server | grep -iE '^[0-9]{2,5}$' | sort -un
   
   # Dynamic symbol / call site
   objdump -d ./cfg_server | grep -nE 'socket@|bind@|listen@|accept@|recv@|recvfrom@'

tips: 防火牆與 binding

找到 service listening 並不等於 WAN 一定可達。
除了 bind() 的 address 之外，還要一起看 firewall / network configuration。

iptables -L -n -v 2>/dev/null

   strings -a ./cfg_server \
     | grep -E '0\.0\.0\.0|127\.0\.0\.1|INADDR_ANY'

0x02 Network Protocol 與 Parser

找到 daemon 之後的下一步是確認他在收發資料跟後續處理的對接
通常可以從 socket receive path 往下追比較容易縮小範圍。

accept() / recvfrom()
   ↓
  收進 buffer
   ↓
 交給某個 parse / decode 函式
   ↓
 依 opcode 分派到不同 handler
   ↓
 handler 內部把欄位取出來使用

這邊經常沒有注意到的可能是一致性檢查：實際收到資料與 parser 認為 packet 有多長，兩者之間的檢查。

Parser 怎麼知道一個 Packet 有多長

自訂協定一定要有辦法分辨封包邊界。常見三種：

TLV：Type-Length-Value

Embedded device 的 config / management protocol 很常看到類似 TLV 的結構。
以ASUS cfg_server 類型的 packet 為例：

struct REQ_TLV {
    uint32_t tlv_type;   // opcode
    uint32_t size;       // 這塊資料的長度
    uint32_t crc;        // 檢查碼
    char     buffer[];   // payload
};

Opcode / Command Dispatch

設定服務幾乎都是一個巨大的 switch：

switch (req->tlv_type) {
    case 0x1:  return cm_processREQ_KU(buf);   // 取 public key
    case 0x2:  ...
    case 0x3:  return cm_processREQ_NC(buf);   // 認證
    default:   return -1;
}

讓你的AI逐個 handler 看，如果某些 command 在 authentication 完成之前也能到達，才需要進一步確認它們是不是 pre-auth reachable。

巢狀結構

進階一點的協定不一定只有一層 header

[REQ_TLV type=0x3]
   └── [subpkt: master_key]  len=16
   └── [subpkt: client_nonce] len=16
   └── [subpkt: group_id]    len=4

這時通常有兩層長度需要確認：

Outer packet length
        ↓
Outer TLV size
        ↓
Inner field length

有時候可以找到一些OOB案例

0x03 Parser Vulnerability Hunting

把 protocol format 大致還原之後，就可以開始整理 parser 裡的 boundary condition。

常見缺陷清單

0x04 Fuzzing 101

三種 harness 策略

To Be Continue

感覺肝在燃燒了
晚點會針對前面幾篇細節重寫+稍微重構一下，感覺目前還是有點亂
加上有一些細節還想再看看>< 有幾天太水了，要重新面對一下
明天來說說針對這些 WAN/LAN 面的自製 Network Protocol 的 Fuzzing

Reference

[1] 有料的fuzzing教材：https://github.com/antonio-morales/Fuzzing101
[2] fuzzing 心法
[3] https://www.linkedin.com/posts/jeppojeps_i-will-be-speaking-ssd-secure-disclosure-activity-7459631833845166080-RjsB