前言

前幾天看的攻擊面，大多都是韌體已經啟動之後暴露出來的 attack surface：Web handler、custom service、authentication flow，或是某個 network-facing daemon。

而另外一個值得獨立提出來的攻擊面是今天的主題 -- 更新機制本身

• 主動連線到外部 server
• 接收遠端提供的檔案
• 解析、解壓縮或轉換內容
• 寫入 flash partition
• 重新啟動裝置
  以上幾個 feature 沒有做好都有可能造成漏洞根因

0x01 定位更新邏輯

以下是一個更新機制大致的順序，其中有些裝置會由 Web interface 直接觸發更新，有些則只是寫入設定，再由另一個 privileged daemon 執行實際更新流程。

Web UI (Optional)
      ↓
CGI / HTTP handler (Optional)
      ↓
update daemon / rc
      ↓
downloader
      ↓
verification
      ↓
flash writer

關於如何定位更新的邏輯：

1. 最直接的是 server URL hardcode 在 binary 裡
2. 也可能是從其他地方讀入 e.g., NVRAM、設定檔、Cloud API等動態取得

0x02 Downloader 與傳輸層

找到更新邏輯後，可以觀察 downloader 怎麼處理連線以及後續憑證驗證等流程。

CVE-2020-15498

舉個例子，ASUS RT-AC1900P 的漏洞原因就是沒有正確驗證憑證， 更新流程呼叫 wget時使用--no-check-certificate， 導致 router 會接受任意 server certificate。

同時也可以注意 --no-check-certificate、 -k、--insecure 這幾個參數值

0x03 Firmware 解壓與安裝

此處可搭配Day03/04的加解密來看，除了可以從更新邏輯裡面撈解密/解壓縮的邏輯外，也可以進一步驗證解密過程的邏輯與處理。

CVE-2025-66255

DB Electronica Mozart FM Transmitter 的 firmware upgrade endpoint 曾被揭露缺乏 signature validation。

Update endpoint 接受 firmware package 時，沒有正確驗證 Header、Signature 和 Format，因此可以接受惡意 firmware package，並進一步導向任意檔案上傳和進一步的RCE

0x04 安裝過程的 Temporary File 與 TOCTOU

更新韌體版本的時候經常會將下載的資料存到比如

/tmp/fw.bin
/tmp/update.json
/tmp/signature

而下載 -> 驗證 -> flash 的過程中，如果驗證和flash過程的導向處理沒有做好，比如以 pathname 開啟檔案造成的時間差，就可能出現 TOCTOU 的情況。

0x05 安裝失敗的fallback

更新失敗的處理實務上的常見設計包括 Dual Image、Boot Count、Recovery Mode 等，會在更新失敗時切換到前一版本上。但如果 boot flag、rollback 條件 或 recovery image 驗證處理不當，也可能造成 降版本攻擊、繞過驗證等問題發生。

Take Away

韌體更新相關的漏洞很多都是出在驗證過程的檢查或是功能實踐的不完全，(有做，但不多的情況)，所以可以多去驗證跟檢查相關的fallback handling或許可以發現一些秘寶(#

To Be Continue

下一篇會選幾個CVE案例去看看更新機制處理不當造成的漏洞案例
肝、、、要鼠了、、、

References

[1] https://nvd.nist.gov/vuln/detail/cve-2020-15498
[2] https://www.ipbuf.com/static/cve/2025/CVE-2025-66255_zh.html