網易首頁 > 網易號 > 正文申請入駐

【安全圈】嚴重漏洞：UniFi OS 無需密碼即可拿下 Root 權限

2026-06-14 19:03:17　來源: 安全圈

江蘇舉報

分享至

關鍵詞

UniFi、Ubiquiti

一、60 秒看完全部要點

一條 HTTP 請求，無憑據、無交互，直取 UniFi OS Serverroot 權限
三個 CVE 串成鏈：訪問控制缺陷 + 路徑穿越 + 命令注入，單個 CVSS 滿分 10.0
受害面有多廣？Ubiquiti 是全球家庭/SMB 網絡第一品牌之一，Cloud Gateway、Dream Machine、UNVR/NVR、UNAS、UniFi Express 全線中招
拿到 root 不只是控制一臺服務器 ——管理平面被攻陷 = 整個網絡 + 門禁 + 攝像頭全部失守
更陰險的是：JWT 簽名密鑰一旦被偷，打了補丁也救不了—— 攻擊者繼續用舊密鑰偽造 admin token
? Bishop Fox 公開了生產可用的檢測工具：CVE-2026-34908-check [2]
? 修復版本：UniFi OS Server 5.0.8（unifi-core 5.0.153）

二、攻擊現場：三次握手拿到 root

2.1 受害應用是個什么玩意兒

UniFi OS Server是 Ubiquiti 的統一管理平臺，把旗下所有產品（Network、Protect 攝像頭、Identity、Update）都攏在一個 Web 界面后面。

它的架構長得像這樣：

┌──────────────────────────────────────────────┐
│   客戶端（你 / 攻擊者）                       │
└──────────────────┬───────────────────────────┘
                   │ HTTPS
                   ▼
         ┌─────────────────────┐
         │  Nginx 前端（11443） │  ← 終止 TLS，做認證
         └──────────┬──────────┘
                    │ 內部轉發
   ┌────────────┬────┴────┬────────────┐
   ▼            ▼         ▼            ▼
 ulp-go      network    protect    update
 (身份)      (網絡)     (攝像頭)    (包更新)

整套安全模型全壓在一個點上：Nginx 前端必須正確判斷"哪些請求是公開的、哪些需要登錄"。

2.2 CVE-2026-34908/34909：Nginx 的"精神分裂"

Bishop Fox 團隊拿到補丁前（5.0.6）和補丁后（5.0.8）的 rootfs，做了三層對比：

Nginx 配置（純文本，diff 干凈）
一個1.2 MB 混淆過的service.js（Node.js 實現 unifi-core 認證處理器）
幾個 Go 二進制（包更新后端）

關鍵漏洞在第一層 —— 一個 Node.js 的authCheck函數：

authCheck = async (req, res) => {
  let uri = getHeader(req.headers, "x-original-uri"); // 原始 $request_uri
  ...
  if (publicRoutes.has(`${method} ${uri}`) ||
      uri?.startsWith("/api/auth/validate-sso/"))      // 白名單前綴匹配
    return res.statusCode = 200, res.end();
  ...
  return res.statusCode = 401, res.end();
};

Bug 在哪？同一個 URI 在 Nginx 眼里有兩個不同的值：

Nginx 變量

用在哪

形態

$request_uri

認證檢查（白名單前綴）

原始字符串，%2f仍然是%2f

$uri

路由（決定轉發到哪個后端）

解碼歸一化，%2f→/，../被壓平

精心構造的請求讓兩邊"看法不一致"：

原始形態以/api/auth/validate-sso/開頭 →白名單放行，200 OK
歸一化形態解析成/proxy/ /xxx→Nginx 把請求轉給"假設已經認證過"的后端

為什么不拆成兩個 CVE？ Bishop Fox 也困惑 —— 在他們看來這就是一個 bug，登記成 CVE-2026-34908 + CVE-2026-34909 大概是按"訪問控制"和"路徑穿越"分別算的影響維度。

2.3 CVE-2026-34910：第二個坑等著你

認證網關被騙過之后，攻擊者能訪問到package-update 后端的一個接口。

這個接口的邏輯很簡單：客戶端傳一個"包名"進來，后端查最新版本，用 shell 命令解析：

// sink 內部大概長這樣
cmd := fmt.Sprintf("sudo /usr/bin/uos runnable latest-versions %v", packageName)
exec.Command("sh", "-c", cmd)

%v 直接插值，零校驗。攻擊者把packageName寫成foo;sleep 5就能在 shell 里任意執行命令。

同一條路徑，有 token 調是 CVE-2026-33000（CVSS 9.1），無 token 調（借由前面的網關繞過）是 CVE-2026-34910（CVSS 10.0）。

Bishop Fox 用了一個非常巧妙的時間型 oracle做無害驗證：

版本

注入sleep 5后響應

