F5 Big-IP appliances vulnerability - Follow-up

Last week, SCYTHE released emulation plans detailing post-exploitation activity by threat actors targeting F5 Big-IP appliances (CVE-2022-1388). 

To add to the fun, SCYTHE’s own Brandon Radosevich created a module to test for the F5 Big-IP vulnerability. SCYTHE normally focuses exclusively on post-exploitation and vulnerability scanning really isn’t our thing. This is the second time SCYTHE has built vulnerability scanning modules (the other being log4j). 

When I first heard we were building another vulnerability-specific module, I was skeptical of the need. I’ll admit that I’m generally more of a “focus on core strengths” kind of guy. But it didn’t take long talking to customers to learn why having modules like this in SCYTHE is extremely beneficial in the context of adversary emulation. Let’s discuss why.

The vulnerability:

• Is exploited over HTTPS so network-based detection isn’t easy
• Targets a system that traditionally doesn’t run endpoint security controls
• Allows anyone to run arbitrary commands as a privileged user

In this situation, it’s easy to see why we’d want a module that can deliver payloads to a vulnerable system. In most organizations, vulnerability management and control validation occurs in different portions of the security team. The staff performing control validation and detection engineering often can’t just fire up the vulnerability scanner of their choice to validate whether a vulnerability exists. And if it does, the vulnerability scanner usually won’t help them with payload delivery and/or control validation.

This is where modules like the one Brandon wrote come into play. The module allows detection engineers to run “what if” scenarios for detections against potentially vulnerable F5 appliances. Why not just patch a vulnerable F5? In a perfect world, patching is always the answer. But perfect isn’t the world we live in. These appliances do a lot of heavy lifting in most networks where they are deployed. Change management windows are usually required to get a patch installed, even for a critical vulnerability that’s being actively exploited in the wild.

Because CVE-2022-1388 can in most cases only be exploited through the local management network interface, many teams will likely delay patching until acceptable outage windows can be achieved. From a risk management perspective, this totally makes sense if new outage windows can’t be coordinated. Every change management window has a definite operational impact vs the hypothetical impact of being exploited. The hypothetical nature of exploitation impact is magnified when the argument “but you’d detect it anyway” is presented.

And this my friends is where SCYTHE’s F5 module comes in. If you find yourself in the position of having to defend assumptions of “but you’d catch that anyway” then fire up the F5 module in SCYTHE and run a campaign. If the activity isn’t detected, you can confidently say put that assumption to rest. If payload delivery is detected, rock on - but at least you’re not guessing. Either way, SCYTHE is enabling the organization to make an informed risk decision based on data rather than feelings.

Note that to deploy the F5 module, you’ll have to add it to your SCYTHE server instance. This video walks you through how to do it. You may not have a non-production F5 BIG-IP appliance to test against. In that case, use this code from Brandon (based on fastAPI) to simulate a vulnerable F5 BIG-IP appliance.

I’ll close by noting that while I don’t have a crystal ball, SCYTHE won't regularly build modules to deliver payloads through exploitation. One of the things SCYTHE prides itself on is being safe to run in production. Most exploits are unfortunately not safe to run in production. Any number of machine or process state variations can cause crashes, even in semi-reliable exploits, leading to loss of availability or even data corruption. The two vulnerability modules SCYTHE has released are both extremely reliable with near-zero chance of causing system issues when properly used. So for future command injection vulnerabilities we expect to be widely exploited, you can expect SCYTHE may build modules. But we’ll only do so when we’re confident that we can guarantee safe operation in customer environments. Since that’s unlikely to ever be the case for vulnerability classes like heap overflows in your favorite application, you can bet against those showing up (for good reason).

The F5 BIG-IP module won’t be in your SCYTHE instance, but Brandon Radosevich has helpfully recorded a video showing how to install a new module in the SCYTHE platform. Happy hunting friends!

This post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.