1 漏洞详情

 根据官方漏洞通报，BIG-IP iControl REST接口存在一个认证漏洞，绕过认证后可调用后端接口执行任意命令，影响版本较广，参考：

https://support.f5.com/csp/article/K23605346

 上一个漏洞CVE-2021-22986影响的接口也是 iControl REST接口，推测CVE-2022-1388是针对此漏洞修复的绕过，CVE-2021-22986的payload如下：

2 修复方案分析

  攻击poc/exp暂未公开，尝试下手分析一波，由于BIG-IP源码未公开，因此无法通过diff新旧代码定位漏洞触发点，唯一的线索只有官方给出的手动修复方案：

   修复方式里建议对配置文件进行修改，包含三个判断逻辑，即对Connection这个header头进行set设置，查一下RFC官方文档对set方法的约定：

https://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader

  根据文档，set方法的作用为，假使发现请求头里存在foo：a，则set foo b会将header值变为：foo：b，修复方案是对Connection这个头进重新赋值，到这基本可以确定漏洞绕过点就存在于Connection请求头中。

 所以问题来了，和Connection头有关的漏洞有哪些？

1) HTTP request smuggling

   HTTP请求走私漏洞，和持久化连接相关，根因为管道化连接pipeline，HTTP规范提供了两种不同的方法来指定请求的结束位置（Content-Length/Transfer-Encoding）,因此判断和此漏洞无关。

2) hop-by-hop headers abuse

  逐跳（hop-by-hop）请求头滥用是个较为生僻的漏洞，关于此漏洞可参考文章：

https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers

 按解析方式，http请求头有两种，逐跳请求头和端对端请求头，参考：

https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1

   顾名思义，逐跳的意思为，当在请求中遇到这些header头时，每一跳的代理（proxy）应该对这些header进行处理，而不将它们转发到下一跳。

 如我们的请求中带有header头：Connection: close, X-Foo, X-Bar，原始请求在转发到代理时，逐跳处理则会将X-Foo和 X-Bar从原始请求中删除。

 利用逐跳请求头的这种特性，可以实现删除任意已有header：

   原作者提出了多种利用思路，包括：删除XFF头隐藏IP、缓存中毒DoS、SSRF、绕过WAF等。

3） 历史CVE分析

 根据关键字搜了一下，hop-by-hop headers abuse在几个漏洞中有利用，比如CVE-2021-32813：

 header头被删除导致的权限提升，再看下漏洞的修复方案：

https://github.com/traefik/traefik/pull/8319/commits/cbaf86a93014a969b8accf39301932c17d0d73f9

  熟悉的Header.set操作，删除Connection头中列举的hop-by-hop头。

 又如下面的例子，将包含关键鉴权信息的header添加到Connection中以完成权限绕过：

• https://github.com/clastix/capsule-proxy/issues/188

• https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr

 到此几乎可以确定，CVE-2022-1388就是使用Connection头中包含hop-by-hop头来绕过鉴权。

 环境搭建，下载F5官网BIG-IP虚拟镜像安装：

  访问web登录页，构造payload验证上述推断：

   这里先回顾下CVE-2021-22986，思路为先通过/mgmt/shared/authn/login 接口的SSRF漏洞获取到凭证X-F5-Auth-Token头，然后访问/mgmt/tm/util/bash接口执行任意命令：

  而CVE-2022-1388的区别在于，不必获取这个X-F5-Auth-Token头，而是将Connection头设置为畸形的hop-by-hop头，即Connection: Keep-alive,X-F5-Auth-Token，BIG-IP的鉴权过程发生在frontend，在后续转发到Jetty时会将此header删除，从而绕过鉴权：

  至于BIG-IP后端具体的处理逻辑，还需要深入代码层分析，这里留个坑。本文也主要是提供一个从修复方案到复现oday/1day漏洞的推断和分析思路。