This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride

There’s a fun logic flaw in how multiple online services handle OAuth logins, that abuses Microsoft’s Azure Active Directory service to allow account takeovers. The problem is how a site handles the “Sign In With Microsoft” option, when there’s an existing account under the same email address. This is an irritating problem for an end-user, when a site offers multiple sign-in options. Trying to remember which option was used to set up an account is a struggle, so many services automatically merge accounts.

The problem is that the Microsoft Azure authentication information includes an email address, but Microsoft hasn’t done any verification that the account in question actually controls that address. And in fact, it’s trivial for the Azure admin to change that address at whim. So if the service accepts that email address as authoritative, and auto-merges the accounts, it’s a trivial account takeover. And it’s more than just a theoretical problem, as researchers at descope were able to demonstrate the attack, and have found multiple medium and large services that were vulnerable, as well as at least two authentication providers that themselves were vulnerable to this attack.

Microsoft has pushed updates to the Azure AD service to make the issue easier to avoid, though it seems that the unverified “email” field is still being sent on authentication transactions. There is a new flag, “RemoveUnverifiedEmailClaim” that eliminates the issue, and is enabled by default for new applications. Unfortunately this means that existing vulnerable applications will continue to be vulnerable until fixed on the application side. Continue reading “This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride”

This Week In Security: USB Cable Kia, Reddit, And Microsoft RCEs

There is vulnerability in many Hyundai and Kia vehicles, where the ignition switch can be bypassed with a USB cable. And it’s getting a patch rollout right now, but it’s not a USB vulnerability, in quite the way you might think. In most cars, the steering column is easily disassembled, but these vehicles have an extra-bad design problem. The ignition cylinder can be disassembled while locked, just by depressing a pin.

Physical security has some parallels to computer security, and one such parallel is that good security can often be bypassed by a simple mistake. When it comes to lock design, one such potential bypass is the ability to disassemble a lock while it’s still locked. And somehow, Kias after 2010, and Hyundais after 2015 were made with exactly this flaw. The lock could be disassembled, and the interface between the lock and the ignition switch just happens to be the right shape and size for USB A. Oh, and these cars don’t have an engine immobilizer — there isn’t a chip built into the keys for extra security.

The problem became widespread late last year when the flaw went viral on TikTok, and thousands of copycat crimes were inspired. Beyond the obvious problem, that teenagers were getting an early start on a life of crime with grand theft auto, there were at least 8 deaths directly attributed to the inane stunt. And this brings us back to this week’s news, that a software update is rolling out to address the issue.

Honestly, I have questions. A software update doesn’t add in-key security chips. At best, it could attempt to detect the key position, and sabotage the engine management control, in an ad-hoc immobilizer. That’s likely a paper clip-turned-jumper away from being bypassed. The other new feature, doubling the alarm time from 30 second to a minute, doesn’t inspire much confidence. Hopefully the changes are enough to kill the trend. Continue reading “This Week In Security: USB Cable Kia, Reddit, And Microsoft RCEs”

This Week In Security: Scamming The FBI, In The Wild, And AI Security

If you’re part of a government alphabet agency, particularly running a program to share information to fight cybercrime, make sure to properly verify the identity of new members before admission. Oh, and make sure the API is rate-limited so a malicious member can’t scrape the entire user database and sell it on a dark web forum.

Putting snark aside, this is exactly what has happened to the FBI’s InfraGuard program. A clever user applied to the program using a CEO’s name and phone number, and a convincing-looking email address. The program administrators didn’t do much due diligence, and approved the application. Awkward.

BSD Ping

First off, the good folks at FreeBSD have published some errata about the ping problem we talked about last week. First off, note that while ping does elevate to root privileges via setuid, those privileges are dropped before any data handling occurs. And ping on FreeBSD runs inside a Capsicum sandbox, a huge obstacle to system compromise from within ping. And finally, further examination of the bug in a real-world context casts doubt on the idea that Remote Code Execution (RCE) is actually possible due to stack layouts.

