This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!

The big story this week is Solarwinds. This IT management company supplies network monitoring and other security equipment, and it seems that malicious code was included in a product update as early as last spring. Their equipment is present in a multitude of high-profile networks, like Fireeye, many branches of the US government, and pretty much any other large company you can think of. To say that this supply chain attack is a big deal is an understatement. The blame has initially been placed on APT42, AKA, the Russian hacking pros.

The attack hasn’t been without some positive effects, as Fireeye has released some of their internal tooling as open source as a result. Microsoft has led the official response to the attack, managing to win control of the C&C domain in court, and black-holing it.

The last wrinkle to this story is the interesting timing of the sale of some Solarwinds stock by a pair of investment firms. If those firms were aware of the breech, and sold their shares before the news was made public, this would be a classic case of illegal insider trading. Continue reading “This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!”

Remoticon Video: Breaking Encrypted Firmware Workshop

If only you could get your hands on the code to fix the broken features on your beloved electronic widget. But wait, hardware hackers have the skills to write their own firmware… as long as we can get the compiled binary into a format the hardware needs.

Luckily, we have Uri Shaked to walk us through that process. This workshop from the 2020 Hackaday Remoticon demonstrates how to decipher the encryption scheme used on the firmware binary of a 3D printer. Along the way, we learn about the tools and techniques that are useful for many encrypted binary deciphering adventures.

Continue reading “Remoticon Video: Breaking Encrypted Firmware Workshop”

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More”

Leaking Data By Ultrasound

Human ears are capable of perceiving frequencies from roughly 20 Hz up to 20 kHz, at least when new. Correspondingly, our audio hardware is designed more or less to target these frequencies. However, there’s often a little extra capability at the upper edges, which [Jacek] shows can be exploited to exfiltrate data.

The hack takes advantage of the fact that most computers can run their soundcards at a sample rate of up to 48 kHz, which thanks to the Nyquist theorem means they can output frequencies up to around 24 kHz — still outside the range of human hearing. Computers and laptops often use small speaker drivers too, which are able to readily generate sound at this frequency. Through the use of a simple Linux shell script, [Jacek] is able to have a laptop output Morse code over ultrasound, and pick it up with nothing more than a laptop’s internal microphone at up to 20 meters away.

[Jacek] enjoys exploring alternative data exfiltration methods; he’s previously experimented with Ethernet leaks on the Raspberry Pi. Of course, with any airgap attack, the real challenge is often getting the remote machine to run the exfiltration script when there’s no existing remote admin access to be had. Video after the break.

Continue reading “Leaking Data By Ultrasound”

This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex

I hope everyone had a wonderful Thanksgiving last week. My household celebrated by welcoming a 4th member to the family. My daughter was born on Wednesday morning, November 25th. And thus explains what I did last week instead of writing the normal Hackaday column. Never fear, we shall catch up today, and cover the news that’s fit to be noticed.

iOS Zero-click Wifi Attack

[Ian Beer] of Google’s Project Zero brings us the fruit of his lockdown-induced labors, a spectacular iOS attack. The target of this attack is the kernel code that handles AWDL, an Apple WiFi protocol for adhoc mesh networks between devices. The most notable feature that makes use of AWDL is AirDrop, Apple’s device-to-device file sharing system. Because AWDL is a proprietary protocol, the WiFi hardware can’t do any accelerated processing of packets. A few years back, there was an attack against Broadcom firmware that required a second vulnerability to jump from the WiFi chip to the device CPU. Here, because the protocol is all implemented in Apple’s code, no such pivot is necessary.

And as you’ve likely deduced, there was a vulnerability found. AWDL uses Type-Length-Value (TLV) messages for sending management data. For a security researcher, TLVs are particularly interesting because each data type represents a different code path to attack. One of those data types is a list of MAC addresses, with a maximum of 10. The code that handles it allocates a 60 byte buffer, based on that maximum. The problem is that there isn’t a code path to drop incoming TLVs of that type when they exceed 60 bytes. The remainder is written right past the end of the allocated buffer.

There is more fun to be had, getting to a full exploit, but the details are a bit too much to fully dive in to here. It interesting to note that [Ian] ran into a particular problem: His poking at the target code was triggering unexpected kernel panics. He discovered two separate vulnerabilities, both distinct from the vuln he was trying to exploit.

Finally, this exploit requires the target device to have AWDL enabled, and many won’t. But you can use Bluetooth Low Energy advertisements to trick the target device into believing an Airdrop is coming in from a trusted contact. Once the device enables AWDL to verify the request, the attack can proceed. [Ian] reported his findings to Apple way back in 2019, and this vulnerability was patched in March of 2020.

Via Ars Technica.
Continue reading “This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex”

Let’s Encrypt Will Stop Working For Older Android Devices

Let’s Encrypt was founded in 2012, going public in 2014, with the aim to improve security on the web. The goal was to be achieved by providing free, automated access to SSL and TLS certificates that would allow websites to make the switch over to HTTPS without having to spend any money.

Hundreds of millions of sites rely on Let’s Encrypt for their HTTPS certificate needs. HTTPS security helps protect sites and users, and makes it harder for malicious actors to steal private information.

The project has just announced that, come September 1, 2021, some older software will stop trusting their certificates. Let’s look at why this has come to pass, and what it means going forward.

Certificates Expire

When Let’s Encrypt first went public in early 2016, they issued their own root certificate, by the name ISRG Root X1. However, it takes time for companies to include updated root certificates in their software, so until recently, all Let’s Encrypt certificates were cross-signed by an IdenTrust certificate, DST Root X3. This certificate had been around much longer, and was already supported by the vast majority of OSes and browsers in regular use. This allowed Let’s Encrypt to hit the ground running while they waited for the majority of software to support their own root certificate. Continue reading “Let’s Encrypt Will Stop Working For Older Android Devices”

Amazon Sidewalk: Should You Be Co-Opted Into A Private Neighbourhood LoRa Network?

WiFi just isn’t very good at going through buildings. It’s fine for the main living areas of an average home, but once we venture towards the periphery of our domains it starts to become less reliable.  For connected devices outside the core of a home, this presents a problem, and it’s one Amazon hope to solve with their Sidewalk product.

It’s a low-bandwidth networking system that uses capability already built into some Echo and Ring devices, plus a portion of the owner’s broadband connection to the Internet.  The idea is to provide basic connectivity over longer distances to compatible devices even when the WiFi network is not available, but of most interest and concern is that it will also expose itself to devices owned by other people. If your Internet connection goes down, then your Ring devices will still provide a basic version of their functionality via a local low-bandwidth wide-area wireless network provided by the Amazon devices owned by your neighbours. Continue reading “Amazon Sidewalk: Should You Be Co-Opted Into A Private Neighbourhood LoRa Network?”