You just have to laugh when a network security company has malicious actors in their systems, undetected for probably years.
F5 said a “sophisticated” threat group working for an undisclosed nation-state government had surreptitiously and persistently dwelled in its network over a “long-term.” Security researchers who have responded to similar intrusions in the past took the language to mean the hackers were inside the F5 network for years.
This could be really bad. F5 produces WAN accelerators, and one feature that those can have is to have X.509 self-signed certificates used by corporate internal CAs stored on them — things that normally, you’d keep pretty damned secure — to basically “legitimately” perform MITM attacks on traffic internal to corporate networks as part of their normal mode of operation.
Like, if an attacker could compromise F5 Networks and get a malicious software update pushed out to WAN accelerators in the field to exfiltrate critical private keys from companies, that could be bad. You could probably potentially MITM their corporate VPNs. If you get inside a customer’s network, it’d probably let you get by a lot of their internal security.
kagis
Yeah, it sounds like that is exactly what they hit. The “BIG-IP” stuff apparently does this:
During that time, F5 said, the hackers took control of the network segment the company uses to create and distribute updates for BIG IP, a line of server appliances that F5 says is used by 48 of the world’s top 50 corporations
MyF5 Home > Knowledge Centers > BIG-IP LTM > BIG-IP Local Traffic Manager: Implementations > Managing Client and Server HTTPS Traffic using a Self-signed Certificate
One of the ways to configure the BIG-IP system to manage SSL traffic is to enable both client-side and server-side SSL termination:
- Client-side SSL termination makes it possible for the system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client. This ensures that client-side HTTPS traffic is encrypted. In this case, you need to install only one SSL key/certificate pair on the BIG-IP system.
- Server-side SSL termination makes it possible for the system to decrypt and then re-encrypt client requests before sending them on to a server. Server-side SSL termination also decrypts server responses and then re-encrypts them before sending them back to the client. This ensures security for both client- and server-side HTTPS traffic. In this case, you need to install two SSL key/certificate pairs on the BIG-IP system. The system uses the first certificate/key pair to authenticate the client, and uses the second pair to request authentication from the server.
This implementation uses a self-signed certificate to authenticate HTTPS traffic.
Well. That…definitely sucks.
Yup. This is really bad.
It definitely is bad, but it may not be as bad as I thought above.
It sounds like they might actually just be relying on certificates pre-issued by a (secured) CA for specific hosts to MITM Web traffic to specific hosts, and they might not be able to MITM all TLS traffic, across-the-board (i.e. their appliance doesn’t get access to the internal CA’s private key). Not sure whether that’s the case — that’s just from a brief skim — and I’m not gonna come up to speed on their whole system for this comment, but if that’s the case, then you’d still be able to attack probably a lot of traffic going to theoretically-secured internal servers if you manage to get into a customer network and able to see traffic (which compromising the F5 software updates would also potentially permit for, unfortunately) but hopefully you wouldn’t be able to hit, say, their VPN traffic.
Me: Uh-huh. Uh-huh. Uh-huh
Those certainly are some words that I understand seperately, but not together.
There is a class of products that consist of a hardware box that you ram your network traffic moving between different business locations in a company through that tries to accelerate this traffic. F5 is one manufacturer of them. One technique these use is to have private key material such that they can pretend to be the server at the other end of a TLS connection — that’s most of the “encrypted” traffic that you see on the Internet. If you go to an “https” URL in your Web browser, you’re talking TLS, using an encrypted connection. They can then decode the traffic and use various caching and other modification techniques on the decoded information to reduce the amount of traffic moving across the link and to reduce effective latency, avoid transferring duplicate information, etc. Once upon a time, when there was a lot less encrypted traffic in the world, you could just do this by working on cleartext data, but over time, network traffic have increasingly become encrypted. Many such techniques become impossible with encrypted traffic. So they have to be able to break the encryption on the traffic, to get at the cleartext material.
The problem is that to let this box impersonate such a server so that it can get at the unencrypted traffic, they have to have a private key that permits them to impersonate the real server. Having access to this key is also interesting to an attacker, because it would similarly let them impersonate the real server, which would let them view or modify network traffic in transit. If one could push new, malicious software up to control these boxes, one could steal these keys, which would be of interest to attackers in attacking other systems.
It sounds, to my brief skim, like attackers got control of the portion of F5’s internal network that is involved with building and distributing software updates to these boxes.
The problem is that if you’re a sysadmin at, say, General Dynamics (an American defense contractor which, from a quick search, apparently uses these products from F5), you may have properly secured your servers internal to the company in all ways…but then the network admin basically let another box, which wasn’t properly secured, into the encrypted communications between your inter-office servers on the network. It could extract information from your encrypted communication streams, or modify it. God only knows what important data you’ve been shoveling across those connections, or what you’ve done with information that you trusted to remain unmodified while crossing such a connection. It’s be a useful tool for an attacker to stick all sorts of new holes into customer networks that are harder to root out.
Sounds like an inbuilt self inflicted back door on encryption to me!
Back doors are always bad!
The attackers can access the keys needed to decrypt traffic going through the appliances.
It’s gonna be a bad time when a nation state presses a button to cripple our digital infrastructure.
It seems hopeless at this point. It’s all just hyper complicated and profitable security theater.
