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

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

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?

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

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

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”

Gaze Upon Just How Thin ATM Skimmers Are Getting

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.)

Retrieving data from such skimmers has also led to some cleverness on the part of the criminals. Insertable readers designed to establish a connection to the skimmer and download data is how that gets done. By the way, retrieving data from an installed skimmer is also something criminals don’t do themselves, so that data is encrypted. After all, it just wouldn’t do to have an intermediary getting ideas about using that data for their own purposes. Continue reading “Gaze Upon Just How Thin ATM Skimmers Are Getting”

This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds

Automated Tank Gauges (ATGs) are nifty bits of tech, sitting unseen in just about every gas station. They keep track of fuel levels, temperature, and other bits of information, and sometimes get tied into the automated systems at the station. The problem, is that a bunch of these devices are listening to port 10001 on the Internet, and some of them appear to be misconfigured. How many? Let’s start with the easier question, how many IPs have port 10001 open? Masscan is one of the best tools for this, and [RoseSecurity] found over 85,000 listening devices. An open port is just the start. How many of those respond to connections with the string In-Tank Inventory Reports? Shodan reports 11,113 IPs as of August of this year. [RoseSecurity] wrote a simple Python script that checked each of those listening IPs came up with a matching number of devices. The scary bit is that this check was done by sending a Get In-Tank Inventory Report command, and checking for a good response. It seems like that’s 11K systems, connected to the internet, with no authentication. What could possibly go wrong? Continue reading “This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds”