I’ve spent the last 24 hours (including a sleeps) gathering intel, testing in the lab and looking at what the path traversal and RCE for the F5 BIG-IP as outlined in CVE-2020-5902 looks like.
Well I’ll be honest.. the whole scenario is a bit of a bloody mess! We’ve got people leaving management interfaces exposed to the internet, we’ve got a vulnerability that’s incredibly old in a security appliance (it’s not exactly uber 1337 either) and we’ve had the release scenario that’s probably ruined peoples weekends and weeks (I’m not going into an Offensive Securitry Tools debate/argument, if you want that go talk to a brick wall or someone else!)

I’ve spent a fair bit of time taking cyber threat intel, downloading proof of concepts code (including the metasploit module) and i’ve made my own bash (1337 right!) POC exploit in the lab.

But i’m not herre to talk about pew pews and being 1337, I’m here to help people defend because that’s all this game is about (unless you are a criminal or a nation state cyber outfit (pro tip most of you are on the defending/legal side of the world).

So I don’t want to drop a ton of technical info on the vulnerability of exploits , you can find that stuff out (it’s public even if some of it requires some work to get it working as an RCE). Let’s look at what we can do to detect, now i’m going to have to make assumptions about the deployment but let’s say this:

• Your managment interface is exposed to the internet (this still applies to internal but for this sake I’m focusing on high risk high likelyhood internet facing scenarios)
• You aren’t proxing web traffic to the management port
• You don’t have logging or your logging config is not very advanced

First things first, understand your asset and configuraion profile. work out if your device is vulnerable. If it is consider removing the management interfac from facing the internet. The second thing to do is see if you can patch, if you can’t easily patch there is a workaround (https://support.f5.com/csp/article/K52145254)

Once you’ve secured your position you will want to start seeing if you have had any form of unauthorised access. This isn’t a total guide for IOCs on this device but a good starting point is to do the following:

Review the /var/log/audit file on the device (for can get to this from ssh)

Look for suspicious activity (take a copy of the log, take two of them and keep one safe and work on the other)

We can see this can be done via ssh (as mentioned above) but also in the GUI (we’d search for *bash* as shown below!

If the MSF POC was used you will probably see something like this

“Jul 6 11:47:31 localhost.localdomain notice tmsh[24772]: 01420002:5: AUDIT – pid=24772 user=admin folder=/Common module=(tmos)# status=[Command OK] cmd_data=run /util bash /tmp/AnPuvRscIcUCgY7OnpoJquupwB0CsCrrxs”

It’s too early to tell what all the IOCs will look like but if you see an entry like this in your audit log it’s highly probably you have had a cyber incident.

Just a quick thank you to everyone that’s helped work on this, from my friends in Cyber Volunteers 19 and CTI league through to people on twitter!

I’ll try and keep intel updated on this as best I can!

be safe, stay secure!