This Week In Security: GoDaddy, Joomla, And ClamAV

We’ve seen some rough security fails over the years, and GoDaddy’s recent news about a breach leading to rogue website redirects might make the highlight reel. The real juicy part is buried on page 30 of a PDF filing to the SEC.

Based on our investigation, we believe these incidents are part of a multi-year campaign by a sophisticated threat actor group that, among other things, installed malware on our systems and obtained pieces of code related to some services within GoDaddy.

That multi-year campaign appears to goes back to at least October 2019, when an SSH file was accessed and altered, leading to 28,000 customer SSH usernames and passwords being exposed. There was also a 2021 breach of the GoDaddy WordPress environment, that has been linked to the same group.

Reading between the lines, there may be an implication here that the attackers had an ongoing presence in GoDaddy’s internal network for that entire multi-year period — note that the quote above refers to a single campaign, and not multiple campaigns from the same actor. That would be decidedly bad.

Joomla’s Force Persuasion

Joomla has a critical vulnerability, CVE-2023-23752, which is a trivial information leak from a web endpoint. This flaw is present in all of the 4.x releases, up to 4.2.8, which contains the fix. The issue is the Rest API, which gives access to pretty much everything about a given site. It has an authentication component, of course. The bypass is to simply append ?public=true. Yes, it’s a good old “You don’t need to see his identification” force suggestion.

There’s even a PoC script that runs the request and spits out the most interesting data: the username, password, and user id contained in the data. It’s not quite as disastrous as that sounds — the API isn’t actually leaking the administrative username and password, or even password hash. It’s leaking the SQL database information. Though if your database is accessible from the Internet, then that’s pretty much as bad as it could be. Continue reading “This Week In Security: GoDaddy, Joomla, And ClamAV”

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: ImageMagick, VBulletin, And Dota 2

There are a few binaries that wind up running in a bunch of places, silently do their jobs, and being easily forgotten about. ImageMagick is used on many servers for image conversion and resizing, and tends to run automatically on uploaded images. Easily forgotten, runs automatically, and with arbitrary inputs. Yep, perfect target for vulnerability hunting. And the good folks at Metabase found two of them.

First up is CVE-2022-44267, a Denial of Service, when ImageMagick tries to process a rigged PNG that contains a textual chunk. This data type is usually used for metadata, and can include a profile entry for something like EXIF data. If this tag is specified inside a text chunk, ImageMagick looks to the given value as a filename for finding that profile data. And notably, if that value is a dash -, it tries to read from standard input. If the server’s image processing flow doesn’t account for that quirk, and virtually none of them likely do, this means the ImageMagick process hangs forever, waiting for the end of input. So while that’s not usually a critical problem, it could be used for a resource exhaustion attack.

But the real problem is CVE-2022-44268. It’s the same trick, but instead of using - to indicate standard input, the processed image refers to a file on the server filesystem. If the file exists, and can be read, the contents are included in the image output. If the attacker has access to the image, it’s a slick data leak — and obviously a real security problem. If a server doesn’t have tight file permissions and isolation, there’s plenty of sensitive information to be found and abused.

The fix landed back in October 2022, and was part of the 7.1.0-52 release. There’s a bit of uncertainty about which versions are vulnerable, but I wouldn’t trust anything older than that version. It’s a pretty straightforward flaw to understand and exploit, so there’s a decent chance somebody figured it out before now. The file exfiltration attack is the one to watch out for. It looks like there’s an Indicator of Compromise (IoC) for those output PNGs: “Raw profile type”. Continue reading “This Week In Security: ImageMagick, VBulletin, And Dota 2”

This Week In Security: Github, Google, And Realtek

GitHub Desktop may have stopped working for you yesterday, Febuary 2nd. The reason was an unauthorized access to some decidedly non-public repositories. The most serious bit of information that escaped was code signing certificates, notably used for GitHub Desktop and Atom. Those certificates were password protected, so it’s unlikely they’ve been abused yet. Even so, Github is taking the proper steps of revoking those certificates.

The only active certificate that was revoked was used for signing the Mac releases of GitHub Desktop, so quite a few older versions of that software is no longer easily installed. If nothing else, it’s a reminder that even a project with a well run security team can have problems.

Sh1mmer-ing Chromebooks

There’s a new, clever attack on the Chromebook, specifically with the goal of unenrolling the device from an educational organization. And the “vulnerability” is a documented feature, the RMA Shim. That’s a special boot loader target that contains a valid signature, but allows the booting of other code, intended for troubleshooting and fixing devices in a repair center. Quite a few of those images have leaked, and Sh1mmer combines the appropriate image with a boot menu with some interesting options.

The first is unenrolling, so the device will act like a privately owned computer. This gets rid of content blocks and allows removing extensions. But wait, there’s more. Like rooting the device, a raw Bash terminal, and re-enabling developer mode. Now, as far as we can tell, this doesn’t *directly* break device encryption, but it’s likely that the RMA shim could be abused to tamper with the device’s filesystem. Meaning that the leak of a bunch of signed shims is a big problem for device security. If you use a Chromebook, it might be time to do some research on whether that model’s shim has been leaked. Continue reading “This Week In Security: Github, Google, And Realtek”

