This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness

August 19, 2022 by 9 Comments

It’s debatable just how useful Secure Boot is for end users, but now there’s yet another issue with Secure Boot, or more specifically, a trio of signed bootloaders. Researchers at Eclypsium have identified problems in the Eurosoft, CryptoPro, and New Horizon bootloaders. In the first two cases, a way-too-flexible UEFI shell allows raw memory access. A startup script doesn’t have to be signed, and can easily manipulate the boot process at will. The last issue is in the New Horizon Datasys product, which disables any signature checking for the rest of the boot process — while still reporting that secure boot is enabled. It’s unclear if this requires a config option, or is just totally broken by default.

The real issue is that if malware or an attacker can get write access to the EFI partition, one of these signed bootloaders can be added to the boot chain, along with some nasty payload, and the OS that eventually gets booted still sees Secure Boot enabled. It’s the perfect vehicle for really stealthy infections, similar to CosmicStrand, the malicious firmware we covered a few weeks ago.
Continue reading “This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness” →

Ubuntu 22.04 setup screen shown on the Google's Nest Hub display

Breaking Google Nest Hub’s Secure Boot

June 20, 2022 by 4 Comments

[frederic] tells a story about their team’s hack of a Google Nest Hub (2nd generation) — running Ubuntu on it, through bypassing Google’s boot image signature checks. As with many good hacks, it starts with FCC website pictures. Reverse-engineering a charger and USB daughterboard pin-out, they found a UART connection and broke it out with a custom adapter. With a debug console and insights into the process, they went on hacking, slicing through hardware and software until it was done with.

This story gives plenty of background and insight into both the code that was being investigated, and the way that attack targets were chosen. Through fuzzing, they found a buffer overflow in the bootloader code that could be triggered with help of a non-standard block size. USB flash drives tend to have these hard-coded, so they built a special firmware for a Pi Pico and shortly thereafter, achieved code execution. Then, they hooked into uboot functions and loaded Ubuntu, bypassing the boot image signature checks.

This is a wonderful documentation of a hacking journey, and an exciting read to boot (pun intended). The bug seems to have been patched for half a year now, so you probably can’t flash your Google Nest into Ubuntu anymore. However, you might be able to run an up-to-date Linux on your Amazon Echo.

We thank [Sven] for sharing this with us!

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

April 29, 2022 by 10 Comments

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures” →

This Week In Security: More Protestware, Another Linux Vuln, And TLStorm

March 18, 2022 by 13 Comments

It seems I have made my tiny, indelible mark on internet security history, with the term “protestware“. As far as I can tell, I first coined this particular flavor of malware while covering the Faker.js/Colors.js vandalism in January.

Yet another developer, [RIAEvangelist] has inserted some malicious code (Mirror, since the complaint has been deleted) in an existing project, in protest of something, in this case the war in Ukraine. The behavior here is to write a nice note on the desktop, preaching “peace not war”. However, a few versions of this sample have a nasty surprise — it does a GeoIP lookup, and attempts to wipe the entire drive if it detects a Russian location. Yes, node-ipc versions 10.1.1 and 10.1.2 contain straight-up malware. It’s not clear how many users ran the potentially malicious code, as it was quickly reverted and released 10.1.3. Up-to-date versions of node-ipc still create the desktop file, and Unity Hub has already confirmed they shipped the library in this state, and have since issued a hotfix.
Continue reading “This Week In Security: More Protestware, Another Linux Vuln, And TLStorm” →

This Week In Security: Chrome 0-day,Cassandra, And A Cisco PoC

February 18, 2022 by 7 Comments

Running Chrome or a Chromium-based browser? Check for version 98.0.4758.102, and update if you’re not running that release or better. Quick tip, use chrome://restart to trigger an immediate restart of Chrome, just like the one that comes after an update. This is super useful especially after installing an update on Linux, using apt, dnf, or the like.

CVE-2022-0609 is the big vulnerability just patched, and Google has acknowledged that it’s being exploited in the wild. It’s a use-after-free bug, meaning that the application marks a section of memory as returned to the OS, but then accesses that now-invalid memory address. The time gap between freeing and erroneously re-using the memory allows malicious code to claim that memory as its own, and write something unexpected.

Google has learned their lesson about making too many details public too early, and this CVE and associated bug aren’t easily found in in the Chromium project’s source, and there doesn’t seem to be an exploit published in the Chromium code testing suite. Continue reading “This Week In Security: Chrome 0-day,Cassandra, And A Cisco PoC” →

This Week In Security: GoDaddy, Tardigrade, Monox, And BigSig

December 3, 2021 by 10 Comments

After the Thanksgiving break, we have two weeks of news to cover, so hang on for an extra-long entry. First up is GoDaddy, who suffered a breach starting on September 6th. According to an SEC filing, they noticed the problem on November 17th, and determined that there was unauthorized access to their provisioning system for their WordPress hosting service. For those keeping track at home, that’s two months and eleven days that a malicious actor had access. And what all was compromised? The email address and customer number of the approximate 1.2 million GoDaddy WordPress users; the initial WordPress password, in the clear; the SFTP and database passwords, also in the clear; and for some customers, their private SSL key.

The saving grace is that it seems that GoDaddy’s systems are segregated well enough that this breach doesn’t seem to have led to further widespread compromise. It’s unclear why passwords were stored in the clear beyond the initial setup procedure. To be safe, if you have a WordPress instance hosted by GoDaddy, you should examine it very carefully for signs of compromise, and rotate associated passwords. The SSL keys may be the most troubling, as this would allow an attacker to impersonate the domain. Given the length of time the attack had access, it would not surprise me to learn that more of GoDaddy’s infrastructure was actually compromised. Continue reading “This Week In Security: GoDaddy, Tardigrade, Monox, And BigSig” →

This Week In Security: Intel Atoms Spill Secrets, ICMP Poisons DNS, And The Blacksmith

November 19, 2021 by 21 Comments

Intel has announced CVE-2021-0146, a vulnerability in certain processors based on the Atom architecture, and the Trusted Platform Module (TPM) is at the center of the problem. The goal of the system around the TPM is to maintain system integrity even in the case of physical access by an attacker, so the hard drive is encrypted using a key stored in a secure chip on the motherboard. The TPM chip holds this encryption key and provides it during the boot process. When combined with secure boot, this is a surprisingly effective way to prevent tampering or data access even in the case of physical access. It’s effective, at least, when nothing goes wrong.

Earlier this year, we covered a story where the encryption key could be sniffed directly from the motherboard, by tapping the traces connecting the TPM to the CPU. It was pointed out that TPM 2.0 can encrypt the disk encryption key on the traces, making this attack impossible.

The entire Trusted Compute Model is based on the premise that the CPU itself is trustworthy. This brings us back to Intel’s announcement that a debug mode could be enabled via physical access. In this debug mode, the CPU master key can be extracted, leading to complete compromise. The drive encryption key can be recovered, and unsigned firmware can be loaded to the Management Engine. This means data in the TPM enclave and the TPM-stored encryption key can be compromised. Updated firmware is rolling out through motherboard vendors to address the problem. Continue reading “This Week In Security: Intel Atoms Spill Secrets, ICMP Poisons DNS, And The Blacksmith” →