This Week In Security: Malicious Themes, Crypto Heists, And Wallbleed

It’s usually not a good sign when your downloaded theme contains obfuscated code. Yes, we’re talking about the very popular Material Theme for VSCode. This one has a bit of a convoluted history. One of the authors wanted to make some money from all those downloads. The original Material Theme was yanked from the VSCode store, the source code (improperly) re-licensed as closed source, and replaced with freemium versions. And this week, those freemium versions have been pulled by Microsoft for containing malware.

Now there’s a quirk to this story. No one has been able to answer a simple yet vital question: What exactly did the theme plugin do that was malicious? The official response is that “A theming extension with heavily obfuscated code and unreasonable dependencies including a utility for running child processes”. Looking at the official statements and unofficial security reviews, I can’t find confirmation that the plugins have actually been observed doing something malicious. The only concrete problem is that the plugin shipped obfuscated JavaScript. There are several incomplete statements about a problem with a sanity.io dependency that may have been compromised.

The conclusion at this point is that a thorough security review of these plugins has not been published. The Microsoft team found enough problematic elements in the plugins to trigger pulling them. But I join the chorus of voices calling on Microsoft to clearly answer the vital question: Have any users of Material Theme plugins actually been compromised?

Low-hanging Backups

NAKIVO backup has an interesting endpoint, the getImageByPath call that’s used for loading the system’s logo, and is accessible for unauthenticated users. It’s pretty simple, just taking a path to a file on the appliance filesystem, and returning the byte array for use as an image. And of course, it doesn’t check whether the requested file is actually an image. Nor is it limited to a list of allowed paths.

So hence we essentially have an arbitrary file read. It’s not entirely arbitrary, as the file is first loaded into memory before being served. So the backups themselves are likely too big to successfully exfiltrate in this way. There are still some rather interesting targets, including the system logs. But the real juicy target is the system database itself. Thankfully, the user credentials for the NAVIKO system itself seem to be properly hashed to avoid casual theft. But setting up useful backups will require all sorts of integrations, like SSH and AWS credentials. And those are stored in plain text inside the database. Whoops.

Apple Did What?

A couple weeks ago we talked about Apple and the UK government having a tussle over iCloud backup encryption. Apple has finally rolled out end-to-end encryption for those backups, and the UK’s Snooper’s Charter has been used to require Apple to add an encryption backdoor in that system. That’s problematic for multiple reasons, and Apple has opted to not quietly oblige the UK government. You may have seen headlines that Apple has pulled access to the new Advanced Data Protection (ADP) for UK users. This seems to be the next step of anti-compliance with the new UK rule.

The logic here seems to be that not offering any end-to-end encrypted backup system for UK users is a better choice than claiming to offer such a system that actually contains a backdoor. That’s doubly true, as the law in question doesn’t seem to limit itself to UK users. If the UK government doesn’t back down on their extremely questionable demands, the next major step may be for Apple to pull sales from the country entirely.

Crypto Heist

We have a pair of crypto heist stories this week, with the first one being the largest in history. At a staggering $1.5 Billion, this seems like the biggest single theft of any kind to ever be successfully pulled off. And the details of how it was done are still a bit murky. The funds were stolen out of a Bybit “multisig” cold wallet. Those are clever currency stores that actually include smart contracts in the storage mechanism, requiring multiple owners to sign off on transactions.

It’s believed that this hack was pulled off by North Korean agents, through the use of very clever but simple techniques: Social engineering, and UI manipulation. In essence, a request for digital signature that claimed to do something benign, that actually unlocked the funds for theft. Some things never seem to change.

And that’s not all that’s happening with Cryptocurrency these days. It turns out that there’s another dead-simple attack that is targeting job-seeking individuals, instead of huge companies. “We may have a job for you, go to this website and run this application to apply!” Rather than a legitimate videoconferencing or interviewing application, the download is a simple backdoor. It’s used primarily to find crypto wallets and siphon the funds out.

