Author: Jonathan Bennett

523 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” →

FLOSS Weekly Episode 771: Kalpa — Because Nobody Knows What Hysteresis Is

February 21, 2024 by 6 Comments

This week, Jonathan Bennett and Dan Lynch talk with Shawn W Dunn about openSUSE Kalpa, the atomic version of openSUSE Tumbleweed, with a KDE twist. What exactly do we mean by an Atomic desktop? Is ALP going to replace openSUSE Tumbleweed? Are snaps coming to Kalpa?

Shawn gives us the rundown of all the above, and what’s holding back a stable release of Kalpa, what’s up with Project Greybeard, and why Kalpa really doesn’t need a firewall.

Continue reading “FLOSS Weekly Episode 771: Kalpa — Because Nobody Knows What Hysteresis Is” →

Making The Commodore SX-64 Mini

February 19, 2024 by 12 Comments

When you find a portable TV from the 1980s, and it reminds you of the portable Commodore 64, there’s only one thing to be done. [Aaron Newcomb] brings us the story of taking an Emerson PC-6 and mating it to the guts of his THEC64 Mini. It’s a bit of a journey, as the process includes modding the TV to include a composite input and trimming some unused PCB off the TV’s mainboard. Then some USB ports and a three-and-a-half inch floppy drive were shoehorned into the chassis, with the rear battery compartment holding the parts from THEC64 Mini.

The build was not entirely without issue. It turns out the degaussing coil connector can plug perfectly into the service port, and Murphy’s law proved itself true again. But no harm was done, and the error was quickly discovered. All that was left was to button the chassis back up and add some paint and 3d-printed trim details. The build looks great! Come back after the break to watch the video from the [Retro Hack Shack] for yourself.

Continue reading “Making The Commodore SX-64 Mini” →

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!” →

FLOSS Weekly Episode 770: 10% More Internet

February 14, 2024 by 7 Comments

This week, Jonathan Bennett and Doc Searls talk with David Taht about the state of the Internet and, specifically, IPv4 exhaustion. We’re running out of IPv4 addresses! But we’ve been running out for something like ten years now. What gives? And why are nearly 20% of the world’s IPv4 addresses sitting unused? David has a hack that would give the world 10% more Internet, but Amazon might have something to say about it.

There’s even more, like Kessler Syndrome, some musing on what the Interplanetary Internet will look like, the worth of real paper books, and a long-term bet for some IPv4 addresses to come to fruition in 2038.

Continue reading “FLOSS Weekly Episode 770: 10% More Internet” →

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?” →

FLOSS Weekly Episode 769: OpenCost — We Spent How Much?

February 7, 2024 by 2 Comments

This week Jonathan Bennett and Katherine Druckman talk with Matt Ray about OpenCost. What exactly is Cloud Native? Why do we need a project just for tracking expenses? Doesn’t the cloud make everything cheaper? Is there a use case for the hobbyist?

The cloud is just a fancy way to talk about someone else’s servers — and what may surprise you is that they charge you money for the privilege of using those computers. But how much? And when you have multiple projects, which ones cost how much? That’s where OpenCost comes in. Not only does it help you track down costs in your cloud usage, it can also catch problems like compromised infrastructure sooner. Mining bitcoin in your Kubernetes Cluster makes a really noticeable spike in processor usage after all.
Continue reading “FLOSS Weekly Episode 769: OpenCost — We Spent How Much?” →