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

October 3, 2025 by Jonathan Bennett 4 Comments

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” →

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

September 26, 2025 by Jonathan Bennett 3 Comments

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” →

This Week In Security: The Shai-Hulud Worm, ShadowLeak, And Inside The Great Firewall

September 19, 2025 by Jonathan Bennett 7 Comments

Hardly a week goes by that there isn’t a story to cover about malware getting published to a repository. Last week it was millions of downloads on NPM, but this week it’s something much more concerning. Malware published on NPM is now looking for NPM tokens, and propagating to other NPM packages when found. Yes, it’s a worm, jumping from one NPM package to another, via installs on developer machines.

It does other things too, like grabbing all the secrets it can find when installed on a machine. If the compromised machine has access to a Github account, a new repo is created named Shai-Hulud, borrowed from the name of the sandworms from Dune. The collected secrets and machine info gets uploaded here, and a workflow also uploads any available GitHub secrets to the webhook.site domain.

How many packages are we talking about? At least 187, with some reports of over 500 packages compromised. The immediate attack has been contained, as NPM has worked to remove the compromised packages, and apparently has added filtering code that blocks the upload of compromised packages.

So far there hasn’t been an official statement on the worm from NPM or its parent companies, GitHub or Microsoft. Malicious packages uploaded to NPM is definitely nothing new. But this is the first time we’ve seen a worm that specializes in NPM packages. It’s not a good step for the trustworthiness of NPM or the direct package distribution model.

Continue reading “This Week In Security: The Shai-Hulud Worm, ShadowLeak, And Inside The Great Firewall” →

This Week In Security: NPM, Kerbroasting, And The Rest Of The Story

September 12, 2025 by Jonathan Bennett 9 Comments

Two billion downloads per week. That’s the download totals for the NPM packages compromised in a supply-chain attack this week. Ninety-nine percent of the cloud depends on one of the packages, and one-in-ten cloud environments actually included malicious code as a result of the hack. Take a moment to ponder that. In a rough estimate, ten percent of the Internet was pwned by a single attack.

What extremely sophisticated technique was used to pull off such an attack? A convincing-looking phishing email sent from the newly registered npmjs.help domain. [qix] is the single developer of many of these packages, and in the midst of a stressful week, fell for the scam. We could refer to the obligatory XKCD 2347 here. It’s a significant problem with the NPM model that a single developer falling for a phishing email can expose the entire Internet to such risk. Continue reading “This Week In Security: NPM, Kerbroasting, And The Rest Of The Story” →

This Week In Security: DNS Oops, Novel C2s, And The Scam Becomes Real

September 5, 2025 by Jonathan Bennett 7 Comments

Something rather significant happened on the Internet back in May, and it seems that someone only noticed it on September 3rd. [Youfu Zhang] dropped a note on one of the Mozilla security mailing lists, pointing out that there was a certificate issued by Fina for 1.1.1.1. That IP address may sound familiar, and you may have questions.

First off, yes, TLS certificates can be issued for IP addresses. You can even get a numeric TLS certificate for your IP address, via Lets Encrypt. And second, 1.1.1.1 sounds familiar because that’s CloudFlare’s public DNS resolver. On that address, Cloudflare notably makes use of DoH, a charming abbreviation for DNS over HTTPS. The last important detail is that Cloudflare didn’t request or authorize the certificate. Significant indeed.

This is a high-profile example of the major weakness of the TLS certificate system. There are over 300 trusted certificate authorities in the Microsoft Root Certificate Program, Financijska agencija (Fina) being one of them. All it takes is for one of those trusted roots to issue a bad certificate, to compromise that system. That it took four months for someone to discover and point out the problem isn’t great. Continue reading “This Week In Security: DNS Oops, Novel C2s, And The Scam Becomes Real” →

This Week In Security: DEF CON Nonsense, Vibepwned, And 0-days

August 29, 2025 by Jonathan Bennett 6 Comments

DEF CON happened just a few weeks ago, and it’s time to cover some of the interesting talks. This year there were two talks in particular that are notable for being controversial. Coincidentally both of these were from Track 3. The first was the Passkeys Pwned, a talk by SquareX about how the passkey process can be hijacked by malware.

[Dan Goodin] lays out both the details on Passkeys, and why the work from SquareX isn’t the major vulnerability that they claim it is. First, what is a Passkey? Technically it’s a public/private keypair that is stored by the user’s browser. A unique keypair is generated for each new website, and the site stores the public key. To authenticate with the Passkey, the site generates a random string, the browser signs it with the private key, and the site checks it against the public key. I stand by my early opinion, that Passkeys are effectively just passwords, but with all the best-practices mandated.

So what is the claim presented at DEF CON? Malicious code running in the context of the browser tab can hijack the passkey process. In the demonstrated attack flow, a browser extension caused the Passkey login to fail, and prompted the user to generate a new Passkey. This is an interesting observation, and a clever attack against Passkeys, but is not a vulnerability in the Passkey spec. Or more accurately, it’s an accepted limitation of Passkeys, that they cannot guarantee security in the presence of a compromised browser. Continue reading “This Week In Security: DEF CON Nonsense, Vibepwned, And 0-days” →

This Week In Security: Anime Catgirls, Illegal AdBlock, And Disputed Research

August 22, 2025 by Jonathan Bennett 28 Comments

You may have noticed the Anime Catgirls when trying to get to the Linux Kernel’s mailing list, or one of any number of other sites associated with Open Source projects. [Tavis Ormandy] had this question, too, and even wrote about it. So, what’s the deal with the catgirls?

The project is Anubis, a “Web AI Firewall Utility”. The intent is to block AI scrapers, as Anubis “weighs the soul” of incoming connections, and blocks the bots you don’t want. Anubis uses the user agent string and other indicators to determine what an incoming connection is. But the most obvious check is the in-browser hashing. Anubis puts a challenge string in the HTTP response header, and JavaScript running in the browser calculates a second string to append this challenge. The goal is to set the first few bytes of the SHA-256 hash of this combined string to 0.

[Tavis] makes a compelling case that this hashing is security theatre — It makes things appear more secure, but doesn’t actually improve the situation. It’s only fair to point out that his observation comes from annoyance, as his preferred method of accessing the Linux kernel git repository and mailing list are now blocked by Anubis. But the economics of compute costs clearly demonstrate that this SHA-256 hashing approach will only be effective so long as AI companies don’t add the 25 lines of C it took him to calculate the challenge. The Anubis hashing challenge is literally security by obscurity.

Continue reading “This Week In Security: Anime Catgirls, Illegal AdBlock, And Disputed Research” →