前言

看了很多 router，今天來看看 Hub 吧

0x00 Target Intro - CVE-2025-65295

設備: 多個 Aqara 廠牌的設備韌體中，包含 Camera Hub G3, Hub M2, Hub M3 (智慧家庭 Hub)
韌體: Aqura archive repo
版本: V4.5.60_0027
漏洞編號: CVE-2025-65295
漏洞簡述: 在Aqara的韌體更新機制實作上，有不安全的簽章認證，使攻擊者可以透過惡意 firmware 通過更新驗證

0x01 定位漏洞

裡面是一個 squashFS 的檔案

在解壓出的 rootFSbin/ 中搜尋firmware相關檔案和腳本可以看到

─$ ls | grep fw
fwdbg
fw_factory.sh
fw_manager.sh
fw_miot_unpack
fw_miot_upgrade.sh
fw_restore.sh
fw_switch.sh
fw_unpack
fw_update
fw_upgrade.sh

其中主要的漏洞位置發生在 fw_manager.sh 中，內建 -s（check sign）與 -n（don't check sign）兩種模式：

259: usage_updater()
260: { 
261:     green_echo "Update firmware."
262:     green_echo "Usage: fw_manager.sh -u [$UPDATER] [path]."
263:     green_echo " -s : check sign."
264:     green_echo " -n : don't check sign."
265: }

實際處理邏輯在 updater() 函式中：

1424: updater()
1425: {
...
1428:     local sign="0"          # 預設值 = 不驗簽章
...
1434:     # Need check sign?
1435:     if [ "$2" = "-s" ]; then sign="1"; fi   # 只有明確傳入 -s 才會啟用

此處的sign 預設關閉，除非指定 -s 參數，而 $sign 值接著往下傳給韌體的解包/驗證程式：

1010:    fw_unpack "$path" "$sign"

0x02 Trace Caller

為了溯源呼叫 fw_manager.sh 的程式，往上看到在 hub 的核心管理程式 ha_master的 .rodata 段中，fw_manager.sh 字串前接著 -n 字串，呼叫時應是一起呼叫的，且並沒有指定 -s 參數

$ uv run python -c "
data = open('bin/ha_master','rb').read()
idx = data.find(b'fw_manager.sh')
print(repr(data[idx-60:idx+60]))
"
b'dfu file from %s to %s\x00\x00burn\x00\x00\x00\x00firmware[%s] burning...\x00-n\x00\x00fw_manager.sh\x00\x00\x00firmware[did=%s] burning...\x008dfu_task\x00\x00\x00...'

（Offset：fw_manager.sh @ 0x63fb9c in bin/ha_master）

0x03 驗證流程

接著查看在 fw_unpack 內的驗證流程
fw_unpack 檔案中 import 了以下 API, 都是RSA相關的API

$ nm-like strings (dynamic symbols):
OPENSSL_init_crypto
BIO_new_mem_buf
PEM_read_bio_RSA_PUBKEY
RSA_public_decrypt
ERR_error_string
ERR_get_error

反編譯main() 後也可以看到以下字串被對應的錯誤分支引用

0x5484: "illegal, fw didn't be signed!!!"
0x54ac: "sign vertify failed"
0x5518: "Public Decrypt failed"
0x5530: "RSA_public_decrypt successful"
0x5500: "signed_info is invalid"

但是由於呼叫端（fw_manager.sh 預設用sign="0"呼叫）沒有執行驗證的指令，因此段防護驗證並不會被實際呼叫路徑觸發

0x04 Hard Coded Key

針對解壓縮的fw_unpack 繼續追相關的 strings，可以看到硬編碼 PEM 公鑰：

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCE9w6rM0ejuwfotGFFW9BitA6SNS9hGcvNVe3w
Qir1gO0HoIEcKsFCwU9h8nos5tezH6ni9UX82cFyiDQhYNKftifZC0dYlDHvRE1+lHUiTY4uozWL
9kLKRIBRNXjFjMMbB6PCG95O9KHRyUA6ueC/JvZ9HCCA94ke61e6P1cXVQIDAQAB
-----END PUBLIC KEY-----

用 Python cryptography 解析驗證，確認是不安全的 1024-bit RSA 公鑰

key size (bits): 1024
exponent e    : 65537
modulus n     : 0x84f70eab3347a3bb07e8 ... f7891eeb57ba3f571755

但還沒結束...

fw_unpack 內完整性檢查相關字串，只有看到不安全的 md5 + CRC32 而沒有任何 SHA-256 等現代雜湊演算法相關實作線索

0x5464: "payload_md5=%s"
0x5914: "local_payload_md5 = %s"
0x595c: "check crc or md5 failed"

$ strings bin/fw_unpack | grep -iE "md5|sha1|sha256|hash"
payload_md5=%s
local_payload_md5 = %s
check crc or md5 failed

0x05 Exploit Chain

綜合以上發現，惡意攻擊者可能透過偽造惡意的有效簽名，並且在沒有經過驗證的情況下安裝惡意的firmware版本。
(由於法遵因素這部分就不PoC了，還不想等傳票)

To Be Continue

原本想來介紹一個迪士尼品牌下的Circle Media製造商出品的家長監控/智慧家庭網路設備的TOCTOU CVE，但檔案被加密過解不開 AES T_T 好想打迪士尼(???)

之後應該會來看看 Emulation Warpup 還有一點 Secure Boot 的東西

Reference

[1] https://www.cve.org/CVERecord?id=CVE-2025-65295