一条日志,打成vCenterroot

admin 2026-09-29 05:27:30 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文分析vCenter两个未认证高危漏洞:CVE-2026-59310通过Syslog日志路径遍历实现root代码执行,CVE-2026-59309利用SRP认证缺陷绕过登录。文章详述利用链、证据分级排查方法及修复版本建议,强调内网可达不等于安全,建议优先升级认证漏洞并核查日志异常。 综合评分: 85 文章分类: 漏洞分析,应急响应,安全运营


一条日志,打成 vCenter root

原创

messfree messfree

MessFreeSecurity

2026年9月26日 22:38 河北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一条 Syslog 日志,能把 vCenter 的 root 拿下来。

不用账号,不用密码。两个 CVE,都是 9.8 分,都能未认证直接打。

这不是危言耸听。安全公司 Atredis 公开了完整技术细节,博通同步发了修复公告。而据公开统计,超过 60% 的大型企业把核心业务跑在 vSphere 上,vSphere 占全球服务器虚拟化市场约 32.1%。

这玩意儿就在你家机房里跑着。

两个洞分别是 CVE-2026-59310 和 CVE-2026-59309,互相独立,不用先打穿一个再打另一个。先看总账:

| 漏洞 | 打哪里 | 先拿到什么 | 后果 | | — | — | — | — | | CVE-2026-59310 | Syslog 日志服务 | 越界写文件 | 条件满足时以 root 执行代码 | | CVE-2026-59309 | 目录服务的 SRP 认证 | 冒用有效账号登录 | 取决于被冒用账号的权限 |

先划一条线:root 和 vCenter 管理员,是一回事吗?

不是。第一个洞拿操作系统 root,第二个洞拿目录管理员。能拿多少,看被冒用的是谁。

一条日志怎么变成 root 后门 🧩

vCenter 里的 rsyslog 有这么一行配置:

$template esxLoc,"/var/log/vmware/esx/%hostname%/%hostname%-syslog.log"

设计想法很朴素:日志按主机名分文件夹,%hostname% 是个普通名字。

要看懂问题出在哪,得先知道一条 Syslog 消息里有什么:

| 字段 | 正常用途 | 该怎么理解 | | — | — | — | | HOSTNAME | 声明消息来自哪台主机 | 发送者随口报的 | | APP-NAME | 声明哪个应用产生 | 过滤用的字符串 | | MSG | 日志正文 | 发送者给什么是什么 |

rsyslog 的动态文件模板,本来是为”按字段分组存日志”设计的。这个功能隐含了一个假设:字段是个名字。这个假设在内网里跑了几十年没出事,慢慢就被当成了信任边界。

可协议里从没写”名字要验证”。报文里填的主机名,不等于接收端认证过这台主机;字段能被解析,也不代表它适合当文件名。Syslog 的格式规则和文件系统的安全规则,是两套东西。

发日志的人说自己是 esxi01,系统就信了。可要是对方填一串 ../../ 呢?路径前缀写着 /var/log/vmware/esx/,文件就真的还在这个目录里吗?

不一定。.. 会按”父目录”解释,文件系统逐个组件解析路径,最后落到哪,前缀说了不算。

一句话:数据进了路径,路径就进了权限。

写进去的也不全是”任意”。这五个约束先摆清楚:

| 约束 | 影响 | | — | — | | 固定后缀 | 文件名多半还带着 -syslog.log | | 同一字段出现多次 | 得按完整展开后的路径算 | | 输出模板 | 内容可能带时间戳等元数据 | | 追加写 | 是追加,不是覆盖 | | 挂载与权限 | 只读挂载、路径不存在都可能失败 |

所以”任意文件写”要打折听。想原样覆盖 /etc/passwd 的,想多了。

写进去只是第一步。落点选在 /etc/bash_completion.d/,这个目录的文件会随 /etc/profile 被 shell 加载。而 vmware-pod 认证时会通过 sudo 启动 root 包装脚本,脚本先加载 profile,再进密码验证。

这里有个反直觉的点:source 是把文件当命令解释的。没有可执行位?照样执行。扩展名是 .log?无所谓。加载它的是 root shell,里面的命令就在 root 上下文里跑。

顺带把几个容易误读的细节说清。

免密 sudo 规则只授权服务账户执行那个认证辅助命令,NOPASSWD 不等于允许 root 执行任意命令。危险出在这个授权程序又加载了外部数据能影响的内容。

包装脚本启动 Python 时带了 -E,忽略 PYTHON* 环境变量。这个防护是给 Python 的,管不了之前已经发生的 shell 加载。

日志开头的时间戳会让 Bash 报错(退出状态 127),但报错不等于终止脚本。是否继续,取决于 errexit 这类选项和执行上下文。

再看触发顺序,这是全文最要命的一张图:

