This Week In Security: WebP, Cavium, Gitlab, And Asahi Lina

September 22, 2023 by 15 Comments

Last week we covered the latest 0-day from NSO group, BLASTPASS. There’s more details about exactly how that works, and a bit of a worrying revelation for Android users. One of the vulnerabilities used was CVE-2023-41064, a buffer overflow in the ImageIO library. The details have not been confirmed, but the timing suggests that this is the same bug as CVE-2023-4863, a Webp 0-day flaw in Chrome that is known to be exploited in the wild.

The problem seems to be an Out Of Bounds write in the BuildHuffmanTable() function of libwebp. And to understand that, we have to understand libwebp does, and what a Huffman Table has to do with it. The first is easy. Webp is Google’s pet image format, potentially replacing JPEG, PNG, and GIF. It supports lossy and lossless compression, and the compression format for lossless images uses Huffman coding among other techniques. And hence, we have a Huffman table, a building block in the image compression and decompression.

What’s particularly fun about this compression technique is that the image includes not just Huffman compressed data, but also a table of statistical data needed for decompression. The table is rather large, so it gets Huffman compressed too. It turns out, there can be multiple layers of this compression format, which makes the vulnerability particularly challenging to reverse-engineer. The vulnerability is when the pre-allocated buffer isn’t big enough to hold one of these decompressed Huffman tables, and it turns out that the way to do that is to make maximum-size tables for the outer layers, and then malform the last one. In this configuration, it can write out of bounds before the final consistency check.

An interesting note is that as one of Google’s C libraries, this is an extensively fuzzed codebase. While fuzzing and code coverage are both great, neither is guaranteed to find vulnerabilities, particularly well hidden ones like this one. And on that note, this vulnerability is present in Android, and the fix is likely going to wait til the October security update. And who knows where else this bug is lurking. Continue reading “This Week In Security: WebP, Cavium, Gitlab, And Asahi Lina” →

Diving Into Starlink’s User Terminal Firmware

August 31, 2023 by 6 Comments

The average Starlink user probably doesn’t spend a lot of time thinking about their hardware after getting the dish aligned and wiring run. To security researchers, however, it’s another fascinating device to tinker with as they reverse-engineer the firmware and try to both find out what makes it tick, as well as how to break it. This is essentially the subject of [Carlo Ramponi]’s article over at Quarkslab as he digs into the firmware architecture and potential weaknesses in its internal communication.

The user terminal hardware itself is a quite standard AArch64 ARM-based SoC, along with the proprietary communication interface, all of which is controlled by the Linux-based firmware. Dumping the firmware itself was made easy thanks to existing work by researchers at the KU Leuven, involving dumping the contents of the onboard eMMC storage. After this the firmware architecture could be analyzed, which turned out to consist out of mostly C++-based binaries, but with a single big binary for the user front-end written in Go.

Communication between these processes is handled through a custom inter-process protocol called ‘Slate Sharing’, all of which is coordinated via the core User Terminal Control process. It are these Slate IPC messages which form the most likely attack surface for a fuzzing attack, with the SoftwareUpdateRequest command being an interesting target as it would seem to not require authentication since it doesn’t address a specific user. This work is part of [Carlo]’s master’s thesis, and should form the basis of further research on the Starlink User Terminal firmware.

This Week In Security: Dating App, WooCommerce, And OpenSSH

July 21, 2023 by 4 Comments

Up first this week is a report from vpnMentor, covering the unsecured database backing a set of dating apps, including 419 Dating. The report is a bit light on the technical details, like what sort of database this was, or how exactly it was accessed. But the result is 2.3 million exposed records, containing email address, photos — sometimes explicit, and more. Apparently also exposed were server backups and logs.

The good news here is that once [Jeremiah Fowler] discovered the database door unlocked and hanging open, he made a disclosure, and the database was secured. We can only hope that it wasn’t discovered by any bad actors in the meantime. The app has now disappeared from the Google Play store, and had just a bit of a sketchy air about it.

WooCommerce Under Siege

Back in March, CVE-2023-28121 was fixed in the WooCommerce plugin for WordPress. The issue here is an authentication bypass that allows an unauthenticated user to commandeer other user accounts.

Within a few months, working exploits had been derived from the details of the patch plugging the hole. It wasn’t hard. A function for determining the current user was explicitly trusting the contents of the X-WCPAY-PLATFORM-CHECKOUT-USER request header. Set that value in a request sent to the server, and ding, you’re administrator.

And now the cows are coming home to roost. Active exploitation started in earnest on July 14, and the folks at Wordfence clocked a staggering 1.3 million exploitation attempts on the 16th. What’s particularly interesting is that the Wordfence data gathering system saw a huge increase in requests for the readme.txt file that indicates the presence of the WooCommerce plugin on a WordPress site. These requests were observed before the attacks got started, making for an interesting early warning system. Continue reading “This Week In Security: Dating App, WooCommerce, And OpenSSH” →

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

June 23, 2023 by 4 Comments

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

February 17, 2023 by 14 Comments

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

December 16, 2022 by 16 Comments

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

December 2, 2022 by 37 Comments

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