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?
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”→
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.
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.
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.
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.
ATM skimmers are electronic devices designed to read financial card information, and they are usually paired with a camera to capture a user’s PIN. These devices always have to hide their presence, and their design has been a bit of an arms race. Skimmers designed to be inserted into a card slot like a parasite have been around for several years, but [Brian Krebs] shows pictures of recently captured skimmer hardware only a fraction of a millimeter thick. And that’s including the battery.
As hardware gets smaller, cameras to capture PIN entry are more easily hidden in things like fake panels.
The goal of these skimmers is to read and log a card’s magnetic strip data. All by itself, that data is not enough to do anything dastardly. That’s why the hardware is complemented by a separate device that captures a user’s PIN as they type it in, and this is usually accomplished with a camera. These are also getting smaller and thinner, which makes them easier to conceal. With a copy of the card’s magnetic strip data and the owner’s PIN, criminals have all they need to create a cloned card that can be used to make withdrawals. (They don’t this so themselves, of course. They coerce or dupe third parties into doing it for them.)
