只是一个普普通通的特性，完全符合设计要求和标准规定。

可当这个特性与系统其他部分组合起来成为整体时，却成为了安全问题的导火索。

这种情况发生在非安全公司的产品上，比较常见且可以理解。

但是发生在网络安全公司号称可以保护安全的设备中，却很不应该。

2022 年 5 月，F5 官方发布了一条安全公告，其内部审计中发现一个 BIG-IP 设备的认证绕过漏洞，最终导致任意系统命令执行。

公告中提供了修补的方案：禁用管理口服务或者规范化“Connection”的 HTTP 字段。
这条公告马上引发了研究者广泛的讨论，这个 Connection 字段和漏洞到底是什么关系？攻击是如何实现的？

很快，有人发现在 RFC 2612 规范中的“Hop-by-hop”: 通过设置特定的“Connection”，代理服务器会将这个字段从原始数据包中删除。

根据 RFC 2616，HTTP/1.1 规范默认将以下 header 认为需要逐跳处理 (Hop-by-hop): Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization 和 Proxy-Authenticate。 
当在请求中遇到这些标头时，兼容代理应该处理或操作这些 header 指示的内容，而不是将它们转发到下一跳。
除了这些默认值之外，请求中还可以自定义一组 header，通过将它们添加到 Connection 这个特殊的 header 中，来将其视为逐跳处理。
这样代理服务器会将这些 header 从原始数据包中删除，再发往下一跳。

攻击者可以通过在请求中添加特殊的 Connection header 来让代理服务器把一些 header 删除掉，从而导致漏洞出现。

利用 Hop-by-hop 的攻击手段其实不是刚刚出现，早在 2019 年的 RITSEC CTF 比赛中就有涉及。

把 Connection header 中自定义的 Hop-by-hop header 删除，这仅是代理规范的一个普通特性，但在 F5 网络设备中，它展现出了强大的杀伤力：

前端认证与后端功能的系统框架模型看似坚不可摧，但利用 Hop-by-hop 删除前端添加的未认证标识，导致后端错误判断，整个系统的认证随即土崩瓦解。

一石激起千层浪，一时间框架漏洞成了 VPN、防火墙等网络设备的主流研究方向。

一则因为网络设备处于传统的网络边界位置，是兵之重地。

二则因为网络设备的使用，如同乐高积木一样，层级丰富而且存在大量的跨越层级的数据流转。

多层数据处理过程中，层级之间的信任关系和依赖关系复杂，出现问题的概率就更大。

2022 年 6 月，外部研究者向 Sophos 提交了一个认证绕过导致的代码执行漏洞。

其根源是利用 Java 和 Perl 层面对于 Unicode 解析的差异性，使用“\u0000”绕过了 Java 层面的白名单检查。

同样是前后端框架，Sophos 系统中的认证强依赖于前端 Java 层面，一旦 Java 层面被突破，后续的 Perl 就不堪一击。

2022 年 10 月，Horizon3 安全团队披露了知名厂商 Fortinet 的主打产品 Fortigate 的认证绕过漏洞。

其前端 Node.js 中对于 XFF 头限制不严格，导致后端代码中对于来源地址判断错误，认证系统最终形同虚设。

普通的特性与系统里其他部分组合起来导致安全问题。

这在大部分软件开发者眼里可能觉得有些意外，但在安全研究者的眼里，却是一个很普通，很自然的漏洞挖掘思路。

上文提到的VPN、防火墙、身份认证设备等都是由网络安全公司开发的守护网络安全的设备。

出现这些问题或许说明厂商并没有对自家产品做充分攻击测试的意识、意愿和能力。

参  考：

[1] https://support.f5.com/csp/article/K23605346

[2] https://ctftime.org/task/9765

[3] https://blog.viettelcybersecurity.com/cve-2022-1040-sophos-xg-firewall-authentication-bypass/

[4] https://www.horizon3.ai/fortios-fortiproxy-and-fortiswitchmanager-authentication-bypass-technical-deep-dive-cve-2022-40684/

下篇预告

请关注《深蓝洞察 | 2022 年度十大安全漏洞与利用》第九篇：

扫码进 DarkNavy 官方交流群
你的洞见  群里见