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. Continue reading “This Week In Security: F5, SonicWall, And The End Of Windows 10”

This Week In Security: ID Breaches, Code Smell, And Poetic Flows

Discord had a data breach back on September 20th, via an outsourced support contractor. It seems it was a Zendesk instance that was accessed for 58 hours through a compromised contractor user account. There have been numbers thrown around from groups claiming to be behind the breach, like 1.6 Terabytes of data downloaded, 5.5 million user affected, and 2.1 million photos of IDs.

Discord has pushed back on those numbers, stating that it’s about 70,000 IDs that were leaked, with no comments on the other claims. To their credit, Discord has steadfastly refused to pay any ransom. There’s an interesting question here: why were Discord users’ government issued IDs on record with their accounts?

The answer is fairly simple: legal compliance. Governments around the world are beginning to require age verification from users. This often takes the form of a scan of valid ID, or even taking a picture of the user while holding the ID. There are many arguments about whether this is a good or bad development for the web, but it looks like ID age verification is going to be around for a while, and it’ll make data breaches more serious.

In similar news, Salesforce has announced that they won’t be paying any ransoms to the group behind the compromise of 39 different Salesforce customers. This campaign was performed by calling companies that use the Salesforce platform, and convincing the target to install a malicious app inside their Saleforce instance. Continue reading “This Week In Security: ID Breaches, Code Smell, And Poetic Flows”

FLOSS Weekly Episode 850: One ROM To Rule Them All

This week Jonathan and Aaron chat with Piers Finlayson about One ROM! Why does the retro-computing world need a solution for replacement ROMs? How difficult was it to squeeze a MCU and layout into the original ROM footprint? And what’s next for the project? Listen to find out!

Continue reading “FLOSS Weekly Episode 850: One ROM To Rule Them All”

This Week In Security: CVSS 0, Chwoot, And Not In The Threat Model

This week a reader sent me a story about a CVE in Notepad++, and something isn’t quite right. The story is a DLL hijack, a technique where a legitimate program’s Dynamic Link Library (DLL) is replaced with a malicious DLL. This can be used for very stealthy persistence as well as escalation of privilege. This one was assigned CVE-2025-56383, and given a CVSS score of 8.4.

The problem? Notepad++ doesn’t run as a privileged user, and the install defaults to the right permissions for the folder where the “vulnerable” DLL is installed. Or as pointed out in a GitHub issue on the Proof of Concept (PoC) code, why not just hijack the notepad++ executable?

This is key when evaluating a vulnerability write-up. What exactly is the write-up claiming? And what security boundary is actually being broken? The Common Weakness Enumeration (CWE) list can be useful here. This vulnerability is classified as CWE-427, an uncontrolled search path element — which isn’t actually what the vulnerability claims, and that’s another clue that something is amiss here. In reality this “vulnerability” applies to every application that uses a DLL: a CVSS 0.

Continue reading “This Week In Security: CVSS 0, Chwoot, And Not In The Threat Model”

FLOSS Weekly Episode 849: Veilid: Be A Brick

This week Jonathan talks with Brandon and TC about Veilid, the peer-to-peer networking framework that takes inspiration from Tor, and VeilidChat, the encrypted messenger built on top of it. What was the inspiration? How does it work, and what can you do with it? Listen to find out!

Continue reading “FLOSS Weekly Episode 849: Veilid: Be A Brick”

This Week In Security: Randomness Is Hard, SNMP Shouldn’t Be Public, And GitHub Malware Delivery

Randomness is hard. To be precise, without dedicated hardware, randomness is impossible for a computer. This is actually important to keep in mind when writing software. When there’s not hardware providing true randomness, most rnd implementations use a seed value and a pseudo random number generator (PRNG). A PRNG is a function that takes a seed value, and turns it into a seemingly random value, and also produces a new seed for the next time a random value is needed. This could be as simple as a SHA256 sum, where the hash output is split to become the next seed and the random value.

The PRNG approach does still have a challenge. Where does the initial seed come from? There are a few common, if flawed, approaches, and one of the most common is to use the system clock. It’s not a bulletproof solution, but using the microsecond counter since the last system boot is often good enough, because there are a lot of them to choose from — the entropy is high. With that brief background in mind, let’s talk about what happens in VBScript. The Randomize call is used to seed that initial value, but Randomize has some quirks.

The first is a great feature: calling Randomize a second time with the same seed doesn’t reset the PRNG engine back to the same initial state. And second, when called without a value, Randomize uses the number of system ticks since midnight as the PRNG seed. There are 64 ticks per second, giving five-and-a-half million possible seeds, or 22 bits of entropy. This isn’t great on its own, but Randomize internally typecasts that number of ticks into a narrower value, with a maximum possible of time-based seeds set at 65,536, which is a lot easier to brute-force.

We don’t know the exact application where the researchers at Doyensec found VBScript generating secure tokens, but in their Proof of Concept (PoC) test run, the generated token could be found in four guesses. It’s a terrible security fail for basically any use, and it’s a deceptively easy mistake to make.

Continue reading “This Week In Security: Randomness Is Hard, SNMP Shouldn’t Be Public, And GitHub Malware Delivery”