This week starts off with examinations of a couple hardware attacks that you might have considered impractical. Take a Ball Grid Array (BGA) NAND removal attack, for instance. The idea is that a NAND chip might contain useful information in the form of firmware or hard-coded secrets.

The question is whether a BGA desolder job puts this sort of approach out of the reach of most attackers. Now, this is Hackaday. We regularly cover how our readers do BGA solder jobs, so it should come as no surprise to us that less than two-hundred Euro worth of tools, and a little know-how and bravery, was all it took to extract this chip. Plop it onto a pogo-pin equipped reader, use some sketchy Windows software, and boom you’ve got firmware.

What exactly to do with that firmware access is a little less straightforward. If the firmware is unencrypted and there’s not a cryptographic signature, then you can just modify the firmware. Many devices include signature checking at boot, so that limits the attack to finding vulnerabilities and searching for embedded secrets. And then worst case, some platforms use entirely encrypted firmware. That means there’s another challenge, of either recovering the key, or finding a weakness in the encryption scheme.

Glitches to the Rescue

Speaking of looking for those vulnerabilities, let’s talk about glitching. We’ve talked about some interesting techniques in the past, like using a peizo element from a lighter. This coverage takes the opposite technique, shorting pins to ground during code runtime. [Maurizio Agazzini] takes a look at glitching technique on the ESP32.

The key, it seems, is setting up a repeatable test case. I like a quote from the article, that the goal is to make a “world” considered non-deterministic a little more deterministic. In this case, that means understanding the exact instructions that the MCU is running, triggering an exception to know the exact state the MCU is in after the test, and exactly timing the fault attempt.

Do 36,000 attempts at different timings and pulse lengths, chart it out, and see what happens. And there are some interesting observations there. One of the most interesting rabbit holes from the article is debunking of the idea of skipped instructions as the result of glitches. What actually seems to happen, when the glitch is a crowbar circuit to ground, is that individual bits get pulled to 0. That can corrupt either the instruction or memory itself. Understanding those glitches is key to figuring out how to abuse them. We’ll be keeping an eye out for the next installment in this one.

The S in IOT Stands for Security

Claroty’s Team82 took aim at the OvrC cloud platform, an IoT remote management solution, and found some problems. And when I say “some problems”, I really mean that every device connected to the cloud controller could be fully pwned. Starting with an easy enumeration using MAC Addresses, every device could be mapped and determined if it was claimed or not. The nutty part here is that users that opted out of cloud control were just considered unclaimed devices, making takeover even easier.

Claiming a device was intended to require both the MAC Address and a unique serial number. A URL endpoint on the platform actually skipped verifying the serial number, allowing for easy claiming of any unclaimed device with only a MAC address. And claimed devices? The OvrC platform has support for device hubs, where is a local management device where a user can pair multiple individual IoT devices. Impersonate a hub, and you can force already claimed devices to the unclaimed status.

Oh, and hub devices had a hidden superuser account with a password derived from the MAC address and another knowable service tag value. And with Superuser access, there’s a diagnostics menu that includes direct command injection. So there’s that. OvrC has addressed and fixed the reported flaws, making for a bit more secure IoT devices.

BinaryFormatter is Insecure and Can’t Be Made Secure

That title isn’t the sort of thing you want to hear from your upstream vendor, about a function call you’re using in your code. Here we have Watchtowr, in their gloriously snarky style, detailing a deserialization flaw in Citrix’s Virtual Apps and Desktops. This is one of those thin client solutions, where the read hard work is done on a central machine in the server room.

One of the killer features of this enterprise app is session recording. That’s the ability to spy on observe users, and play it back later for analysis. The problem is that this data has to get serialized and streamed over the network. And in a weird turn of programming fate, the MSMQ service that handles this is accessible over HTTP. That’s SOAP over HTTP, if you really must know. And because of the reliance on BinaryFormatter, it’s remotely exploitable. This ends up as a remote code execution bug, and the resolution is as yet not entirely known. Citrix has received and confirmed the bug, and the disclosure was set for November 12, but no CVE or formal patch announcement has been made.

Bits and Bytes

I’m not sure if it’s more insulting or less insulting to fall to a ransomware attack where it’s just Windows Bitlocker that’s doing the encryption. Apparently the criminals behind ShrinkLocker have taken the approach that there’s no reason to bother actually writing encryption code for their ransomware, since Microsoft has perfectly serviceable encryption already. The good news is that as one might expect from such coding laziness, the implementation is flawed, and there is a decryptor available that can potentially recover the password.

In a strike against fraud and global computer crime, law enforcement agencies have seized a whopping 22,000 IP addresses, and made 41 arrests. Dubbed Operation Synergia II, this one is interesting in that much of the law enforcement action happened in China and other Eastern countries, with support from both Kaspersky and Interpol.

There’s a new sneaky way to smuggle malicious payloads on MacOS. This one seems to be coming from North Korea’s Lazarus group. MacOS has extended Attributes for files and directories, and can apparently be used to hold raw text. It’s not visible in Finder, but can be found with xattr command. In this case, it’s not a vulnerability, but simply a very uncommon place to sneak some malicious script onto a system.