“Alexa, Stop Listening To Me Or I’ll Cut Your Ears Off”

February 2, 2021 by Dan Maloney 88 Comments

Since we’ve started inviting them into our homes, many of us have began casting a wary eye at our smart speakers. What exactly are they doing with the constant stream of audio we generate, some of it coming from the most intimate and private of moments? Sure, the big companies behind these devices claim they’re being good, but do any of us actually buy that?

It seems like the most prudent path is to not have one of these devices, but they are pretty useful tools. So this hardware mute switch for an Amazon Echo represents a middle ground between digital Luddism and ignoring the possible privacy risks of smart speakers. Yes, these devices all have software options for disabling their microphone arrays, but as [Andrew Peters] relates it, his concern is mainly to thwart exotic attacks on smart speakers, some of which, like laser-induced photoacoustic attacks, we’ve previously discussed. And for that job, only a hardware-level disconnect of the microphones will do.

To achieve this, [Andrew] embedded a Seeeduino Xiao inside his Echo Dot Gen 2. The tiny microcontroller grounds the common I²S data line shared by the seven (!) microphones in the smart speaker, effective disabling them. Enabling and disabling the mics is done via the existing Dot keys, with feedback provided by tones sent through the Dot speaker. It’s a really slick mod, and the amount of documentation [Andrew] did while researching this is impressive. The video below and the accompanying GitHub repo should prove invaluable to other smart speaker hackers.

Continue reading ““Alexa, Stop Listening To Me Or I’ll Cut Your Ears Off”” →

Nissan Gives Up Root Shell Thanks To Hacked USB Drive

January 30, 2021 by Tom Nardi 46 Comments

For the impatient Nissan owners who may be joining us from Google, a hacker by the name of [ea] has figured out how to get a root shell on the Bosch LCN2kai head unit of their 2015 Xterra, and it looks like the process should be the same for other vehicles in the Nissan family such as the Rogue, Sentra, Altima, and Frontier. If you want to play along at home, all you have to do is write the provided image to a USB flash drive and insert it.

Now for those of us who are a more interested in how this whole process works, [ea] was kind of enough to provide a very detailed account of how the exploit was discovered. Starting with getting a spare Linux-powered head unit out of a crashed Xterra to experiment with, the write-up takes the reader through each discovery and privilege escalation that ultimately leads to the development of a non-invasive hack that doesn’t require the user to pull their whole dashboard apart to run.

The early stages of the process will look familiar to anyone who’s messed with embedded Linux hacking. The first step was to locate the board’s serial port and connect it to the computer. From there, [ea] was able to change the kernel parameters in the bootloader to spawn an interactive shell. To make things a little easier, the boot scripts were then modified so the system would start up an SSH server accessible over a USB Ethernet adapter. With full access to the system, the search for exploits could begin.

A simple script on the flash drive enables the SSH server.

After some poking, [ea] discovered the script designed to mount USB storage devices had a potential flaw in it. The script was written in such a way that the filesystem label of the device would be used to create the mount point, but there were no checks in place to prevent a directory traversal attack. By crafting a label that read ../../usr/bin/ and placing a Bash script on the drive, it’s possible to run arbitrary commands on the head unit. The provided script permanently adds SSHd to the startup process, so when the system reboots, you’ll be able to log in and explore.

So what does [ea] want to do with this new-found exploit? It looks like the goal is to eventually come up with some custom programs that extend the functionality of the in-dash Linux system. As it seems like these “infotainment” systems are now an inescapable feature of modern automobiles, we’re certainly excited to see projects that aim to keep them under the consumer’s control.

This Week In Security: Sudo, Database Breaches, And Ransomware

January 29, 2021 by Jonathan Bennett 27 Comments

We couldn't resist, OK? — Obligatory XKCD

Sudo is super important Linux utility, as well as the source of endless jokes. What’s not a joke is CVE-2021-3156, a serious vulnerability around incorrect handling of escape characters. This bug was discovered by researchers at Qualys, and has been in the sudo codebase since 2011. If you haven’t updated your Linux machine in a couple days, you may very well be running the vulnerable sudo binary still. There’s a simple one-liner to test for the vulnerability:

sudoedit -s '\' `perl -e 'print "A" x 65536'`

In response to this command, my machine throws this error, meaning it’s vulnerable:

malloc(): corrupted top size Aborted (core dumped)

