Security Hacks

1388 Articles

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

Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers

January 15, 2024 by 16 Comments

Espressif’s ESP32 microcontrollers come with a Flash encryption feature that when enabled ensures that the data and code stored on the (usually external) Flash chip is encrypted with AES-256 (ESP32) or better (ESP32-C3, -C6). For the ESP32 this encryption feature has been shown to be vulnerable to side channel attacks (SCA), leading [courk] to not only replicate this result with a custom ESP Correlation Power Analysis (CPA) board (pictured) that captures power usage of the MCU, but also to try his luck with the ESP32-C3 and ESP32-C6 parts that should be tougher nuts to crack.

Whereas the ESP32 uses a fairly straightforward AES-256 encryption routine that together with the exposed Flash communication lines on the QSPI bus make for a textbook SCA example, the ESP32-C3 ups the encryption to XTS-AES, which uses two 128-bit keys on the -C3 part (XTS-256). This particular MCU is still susceptible to the same SCA attack with CPA, making it somewhat harder to attack than the ESP32, but by no means impossible.

Continue reading “Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers” →

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

This Week In Security: Bitwarden, Reverse RDP, And Snake

January 5, 2024 by 10 Comments

This week, we finally get the inside scoops on some old stories, starting with the Bitwarden Windows Hello problem from last year. You may remember, Bitwarden has an option to use Windows Hello as a vault unlock option. Unfortunately, the Windows credential API doesn’t actually encrypt credentials in a way that requires an additional Windows Hello verification to unlock. So a derived key gets stored to the credential manager, and can be retrieved through a simple API call. No additional biometrics needed. Even with the Bitwarden vault locked and application closed.

There’s another danger, that doesn’t even require access to the the logged-in machine. On a machine that is joined to a domain, Windows backs up those encryption keys to the Domain Controller. The encrypted vault itself is available on a domain machine over SMB by default. A compromised domain controller could snag a bitwarden vault without ever even running code on the target machine. The good news is that this particular problem with Bitwarden and Windows Hello is now fixed, and has been since version 2023.10.1.

Reverse RDP Exploitation

We normally think about the Remote Desktop Protocol as dangerous to expose to the internet. And it is. Don’t put your RDP service online. But reverse RDP is the idea that it might also be dangerous to connect an RDP client to a malicious server. And of course, multiple RDP implementations have this problem. There’s rdesktop, FreeRDP, and Microsoft’s own mstsc that all have vulnerabilities relating to reverse RDP.

The technical details here aren’t terribly interesting. It’s all variations on the theme of not properly checking remote data from the server, and hence either reading or writing past internal buffers. This results in various forms of information leaks and code executions problems. What’s interesting is the different responses to the findings, and then [Eyal Itkin]’s takeaway about how security researchers should approach vulnerability disclosure.

So first up, Microsoft dismissed a vulnerability as unworthy of servicing. And then proceeded to research it internally, and present it as a novel attack without properly attributing [Eyal] for the original find. rdesktop contained quite a few of these issues, but were able to fix the problem in a handful of months. FreeRDP fixed some issues right away, in what could be described as a whack-a-mole style process, but a patch was cooked up that would actually address the problem at a deeper level: changing an API value from the unsigned size_t to a signed ssize_t. That change took a whopping 2 years to actually make it out to the world in a release. Why so long? Continue reading “This Week In Security: Bitwarden, Reverse RDP, And Snake” →

Getting Root Access On A Tesla

January 5, 2024 by 36 Comments

A growing number of manufacturers are locking perfectly good hardware behind arbitrary software restrictions. While this ought to be a bigger controversy, people seem to keep paying for things like printers with ink subscriptions, cameras with features disabled in firmware, or routers with speed restrictions, ensuring that this practice continues. Perhaps the most blatant is car manufacturers that lock features such as heated seats or even performance upgrades in the hopes of securing a higher price for their vehicles. This might be a thing of the past for Teslas, whose software has been recently unlocked by Berlin IT researchers.

Researchers from Technische Universität Berlin were able to unlock Tesla’s driving assistant by inducing a two-microsecond voltage drop on the processor which allowed root access to the Autopilot software. Referring to this as “Elon mode” since it drops the requirement for the driver to keep their hands on the steering wheel, they were able to access the full self-driving mode allowing autonomous driving without driver input. Although this might be a bad idea based on the performance of “full self-driving” in the real world, the hack at least demonstrates a functional attack point and similar methods could provide free access to other premium features.

While the attack requires physical access to the vehicle’s computer and a well-equipped workbench, in the short term this method might allow for owners of vehicles to use hardware they own however they would like, and in the long term perhaps may make strides towards convincing manufacturers that “features as a service” isn’t a profitable strategy. Perhaps that’s optimistic, but at least for Teslas it’s been shown that they’re not exactly the most secured system on four wheels.