Traffic Management User Interface Vulnerability: The Fix and Temporary Mitigation Options

*** Updated July 8, 2020 ***


A new Remote Code Execution vulnerability announcement that affects several versions of BIG-IP was just released on June 30, 2020. Remote Code Execution (RCE) vulnerabilities are arguably the most severe vulnerabilities that exist...because an attacker can take over your system and start running commands (modifying files, disabling services, executing code, etc). This specific RCE allows unauthenticated attackers, or authenticated users, with network access to the Traffic Management User Interface (TMUI), through the BIG-IP management port and/or Self IPs, to remotely execute system commands. This vulnerability does not affect the data plane, but the control plane is affected and could lead to complete system compromise.


The Fix

Because of the severity of this vulnerability, we recommend immediately installing the latest patched version in order to protect your BIG-IP system from compromise.


The following is a table of known vulnerable BIG-IP versions and the associated fixed versions:



Temporary Mitigation Options

One of the primary reasons this vulnerability is exploitable is that admins open the management port of their BIG-IP to the Internet. This is not a good idea...you should never expose your management port (TMUI) to the open Internet. If you do, you are allowing attackers an open invitation to do all kinds of bad things to your BIG-IP system. Certainly, your BIG-IP system will process traffic from the open Internet via Virtual Servers, etc configured on your BIG-IP system, but the administrative control of your system (TMUI) should be locked down to secure, internal access only.


The other reason this vulnerability is exploitable is that Self-IPs are not locked down properly on BIG-IP systems. By default, Self-IPs are locked down (Port Lockdown set to "Allow None") but some admins change this setting to open certain ports for some Self-IPs. If a Self-IP port is open to the default TMUI port of 443 (or, in some cases, 8443), then that Self-IP will have access to the TMUI and an attacker could gain access to your system via a compromised Self-IP that is then allowed to access the TMUI.


The good news is that all of this is configurable to lock it down properly. First, as I said before, never expose your management port (TMUI) to the open Internet. Next, lock down your Self-IP ports to "Allow None"...or, if you really must open ports for your Self-IP then be sure to not open the port for your TMUI. Also, you can configure which port the TMUI listens on. So, there are a multitude of options for you to configure your BIG-IP system properly in order to avoid exploitation of a significant vulnerability like this.


Other Important Things to Consider

I would recommend using the F5 iHealth service to diagnose vulnerabilities on your BIG-IP system. iHealth is awesome...you simply upload a QKView file from your BIG-IP and then iHealth runs that file against a multitude of configuration recommendations, security checks, etc and then it gives you a list of recommendations of what to change on your BIG-IP system and how to change it all. You can't go wrong!


The Internet is a complex place, and we all want to help each other thrive as we navigate these inevitable hurdles of security issues. Use the comment section below to ask any questions or provide feedback for others who might be looking for great advice from this amazing community. We are all in this together...thanks for being the best community in the world!


For more information, check out the video below where I discuss more about this vulnerability and how to mitigate it.



Published Jul 06, 2020
Version 1.0
BIG-IP
CVE-2020-5902
security

Was this article helpful?

8 Comments

Sort By
  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Jul 06, 2020

    If you want to use the Rest API to apply the specific mitigations from the article without using tmsh edit:

    # curl -sk -u admin:password https://localhost/mgmt/tm/sys/httpd/ -X PATCH -H "Content-Type: application/json" -d '{"include": "<LocationMatch \\\".*\\\\.\\\\.;.*\\\">\nRedirect 404 /\n</LocationMatch>\n"}'

    The following one-line bash script checks to see if the include already has the LocationMatch, preserves any existing include setting, and adds the K52145254 LocationMatch stanza.

    if [ $(curl -sk -u admin:password https://localhost/mgmt/tm/sys/httpd/ | jq . -M | grep -c LocationMatch) -eq 0 ]; then new_include=$(echo '{"include":"'$(curl -sk -u admin:password https://localhost/mgmt/tm/sys/httpd/ | jq . -M | grep include | awk -F'^"|":|:"| "|",' '{print $4}')'\n<LocationMatch \\\".*\\\\.\\\\.;.*\\\">\nRedirect 404 /\n</LocationMatch>\n')'"}'; curl -sk -u admin:password https://localhost/mgmt/tm/sys/httpd/ -X PATCH -H "Content-Type: application/json" -d "$new_include"; fi

    I'm sure someone will write this more elegantly in Python or somesuch, but it's a start.

  • Subrun's avatar
    Subrun
    Icon for Cirrostratus rankCirrostratus
    Jul 06, 2020

    John, How Can I validate that Temporary Mitigation steps mentioned in this DOC K52145254 for "All Network Interfaces" would not impact F5 Services hosted/ configured with VIP's configured at F5 ?

     

    And How do I validate that all my All network interfaces are vulnerable according to this KB ? Other than it matches the Vulnerable Code Version ?

     

     

  • ltwagnon's avatar
    ltwagnon
    Ret. Employee
    Jul 09, 2020

    : 15.1.0.4 for Azure is being worked aggressively, but we don't have a definite timeline right now. 

  • ltwagnon's avatar
    ltwagnon
    Ret. Employee
    Jul 09, 2020

     : the "All Network Interfaces" portion of the recommended mitigation steps was recently removed. So, the primary recommendation is still to upgrade, but short of that, the recommendation is don't expose Management Interface to the Internet and lock down ports on Self IPs.