收到认证请求     ↓ sudo 启动 root 包装脚本     ↓ 加载 /etc/profile(日志在这里被执行)     ↓ 进入密码验证

看明白了吗?密码验证失败,也撤不回验证之前已经执行的脚本。

做认证代码审计的都该记住这条:别只看最后返回”成功”还是”失败”,要看验证之前都干了什么。

一串数字,废掉整套密码认证 🔐

第二个洞在 VMware Directory Service 的 SRP 认证里。

SRP 是套数学协议:客户端不发密码,靠计算证明”我知道密码”。这套机制的根,是一个叫 A 的客户端公开值。协议规范白纸黑字写着:A mod N = 0 时,服务端必须拒绝。

为什么要查这个?攻击者可以发 A = N。N 是正整数没错,可 N mod N 等于 0。只检查 A > 0 的实现,就这么漏过去了。

代入服务端公式一算,共享秘密直接等于 0。

本该由密码和随机数共同决定的秘密,变成了所有人都知道的常量。

还有个更细的坑:实现里这个 0 不是字符串 "0"(那是一个字节 0x30),核对的源码里它连一个 0x00 字节都不是,而是空字节序列。认证安不安全,公式对只是一半,编码错一处,结果就不一样。

共享秘密已知,后面的认证证明自然全对得上。但证明对得上,不代表密码真的对。

给内行补一句:公告引用的公式和 RFC 2945 并不一致,它是 Cyrus SASL 用的变体,对照时别拿错版本:

| 对照项 | RFC 2945 | 实际用的 SASL 变体 | | | | — | — | — | — | — | | 服务端公开值系数 | v | 3v | | | | 混合参数 | H(B) | H(A | | B) | | 会话密钥 | SHA_Interleave(S) | H(S) | | |

这两条路,凑齐条件有多难

评估漏洞不能光看分,得看前置条件在真实环境里凑齐的难度。

Syslog 这条要过三关:消息能到 514 或 1514 端口,目标跑着未修复的路径模板,写入位置在加载链上。第一关最难,绝大多数企业的 syslog 端口只对内网设备开。

可正因为这样,一台配置错误的交换机、一台被控的堡垒机,就能把包发进来。内网可达从来不等于安全。

SRP 这条更”日常”:能访问 vCenter 的登录口就行,连有效账号都不用有。这也是我判断它更值得优先关注的原因:它不需要任何内网立足点。

防守侧该看什么

“有没有被打”不能靠感觉。说几个具体的证据位置。

Syslog 侧三处:日志原文里出现 ../ 或异常长的 hostname 字段;预定日志目录之外冒出 *-syslog.log 文件;用一个假主机名主动发条测试日志,看它落在哪,落点越界就是配置没修。

认证侧两处:目录服务日志里出现 A mod N 为零的 SRP 请求;同一源地址高频建立又立即断开的 SRP 会话。

说实话,多数环境里这条判定链是断的:rsyslog 收到的日志直接落盘,没人检查字段内容;514 端口没有任何来源认证;SIEM 收的是日志,不是针对这类字段的告警。断在哪一节,补哪一节。

排查的时候,证据要分级。这张表是全文最值钱的:📊

| 观察到的证据 | 能下的结论 | 还证明不了 | | — | — | — | | 配置未净化、服务可达 | 有利用条件 | 没人打过 | | 日志出现路径遍历内容 | 有利用尝试 | 文件没写进去 | | 越界位置出现带标记文件 | 写入成功 | 内容未必执行 | | 加载链执行了受控内容 | 代码执行成功 | 权限未必是 root | | 执行进程确认为 root | root 坐实 | 环境未必全丢 | | 非法 SRP 参数被接受 | 认证绕过可验证 | 后续操作未必发生 |

每一层证据,只支持对应层级的结论。跳跃定级,报告就废了。

修复版本,对号入座 ⚙️

博通矩阵给出的修复版本:

| 分支 | 修复版本 | | — | — | | 9.1 | 9.1.0.0300 | | 9.0 | 9.0.2.0100 | | 8.0 | U3k / U2f | | 7.0 | 扩展支持,联系厂商 |

注意一个坑:9.1.0.0200 只先修了认证绕过,要同时盖住两个 CVE,得按当前矩阵核对。

我的升级优先级建议:登录口对 VPN 或办公网开放的,本周期内升完;syslog 端口暴露给不可信网络的,当天就处理;收在内网管理段且补丁到位的,照常走维护窗口。

最后说两句

这两个洞,本质各一句话。

Syslog 那个:消息字段没净化就进了文件路径,叠加 root 进程加载该文件,网络数据一路走到代码执行,而执行发生在密码验证之前。

SRP 那个:一个 A mod N = 0 的退化输入,把共享秘密固定成已知常量,整套证明当场失效。


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。

本文转载自:MessFreeSecurity messfree messfree《一条日志,打成 vCenter root》

    评论:0   参与:  0