5.0.6（未修復）

HTTP 200，但延遲了 5 秒（命令真的執行了）

5.0.8（已修復）

HTTP 400，零延遲（拒絕執行）

"slow 200 vs fast 400" —— 這就是驗證漏洞的標志性差異。

2.4 第三跳：服務賬號的"豪華 sudo 配置"

命令注入拿到的 shell 不是 root，而是ucs-update這個服務賬號。

按理說被沙箱化也認了。但 Ubiquiti 給了這個賬號一個豪華 sudoers 白名單：

ucs-update ALL=(ALL) NOPASSWD: /usr/bin/dpkg
ucs-update ALL=(ALL) NOPASSWD: /bin/chmod
ucs-update ALL=(ALL) NOPASSWD: /bin/systemctl
ucs-update ALL=(ALL) NOPASSWD: /usr/bin/uos

每一條都是"一鍵 root"： dpkg -i 安裝一個 .deb ，postinst 腳本以 root 跑 chmod 改 /etc/shadow 權限 systemctl 改服務配置 uos 是 Ubiquiti 自家命令

Bishop Fox 選了最簡單的dpkg路徑：打了個空殼 .deb 包，postinst 腳本里寫一句cat /etc/shadow > /tmp/out，sudo -n dpkg -i evil.deb—— 拿到 shadow 文件內容，root 身份坐實。

"提權不是難點，是走個過場" —— 攻擊者從一條 HTTP 請求到 root shell，總共三次跳轉。

三、為什么"拿到 root"等于"控制整個家"

UniFi OS Server 不是一個普通應用服務器，它是管理平面。

Bishop Fox 在博客里點出關鍵：

Root 讀到的是整個密鑰庫： JWT 簽名密鑰（最致命 —— 見第四節） TLS 私鑰云端 token 用戶數據庫 RADIUS / WiFi / VPN 憑據

Root 寫的是物理世界：解鎖門禁（UniFi Access）關閉/調取攝像頭（UniFi Protect）控制交換機 ACL、防火墻規則改 DNS 把所有客戶端劫持到釣魚頁

一個家庭或小公司可能花幾十萬元部署 UniFi 全套生態，結果一條 HTTP 請求就全部拱手讓人。

四、最陰險的細節：補丁救不了你

Bishop Fox 在結尾專門強調了一段所有應急人員必看的話：

"The fix closes the way in, but it does not reach back and undo what an attacker already did with root on an instance that was exposed beforehand."

具體說：

攻擊者已經做過的

補丁能不能撤銷

偷走 JWT 簽名密鑰

?不能

用舊密鑰鑄造的偽造 admin token

?繼續有效，直到密鑰輪換

設置 SSH root 密碼 / 留后門

?繼續有效

留持久化（cron / systemd unit）

?繼續存在

所以"打補丁"是起點，不是終點。 Bishop Fox 強烈建議已經暴露過但還沒確認是否被入侵的設備，直接重建，不要相信"輪換密鑰就夠了"。

五、給防御者的 5 步操作清單

5.1 立刻打補丁

產品線

修復版本

UniFi OS Server

（軟件）

5.0.8

（unifi-core 5.0.153）

Cloud Gateways / Dream Machines / NVR

5.1.12+

UNAS 系列

5.1.10+

Dream Machine Beast

5.1.11+

UniFi Express

4.0.14+5.2 如果暫時打不了補丁

只做一件事：把管理界面的網絡可達范圍縮到最小。

UniFi OS Server 默認監聽TCP 11443。兩條鐵律：

?絕不要讓這個端口能從公網直接訪問
?絕不要讓這個端口暴露在訪客 VLAN
? 放在專門的管理 VLAN，ACL 收緊

5.3 跑 Bishop Fox 公開的檢測工具

git clone https://github.com/BishopFox/CVE-2026-34908-check
cd CVE-2026-34908-check
# 單個目標
python3 check.py 192.168.1.1:11443
# 批量
python3 check.py -f targets.txt --json

它做了什么、為什么安全：

? 發一個不帶注入參數的探測請求，不會執行任何命令
? 不會讀任何文件或密鑰
? 不會修改目標狀態
? 4 種結論：vulnerable / patched / unaffected（不是 UniFi OS Server）/ inconclusive（需要人工）

退出碼非零 = 有目標未修復，可以直接接 CI/CD 或巡檢腳本。

5.4 輪換所有密鑰（從 JWT 簽名密鑰開始

ssh root@
openssl rand -hex 32          # 生成新密鑰
# 編輯 /data/unifi-core/config/jwt.yaml → secret: 
<新密鑰>
reboot                        # 必須重啟，所有 token 消費者重載

然后再輪換：TLS 私鑰、云端 token、數據庫密碼、RADIUS / WiFi / VPN 憑據。最后強制所有用戶登出。

