F5 emits fixes for critical flaws in BIG-IP gear: Hopefully yours aren't internet-facing while you ready a patch

Network administrators are urged to patch their F5 BIG-IP application delivery controllers following the disclosure of a pair of critical remote takeover bugs. The flaws in question, CVE-2020-5902 and CVE-2020-5903, lie within in a configuration tool known as the Traffic Management User Interface. Successful exploitation …

[PM from Hell]

Public services are probably at higher risk

"These flaws are particularly bad because the vulnerable BIG-IP gear is generally used by large enterprises to handle traffic to and from critical applications. A successful attack could potentially be disastrous for Fortune 500 companies that make up F5's userbase."

The F5 gear is very cost effective and good at handling high throughput internet connections with many thousands of connections. They've been heavily taken up by local government in the UK where the corporate connection is often servicing libraries. I just hope people are on the ball in terms of patching but have real concerns dies to budget cuts in most IT departments. Don't forget these devices are protecting access to your social care, council tax, housing benefit and potentially medical records too.

technical Teams have shrunk and a lot of the best guys left for private industry a few years ago. At least 2 councils I worked with didn't have full time security managers with the skills to manage CVE exploit mitigation. In one case this was addressed by using a long term contractor, in another the responsibility was passed onto the technical team - security manager roles were introduced outside technical teams for a reason !!!

AC as I'm a contractor in the local government sphere. I left permanent employment in local government as years without any form of pay increase left me unable to pay the bills.

[Anonymous Coward]

Re: Public services are probably at higher risk

F5 - "Cost Effective" ?!? Seriously?

You should look at the wider market and see which Vendors are far lower initial cost and offer similar features at a vastly reduced TCO. The days of "you don't get fired for buying IBM or F5" are long gone.

Look at vendors who offer products that are simpler to manage as well.

[Anonymous Coward]

Re: Public services are probably at higher risk

The days of "you don't get fired for buying IBM or F5" are long gone - You must not work at a bank, where this mantra is very much alive and kicking

[david flacks]

Re: Public services are probably at higher risk

Ok, yes, agreed. Banks are the exception. Public sector, they should be fired for wasting public funds.

[yoganmahew]

Re: Public services are probably at higher risk

They're all architected to the same shoddy standard, though, lowest common denominator development, make it secure as an afterthought..

[david flacks]

Re: Public services are probably at higher risk

Actually I refute that. I work for a vendor that isn't F5 or Citrix and I would say that security is one of the highest priorites in the development team. Hence we've never had a vulnerability that you could drive a fleet of buses through.

I'm not mentioning who I work for obviously as I'm trying remain impartial. But we have darn good reviews on Gartner Peer Insights.

[Anonymous Coward]

Re: Public services are probably at higher risk

You should try convincing some of the big wigs where I am. Mind you, F5 cost is a drop in the ocean to the other wastage.

I think the main thing keeping F5 in favour is that they are 'reassuringly expensive'

[Anonymous Coward]

Re: Public services are probably at higher risk

I totally agree.

AC as a public sector contractor myself.

Where I am I run some F5s because it's still essentially the 'corporate policy' to use them. They're not internet facing but nonetheless my poor colleague who only just upgraded them to latest release about a week ago is now going to have to repeat the exercise rather sooner than expected.

There are other F5s in this organisation and the telecoms monopoly that holds the current contract for their upkeep has almost no people with skills to even do quite basic configuration on them (not massively different from the previous contract holder once their single F5 'expert' had quit). They've only just done their first F5 upgrade in many years and only from a version so old and EOL that the documentation has been deleted online to a version that's already several years old.

If this is a similar story at even just a few other public sector orgs then they could very well be up shit cheek with this one.

[Roland6]

Re: Public services are probably at higher risk

>my poor colleague who only just upgraded them to latest release about a week ago is now going to have to repeat the exercise rather sooner than expected.

Hope your colleague is also a contractor, so should welcome the £work :)

[Anonymous Coward]

Who on earth has the management interface available on the internet, surely its all locked down on a private management network that has known and monitored ingress/egress points

[Anonymous Coward]

Last count...

