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.

8 thoughts on “This Week In Security: Ransomware Decryption, OpenSSL, And USBGadget Spoofing

  1. ” …can confirm that at the very least, the FBI in the US are very interested in keeping track of the various ransomware attacks”

    Can you write about your direct experiences with FBI people? Did you consider them competent? Did they outsource the computer security stuff or was it done in house?

    1. One of my local clients got hit with ransomware a few months back. Thanks to a good backup system, we had everything back in just a couple hours. The client wanted to report it, so made a call to the closest FBI branch. I really didn’t think much would come of it, but I was surprised to get a call from an agent a few days later.

      Agent wanted the story of what happened, how they got in, a screenshot of the ransom note, and the exact strain of ransomware. I asked why, and he explained that they wanted documentation on as many attacks as possible, so when they finally catch a crook, they have a case.

      I didn’t see him work any magic, but he really seemed to track the details about the attack, as I explained what happened.

        1. For scam calls on the land-line phone, I just have an extension configured in Asterisk that plays a section of Deborah Harry’s Hangin’ on the telephone on continuous loop…

          Scammer calls: “Hello, I’m $name from the NBN, we’ve been trying to contact you and are about to disconnect your Internet connection”
          Me: “Sure, please hold” → presses Blind Transfer on IP phone, dial 666, hang-up.

      1. Seems like you really need to document everything when it happens… and not wait as a former work colleague did.

        Years ago (maybe 2014-2015)… said colleague got hit with CryptoWall ransomware on his laptop. It encrypted a number of files on his laptop, then went out on the network and started encrypting files on the office network share.

        We didn’t find out about it until months later, he just complained about some Excel spreadsheets that wouldn’t open properly… in the same directory as those spread sheets was a helpful text file explaining that the files had been encrypted and we were to pay $X in bitcoin to some bitcoin wallet.

        The expiry date had been missed by a couple of months. _Nobody_ had noticed the same text files sitting in various places on the network file shares. Of course being that even the person who got hit didn’t even notice, there were no screenshots taken.

        Muggings went on a seek-and-destroy mission: the laptop got formatted and fresh re-loaded with Windows 7 (losing any files that were stored there).

        I then consulted the back-ups we had of the file server. For stuff that old we had monthly snapshots… generated using `cp -al` and `rsync` (Linux server).

        I was able to recover _all_ files from the file shares, bar 6, which were some virtual machine snapshots for a mining site we no longer supported, and thus didn’t need to keep. We suspect trying to encrypt multi-gigabyte virtual machine disk images over a 1Gbps Ethernet link slowed it down and limited the scope of the damage.

        The incident taught me a number of things:
        1. people often don’t look for answers
        2. none of the files that got encrypted were critical to business operations
        3. our back-up procedures worked
        4. the habits of some of my coworkers at the time clearly aren’t cybersecurity-safe

        We’re not under the juristiction of the FBI so I doubt they’d care. I do not think the Queensland Police or Australian Federal Police would’ve cared at the time either, nor would they care now being that it’s a “historic” case.

      1. This. I’ve got a 2019 Honda & access to a 2007 & 2012 and if I asked my neighbors a few more. I just don’t have the SDR gear. Although I’m thinking about getting it since I want to play around with a few things.

        My 2019 is a keyless FOB. I’m curious if this vulnerability extends to starting the engine. I can’t do remote start, the FOB has to be inside the vehicle in order to start the engine.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.