This Week In Security: MOAB, Microsoft, And Printers

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

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

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

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

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

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.

Two pictures of the mobo side by side, both with kapton tape covering everything other than the flash chip. On the left, the flash chip is populated, whereas on the right it's not

Enabling Intel AMT For BIOS-over-WiFi

Intel ME, AMT, SMT, V-Pro… All of these acronyms are kind of intimidating, all we know about them is that they are tied to remote control technologies rooted deep in Intel CPUs, way deeper than even operating systems go. Sometimes though, you want remote control for your own purposes, and that’s what [ABy] achieved. He’s got a HP ProDesk 600 G3 Mini, decided to put it into a hard to reach spot in his flat, somewhere you couldn’t easily fetch a monitor and a keyboard for any debugging needs. So, he started looking into some sort of remote access option in case he’d need to access the BIOS remotely, and went as far as it took to make it work. (Google Translate)

The features he needed are covered by Intel AMT — specifically, BIOS access over a WiFi connection. However, his mini PC only had SMT enabled from the factory, the cut-down version of AMT without features like wireless support. He figured out that BIOS dumping was the way, promptly did just that, found a suitable set of tools for his ME region version, and enabled AMT using Intel’s FIT (Flash Image Tool) software.

Now, dumping the image could be done from a running system fully through software, but apparently, flashing back requires an external programmer. He went with the classic CH341, did the 3.3 V voltmod that’s required to make it safe for flash chip use, and proceeded to spend a good amount of time making it work. Something about the process was screwy, likely the proprietary CH341 software. Comments under the article highlight that you should use flashrom for these tasks, and indeed, you should.

This article goes into a ton of detail when it comes to working with Intel BIOS images — whichever kind of setting you want to change, be it AMT support or some entirely different but just as tasty setting, you will be well served by this write-up. Comments do point out that you might want to upgrade the Intel ME version while at it, and for what it’s worth, you can look into disabling it too; we’ve shown you a multitude of reasons why you should, and a good few ways you could.