Attack Turns Mouse Into Microphone

As computer hardware gets better and better, most of the benefits are readily apparent to users. Faster processors, less power consumption, and lower cost are the general themes here. But sometimes increased performance comes with some unusual downsides. A research group at the University of California, Irvine found that high-performance mice have such good resolution that they can be used to spy on a user’s speech or other sounds around them.

The mice involved in this theoretical attack need to be in the neighborhood of 20,000 dpi, as well as having a relatively high sampling rate. With this combination it’s possible to sense detail fine enough to resolve speech from the vibrations of the mouse pad. Not only that, but the researchers noted that this also enables motion tracking of people in the immediate vicinity as the vibrations caused by walking can also be decoded. The attack does require a piece of malware to be installed somewhere on the computer, but the group also theorize that this could easily be done since most security suites don’t think of mouse input data as particularly valuable or vulnerable.

Even with the data from the mouse, an attacker needs a sophisticated software suite to be able to decode and filter the data to extract sounds, and the research team could only extract around 60% of the audio under the best conditions. The full paper is available here as well. That being said, mice will only get better from here so this is certainly something to keep an eye on. Mice aren’t the only peripherials that have roundabout attacks like this, either.

Thanks to [Stephen] for the tip!

Continue reading “Attack Turns Mouse Into Microphone”

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”

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”

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”

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

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”

The Inside Story Of The UK’s Great CB Petrol Scam

Looking at gasoline prices today, it’s hard to believe that there was a time when 75 cents a gallon seemed outrageous. But that’s the way it was in the 70s, and when it tripped over a dollar, things got pretty dicey. Fuel theft was rampant, both from car fuel tanks — remember lockable gas caps? — and even from gas stations, where drive-offs became common, and unscrupulous employees found ways to trick the system into dispensing free gas.

But one method of fuel theft that escaped our attention was the use of CB radios to spoof petrol pumps, which [Ringway Manchester] details in his new video. The scam happened in the early 80s, only a few years after CB became legal in the UK but quite a while since illegal use had exploded. The trick involved a CB transceiver equipped with a so-called “burner,” a high-power and highly illegal linear amplifier used to boost the radiated power of the signal. When keyed up in the vicinity of dispensers with digital controls, the dispensing rate on the display would appear to slow down markedly, while the pump itself stayed at the same speed. The result was more fuel dispensed than the amount reported to the cashier.

If this sounds apocryphal, [Ringway] assures us that it wasn’t. When the spoofing was reported, authorities up to and including Scotland Yard investigated and found that it was indeed plausible. The problem appeared to be the powerful RF signal interfering with the pulses from the flowmeter on the dispenser. The UK had both 27 MHz and 934 MHz CB at the time; [Ringway] isn’t clear which CB band was used for the exploit, but we’d guess it was the former, in which case we can see how the signals would interfere. Another thing to keep in mind is that CB radios in the UK were FM, as opposed to AM and SSB in the United States. So we wonder if the same trick would have worked here.

At the end of the day, no matter how clever you are about it, theft is theft, and things probably aren’t going to go well for you if you try to pull this off today. Besides, it’s not likely that pumps haven’t been hardened against these sorts of attacks. Still, if you want a look inside a modern pump to see if you can find any weaknesses, have at it. Just don’t tell them where you heard about it.

Continue reading “The Inside Story Of The UK’s Great CB Petrol Scam”

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

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”