Wallbleed

Remember Heartbleed? That’s the glitch in OpenSSL from 2014, where the TLS heartbeat implementation could trivially leak large amounts of system memory. Wallbleed is a strangely similar bug in the implementation of the Chinese Great Firewall system. One way the Great Firewall does censorship is via DNS injection. Request the DNS information for a blocked domain, and the firewall will intercept that request in real time, and return a spoofed response with a bogus IP address for the requested domain. Importantly for this discussion, that spoofing is bi-directional. You can send DNS requests to Chinese IP addresses, and get spoofed responses from the Great Firewall.

DNS request and response packets use an interesting variable length transport system, where the domain name being requested is turned into a set of length-value pairs. example.com is represented as 07example03com00. 7 bytes for the domain, then 3 bytes for the TLD, and a terminating null. Many of us are immediately wondering, what happens if that query was packed incorrectly: 07example20com00? There aren’t actually 20 bytes in the query, so what do various DNS responders do when handed such a query? Well-written DNS servers recognize that this is garbage, and just drop the packet. Some of the great firewall infrastructure did something far more interesting. It spoofs the DNS response, and performs a buffer over-read when constructing the response. Yes, leaking a few bytes of raw system memory back to the requester, a la Heartbleed.

And when we say “a few bytes”, the maximum observed leakage in a single spoofed response was 125. As you might imagine, that’s quite a bit of data. Enough data, in fact, to learn quite a bit about the Great Firewall and what sort of traffic it sees. There were also what appeared to be x86_64 pointers and Linux stack frames.

This attack was first discovered by researchers in 2021 and finally completely fixed in March 2024. In the intermediate time, those researchers used the vulnerability quite heavily to mine the Great Firewall infrastructure for data. This is an interesting ethical question. Normally it’s considered completely unacceptable to weaponize a vulnerability beyond what’s needed as a proof of concept. The Great Firewall is in some ways an adversarial device, making exploitation a bit murkier. On the other hand, vulnerabilities like this a usually disclosed in order to get them fixed. What is a researcher’s responsibility in this case, when the vulnerability is in a censorship device? It seems the Chinese authorities discovered the Wallbleed vulnerability themselves, excusing researchers from needing to fully answer this particular ethical question.

Bits and Bytes

It’s not surprising to open up an electronic device, and find an ugly glob of potting compound spread over one or several of the key chips inside. Or for some devices, the compound is ubiquitous, covering everything. [Graham Sutherland] has some thoughts on how to defeat the stuff. And while some is obvious, like using a drill press to very carefully expose a target interface, there are some really inventive ideas I would never have considered, like throwing an entire board into a pressure cooker for an hour!

How long does it take for a cyber criminal to go from initial access on an internal machine, to full access to a privileged computer? In the ReliaQuest case, it was 48 minutes. The hack was simple and clever. Start a mass spam and phishing campaign, and then pose as a helpful IT worker who could help end the carnage. All it takes is one employee to fall for the fake help desk routine, and 48 minutes.

Let’s say you wanted to pirate music from a streaming service like Deezer, but you really didn’t want your IP address or machine associated with the piracy. What would you do? Use Tor? VPNs? How about create a malicious PyPi package that does your downloading for you. That seems to be the bizarre case of automslc, a reasonably popular package that secretly downloads and scrapes from the music platform.

3 thoughts on “This Week In Security: Malicious Themes, Crypto Heists, And Wallbleed

  1. What a fascinating piece by Graham Sutherland. And I confess to a wry smile at his tale of heating potted devices in oil to remove the epoxy, “…something about boiling hardware in olive oil seemed deeply wrong, but [I] quickly wrote the approach off when I realised that aggressively hacking away at a very slippery device covered in boiling hot mineral oil with a box cutter was an instant trip to the hospital in disguise…” :)

    Someone please give that guy a job ASAP, if only before he blows his kitchen up!

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.