Security Hacks

1478 Articles

This Week In Security: Wyze, ScreenConnect, And Untrustworthy Job Postings

February 23, 2024 by 7 Comments

For a smart home company with an emphasis on cloud-connected cameras, what could possibly be worse than accidentally showing active cameras to the wrong users? Doing it again, to far more users, less than 6 months after the previous incident.

The setup for this breach was an AWS problem, that caused a Wyze system outage last Friday morning. As the system was restored, the load spiked and a caching library took the brunt of the unintentional DDoS. This library apparently has a fail state of serving images and videos to the wrong users. An official report from Wyze mentions that this library had been recently added, and that the number of thumbnails shown to unauthorized users was around 13,000. Eek. There’s a reason we recommend picking one of the Open Source NVR systems here at Hackaday.

ScreenConnect Exploit in the Wild

A pair of vulnerabilities in ConnectWise ScreenConnect were announced this week, Proof of Concepts were released, and are already being used in active exploitation. The vulnerabilities are a CVSS 10.0 authentication bypass and a CVSS 8.4 path traversal bypass.

Huntress has a guide out, detailing how embarrassingly easy the vulnerabilities are to exploit. The authentication bypass is a result of a .Net quirk, that adding an additional directory on the end of a .aspx URL doesn’t actually change the destination, but is captured as PathInfo. This allows a bypass of the protections against re-running the initial setup wizard: hostname/SetupWizard.aspx/literallyanything

The second vulnerability triggers during extension unpack, as the unzipping process doesn’t prevent path traversal. The most interesting part is that the unzip happens before the extension installation finishes. So an attacker can compromise the box, cancel the install, and leave very little trace of exploitation. Continue reading “This Week In Security: Wyze, ScreenConnect, And Untrustworthy Job Postings” →

Your Noisy Fingerprints Vulnerable To New Side-Channel Attack

February 23, 2024 by 28 Comments

Here’s a warning we never thought we’d have to give: when you’re in an audio or video call on your phone, avoid the temptation to doomscroll or use an app that requires a lot of swiping. Doing so just might save you from getting your identity stolen through the most improbable vector imaginable — by listening to the sound your fingerprints make on the phone’s screen (PDF).

Now, we love a good side-channel attack as much as anyone, and we’ve covered a lot of them over the years. But things like exfiltrating data by blinking hard drive lights or turning GPUs into radio transmitters always seemed a little far-fetched to be the basis of a field-practical exploit. But PrintListener, as [Man Zhou] et al dub their experimental system, seems much more feasible, even if it requires a ton of complex math and some AI help. At the heart of the attack are the nearly imperceptible sounds caused by friction between a user’s fingerprints and the glass screen on the phone. These sounds are recorded along with whatever else is going on at the time, such as a video conference or an online gaming session. The recordings are preprocessed to remove background noise and subjected to spectral analysis, which is sensitive enough to detect the whorls, loops, and arches of the unsuspecting user’s finger.

Once fingerprint patterns have been extracted, they’re used to synthesize a set of five similar fingerprints using MasterPrint, a generative adversarial network (GAN). MasterPrint can generate fingerprints that can unlock phones all by itself, but seeding the process with patterns from a specific user increases the odds of success. The researchers claim they can defeat Automatic Fingerprint Identification System (AFIS) readers between 9% and 30% of the time using PrintListener — not fabulous performance, but still pretty scary given how new this is.

This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!

February 16, 2024 by 7 Comments

Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.

Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.

To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.

Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.

The real danger here is that we have another case where some hardware appliance manufacturer has used ClamAV for email filtering, and uses this configuration by default. That’s how we get orders from CISA to unplug your hardware, because it’s already compromised. Continue reading “This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!” →

Why Stealing A Car With Flipper Zero Is A Silly Idea

February 15, 2024 by 27 Comments

In another regular installment of politicians making ridiculous statements about technology, Canada’s Minister of Innovation, Science and Industry, [François-Philippe Champagne], suggested banning Flipper Zero and similar devices from sale in the country, while accusing them of being used for ‘stealing cars’ and similar. This didn’t sit right with [Peter Fairlie] who put together a comprehensive overview video of how car thieves really steal cars. Perhaps unsurprisingly, the main method is CAN bus injection, for which a Flipper Zero is actually a terribly clumsy device. Rather you’d use a custom piece of kit that automates the process.

You can also find these devices being sold all over the internet as so-called ‘Emergency Start’ devices for sale all over the internet, all of which use weaknesses in the car’s CAN bus network. The common problem appears to be that with these days even the lights on the car being part of the CAN network, an attacker can gain access for injection purposes. This way no key fob is needed, and the ignition system can be triggered with the usual safeties and lockouts being circumvented.

Ultimately, although the Flipper Zero is a rather cutesy toy, it doesn’t do anything that cannot be done cheaper and more effectively by anyone with a bit of CAN bus knowledge and a disregard for the law.

Thanks to [Stephen Walters] for the tip.

Continue reading “Why Stealing A Car With Flipper Zero Is A Silly Idea” →

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

February 9, 2024 by 8 Comments

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?” →

Beating Bitlocker In 43 Seconds

February 6, 2024 by 69 Comments

How long does it take to steal your Bitlocker keys? Try 43 seconds, using less than $10 in hardware. Encrypting your hard drive is good security. If you’re running Windows, the most popular system is BitLocker, which has come with Windows since Vista. We’ve known for some time that Bitlocker could be defeated with direct access to the hardware. Microsoft claims that the process requires an attacker with skill and lengthy access to the hardware. [Stacksmashing] wanted to define lengthy, so he gave it a try. The result is a shockingly fast attack.

Anyone who uses Windows has probably run into Bitlocker. Your hard drive is encrypted, and Bitlocker runs silently in the background, decrypting data on demand.  The problem is key storage. In a simplified sense, encryption keys are stored in the Trusted Platform Module (TPM). When your computer boots, it reads the key from the TPM over the LPC (low pin count) bus, which is one of the last remnants of the original ISA bus.

Continue reading “Beating Bitlocker In 43 Seconds” →

This Week In Security: Glibc, Ivanti, Jenkins, And Runc

February 2, 2024 by 4 Comments

There’s a fun buffer overflow problem in the Glibc __vsyslog_internal() function. This one’s a real rollercoaster, because logging vulnerabilities are always scary, but at a first look, it seems nearly impossible to exploit. The vulnerability relies on a very long program name, which can overflow an internal buffer. No binaries are going to have a name longer than 1024 bytes, so there’s no problem, right?

Let’s talk about argv. That’s the list of arguments that gets passed into the main() function of every Linux binary when it launches. The first string in that list is the binary name — except that’s a convention, and not particularly enforced anywhere. What really happens is that the execve() system call sets that list of strings. The first argument can be anything, making this an attacker-controlled value. And it doesn’t matter what the program is trying to write to the log, because the vulnerability triggers simply by writing the process name to a buffer.

There is a one-liner to test for a vulnerable Glibc:

exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null

and the Qualys write-up indicates that it can be used for an escalation of privilege attack. The good news is this seems to be a local-only attack. And on top of that, a pair of other lesser severity issues were found and fixed in glibc while fixing this one.
Continue reading “This Week In Security: Glibc, Ivanti, Jenkins, And Runc” →