Technology

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.

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.

The attackers can access the keys needed to decrypt traffic going through the appliances.