Been trying to relax this weekend, but infosec never sleeps, and this one is just so bad. Gonna take a minute to break it down for folks who have F5 in their environment, but haven't gotten a good feel for the actual real world impact of CVE-2020-5902 (thread) https://twitter.com/n0x08/status/1279433935101943810

Let's start with BIG-IP on LTM. This is what you traditionally think of as a load balancer. Sends traffic to healthy systems, takes unhealthy hosts out of the pool. But it's much, much bigger than that. (2/x)

Most LTMs handle SSL/TLS termination, which means they house public/private keypairs. Additionally, LTMs provide content injection via iRules, F5's proprietary scripting language. You can inject or modify any content, from headers to JavaScript, with iRules. (3/x)

Imagine a situation where thousands of sensitive public/private certs were stolen. Imagine an iRule that scraped credentials or payment info, a Magecart panacea. This bug allows all of this for unauthenticated users. (4/x)

You can patch your applications and server farm and build WAF rules all day, but if the device sitting above can subvert all of that, it's game over. (5/x)

Now let's talk GTM. GTMs are essentially very powerful DNS servers. They can redirect, based on geographic location and many other factors, any DNS record to whatever IP address is defined in the GTM. Many orgs trust GTM implicitly both internally and externally. (6/x)

Imagine a bad guy has access to a GTM management interface on your network. Now they can redirect any DNS call defined in GTM to the server of their choosing, without regard to SSL/TLS because they control that, too. (7/x)

This is probably one of the most impactful vulnerabilities I've seen in my 20+ years in infosec. It's not just the ability to compromise one LTM or GTM. It's the ability to compromise any application sitting behind one. (8/x)

It's the ability to redirect to a system of the attacker's choosing, decrypt SSL/TLS, inject code into the target. It's really bad. (9/x)

So what can you do? First, assume that if you have F5 devices on your network, you are impacted. Determine if you've protected the self-IPs or management IPs. Run this NSE from the same network locations where your users are if you aren't sure. https://raw.githubusercontent.com/RootUp/PersonalStuff/master/http-vuln-cve2020-5902.nse

Network admins don't tend to rush toward shiny new versions of BIG-IP, and I don't blame them (been there, it sucks). But the workaround is solid and prevents the worst case unauthenticated scenario. Follow the procedures in the Mitigation section https://support.f5.com/csp/article/K52145254

Network admins don't tend to rush toward shiny new versions of BIG-IP, and I don't blame them (been there, it sucks). But the workaround is solid and prevents the worst case unauthenticated scenario. Follow the procedures in the Mitigation section https://support.f5.com/csp/article/K52145254 (12/x)

Long term, protect your management interfaces. Don't expose this or any other management interface such as an iLO, iDRAC, firewall, KVM, or the like to untrusted networks. Almost always, untrusted networks include the ones that non-IT employees access. (13/x)

This won't be the first or last time a bug like this comes along. Segment your flat network. Thanks so much for all the hard work done to find and raise awareness on the bug, esp.: @__mn1__, @HackingDave, @GossiTheDog, @RandomDhiraj, @x4ce, and many others. (14/14)

Apologies for my poor threading and missing s/o to @SwiftOnSecurity who never fails to raise the red flag