5.5 在邊界上檢測攻擊特征

Bishop Fox 給的規則極其干凈：

任何合法請求都不應該帶 URL 編碼的路徑穿越序列。所以你只要在 Nginx / WAF 上配規則： URI 同時包含 /api/auth/validate-sso/ 和 ..%2f / ..%2e / %2e%2e 等 → 告警 package-update 路由（ /.../ucs/update/latest_package ）參數含 shell 元字符 → 告警主機上出現異常子進程 → 告警

?? 重要：必須在邊界日志或SIEM上做這件事，不能依賴目標主機的本地日志 —— 攻擊者拿到 root 后能清日志，而且 ucs-update 這個賬號的 sudo 操作默認就不寫日志。

六、CVE 一覽表

CVE

描述

觸發條件

CVSS

致謝

CVE-2026-34908

認證網關訪問控制缺陷

未認證10.0

Duc Anh Nguyen (@heckintosh_)

CVE-2026-34909

認證網關路徑穿越

未認證10.0

Abdulaziz Almadhi（Catchify Security）

CVE-2026-34910

包更新后端命令注入

未認證

（走網關繞過）

10.0

John Carroll

CVE-2026-33000

同上命令注入 sink

帶有效 view:identity:update token

9.1

V3rlust

CVE-2026-34911

低權文件讀路徑穿越

部分認證

7.7

Hakai Security

三個 10.0 串成鏈，而且致謝來自三個不同的安全研究者 —— 這條攻擊鏈不是單點發現，是社區協作拼出來的。

七、幾個值得追問的反思

7.1 "一行 if 缺失"的故事再次上演

還記得 Meta Instagram 那個"密碼重置不驗證郵箱"的洞嗎？

這次的 UniFi OS 漏洞是同一個劇本：

"本來該寫但沒寫的一行代碼" if (uri_normalized !== uri_raw) return reject; // 沒人寫這行

安全行業有個說法：最貴的不是 0day，是"一行沒寫過的 if"。

7.2 服務賬號為什么有 NOPASSWD sudo dpkg？

ucs-update這個賬號的業務是"包更新"。給它dpkg權限聽起來"合理" —— 但任何能在 root 上下文跑 postinst 腳本的能力，就是 root 本身。

這是經典的"最小權限原則"失守案例：

業務需要dpkg?
但不一定要 NOPASSWD?
更不一定要能裝任意來源的 .deb?

正解：用 apt 的本地倉庫 + 簽名校驗，讓ucs-update只能"裝白名單里的包"，而不是"裝網上下載的任何 .deb"。

7.3 "補丁即終點"是個危險的幻覺

"我們已經打了補丁"是 90% 應急響應的句號，但這次是逗號。

JWT 簽名密鑰的"前向保密"問題，在幾乎所有 SaaS / 設備管理平臺都存在：

平臺類型

類似的"補丁救不了"風險

單點登錄（SSO）

簽名密鑰泄漏 → 攻擊者繼續偽造 SAML/JWT token

API Gateway

API 簽名密鑰泄漏 → 攻擊者繼續簽發請求

設備管理平臺

設備身份密鑰泄漏 → 攻擊者繼續冒充設備

"先補丁，再輪換，再清理" 永遠是這個順序。

7.4 這次"無危害"檢測的設計值得借鑒

Bishop Fox 的探測工具不靠 PoC 復現，靠的是目標行為差異：

漏洞版：缺參數時到達 handler 內部才報錯（HTTP 200）
修復版：在網關層就攔下來（HTTP 400）

這種"用行為差異代替真實利用"的檢測思路，值得國內安全團隊抄作業。它適用于一切你不能隨便"實際入侵"的生產環境。

八、結語

一次 HTTP 請求，2 萬美元設備交出 root。一次完整攻擊鏈，CVSS 三個 10.0。一次成功入侵，補丁都救不回來。

UniFi 是全球數百萬家庭和企業的網絡心臟。當心臟可以被一次 HTTP 請求停跳，整個生態就都暴露在刀鋒上。

漏洞從不偏心 —— 它挑沒寫那行 if 的人，挑給服務賬號豪華 sudo 的人，挑把"打補丁"當終點的人。

記住三件事：補丁是起點，不是終點 NOPASSWD sudo 是潘多拉魔盒檢測能用行為差異，就別真的去利用

行動按鈕：

立刻跑檢測：CVE-2026-34908-check [3]
補丁下載：Ubiquiti 官方 → UniFi Network → Downloads
懷疑被入侵？別只打補丁，先離線快照取證，再做密鑰輪換 + 重建評估

-2026-34908

安全圈

網羅圈內熱點專注網絡安全

實時資訊一手掌握！

好看你就分享有用就點個贊

支持「安全圈」就點個三連吧！

特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.