We’ve covered a lot of sketchy USB devices over the years. And surely you know by now, if you find a USB drive, don’t plug it in to your computer. There’s more that could go wrong than just a malicious executable. We’ve covered creative and destructive ideas here on Hackaday, from creative firmware to capacitors that fry a machine when plugged in. But what happened to a handful of Ecuadorian journalists was quite the surprise. These drives went out with a bang.
That is, they literally exploded. The drives each reportedly contained a pellet of RDX, a popular explosive in use by militaries since the second World War. There have been five of these hyperactive USB devices located so far, and only one actually detonated. It seems that one only managed to trigger half of its RDX payload. Because of this, and the small overall size of a USB drive, the explosion was more comparable to a firecracker than a bomb.
Mr Self Destruct v1 pic.twitter.com/aFloN5VGKI
— MG (@_MG_) October 6, 2017
Of the other four, two more were plugged in, but failed to go off. One of which using a USB extension cable, which is reported to have lacked enough voltage under load to have triggered the payload.
Yet another reporter …. might have set off the USB stick’s explosives if he had plugged it into the computer properly[.]
So either these were the worst-designed bombs in the world, or a handful of journalists got incredibly lucky. The universal multi-flip process of trying to plug in a USB drive came in hand this time, it seems. But the proof-of-concept is out there, and it’s just a matter of time before someone clever packs a larger USB gizmo with something nasty. So if you’re something like a journalist, and you absolutely have to access untrusted USB drives, there’s yet another step to take to do so safely.
On the Hackaday Discord, we discussed how one might go about this safely, and the conclusion was a machine without writable firmware, without internet access, and booted off either a DVD, or disposable SD card. A standalone Raspberry Pi might be great, if only we could get our hands on them. Oh, and apparently now the drive needs to be behind a blast shield, inside a fume hood, because who knows what’s going to happen when you power it on.
We’ve Entered the Acropalypse
Google’s Android 10 introduced a silent API change to ParcelFileDescriptor.parseMode(), making the write mode non-truncating. So overwrite a large file with a shorter one leaves the original data untouched at the end. That probably should have been treated as a security vulnerability in itself, and we have the first real-world problem as a result. Acropalypse, CVE-2023-21036.
Pixel phones include a nifty tool, Markup, that’s specifically designed for editing screenshots. And until the March Pixel update, it used this non-truncating file write mode for saving modified screen shots. So that screen shot you cropped and then uploaded to Discord? Part of the cropped-out data is probably still right there in the file. And now there’s a tool to try to work out the original image.
Introducing acropalypse: a serious privacy vulnerability in the Google Pixel's inbuilt screenshot editing tool, Markup, enabling partial recovery of the original, unedited image data of a cropped and/or redacted screenshot. Huge thanks to @David3141593 for his help throughout! pic.twitter.com/BXNQomnHbr
— Simon Aarons (@ItsSimonTime) March 17, 2023
And it’s not just Android. Apparently Windows’ UWP API has the same problem, where files are not truncated on write. As a result, the Windows Snipping tool is vulnerable to the exact same problem. This pair of vulnerabilities looks to be a real problem, and expect to hear more about this as years worth of uploaded screenshots are mined for data.
Disappearing Bitcoins
There’s a new take on ATM jackpotting, and this time it’s cryptocurrency. You may not know that we’ve entered the cryptocurrency age, and there are now Bitcoin ATMs around the world. And of course, those ATMs have now been hacked, and about $1.5 million worth of Bitcoin stolen.
General Bytes, the vendor that produced the ATMs and backing software, has put out a statement on the breach. The vulnerability was an unrestricted file upload, taking advantage of an API used for uploading videos from the ATMs to the cloud. It’s unclear why those ATMs had video capability, but this upload meant that an attacker could host a Java application on the backend servers. That malicious app started automatically, and ran with sufficient privileges to do database reads, pull API keys, and transfer funds.
Attackers discovered this vulnerability chain, and pulled off attacks against both the General Bytes backend, and instances hosted by customers. In a burst of effort, a fixing patch was out within 15 hours of the attack launching. What is most surprising is that GB states that they’ve run multiple code audits since the vulnerability was introduced in 2021, and this particular issue wasn’t found. This reinforces two truths: no audit is truly comprehensive, and it takes many eyeballs to see all the possible ways a codebase can break.
Patch To Pwn
How long does it take to deconstruct a patch, figure out the vulnerability, and turn it into a working proof of concept? A whole bunch of hardening has gone into our operating systems in the last few years to try to keep the reverse engineering window far enough ahead of the patch application curve. But ocassionally, the turnaround still manages to clock in at about a day.
CVE-2023-21768 is a vulnerability in the Ancillary Function Driver, part of the Winsock API. The patch modifies kernel code, and it took some work for researchers at SecurityIntelligence to understand how to trigger the flaw from userspace. It’s an unchecked memory write, to a pointer supplied by userspace. The steps to set up the write were a bit complicated, but not insurmountable. This particular group of researchers opted to use a Windows I/O ring to map kernel memory into userspace, gaining a read/write primitive. And that’s pretty much game over for an exploit. Interestingly, another group of researchers found this same vulnerability being exploited in-the-wild in January, likely very shortly after the patch was released by Microsoft.
Malicious Packages Come for .Net
One of the ongoing stories from the past year is the variety of malicious python and JS packages on NPM and PyPI. Those aren’t the only library package managers out there, and it turns out that the “love” is destined to be shared. NuGet, a .Net package manager was in the midst of a typosquatting attack, when Jfrog researchers opted to do an audit. When one of these packages is installed via Visual Studio, an init.ps1 script is automatically run if present.
So far there have been thirteen packages discovered, most of them typos of popular packages, and there’s a worrying 168,000 downloads between them. There was quite a bit of work done on these packages, to make them look more legitimate, like putting real data and developer names in the metadata. The final payload seems to be custom, and does cryptocurrency stealing, code execution, and self updates. A handful of indicators of compromise are published in the article linked above. To avoid falling for this trick yourself, the normal advice about checking carefully for typos applies, but you might also use the NuGet Package Explorer to look for install-time scripts.
Bits and Bytes
Emotet is back after three months of silence. It learned a new trick in the meantime, and is now using OneNote scripts to compromise machines. It uses a fake prompt to view the emailed file, and when the user clicks the fake button, it runs the script instead.
Another similar new trick is to use Adobe Acrobat’s e-signature feature to slip malware by various mitigations. When Acrobat is used for this purpose, the document to be signed is hosted by Adobe, and linked to in a legitimate signature request. The document contains a link to another site, and there a malicious executable is offered. The scheme starts out looking very legitimate, since it really is an Adobe email, so watch out.
Ransomware is alive and all-too-well, with the latest news being that both Ferrari and shipping giant Royal Dirkzwager. These are both the newest, most insidious ransomware forms, where it’s not just data deletion that’s being threatened, but full release of the entire data archive, too. Ferrari has outright refused to give an inch, instead informing customers that their data was taken — you can do this when the nature of the breach isn’t too personal. Royal Dirkzwager has reportedly tried to negotiate, though more information is not yet available.
And Google is releasing four vulnerabilities via Project Zero, this time relating to the Exynos modems found in many cell phones. The 90 day deadline is up on these flaws, and so they’re publicly announced. There are four other flaws that are particularly serious, potentially allowing device compromise from across the Internet, and these are still being withheld from public access. And another ten, also less severe, will release in due time once their 90-day timer ticks to zero.
This Week in Security: USB Boom! Acropalypse, and a Bitcoin Heist
Source: Manila Flash Report
0 Comments