...how about 15,000+ cases where that wasn't true.

Lots of it about, just use Shodan to have a look for Palo Alto's, Junipers, Cisco's etc where you can reach admin ports.

It's absolutely vast.

[Giles C]

Re: Last count...

I actually found that with a company router.

Router had been setup for telnet access only, I idly searched on shodan and got a login prompt.

Quick explanation to my boss and an ACL was added to remove all access from any address not in Rfc1918 got me enough breathing space to plan an upgrade to a newer image.

[Jellied Eel]

Re: Last count...

I blame the management.. Both customer and vendor. I've been offered 'Carrier Grade' kit that comes with a convenient web management interface so it can be managed via the Internet. Yey!

But 'carrier grade' design principles should demand seperate console/craft interfaces that can be accessed via a physical or logically seperate DCN, ideally on an OOB (Out Of Band) network. Then disable (or try to) any control plane access to the device so it can only be managed from trusted connections.

Snag with that is creating a secure DCN costs $$$, and bean counters may object because they can manage their fridge via the Internet, so why can't business critical kit be managed the same way? Or vendors make it difficult/impossible to physically or logically isolate management interfaces and it's then down to trust... Which can be FUN when security meets the cloud, the vendor only offers Internet/VPN access, and security devices are virtualised inside your cloud instance. And I've been told a few times that vendor X doesn't allow 3rd party connections into their cloud 'for security'.

Biggest problem though is clients that balk at the cost of having a proper management architecture. Why do we need a second network to manage this? Well, so that only your trusted people can manage your entire IT infrastructure, that your business relies on..

[J. Cook]

That's about the only saving grace- it only affects the control plane and management UI.

[Anonymous Coward]

In years past before iHealth became a thing, it was very common for F5 Support to request access to your box for advanced troubleshooting. The setup utility optionally added a handful of IPv4 addresses owned by F5 to various config files to allow access. It "saved you the trouble" of throwing ACLs on your firewall for the devices. Maybe this is still an allowed process at some shops.

At my workplace, this would be a career terminating decision.

[Anonymous Coward]

Agreed - anyone configuring something like this who leaves the management portal flapping in the wild wild web breeze should be taken out and shot. Doesn’t mean it doesn’t happen though.

[Anonymous Coward]

For goodness sake ...

... how does a company whose principle business seems to be protecting external network interfaces make such catastrophic errors?

Sotware is becoming as important as physical infrastructure - it's time we started holding people to account.

[Nick Ryan]

Re: For goodness sake ...

But then software development companies would have to actually test their software properly, train and manage their developers - particularly training as many lack the most basic of comprehension of elementary security, database and accessibility topics.

They would also have to change the delivery principles of "we are providing software and it may or may not work at all or do what you want or may be heavily flawed but this doesn't matter, just give us some more money to upgrade to the next bug ridden version".

[hisdad]

Can be mitigated

F5 recommend that the Management IP not be on a Public Network.

However the External Self IP are often on Public Networks.

If they are Set "Allow All", that exposes the TMUI server.

This is documented and exposed in ihealth as a Diagnostic, but mostly nobody cares.

f5's support article https://support.f5.com/csp/article/K52145254 documents a simple mitigation

--Dad

[Anonymous Coward]

Gulp, indeed

"However, it is estimated more than 10,000 devices running the software could be facing the public web. Positive Technologies reckons that figure is at least 8,000. Gulp. ®"

Many moons ago, when I was working for a completely clueless company, the clueless apps people had devised a cunning trick.

Any internet facing app would come to the DC with their systems plus 3 F5 boxes. This was because the network security for internet facing apps was

3 layers, with each layer only able to communicate with the next.

To work this around, the idiots were, every time, setting up an F5 as an HTTP router to bounce from one layer to the other, up to internal network.

Yes, retarded, and yes, surely it has been exploited. Actually, there were so many F5 boxes and the idiots never realized just 3 could cover ALL apps

that they stacked in the DC unused ! Some dozens of them.

I remember a really painful discussion with one corporate security dude to which I asked if he sponsored this. Hetold me "this comes from business, we can't do anything".

Happy I left them to their misery.

Anon of course