This Week in Security: More Protestware, Another Linux Vuln, and TLStorm [Hackaday]

View Article on Hackaday

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.

This story is continuing to develop, but there was also an issue raised by a node-ipc user who claimed to be associated with a human rights organization that worked with observers in Eastern Europe. The unsubstantiated claim is that node-ipc ran on their whistle-blowing infrastructure, and the malicious code in version 10.1.1 or 10.1.2 wiped a massive collection of evidence. While this could be a hoax — anyone can claim anything on the internet — there is a threat of legal action, which would give substance to the claim. If we catch wind of anything more developing, we’ll update you on it.

This recurrence of protestware is going to force the Open Source world to come to some conclusions about what sort of social and political commentary is appropriate in widely-used projects. Wiping hard drives is obviously way beyond the pale. It’s not entirely clear that code was intended to be rolled out to the public, as it was picked up in an unrelated changeset, suggesting either an accidental inclusion, or an attempt to smuggle it in. But what about the creation of a virtual pamphlet on the user’s desktop? I suggest that this, too, is unacceptable for a serious project. What about rhetoric in log output? The impetus behind protestware seems to be unchanging, so we’ll need to work out the answers to such questions.

Netfilter RCE

Up next is the announcement of another Linux Kernel vulnerability, CVE-2022-25636, this one an out-of-bounds write in the Linux firewall code. If you’re suddenly having heart palpitations at the thought of Remote Code Execution, try to relax. This flaw is serious, but just like DirtyPipe we covered last week, it’s entirely limited to a local user account that can run shell commands. A pair of tricks allows any user the ability to trigger the flaw with any hardware, meaning that it’s a straightforward elevation of privileges.

Making this a more serious issue, there are at least two Proof-of-Concepts available: one in the disclosure linked above, and the second on Github from [Bonfee]. The problem was introduced in kernel 5.4, and fixed in 5.16.12, 5.15.26, 5.10.103, 5.4.182, and has landed in 5.17 which is due to be released very soon. Unfortunately, there are incorrect reports that this CVE was fixed in 5.6.10, including the NIST page on the bug. The problem is that 5.6.10 was released more than a year before the problem was found. Adjust your response accordingly.

How to Brick Thousands of Satellite Terminals

You may have seen the story of several thousand wind turbines in Europe suddenly lost their satellite link to their controllers. There has finally been enough information released to piece together an educated guess as to what went wrong. [Ruben Santamarta] combines his experience breaking satellite systems with the hints given in official statements, and presents a likely explanation. First, the outage corresponded with the war in Ukraine and was being investigated as a cyberattack. This could have been a simple DDoS, but a military official stated that “terminals have been damaged, made inoperable and probably cannot be repaired.” DDoS attacks don’t generally brick devices.

What does brick devices is flashing bad firmware to them. The most likely scenario is that Russian attackers either compromised a ground station, or spoofed it. They used this connection, and the TR-069 protocol, to send a malicious firmware update. This attack knocked out terminals in Ukraine, Czech Republic, Slovakia, and Germany.

TLStorm

It’s a catchy name, a logo, and even a slick informational video. Is TLStorm more than a flash-in-the-WAN? Maybe — there are a trio of serious vulnerabilities at play. Researchers at Armis found these in APC Smart-UPS firmware.

Let’s start with the Firmware authentication problem. To really ensure that malicious firmware can’t be installed, devices use a signed and encrypted approach, where the signing key is held very securely by the manufacturer. Smart-UPS firmware was simply being encrypted with a symmetric key, meaning the same key is used to both encrypt and decrypt the firmware. The check done in the target device was to decrypt the new firmware, and sanity-check it, usually by looking for a magic value in the header. The problem is that every device that shares firmware compatibility is also sharing the same encryption key. Extracting the key from one unit allows an attacker to produce valid-yet-malicious firmware for all of them.

Problem two is a Man in the Middle TLS attack. This one takes advantage of state confusion in the nanoSSL library shipped with the APC devices. The client tries to communicate with the APC cloud, and the attacker interrupts the initial handshake. Now that the connection is in this state, the attacker can send a TLS resumption message, and the client accepts it, skipping the all-important verification of the HTTPS certificate.

The final exploit is an RCE, taking advantage of TLS fragmentation. The attacker sends a fragmented message, and then keeps sending fragments beyond the expected byte-count, overflowing the allotted buffer. This one allows for full control, and chains into the malicious firmware problem. Put together, these give an attacker a very wide range of options, from powering off downstream devices, to modifying the firmware to induce unsafe operations. The Hollywood trope finally comes true, where the hacker can make devices explode remotely.

Bits and Bytes

That nifty device you carry everywhere has a baseband processor and firmware on it, and that has historically been a very opaque component. There’s a new tool to get some insight into what that firmware is doing, FirmWire. It’s a baseband emulator, intended to let you fuzz, debug, and otherwise delve the secrets of your baseband firmware.

Is it just me, or has Google Chrome had an uptick of in-the-wild exploits recently? Apparently the trend is real, and researchers at Google have noticed. They point out a few reasons for the trend. Chromium is the biggest browser game in town, so naturally it’s the one being attacked. A counter-intuitive point is that better security artificially inflates the vulnerability count, as sandboxing requires a real attack to chain at least two bugs together to accomplish anything worthwhile. The post rounds out with a discussion of Google’s plans to keep ratcheting the code in Chrome/Chromium to a more secure standard.

Remember the impressive WordPress fuzzing tool we covered a few weeks back? A few commentors wanted to know where to find the source for the new tool. Wpgarlic has now been released, and is ready for you to use, improve, and unleash your hacking creativity upon. If you find something particularly interesting with it, be sure to let us know!