自己的blog,第一次搭,不好意思
https://blog.di0.uk
魔方雲 KVM 管理鏈漏洞報告
1. 漏洞概述
在魔方雲 KVM 節點部署與管理過程中,確認存在多項高風險安全問題,主要涉及:
- libvirt 遠端管理接口未啟用身份驗證;
- libvirt 管理端口直接監聽公網地址;
- KVM VNC 控制台直接監聽公網且未設置密碼;
- 面板將 libvirt 控制地址與 NAT 公網 IP 混用;
- 管理平面與業務網絡缺乏有效隔離。
上述問題會使原本僅應供宿主機或管理後端使用的虛擬化控制平面直接暴露給外部網絡。
漏洞已確認成立。
2. 漏洞一:libvirt 遠端管理接口未認證
漏洞等級
嚴重 / Critical
問題配置
節點曾存在以下配置:
listen_tcp = 1
auth_tcp = "none"
同時 libvirt TCP 服務監聽:
0.0.0.0:16509
其中:
listen_tcp = 1
代表啟用 libvirt TCP 遠端管理能力。
而:
auth_tcp = "none"
代表 TCP 連線不需要經過 libvirt 身份驗證。
當服務同時綁定:
0.0.0.0
時,所有可以訪問該端口的網絡來源均能直接接觸 libvirt 管理接口。
安全影響
libvirt 並不是普通的狀態查詢服務,而是 KVM/QEMU 的核心管理接口。
未授權訪問可能涉及:
- 查看宿主機上的虛擬機列表;
- 查看虛擬機 UUID、狀態及配置;
- 讀取虛擬機 XML;
- 啟動虛擬機;
- 關閉虛擬機;
- 重啟虛擬機;
- 修改虛擬機配置;
- 修改虛擬磁碟配置;
- 修改虛擬網卡配置;
- 修改 VNC/SPICE 配置;
- 修改啟動設備及啟動順序;
- 掛載或替換虛擬媒體;
- 接觸 Guest Agent 等管理功能。
因此,暴露的未認證 libvirt 接口等同於將虛擬機核心管理平面暴露給未授權用戶。
漏洞本質
問題不是「16509 端口被開放」本身。
真正的漏洞組合為:
遠程 libvirt TCP
+
監聽公網
+
無身份驗證
其中:
auth_tcp = "none"
是最關鍵的安全問題之一。
3. 漏洞二:KVM VNC 控制台無認證公開暴露
漏洞等級
嚴重 / Critical
問題配置
KVM001 曾存在:
VNC:0.0.0.0:10000
Password:未設定
也就是:
監聽全部地址
+
無 VNC 密碼
安全影響
VNC 屬於虛擬機控制台,而不是普通的應用服務。
未授權人員取得 VNC 控制台後,可以直接操作虛擬機的:
- 鍵盤;
- 顯示器;
- 登入界面;
- 開機流程;
- GRUB;
- Recovery/Rescue 環境;
- 系統 Console。
這意味著攻擊者不一定需要:
SSH 帳號
SSH 密碼
Guest 對外開放 SSH
即可直接操作虛擬機。
因此 Guest 內部 SSH 防火牆不能作為 VNC 暴露情況下的有效安全邊界。
漏洞本質
以下配置不得同時存在:
VNC Listen:0.0.0.0
VNC Password:None
虛擬機控制台應始終位於受保護的管理網絡內。
4. 漏洞三:libvirt 控制地址與 NAT 公網 IP 混用
漏洞等級
高危 / High
問題描述
魔方雲目前的節點配置邏輯存在設計問題:
libvirt 連接地址
與:
NAT 對外公網 IP
沒有被完全拆分。
例如,當 libvirt 地址配置:
127.0.0.1
時,面板相關 NAT 地址也可能錯誤顯示:
127.0.0.1
這會迫使管理員為了讓 NAT 功能正常顯示或生成規則,而將 libvirt Host 修改為:
宿主機公網 IP
最終容易形成:
魔方雲需要 NAT 公網 IP
↓
管理員填寫宿主機公網 IP
↓
libvirt 同時使用該地址
↓
管理接口暴露至公網
正確設計
兩者應完全獨立:
Libvirt URI
↓
qemu:///system
或
專用管理網地址
NAT Public IP
↓
宿主機實際公網 IP
例如:
Libvirt URI:qemu:///system
NAT Public IP:211.x.x.x
NAT 規則只能讀取:
NAT Public IP
而不能從:
libvirt host
生成。
安全影響
目前的設計容易誘導管理員將原本僅供內部使用的 libvirt 管理接口暴露到互聯網。
因此這不僅屬於錯誤配置問題,同時也是面板節點設計上的安全缺陷。
5. 漏洞四:虛擬化管理平面與公網缺乏隔離
漏洞等級
高危 / High
問題描述
虛擬化宿主機存在多類不同安全級別的服務:
業務服務
NAT
SSH
VNC
libvirt
Guest Agent
面板 API
其中 libvirt、VNC、Guest Agent 等均屬於:
管理平面
不應與普通業務端口使用相同的公網暴露方式。
安全風險
一旦管理接口直接公開:
Internet
↓
宿主機管理端口
↓
libvirt / VNC
↓
VM
Guest 自身的部分安全措施將失去意義。
典型情況包括:
SSH 沒有公開
但:
VNC 公開
仍然可以接觸 Guest Console。
或者:
Guest 防火牆完善
但:
libvirt 管理接口公開
仍然可以直接從虛擬化層控制 VM。
因此虛擬化管理平面必須與業務網絡隔離。
6. 已確認安全影響
事發 KVM001 已確認出現 root 級別入侵及持久化。
系統中確認存在:
/etc/systemd/system/ustar.service
/.ustarp
/.ustar5
/.ustar6
/etc/ld.so.preload
惡意服務使用:
User=root
Group=root
Restart=always
RestartSec=5
並通過:
/etc/ld.so.preload
載入惡意共享物件。
同時存在 RandomX 挖礦程序。
這說明暴露管理鏈所保護的 VM 一旦失陷,攻擊者可以取得足以完成:
root 控制
→
持久化
→
惡意程序植入
→
系統級注入
→
長時間運行惡意負載
的權限。
7. 正常安全架構
單機部署時推薦:
魔方雲面板
↓
本機
↓
qemu:///system
↓
libvirt
↓
QEMU/KVM
不需要:
Internet
↓
16509
↓
libvirt
面板與計算節點分離時
推薦:
控制端
↓
VPN / WireGuard / 專用管理網
↓
計算節點
↓
libvirt
或者:
SSH Tunnel
以及:
TLS + 身份驗證
禁止使用:
公網 TCP + auth_tcp=none
8. 修復要求
8.1 關閉 libvirt 公網 TCP
單機環境優先使用:
qemu:///system
停止使用:
tcp://公網IP:16509
並關閉不需要的 libvirt TCP socket。
防火牆應持續阻止來自公網的:
16509/tcp
8.2 禁止 auth_tcp=none
不得使用:
auth_tcp = "none"
如果確實需要遠端 libvirt,至少應配置:
TLS
+
身份驗證
+
來源 IP 限制
更加推薦直接使用:
VPN
建立獨立管理網。
8.3 修復 VNC
禁止:
0.0.0.0 + 無密碼
推薦:
127.0.0.1
或:
管理網 IP
作為 VNC Listen 地址。
控制台訪問通過面板提供:
瀏覽器
↓
一次性/短時 Token
↓
WebSocket Proxy
↓
localhost VNC
而不是將 QEMU VNC 端口直接暴露至公網。
8.4 拆分面板配置
魔方雲應至少提供兩個獨立字段:
Libvirt Connection / URI
NAT Public IP
其中:
Libvirt URI
只負責連接虛擬化管理服務。
而:
NAT Public IP
只負責生成:
DNAT
SNAT
Port Forward
相關規則。
兩個字段不得互相引用。
9. 建議增加的安全措施
宿主機:
16509:禁止公網訪問
VNC:禁止公網直接訪問
管理 API:限制來源
SSH:僅管理地址訪問
Guest:
禁止 root 密碼 SSH 登入
使用 SSH Key
不同 VM 使用不同憑證
監控:
/etc/ld.so.preload
/etc/systemd/system/
/usr/lib/systemd/system/
根目錄隱藏 ELF
異常高 CPU 使用率
異常 systemd service
日誌:
面板操作日誌
libvirt API 日誌
VNC 訪問日誌
NAT 配置變更
Guest Agent 操作
宿主機防火牆日誌
建議集中保存至少:
30~90 天
10. 漏洞總結
本次確認的核心問題可以歸納為:
① libvirt 未認證遠程管理
② libvirt 管理接口公網暴露
③ VNC 公網暴露且無密碼
④ libvirt 地址與 NAT 公網 IP 設計耦合
⑤ 虛擬化管理平面缺乏網絡隔離
其中最嚴重的兩項為:
0.0.0.0:16509
+
auth_tcp = none
以及:
VNC 0.0.0.0
+
無 Password
兩者均屬於不應出現在公網環境中的高危配置。
最終修復原則
管理面與業務面分離
↓
libvirt 不直接暴露 Internet
↓
VNC 不直接暴露 Internet
↓
NAT IP 與 libvirt 地址完全解耦
↓
所有遠程管理均需要認證及網絡隔離