F5 BIG-IP is a series of application delivery platforms with multiple functions such as load balancing, traffic management, and application management. There is a remote code execution vulnerability in F5 BIG-IP's TMUI (Traffic Management User Interface). This vulnerability allows unauthenticated attackers to access TMUI through the BIG-IP management port and execute arbitrary system commands.
The vulnerability information was published by F5 on July 1, 2020.
As of July 8, 2020, the official has released security updates for all versions.
On July 5, 2020, PoC of exploiting this vulnerability appeared on the Internet.
On July 7, 2020, bypassing protection rules against this vulnerability appeared on the Internet.
Sangfor security team verified the PoC and bypassing at the first time and offered a solution.
Introduction to Related Components
F5 BIG-IP is a series of application delivery platforms issued by F5 Networks in the United States. It has multiple functions such as load balancing, traffic management, and application management. It can provide the basic components required to build a flexible application delivery network architecture, and at the same time promote the implementation of enterprise cloud architecture. Users can fully monitor their own application delivery environment.
There is a remote code execution vulnerability in Traffic Management User Interface (TMUI). The vulnerability allows unauthorized attackers or authorized users to execute arbitrary system commands, add or delete files, stop services, or execute arbitrary Java code through the BIG-IP management port and/or their own IP. The vulnerability will cause complete system damage, and it also exists in BIG-IP devices.
The BIG-IP server uses the Servlet interface in Java to complete the interaction between middleware and business logic. The function request.getPathInfo() used by Tomcat to parse URL obtains the attribute value of the pathInfo according to the analysis of the middleware and returns this URL directly. The URL path is passed to Servlet, which is the entire content in last "/" before the truncation symbol, that is, regardless of all the higher-level directories, only focuses on the directly accessed files, and can be truncated by semicolons.
This path is instantiated as a URLMappings handle by the function Mappings.getRequestByURL().
The function User.haveAccessToAtLeastOneTargetLevel() determines whether a path has the access rights of the current user. Detailed implementation method is:
1. Initializing based on xml file
com.f5.controller.ControlServlet.class is the used servlet class which rewrites a series of functions such as init, doGet, fail, doPost. Line 104 in the init method calls F5WebController.initMappings(this.getServletConfig()). This function is located in line 51 and calls the initMappings method in F5WebController.class.
Part of key code in ControlServlet.class is shown in the above figure.
Part of key code in F5WebController.class is shown in the above figure.
The initMappings function initializes a Mappings object, and it can be analyzed from the constructor of Mappings.class that it has accessed two xml files used for initialization: requestmappings.xml and responseemappings.xml.
The two xml files used for initialization are located in /WEB-INF/xml/, and these xml files link functions that process requests and responses.
These files can be used to locate functions that handle business logic, including functions for permission control.
2. Receiving passed in URL and instantiate it
We continue to analyze F5WebController.class, where the processWebRequest function (line 60) receives and processes the URL.
This function obtains the path passed by the tomcat's API getPathInfo function, and then instantiates this path as a handler. This path is the content of the pathInfo attribute value.
3. Obtaining the identity of current user
User.getUser located at line 103 under F5WebController.class obtains the identity of current user. This function is based on the processing of the login code of Role.class to divide the user into multiple roles, each of which has different permission levels.
4. Comparing whether the current user has permission to access the URL
System determines the permission by the returned valued of function requestHandler.getAllowedLevels(). The URL used for determining is the one obtained by parsing in the second stage, and the function returns the range of user roles allowed by the current path. Then we call the User.haveAccessToAtLeastOneTargetLevel method to determine whether the current role permission ID is within the allowed role range.
If yes, the user is granted access permission, and the HTTP request will not be intercepted.
Suppose attack URL is as follows:
During URL parsing, the first parsing will focus from the first half to login.jsp which is legitimate. The system pass request.getPathInfo() to determine whether the current user has permission to access the URL. Next, Tomcat performs the second parsing. At this time, Tomcat will parse "..." As the upward traceback path, and the semicolon will be ignored, so that login.jsp and .. are canceled out, and a URL with path traversal can be constructed. In request.getPathInfo() code which is permission-controlled, the semicolon will be regarded as truncated, that is, only the path of the previous jsp is considered, and this part of the path is used to return the corresponding permission, and login.jsp, welcome.jsp, Files such as index.jsp can be accessed without authorization, so writing it into a URL can bypass permission detection and gain unauthorized access. But during execution, it will be based on the following fileRead.jsp, which reads unauthorized files, and other attacks are also based on this principle.
July 1, 2020 F5 released security updates.
July 3, 2020 Sangfor FarSight Labs released security alerts.
July 5, 2020 PoC of this vulnerability was disclosed.
July 6, 2020 Sangfor FarSight Labs released updates of security alerts and Sangfor solutions.
July 8, 2020 Sangfor FarSight Labs released updates of security alerts, technical details, and bypass of this vulnerability, as well as solutions update.
This bug can be fixed by upgrading BIG-IP to the latest version. The corresponding fixed versions are as follows:
For 15.1.0 & 15.0.0, upgrade to 188.8.131.52
For 14.1.0-14.1.2, upgrade to 184.108.40.206
For 13.1.0-13.1.3, upgrade to 220.127.116.11
For 12.1.0-12.1.5, upgrade to 18.104.22.168
For 11.6.1-11.6.5, upgrade to 22.214.171.124
For Sangfor NGAF customers, simply turn on the corresponding security protection feature.
Sangfor Cloud WAF has automatically updated its database in the cloud. Those users are already protected from this vulnerability without needing to perform any additional operations.
Sangfor Cyber Command is capable of detecting attacks which exploit this vulnerability and can alert users in real time. Users can correlate Cyber Command to Sangfor NGAF to block an attacker's IP address.
The official provides the following methods to avoid attacks without affecting the system:
3.2 Self IP
Disabling self-IP prevents BIG-IP systems from accessing TMUI. For each self-IP, the Port Lockdown in the system can be set to Allow None. If you must open some ports, you should use Allow Custom. Note that access to TMUI is not allowed. By default, TMUI listens on port 443, but from BIG-IP version 13.0.0, the components of Single-NIC BIG-IP VE use TCP port 8443, In addition, you can also set the custom port.
3.3 Management interface
To mitigate vulnerabilities in affected F5 products, only managers should be allowed to access F5 products through a secure network.
3.4 Signs of being attacked
The following methods can be used to check whether the host has been attacked:
For version earlier than 14.1.0:
You can use the default configuration, and the /var/log/audit and /var/log/ltm directories can be checked as follows:
A log similar to the following is a sign that the device is under attack.
For version older than 14.1.0:
You can check the output of journalctl by entering the following command in the terminal (bash) to prove that the vulnerability has been exploited:
On attacked devices, the command output may be similar to the following example (this example deletes some elements, the complete URL and the IP address that sent the request will usually be visible):
These logs are created only by unauthenticated attacks, and authenticated access does not leave this record.
Other damages to the device include modification of files, configurations, and processes.