This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG

October 14, 2022 by Jonathan Bennett 12 Comments

First up is some clever wizardry from the [Aqua Nautilus] research team, who discovered a timing attack that leaks information about private npm packages. The setup is this, npm hosts both public and private node.js packages. The public ones are available to everyone, but the private packages are “scoped”, meaning they live within a private namespace, “@owner/packagename” and are inaccessible to the general public. Trying to access the package results in an HTTP 404 error — the same error as trying to pull a package that doesn’t exist.

The clever bit is to keep trying, and really pay attention to the responses. Use npm’s API to request info on your target package, five times in a row. If the package name isn’t in use, all five requests will take the expected amount of time. That request lands at the service’s backend, a lookup is performed, and you get the response. On the flipside if your target package does exist, but is privately scoped, the first request returns with the expected delay, and the other four requests return immediately. It appears that npm has front-end that can cache a 404 response for a private package. That response time discrepancy means you can map out the private package names used by a given organization in their private scope.

Now this is all very interesting, but it turns into a plausible attack when combined with typosquatting and dependency confusion issues. Those attacks are two approaches to the same goal, get a node.js deployment to run a malicious package instead of the legitimate one the developer intended. One depends on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package.

Continue reading “This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG” →

Hacking Google With Plasma

October 10, 2022 by Al Williams 17 Comments

Google recently made some videos to highlight cybersecurity. The video below is episode three, and it tells an interesting story about the first crash test dummy. However, the really interesting part is the story about a USB plasma globe built to hack into computers. One of the people who built that globe tells the story of its insides in a recent blog post that has a bit more technical detail.

The attack in question was in 2012, when people were starting to get the idea that inserting random USB drives into their computers wasn’t a great idea. However, what harm could there be in a cute little plasma globe that just draws power from the port?

Continue reading “Hacking Google With Plasma” →

This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis

October 7, 2022 by Jonathan Bennett 1 Comment

If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.
Continue reading “This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis” →

This Week In Security: Exchange 0-day, Doppelgangers, And Python Gets Bit In The TAR

September 30, 2022 by Jonathan Bennett 13 Comments

According to researchers at GTSC, there’s an unpatched 0-day being used in-the-wild to exploit fully patched Microsoft Exchange servers. When they found one compromised server, they made the report to Microsoft through ZDI, but upon finding multiple Exchange servers compromised, they’re sounding the alarm for everyone. It looks like it’s an attack similar to ProxyShell, in that it uses the auto-discover endpoint as a starting point. They suspect it’s a Chinese group that’s using the exploit, based on some of the indicators found in the webshell that gets installed.

There is a temporary mitigation, adding a URL-based request block on the string .*autodiscover\.json.*\@.*Powershell.. The exact details are available in the post. If you’re running Exchange with IIS, this should probably get added to your system right now. Next, use either the automated tool, or run the PowerShell one-liner to detect compromise: Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200. This one has the potential to be another really nasty problem, and may be wormable. As of the time of writing, this is an outstanding, unpatched problem in Microsoft Exchange. Come back and finish the rest of this article after you’ve safed up your systems.

Continue reading “This Week In Security: Exchange 0-day, Doppelgangers, And Python Gets Bit In The TAR” →

So How Do You Make A Self-Destructing Flash Drive?

September 26, 2022 by Tom Nardi 57 Comments

A self-destructing storage device that vaporizes its contents at the first sign of trouble would be an invaluable tool for many people, but good luck getting your hands on such a thing if you don’t work for a three-letter agency. Or at least, that’s what we would have said before [Walker] got on the case. He’s working on an open source self-destructing USB flash drive for journalists, security researchers, whistleblowers, or anyone else who really values their privacy.

When we previously covered this project in July, [Walker] had only planned to make the flash drive hide its contents unless you knew to wet your fingers before plugging it in. We admit it sounds a little weird, but as far as clandestine methods of activating something goes, it’s pretty clever. But based on the feedback he received, he decided to go all-in and make the USB drive literally trash itself should it be accessed by somebody who doesn’t know the secret.

An elegant weapon for a more civilized age.

But how exactly do you pull that off? Sure we’d love to see a small thermite charge or vial of acid packed in there, but obviously that’s not very practical. It needs to be safe to carry around, and just as importantly, unlikely to get you into even more trouble with whoever is searching through your belongings. To that end, [Walker] thinks he’s come up with an elegant solution.

The datasheet for his flash memory chip says the maximum voltage it can handle before releasing the Magic Smoke is a meager 4.6 V. So he figures running a voltage doubler on the nominal 5 V coming from a USB port should disable the chip nicely with a minimum of external drama. Will it be enough to prevent the data from being recovered forensically? We don’t know, but we’re eager to find out.

In the write-up, [Walker] takes readers through the circuit designs he’s come up so far, and shows off the source code that will run on the ATtiny25 to determine when it’s time to toast the flash. He says by the next post he should have the entire flash drive built and documented, so stay tuned.

This Week In Security: Malwarebytes Goes Nuts, Uber

September 23, 2022 by Jonathan Bennett 12 Comments

I got a rude awakening Wednesday morning this week. HaD writers don’t necessarily keep normal hours — don’t judge. A local client called, complaining that Google Maps was blocking on one of their computers, and the browser stated that it was a malicious site. Well that got my attention. Standard incident response: “Turn off the affected computers, I’m on my way.” Turns out, it was Malwarebytes that was complaining and blocking Google Maps, as well as multiple other Google domains. That particular machine happened to have a fresh install of the program, and was still in the trial period of Malwarebytes premium, which includes the malicious IP and domain blocking feature.

Oof, this could be bad. The first possibility that came to mind was a DNS hijack. The desktop’s DNS was set to the router, and the router’s DNS was set to the ISP’s. Maybe the ISP had their DNS servers compromised? Out came the cell phone, disconnected from the WiFi, for DNS lookups on some Google domains. Because Google operates at such a massive scale, they have multiple IPs serving each domain, but since the two different results were coming from the same subnet, the suspicious DNS server was likely OK. A whois on the blocked IP also confirmed that it was a Google-owned address. We were running out of explanations, and as a certain fictional detective was known for saying, “whatever remains, however improbable, must be the truth.” And, yes, Malwarebytes did indeed accidentally add Google to its bad list. The upside was that my customer wasn’t compromised. The downside? I had to answer a phone call before my first cup of coffee. Blegh.

Continue reading “This Week In Security: Malwarebytes Goes Nuts, Uber” →

What’s Old Is New Again: GPT-3 Prompt Injection Attack Affects AI

September 16, 2022 by Donald Papp 13 Comments

What do SQL injection attacks have in common with the nuances of GPT-3 prompting? More than one might think, it turns out.

Many security exploits hinge on getting user-supplied data incorrectly treated as instruction. With that in mind, read on to see [Simon Willison] explain how GPT-3 — a natural-language AI — can be made to act incorrectly via what he’s calling prompt injection attacks.

This all started with a fascinating tweet from [Riley Goodside] demonstrating the ability to exploit GPT-3 prompts with malicious instructions that order the model to behave differently than one would expect.

Continue reading “What’s Old Is New Again: GPT-3 Prompt Injection Attack Affects AI” →