This Week in Security: F5, SonicWall, and the End of Windows 10
F5 is unintentionally dabbling in releasing the source code behind their BIG-IP networking gear, announcing this week that an unknown threat actor had access to their internal vulnerability and code tracking systems. This security breach was discovered on August 9th, and in the time since, F5 has engaged with CrowdStrike, Mandiant, and NCC Group to review what happened.
So far it appears that the worst result is access to unreleased vulnerabilities in the F5 knowledge management system. This means that any unpatched vulnerabilities were effectively 0-days, though the latest set of patches for the BIG-IP system has fixed those flaws. There aren’t any reports of those vulnerabilities being exploited in the wild, and F5 has stated that none of the leaked vulnerabilities were critical or allowed for remote exploitation.
Slightly more worrying is that this access included the product development environment. The problem there isn’t particularly the leak of the source code — one of the covered projects is NGINX, which is already open source software. The real danger is that changes could have been surreptitiously added to those codebases. The fact that NGINX is Open Source goes a long way to alleviate that danger, and when combined with the security built into tools like git, it seems very unlikely that malicious code could be sneaked into the NGINX public code base. A thorough review of the rest of the F5 codebases has similarly come up negative, and so far it looks like the supply-chain bullet has been dodged.
WatchGuard Out of Bounds
WatchGuard’s Fireware OS has a stack buffer overflow. There’s a few interesting details about this story. The first, as WatchTowr researchers gleefully point out, is that it’s 2025 and a security vendor has a stack overflow bug straight out of the ’90s. But second, this is one of the first vulnerabilities we’ve covered that has a CVSS 4.0 score. In CVSS 3 terms, this would be a severity 10 vulnerability. As the the 4th iteration of the Common Vulnerability Scoring System also measures the impact on the rest of the network, it scores a bit lower 9.3 there, though one could probably make an argument that it should be higher.
The actual vulnerability is in the VPN service, and it’s as simple as it gets. An attacker controlled buffer is copied into a fixed length memory region without any bounds checking. That VPN service uses an IKEv2 handshake protocol to establish connections, and the server responds with an odd Base64 encoded string. Decode the string, and it turns out the vulnerable service announces VN=12.11.3 BN=719894, the version number and build string, allowing for super easy identification of vulnerable targets.
The final step in turning this into a true vulnerability is to corrupt the stack, take control of the program counter, and Return-Oriented-Program your way through a couple gadgets to be able to call system(). Right? This platform doesn’t turn on every mitigation — stack canaries and position independent execution are noticeably missing. But there are some good hardening steps that were done, like leaving out /bin/sh altogether. How do you run shellcode when the machine doesn’t have a shell at all? The answer the WatchTowr crew turned to was to run the system code in the Python3 shell. Thinking outside the box!
Sonicwall and Unintentional Distributed Backups
About a month ago, we shared the news that Sonicwall had a breach of their own, with limited customers backups being exposed. At the time, the word was that fewer than 5% of customers would be affected. That estimate seems to have been a bit optimistic, as SonicWall is now recommending that all customers step through their new remediation playbook, which calls for a complete cycling of all credentials stored on Sonicwall devices.
It’s unclear if this is because more configuration data was accessible than was previously believed, or because attackers are actively using the pilfered data in attacks against SonicWall customers. The unintentional distribution of system backups turns out not to have been a good strategy.
UEFI Backdoor
UEFI and Secure Boot have been viewed with skepticism, particularly by Linux enthusiasts over the years. There is, however, something to be said for the idea that your computer won’t boot a manipulated OS without your permission, and especially since major Linux distros have access to signed Secure Boot keys, it hasn’t been the dystopian disaster that many of us feared. The security question of the UEFI root of trust has had its own problems, and one of those problems has recently bitten Framework laptops. The issue is the mm (Memory Modify) command that can optionally be built into UEFI shells. This is strictly for debugging purposes, and it’s been discovered that allowing arbitrary access to system memory is not great for system security.
Eclypsium researchers are calling this one BombShell, and it boils down to overwriting the security handler pointer in the UEFI firmware, so all Secure Boot checks are disabled. It seems that this level of tampering is invisible to the system and booted OS. And with just a bit of cleverness, it can be injected as a permanent boot payload. While it’s specifically Framework laptops that are in question with this specific disclosure, it’s not strictly a Framework issue, but can affect any UEFI machine that ships a signed UEFI shell, that includes dangerous commands like mm.
Hack a Car Company, and All the Cars
We have a delightful hack from Def Con 33, where an as-of-yet-unnamed car brand had a couple security problems with their admin web portal, and those problems are pretty serious when put together. First, the invite-only dealer portal didn’t actually verify the invite tokens. And second, when creating an account, the back-end didn’t actually check the account creation details. Meaning that anyone that knew where to look could create an admin account.
The result was that a VIN number could be used to look up a car, and the owner’s details could be accessed. Or the system could be searched via owner’s information, to find vehicle information. It allowed transferring authentication of one of the vehicles to a new mobile app account, and the mobile app could be used to unlock the vehicle.
youtube.com/embed/U1VKazuvGrc?…
Windows 10
It’s time to turn out the lights, the party is over. The sun has set and Windows 10 has entered its twilight. The advice from every other legacy OS applies: upgrade if you can. Yes, there are some frustrating problems with upgrading to Windows 11, particularly if your machine is just too old to have a TPM or Secure Boot.
If you’re stuck on Windows 10, there’s good news and bad news. The good news is that Microsoft is making security updates available for free, for many computers, if you use a Microsoft account on the machine. The bad news is that those updates are a monthly trickle of fresh vulnerabilities that some machines just won’t ever get patched for.
Bits and Bytes
What do you do when you’re flying, and you’re too cheap frugal to pay for in-flight wifi? Naturally, find some way to tunnel out for free. The key is usually DNS. It’s probably the inverse of the meme, that the problem is always DNS, as that’s the last thing a security hardening team wants to break. And if that won’t work, there’s always MAC address cloning.
Many a pen test has hit a brick wall when faced with a gRPC endpoint. Google’s Remote Procedure Call framework is binary, and without reflection turned on, extremely difficult to map what calls are available. There’s a new tool, grpc-scan, that just might shed some light on the subject. It’s a combination of common design patterns, and carefully parsing the returned errors to learn about the system.
And finally, where’s the most bulletproof place you can host some malicious code? A server in Russia? Apparently it’s now on the blockchain. This isn’t a theoretical attack from a security thinktank, but a real-world malware campaign believed to originate from North Korean hackers. Yet another red flag to watch out for in smart contracts!