To understand the problem with sudo, we have to understand escape characters. It really boils down to spaces in file and folder names, and how to deal with them. You want to name your folder “My Stuff”? That’s fine, but how do you interact with that directory name on the command line, when spaces are the default delimiter between arguments? One option is to wrap it in quotation marks, but that gets old in a hurry. The Unix solution is to use the backslash character as an escape character. Hence you can refer to your fancy folder as My\ Stuff. The shell sees the escape character, and knows to interpret the space as part of the folder name, rather than an argument separator. Escape characters are a common vulnerability location, as there are plenty of edge cases. Continue reading “This Week In Security: Sudo, Database Breaches, And Ransomware” →

This Week In Security: OpenWRT, Favicons, And Steganographia

January 22, 2021 by Jonathan Bennett 29 Comments

OpenWRT is one of my absolute favorite projects, but it’s had a rough week. First off, the official OpenWRT forums is carrying a notice that one of the administrator accounts was accessed, and the userlist was downloaded by an unknown malicious actor. That list is known to include email addresses and usernames. It does not appear that password hashes were exposed, but just to be sure, a password expiration has been triggered for all users.

The second OpenWRT problem is a set of recently discovered vulnerabilities in Dnsmasq, a package installed by default in OpenWRT images. Of those vulnerabilities, four are buffer overflows, and three are weaknesses in how DNS responses are checked — potentially allowing cache poisoning. These seven vulnerabilities are collectively known as DNSpooq (Whitepaper PDF). Continue reading “This Week In Security: OpenWRT, Favicons, And Steganographia” →

This Week In Security: Ubiquiti, Nissan, Zyxel, And Dovecot

January 15, 2021 by Jonathan Bennett 27 Comments

You may have been one of the many of us who received an email from Ubiquiti this week, recommending a password change. The email stated that there was an unauthorized access of Ubiquiti systems, and while there wasn’t evidence of user data being accessed, there was also not enough evidence to say emphatically that user data was not accessed. Ubiquiti has mentioned that the database that may have been accessed contains a user’s name, email address, hashed password, and optionally the mailing address and phone number.

Depending on how the Ubiquiti authentication system is designed, that hashed password may be enough to log in to someone’s account. In any case, updating your password would invalidate the potentially compromised hash. This event underscores a complaint voiced by Ubiquiti users: Ubiquiti has been making it difficult to administrate hardware without a cloud-enabled account. Continue reading “This Week In Security: Ubiquiti, Nissan, Zyxel, And Dovecot” →

This Week In Security: Android Bluetooth RCE, Windows VMs, And HTTPS Everywhere

January 8, 2021 by Jonathan Bennett 5 Comments

Android has released it’s monthly round of security updates, and there is one patched bug in particular that’s very serious: CVE-2021-0316. Few further details are available, but a bit of sleuthing finds the code change that fixes this bug.

Fix potential OOB write in libbluetooth Check event id if of register notification command from remote to avoid OOB write.

It’s another Bluetooth issue, quite reminiscent of BleedingTooth on Linux. In fact, in researching this bug, I realized that Google never released their promised deep-dive into Bleedingtooth. Why? This would usually mean that not all the fixes have been rolled out, or that a significant number of installations are unpatched. Either way, the details are withheld until the ramifications of releasing them are minimal. This similar Bluetooth bug in Android *might* be why the BleedingTooth details haven’t yet been released. Regardless, there are some serious vulnerabilities patched this in this Android update, so make sure to watch for the eventual rollout for your device. Continue reading “This Week In Security: Android Bluetooth RCE, Windows VMs, And HTTPS Everywhere” →

This Week In Security: Deeper Dive Into SolarWinds, Bouncy Castle, And Docker Images

December 31, 2020 by Jonathan Bennett 13 Comments

Merry Christmas and happy holidays! I took Christmas day off from writing the security roundup, coming in a day early with this week’s installment, dodging New year’s day. The SolarWinds story has continued to dominate the news, so lets dive into it a bit deeper.

Microsoft has published their analysis of Solorigate, and the details are interesting. The added code was carefully written to blend in with the rest of the code, using the name OrionImprovementBusinessLayer.Initialize, which sounds like a perfectly boring-yet-legitimate function. The actual backdoor is obfuscated using zip compression and base64 encoding.

Once this bootstrap code begins, it runs a series of checks before actually doing anything malicious. It waits 2 weeks after installation to do anything, and then checks the system domain name for any indication it’s running in a test environment. It then checks for certain security applications, like Wireshark, and refuses to run if they are detected. This series of checks all seem to be an effort to avoid detection, and to only run in a deployed environment. Even the Command and Control URL that the backdoor uses is constructed to appear benign. Beyond this, it seems that the malware simply waited for instructions, and didn’t take any automated actions. All the attacks were performed manually.

Continue reading “This Week In Security: Deeper Dive Into SolarWinds, Bouncy Castle, And Docker Images” →