從 IDOR 到 Root 權限：H3C 光網路終端固件逆向與權限提升實錄

隨著中國聯通的寬帶升級，ISP 連同更換了新款的 H3C HM2004-DU¹光網路終端（Optical Network Terminal/Modem/光貓）。該設備採用了較新的 ARM aarch64 架構與容器化管理設計，與以往常見的 MIPS 架構設備有顯著差異，傳統的提權工具對其失效。

我們應當如何獲取權限呢？無論如何，先明確目標是規劃的根基。

設定目標

獲取 Web 超級管理員賬戶權限與持久化
獲取終端特權
SSH 持久化

權限控制失效

在嘗試 Common Path 遍歷後，我鎖定了一個特殊的路徑 /cgi-bin/telnet.asp。理論上，路徑應當受到特權保護。但出乎意料的是，以普通用戶登入 Web 同樣能夠進入此頁面開啟臨時 Telnet。

這是典型的 Insecure Direct Object References。同時暴露了系統缺乏有效的 Role-Based Access Control 機制——後端僅驗證了會話的有效性，卻未校驗會話所屬角色的權限等級。

終端權限混亂

啟用 Telnet 後，系統僅接受一組硬編碼的憑證 admin:admin，其他賬戶均被拒絕。成功進入後，受限的 Shell 環境缺失了大部分 GNU 標準工具，且 admin 用戶並非 UID 0，這意味著我們僅獲得了一個低權限的維護接口。

基於嵌入式 Linux 的運行機制，運行時的解密配置通常會駐留在 tmpfs 中。透過檢查 /tmp 目錄，我定位到了 ctromfile.cfg 檔案。這份 XML 格式的配置檔案以明文形式存儲了包括超級管理員密碼在內的關鍵憑證。

# cat /tmp/ctromfile.cfg | grep CUAdmin
<Entry0 Active="Yes" username="CUAdmin" web_passwd="[REDACTED]" display_mask="FF FF FF FF FF FF FF FF FF" Logged="0" LoginTimes="0" Logoff="0" />

更出乎意料的是 /etc/passwd 的內容。系統中存在多個 UID 0 賬戶，且權限管理極其混亂。透過嘗試 Credential Reuse Attack，我發現 Web 普通用戶的密碼竟然可以直接用於 su user 的驗證。由於 user 賬號在底層對應 UID 0。我成功的從「Web 普通用戶」到「Linux Root」權限提升。

# cat /etc/passwd
CUAdmin:$1$$...:0:0:root:/:/bin/sh
user:$1$$...:0:0:root:/:/bin/sh
H3CT:$1$$...:668:668:H3CT:/:/bin/sh
CUAdmin:$1$$...:0:0:root:/mnt:/sbin/nologin

Web 權限的持久化

透過從 ctromfile.cfg 中獲取的 CUAdmin 明文密碼，進入超級管理員 Web 控制檯後，首先要移除「TR-069」協議配置，以防止 ISP 透過自動配置伺服器遠程重置密碼或下發固件更新。

在「基本配置」頁面中，「TR069」連接的刪除按鈕為灰色不可用狀態，但當我們刪除對應按鈕元素內的 disable 屬性後，能夠成功刪除「TR069」。

Disclaimer：
刪除 TR-069 可能會導致 ISP 遠程維護失效，無法接受安全補丁等等風險，謹慎考慮。

這是過度依賴前端驗證的後果。攻擊者可以輕易透過 DOM 操作繞過 UI 限制，而後端 API 對於來自超級管理員 Session 的請求缺乏對關鍵參數的安全校驗。

SSH 持久化訪問

為了擺脫不穩定的 Telnet（受 Web 會話超時限制），部署 SSH 是必要的。

該設備採用了較為摩登的 LXC（Linux Containers）架構，根目錄 / 為唯讀的 SquashFS，傳統的 /etc/rc.local 修改法無效。經過分析，業務邏輯運行在 cuinform 容器中，且其掛載點 /opt/cu/apps 位於可寫的 UBIFS 分區。

將靜態編譯的 Aarch64 架構 Dropbear² 透過機身自帶的 USB 傳輸至設備，我選擇了新建 /opt/cu/apps/ssh/目錄存放二進制與密鑰，並利用容器的啟動鏈，在 init.d 中注入了啟動腳本。這樣 SSH 服務就會作為容器的一個子進程隨系統啟動，實現了持久化。