If someone messes up somewhere, go look if you messed up in the same or similar way somewhere else.

Sage advice from [Florian Obser], OpenBSD developer. So seeing the ping problem in FreeBSD, he set about checking the OpenBSD ping implementation for identical or similar problems. The vulnerable code isn’t shared between the versions, so he reached for afl++, a fuzzing tool with an impressive list of finds. Connect afl++ to the function in ping that handles incoming data, and see what shakes out. The conclusion? No crashes found in this particular effort, but several hangs were identified and fixed. And that is a win. Continue reading “This Week In Security: Scamming The FBI, In The Wild, And AI Security”

This Week In Security: Huawei Gets The Banhammer, Lastpass, And Old Code Breaking

While many of us were enjoying some time off for Thanksgiving, the US government took drastic action against Huawei and four other Chinese companies. The hardest hit are Huawei and ZTE, as the ban prevents any new products from being approved for the US market. The other three companies are Dahua and Hikvision, which make video surveillance equipment, and Hytera, which makes radio systems. FCC Commissioner Brendan Carr noted the seriousness of the decision.

[As] a result of our order, no new Huawei or ZTE equipment can be approved. And no new Dahua, Hikvision, or Hytera gear can be approved unless they assure the FCC that their gear won’t be used for public safety, security of government facilities, & other national security purposes.

There is even the potential that previously approved equipment could have its authorization pulled. The raw FCC documents are available, if you really wish to wade through them. What’s notable is that two diametrically opposed US administrations have both pushed for this ban. It would surely be interesting to get a look at the classified reports detailing what was actually found. Maybe in another decade or two, we can make a Freedom of Information Act request and finally get the full story.

Continue reading “This Week In Security: Huawei Gets The Banhammer, Lastpass, And Old Code Breaking”

This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness

It’s debatable just how useful Secure Boot is for end users, but now there’s yet another issue with Secure Boot, or more specifically, a trio of signed bootloaders. Researchers at Eclypsium have identified problems in the Eurosoft, CryptoPro, and New Horizon bootloaders. In the first two cases, a way-too-flexible UEFI shell allows raw memory access. A startup script doesn’t have to be signed, and can easily manipulate the boot process at will. The last issue is in the New Horizon Datasys product, which disables any signature checking for the rest of the boot process — while still reporting that secure boot is enabled. It’s unclear if this requires a config option, or is just totally broken by default.

The real issue is that if malware or an attacker can get write access to the EFI partition, one of these signed bootloaders can be added to the boot chain, along with some nasty payload, and the OS that eventually gets booted still sees Secure Boot enabled. It’s the perfect vehicle for really stealthy infections, similar to CosmicStrand, the malicious firmware we covered a few weeks ago.
Continue reading “This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness”

Ubuntu 22.04 setup screen shown on the Google's Nest Hub display

Breaking Google Nest Hub’s Secure Boot

[frederic] tells a story about their team’s hack of a Google Nest Hub (2nd generation) — running Ubuntu on it, through bypassing Google’s boot image signature checks. As with many good hacks, it starts with FCC website pictures. Reverse-engineering a charger and USB daughterboard pin-out, they found a UART connection and broke it out with a custom adapter. With a debug console and insights into the process, they went on hacking, slicing through hardware and software until it was done with.

This story gives plenty of background and insight into both the code that was being investigated, and the way that attack targets were chosen. Through fuzzing, they found a buffer overflow in the bootloader code that could be triggered with help of a non-standard block size. USB flash drives tend to have these hard-coded, so they built a special firmware for a Pi Pico and shortly thereafter, achieved code execution. Then, they hooked into uboot functions and loaded Ubuntu, bypassing the boot image signature checks.

This is a wonderful documentation of a hacking journey, and an exciting read to boot (pun intended). The bug seems to have been patched for half a year now, so you probably can’t flash your Google Nest into Ubuntu anymore. However, you might be able to run an up-to-date Linux on your Amazon Echo.

We thank [Sven] for sharing this with us!

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”