What can we learn from the recent F5 security vulnerability?

If exploited, the CVE-2022-1388 vulnerability can lead to a full system takeover. So how can this F5 vulnerability be avoided?

F5 recently announced a critical security vulnerability, allowing an attacker to bypass its iControl REST authentication, and execute commands such as creating or deleting files and disabling services.

Luckily only the management plane is vulnerable, so as long as that is protected as recommended you're relatively safe.  But shockingly it's thought that up to 2,000 F5 ADCs have the management layer unprotected from the internet!

OK, So it's bad — but not as bad as the recent Citrix vulnerability hitting 80,000 people leaving customers wide open to attack. And at least F5 patched the vulnerability immediately, Citrix didnt even fix the problem for weeks.

The bottom line? The F5 vulnerability is simple to exploit and causes a lot of damage. Once an attacker has gained initial access to networks, he or she can spread unchecked to other devices.

We all know F5 is one of the best ADCs on the market. By “best” I mean it is incredibly feature-rich and does a lot more than other appliances. Hence it is often championed as a host for many critical applications. And one that is often dealt with by technology providers on behalf of their customers, who are responsible for hundreds of F5 instances at a time. So when a vulnerability such as this one reveals itself, the headache becomes A LOT worse, with any changes or maintenance windows turning into a complex nightmare.

How can you reduce the risk of new vulnerabilities?

This F5 vulnerability comes off the back of a series of other vulnerabilities over the last few years, these vulnerabilities are rare, and yet inevitable. But there are ways to mitigate the potential risks — like not exposing your management network :-).

1.  Isolate each application with dedicated load balancers

The more applications that organizations try to balance on a single load balancer platform, and the more customizations are made, the more difficult the load balancer becomes to support, and the more vulnerable it becomes to downtime.

The alternative is to isolate applications behind pairs of load balancers. This approach is particularly recommended for mission-critical applications, as a pair of load balancers can be tuned specifically for the application to ensure they remain highly available. Far easier to set up and manage, dedicated load balancers are also less likely to be compromised by human error. Not only do you reduce the potential damage that an attacker could cause, but this strategy simplifies your application delivery, removing a single point of failure and making your maintenance so much easier.

This doesn’t mean that you’ll have to spend a ridiculous amount of time looking after a large number of load balancers. Using centralized management platforms (like ours) will significantly simplify this task by accessing your entire estate from a single pane of glass, and scheduling/automating updates.

The cost doesn’t have to be extortionate either. Some vendors offer site licenses which provide a cost-effective option for those dealing with a large number of applications.

2. Never underestimate the importance of backup and restore!

Simplifying automating the backup of your ADC infrastructure is just as important as data backups. Your response to a crisis will have a huge impact on the business. So look for appliances that will make the restore process as easy as possible. The last thing you want to do is waste time retrieving a license key when you’re dealing with chaos! That’s why we’ve introduced single-click backup and recovery in our appliance. Not only that, we’ve made switching from an F5 to the Loadbalancer.org Enterprise ADC incredibly simple. Deploy a pair of our load balancers in parallel to the live F5s, migrate the configuration across, then shut down the F5s and activate the Floating IPs on our load balancers at the same time. Minimal downtime and flexibility achieved simply — with simple roll-back if you have any issues.

3. Diversify your product range — to obfuscate attack vectors

I was chatting with our Head of Solutions a while back about edge networks, and he was telling me that an appliance like F5 could in theory be the perfect fit because it can do everything. But he asked me this: do you really want one appliance to do everything? He said he knows several large e-commerce sites that have a strict policy of using at least two vendors for each network infrstructure appliance. If one vendor is compromised, then they have another vendor you can quickly swap over to.  This leads me to my next point...

4. Double up on security layers — to complicate attack vectors

My colleague, security expert, and technical author, Andrew Howe, highlighted in a previous blog the importance of a multi-layered defense-in-depth approach. With independent layers of defense in place, even if one or more layers should fail, there are still other defensive measures in place to block attacks and raise the alarm. So perhaps having different products that can do dedicated tasks really well is a safer approach than one product that can do everything? We usually recommend that load balancers are placed next to your application servers — well behind the external firewall perimiter.

5. Remove functionality — to reduce attack vectors

You may be thinking that no vendor will do this. Well, that’s not entirely true. We have started to work with multiple technology providers that need a load balancer that does only what their application needs — nothing more and nothing less, removing any unnecessary functionality that could potentially introduce user errors, or security issues. We provide this tailoring service specifically for technology providers. So if you are a product manager with F5s that are too complex for your application, we can help.

6. Consider using Open Source software?

Do I think ongoing F5 vulnerabilities will damage the market for proprietary systems? Absolutely not. But adoption of open source alternatives is increasing for multiple reasons. From a security perspective, open source software ensures a higher quality code, therefore, presenting fewer vulnerabilities. So why not have the best of both worlds? A product that combines the responsiveness and flexibility of an open source solution, with the support services of a commercial organization.

Conclusion

Security vulnerabilities are a fact of life. Some are more serious than others, and I've discussed many options for improving your defenses. In the end the amount of risk your willing to take is a personal choice.

But I would prefer putting in the work,  with the comfort of knowing I've done all that I can.  In order to avoid the excruciating pain of getting hacked.