This Week In Security: Huawei Gets The Banhammer, Lastpass, And Old Code Breaking

While many of us were enjoying some time off for Thanksgiving, the US government took drastic action against Huawei and four other Chinese companies. The hardest hit are Huawei and ZTE, as the ban prevents any new products from being approved for the US market. The other three companies are Dahua and Hikvision, which make video surveillance equipment, and Hytera, which makes radio systems. FCC Commissioner Brendan Carr noted the seriousness of the decision.

[As] a result of our order, no new Huawei or ZTE equipment can be approved. And no new Dahua, Hikvision, or Hytera gear can be approved unless they assure the FCC that their gear won’t be used for public safety, security of government facilities, & other national security purposes.

There is even the potential that previously approved equipment could have its authorization pulled. The raw FCC documents are available, if you really wish to wade through them. What’s notable is that two diametrically opposed US administrations have both pushed for this ban. It would surely be interesting to get a look at the classified reports detailing what was actually found. Maybe in another decade or two, we can make a Freedom of Information Act request and finally get the full story.

Continue reading “This Week In Security: Huawei Gets The Banhammer, Lastpass, And Old Code Breaking”

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

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

[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

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

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

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

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”