This Week in Security: Ransomware Decryption, OpenSSL, and USBGadget Spoofing

We’ve covered a lot of ransomware here, but we haven’t spent a lot of time looking at the decryptor tools available to victims. When ransomware gangs give up, or change names, some of them release a decryption tool for victims who haven’t paid. It’s not really a good idea to run one of those decryptors, though. The publishers don’t have a great track record for taking care of your data, after all. When a decryptor does get released, and is verified to work, security researchers will reverse engineer the tool, and release a known-good decryption program.

The good folks at No More Ransom are leading the charge, building such tools, and hosting a collection of them. They also offer Crypto Sheriff, a tool to identify which ransomware strain got your files. Upload a couple encrypted files, and it will inform you exactly what you’re dealing with, and whether there is a decryptor available. The site is a cooperation between the Dutch police, Interpol, Kaspersky, and McAfee. It may surprise you to know that they recommend reporting every ransomware case to the authorities. I can confirm that at the very least, the FBI in the US are very interested in keeping track of the various ransomware attacks — I’ve fielded a surprise call from an agent following up on an infection.

OpenSSL

The OpenSSL project has fixed a pair of vulnerabilities, CVE-2021-3711 and CVE-2021-3712 with release 1.1.11l. The first is a possible buffer overflow caused by a naive length calculation function. A “fixed” length header is actually dynamic, so a carefully crafted plaintext can overflow the allocated buffer.

The second vulnerability is less severe, but more interesting. It’s a mismatch between the formal specification of the ASN1_STRING structure, and how that struct is used in practice, in OpenSSL. The structure contains, among other things, a byte array and a length. The question is whether that array is null terminated. In essentially all of the OpenSSL code, this is treated like a standard C string, but nowhere does the documentation enforce the null terminator. The real problem comes when a program uses the OpenSSL library, and constructs an ASN string locally. Strictly following the documentation would lead to an unterminated array. When OpenSSL acts on that value, it prints out that information to the log using printf() and the %s placeholder, which keeps printing characters til the next null character is hit. This can disclose all sorts of unintended information.

Atlassion’s Confluence Vulnerable

Confluence is a knowledge management platform, essentially a fancy wiki for businesses. They just patched a vulnerability that is present in the last four major release versions. CVE-2021-26084 is a OGNL injection problem with a severity of 9.8. An attacker can abuse the bug to execute code on the underlying server, in some cases even unauthenticated.

OGNL is the Object-Graph Navigation Language, and is described as an expression language for Java. The injection problem is quite similar to a SQL injection attack, where user supplied data can contain expressions. OGNL injection often looks like ${(#rt = @java.lang.Runtime@getRuntime(),#rt.exec("calc.exe"))}.

Clever Girl^H^H^H^HHacker

Remember the trivial privilege escalation to SYSTEM when plugging in a Razer mouse? The hardest part of that attack was that you had to physically bring the Razer or SteelSeries device to the computer you want to compromise. Well no longer. If you have root on your Android phone, you can now use usbgadget-tool to spoof the right kind of hardware. The drivers used by these two specific devices will likely be fixed very soon, but there’s sure to be quite a few similar cases, rife for abuse.

This is a particularly simple exploit to pull off, and you may be tempted to actually use it on a work computer, or a similar situation. This is your periodic reminder that plugging in a Razer mouse is a crime — if you do it to gain SYSTEM on a machine without permission. In the immortal words of Bosnian Bill, “stay safe, and stay legal.”

Honda’s Hackable Key Fobs

Rolling key codes have been in use since 1995. An incrementing counter is used as part of an encryption key, and is kept synced between a vehicle and keyfob. This arrangement makes replay attacks much harder, as it allows the vehicle to ignore messages signed with a previously used counter value. There have been some very clever attacks devised against this system, like capturing a message while simultaneously jamming it so the vehicle doesn’t receive it. This isn’t one of those clever hacks. This really looks like a broken system deployed in the wild.

[Blake Berry] was working on a simple script to highlight different bits in two strings, and tested it on a pair of keyfob captures sent to a Honda vehicle. The two strings were disconcertingly similar. After further work, it was discovered that a captured lock command could be replayed with a few specific bits flipped, and the vehicle would unlock. The attack has been confirmed on a vehicle as old as 2009, as well as a 2020 model. It seems that Honda/Acura simply does not do any effective cryptography in their keyfob system at all. This issue has been assigned CVE-2019-20626, which makes the presence of the flaw in the 2020 model particularly revealing.

(Editor’s note: We were initially skeptical about this, because it’s just too obvious, and we’ll note here that the CVE is “undergoing reanalysis” at the present. If we had a Honda, we’d test it out before lunch. Could you? Let us know.)

Subdomain Takeover Via DNS

Subdomain takeover is when an authorized party can run arbitrary services at the IP referred to by a subdomain. There have been a few ways to pull this off, like deleting a GitHub Pages site, but leaving the DNS running. Someone else can come along and claim the same name, and then host their own content on that subdomain. There’s another way to pull this off, via hosted DNS, and there’s a new tool to find vulnerable domains. DNSTake lets you specify a domain, and it will walk up the DNS chain to find the nameservers, looking for odd DNS status responses.

The goal is to find a domain that uses a hosted DNS provider, where the domain has been deleted in that provider’s interface, but the NS records still exist. For many such providers, anyone can go add a DNS record for the unclaimed domain. There’s quite a range of mischief possible once an attacker has control over a subdomain.