F5 released a patch on 30 June 2020 tied to a doozy of a vulnerability discovered by Positive Technologies. The vulnerability didn’t get much attention until Positive Technology’s blog on the matter was released on 02 July 2020, right before a holiday weekend in the United States. The criticality of the remote code execution (RCE) combined with the significance of the F5 BIG-IP product in many major networks set off a race for an exploit. Presumably, Positive Technologies as the discoverer already possessed such a working exploit, but public proof of concepts (POCs) took a few days to emerge via various Twitter posts, followed by a Metasploit module on 05 July 2020.
The vulnerability – and subsequent release of public exploits – led to no shortage of alarmist statements and coverage. While I’d normally pounce on such things as unhelpfully overhyping matters, in this case such reaction is quite appropriate. This vulnerability is very serious, and its exploitation by actors that know what they’re doing is deeply concerning – yet not likely for the reasons many think.
The typical thought on a RCE on external-facing infrastructure is the ability to breach networks for initial access. While this is a definite concern for the F5 item, and will likely represent the primary goal of many now deploying one of various POCs, this is honestly one of my least concerns with the weaponization of this vulnerability.
Before moving further, we first need to understand just what an F5 BIG-IP does. As described by F5, the BIG-IP started life as an application delivery controller (ADC) primarily used for load balancing – but to both enable this and add additional features, the product is now so much more. BIG-IP combines DNS functionality for controlled traffic as well as extensive traffic inspection, shaping, and potential modification capabilities as a traffic manager. To enable all of these powerful features, as well as other items such as web application firewall and related security items, the BIG-IP has extensive access to traffic flowing through it.
Given the above, unfettered, root-level access to an F5 BIG-IP is a powerful place for an attacker to be – and not necessarily aimed at the organization managing the compromised device. Instead, a compromised BIG-IP enables very powerful possibilities for Man-in-the-Middle traffic capture, traffic redirection or shaping, and even potentially injecting payloads into monitored traffic. Even if the data in question is not directly accessible, management level access can enable an actor to apply configuration changes to shape or direct traffic in such a way as to enable a number of these possibilities indirectly. While not easy to deploy as such capabilities would require understanding of the F5 BIG-IP itself for how to execute such attacks without breaking the device or obviously degrading service, such capabilities would be very valuable for a state-sponsored entity to invest in.
Even if the data plane is not directly impacted by this vulnerability – which appears to be the case based on F5 statements – full administrative control nonetheless is extremely problematic. Even if data is inaccessible directly from this position, the possibility of applying configuration and logic changes via the access gained makes data access and potential manipulation possible through modification of BIG-IP logic and functionality.
The possibilities at this level include not just data theft (e.g., stealing credentials to systems using the BIG-IP as a load balancer to the desired resource), but the possibility of furthering supply-chain like or midpoint compromise for customers or clients of the victim enterprise. As previously described in this blog, midpoint attack methods are increasingly popular with a number of attackers and present a number of problems for defenders. Yet one of the primary means of defeating these attacks – encrypting traffic – falls by the wayside given the F5 BIG-IP’s capability for SSL inspection in order to perform its regular functions. Any traffic flowing through a compromised F5 should be treated as insecure with the potential of full visibility to an attacker.
Based on this cursory analysis, if I am a sufficiently skilled attacker, my primary goal in compromising an F5 would be to use it as a tool to enable follow-on exploitation at numerous additional victims. Examples include the credential capture item described previously, but also the possibility of injecting payloads into response traffic or similar manipulations that can enable direct exploitation of clients at scale. Given that F5’s BIG-IP is designed for high-availability, high-demand applications, the possibilities here are both vast and very concerning.
Furthermore, I fear that many organizations will likely apply mitigating controls – blocking or filtering access to the BIG-IP configuration console, which is required to exploit the vulnerability – instead of applying the patch. Patching devices such as BIG-IP requires a potentially painful shutdown which produces a hit on availability for high-demand applications that many organizations will likely try to put off. Removing external access to the management console will certainly help reduce exposure and likely defeat all the script kiddies using the Twitter POCs to get shells – but it will mean nothing for the state-sponsored entities realizing the potential of a compromised F5.
These actors will instead invest the time and effort to penetrate networks of interest to get access to management consoles via internal communications. This effort is more than worth it as the payoff of using an F5 is quite large and powerful. Furthermore, attackers can probably assume that even if the device is later patched during upcoming scheduled downtime, harvested system information (such as credentials) will likely go unchanged. In this scenario, even with the system later patched, an attacker will have time to solidify access and develop alternative means of communicating with the compromised device.
Overall, this vulnerability enables a number of scary scenarios. Ideally organizations will patch as soon as practical. More likely, organizations will limit or block all external access to the BIG-IP management interface, and call things “OK enough” until a future planned maintenance period to patch. While the “skids” will be blocked and frustrated, state entities will realize the possibilities of accessing these devices and leverage intrusions to gain incredibly valuable real estate to enable further intrusions.