This Week In Security: GTA, Apple And Android, And Insecure Boot

When we first saw tweets about a security issue in Grand Theft Auto V, it sounded a bit like a troll. “Press ‘alt and f4’ to unlock a cheat mode”, or the hacker that claims to be able to delete your character. [Tez2]’s warning tweet that you shouldn’t play GTA Online without a firewall sounds like another of these online urban legends. But this one actually seems legit. NIST is even in on the fun, assigning CVE-2023-24059 for the exploit.

When playing an online game, other users send a “join request” to join the active session. This packets can contain malformed data which has been observed to crash the game client remotely. It’s believed, though not publicly confirmed, that it’s also a Remote Code Execution (RCE) vulnerability. It seems likely that this aspect will be added to some of the various cheat panels that are already widely used for this 10-year-old game. So now, rather than just giving your own character infinite ammo and health, you can inflict some havoc on other players, possibly up to corrupting their character files and getting them banned.

But why stop there? If we have code execution inside the game, what stops another player from launching a real attack? A video game isn’t sandboxed like a browser, and there’s nothing preventing a disk wiper attack or even a worm from compromising a bunch of players. The worst part is that it’s an old game, and even though there’s a large playerbase, it’s not guaranteed to get a fix. There’s at least one project aiming to be a firewall to prevent the issue. Continue reading “This Week In Security: GTA, Apple And Android, And Insecure Boot”

This Week In Security: Git Deep Dive, Mailchimp, And SPF

First up, git has been audited. This was an effort sponsored by the Open Source Technology Improvement Fund (OSTIF), a non-profit working to improve the security of Open Source projects. The audit itself was done by researchers from X41 and GitLab, and two critical vulnerabilities were found, both caused by the same bad coding habit — using an int to hold buffer lengths.

On modern systems, a size_t is always unsigned, and the same bit length as the architecture bit-width. This is the proper data type for string and buffer lengths, as it is guaranteed not to overflow when handling lengths up to the maximum addressable memory on the system. On the other hand, an int is usually four bytes long and signed, with a maximum value of 2^31-1, or 2147483647 — about 2 GB. A big buffer, but not an unheard amount of data. Throw something that large at git, and it will break in unexpected ways.

Our first example is CVE-2022-23521, an out of bounds write caused by an int overflowing to negative. A .gitattributes file can be committed to a repository with a modified git client, and then checking out that repository will cause the num_attrs variable to overflow. Push the overflow all the way around to a small negative number, and git will then vastly under-allocate the attributes buffer, and write all that data past the end of the allocated buffer.

CVE-2022-41903 is another signed integer overflow, this time when a pretty print format gets abused to do something unexpected. Take a look at this block of code:

Continue reading “This Week In Security: Git Deep Dive, Mailchimp, And SPF”

This Week In Security: Cacti RCE, VMs In The Browser, And SugarCRM

This week we start with a Remote Code Execution (RCE) vulnerability that has potential to be a real pain for sysadmins. Cacti, the system monitoring and graphing solution, has a pair of bugs that chain together to allow an attacker with unauthenticated access to the HTTP/S port to trivially execute bash commands. The first half of this attack is an authentication bypass, and it’s embarrassingly trivial. The Cacti authentication code trusts the Forwarded-For: header in the request. Set it to the server’s IP, and the authentication code treats it like a localhost request, bypassing any real authentication process.

The second half is found in the remote_agent.php endpoint, where the poller_id is set by the user and treated as a string. Then, if the right host_id and local_data_id item is triggered, that string is concatenated into a proc_open() function call. The string isn’t sanitized, so it’s trivial enough to include a second command to run, dropping a webshell, for instance.

Version 1.2.23 of Cacti contains the fix, and released on the 2nd. This one is likely to be exploited, and if automated exploitation hasn’t started already, it likely will soon. So if you have a Cacti install, go double-check that the interface isn’t exposed to the world.

JSON Web Token

Researchers at Unit 42 found an exploit that can be used to achieve an RCE in the JsonWebToken project. The issue is this library’s verify() function, which takes arguments of the token to check, the key to use, and options. If there aren’t any algorithms specified in the options object, then the key is processed as a PEM string. The toString() method of that key is called during the actual check, and the assumption is that it’s either a string or buffer. But what if the key passed in to the verify() function was actually a complex object, bringing it’s own toString() method along to play. At that point, we have arbitrary code execution. And if this code is running on the server-side under node.js, that means a popped server.

But wait, it’s not that simple, right? It’s not like a valid JWT can contain an arbitrary object — that would be a problem all on its own. So CVE-2022-23529 is a stepping-stone. It’s insecure code, but the rest of the application has to have another vulnerability for this one to be reachable. Continue reading “This Week In Security: Cacti RCE, VMs In The Browser, And SugarCRM”