Archives

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

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

February 16, 2024 by 6 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!” →

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

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

This Week In Security: MOAB, Microsoft, And Printers

January 26, 2024 by 15 Comments

This week, news has broken of the Mother of All Breaches, MOAB. It’s 12 terabytes and 26 billion records, averaging about 500 bytes each. Now note that a record here is likely not a discrete email address, but simply a piece of data — a row on the database.

Now before we all lose our minds over this, there’s an important detail to take note of: These aren’t new leaks. This is a compilation of leaks, and as far as researchers have checked, there aren’t any new leaks disclosed here. This was someone’s database of accumulated leak data, accidentally re-leaked via an unsecured database. [Troy Hunt] goes so far as to speculate that it could be from a breach search service, which sounds pretty plausible.

There was yet another release of credentials late last week that hasn’t attracted as much attention, but seems to represent a much bigger issue. The Naz.api data set isn’t a breach where a company was hacked, and their entire user database was stolen. Instead, this one is combination of a credential stuffing list and stealer logs.

Credential stuffing is basically a smarter brute force attack, where the credentials from one breach are tried on multiple other sites. Such a list is just the results where guesses were successful. The really interesting bit is that this dataset seems to include stealer logs. Put simply, that’s the results of malware that scrapes victim machines for credentials.

Naz.api has over 70 million unique email addresses, and it looks like about a third of them are new, at least according to the Haveibeenpwned dataset. Now that’s significant, though not really worthy of the MOAB title, either. Continue reading “This Week In Security: MOAB, Microsoft, And Printers” →

This Week In Security: Gitlab, VMware, And PixeFAIL

January 19, 2024 by 3 Comments

There’s a Gitlab vulnerability that you should probably pay attention to. Tracked as CVE-2023-7028, this issue allows an attacker to specify a secondary email during a the password reset request. Only one email has to match the one on record, but the password reset link gets sent to both emails. Yikes!

What makes this worse is there is already a Proof of Concept (PoC) released, and it’s a trivial flaw. In an HTTP/S post containing the password reset request, just include two email addresses. Thankfully, a fix is already out. Versions 16.7.2, 16.6.4, and 16.5.6 contain this patch, as well as fixes for a flaw that allowed sneaking unauthorized changes into a previously approved merge request, and an issue with Slack and Mattermost where slash commands could be spoofed.

VMware

We don’t want to over-dramatise this vulnerability, but VMware is calling it an emergency. This one affects VMware vRealize and Aria Automation. According to the the CVSS calculator, it’s a low complexity network flaw, but does require at least some privileges. Hopefully more information will come out about this vulnerability, but for now that’s about all we know.

Continue reading “This Week In Security: Gitlab, VMware, And PixeFAIL” →

This Week In Security: AI Is Terrible, Ransomware Wrenches, And Airdrop

January 12, 2024 by 8 Comments

So first off, go take a look at this curl bug report. It’s a 8.6 severity security problem, a buffer overflow in websockets. Potentially a really bad one. But, it’s bogus. Yes, a strcpy call can be dangerous, if there aren’t proper length checks. This code has pretty robust length checks. There just doesn’t seem to be a vulnerability here.

OK, so let’s jump to the punch line. This is a bug report that was generated with one of the Large Language Models (LLMs) like Google Bard or ChatGPT. And it shouldn’t be a surprise. There are some big bug bounties that are paid out, so naturally people are trying to leverage AI to score those bounties. But as [Daniel Stenberg] point out, LLMs are not actually AI, and the I in LLM stands for intelligence.

There have always been vulnerability reports of dubious quality, sent by people that either don’t understand how vulnerability research works, or are willing to waste maintainer time by sending in raw vulnerability scanner output without putting in any real effort. What LLMs do is provide an illusion of competence that takes longer for a maintainer to wade through before realizing that the claim is bogus. [Daniel] is more charitable than I might be, suggesting that LLMs may help with communicating real issues through language barriers. But still, this suggests that the long term solution may be “simply” detecting LLM-generated reports, and marking them as spam. Continue reading “This Week In Security: AI Is Terrible, Ransomware Wrenches, And Airdrop” →