F5 BIG-IP 的信任 iControl REST 接口在特定版本中存在一个认证绕过漏洞,攻击者无需有效凭据就能以高权限执行命令。管理这不是问题理论推演,2022年CVE-2022-1388被公开时,漏洞大量未及时修补的信任BIG-IP设备直接暴露在公网上,扫描器几小时内就开始批量抓取。管理
漏洞的问题核心出在 /mgmt/shared/authn/login 这个端点。正常情况下,漏洞请求需要携带合法的信任 X-F5-Auth-Token。但攻击者可以构造一个带有 Connection: X-F5-Auth-Token 和 X-F5-Auth-Token: anything 的管理请求,让后端在处理转发时跳过认证校验。问题说白了,漏洞就是信任利用 HTTP 头部的解析差异,骗过 iControl REST 的管理鉴权逻辑。
这个问题的问题根子不在 nginx 本身,但 nginx 作为 BIG-IP 前端反向代理,扮演了关键角色。iControl REST 的后端服务跑在 localhost 上,nginx 负责把外部请求转发过去。当请求头里同时出现 Connection 和 X-F5-Auth-Token 时,nginx 的某些版本会按照 hop-by-hop 头部规则处理,把 X-F5-Auth-Token 从转发请求中剥离或改写。后端一看没有 token,按理该拒绝——但它没有。后端信任了来自 nginx 的请求,认为既然请求到了这一层,认证已经通过了。
这是典型的“边界信任”模型崩塌。nginx 认为后端会自己做认证,后端认为 nginx 已经做好了认证。两边都把安全责任推给对方,结果谁都没做。攻击者只需要找到一个能让 nginx 转发请求、但又不触发后端认证检查的路径组合,就能长驱直入。
更麻烦的是,这种漏洞的利用门槛极低。一个 curl 命令就能验证:
curl -su admin: -H "Content-Type: application/json" \ -H "X-F5-Auth-Token: anything" \ -H "Connection: X-F5-Auth-Token" \ -X POST https://target/mgmt/shared/authn/login \ -d '{ "username":"admin","password":"anything"}' 如果返回了 token,说明设备已经沦陷。攻击者拿到 token 后可以创建新用户、修改配置、执行任意 tmsh 命令。整个过程不需要知道任何真实密码。
F5 在 BIG-IP 的 nginx 配置中使用了 proxy_pass 转发到 http://localhost:8100。问题出在对 Connection 头部的处理上。HTTP/1.1 规范允许 Connection 头指定 hop-by-hop 头部列表,nginx 默认会移除这些头部再转发。但 F5 的配置里没有显式禁止客户端传入 X-F5-Auth-Token 作为 hop-by-hop 值。攻击者正是利用这一点,让 nginx 把本应保留的认证 token 当作 hop-by-hop 头部处理掉。
后端 iControl REST 的 Java 服务在收到没有 token 的请求时,没有返回 401,而是继续处理。这个逻辑缺陷和 nginx 的转发行为叠加,构成了完整的攻击链。
F5 发布的修复版本修改了 nginx 配置,显式拒绝包含 Connection: X-F5-Auth-Token 的请求。同时后端也增加了对缺失 token 的强制校验。但真正的教训在于:任何依赖反向代理做认证、后端盲目信任代理的场景,都存在同类风险。
我见过一些企业把 BIG-IP 管理接口放在内网,以为就安全了。但横向移动攻击中,内网设备的管理接口往往是跳板首选。这个漏洞不需要用户交互,不需要钓鱼,一个 HTTP 请求就能拿到最高权限。
检查设备是否受影响,除了看版本号,还可以查日志里有没有异常的 /mgmt/shared/authn/login 请求,特别是那些返回 200 但请求头里带 Connection: X-F5-Auth-Token 的记录。有的话,设备大概率已经被扫过了。
安全设备自身的安全,往往比它保护的业务系统更脆弱。F5 这个漏洞不是孤例,Citrix、Fortinet 都出过类似问题。反向代理和认证服务之间的信任边界,需要显式定义和验证,不能靠默认行为。