Security Hacks

1519 Articles

This Week In Security: ISNs, Patch Tuesday, And Clubhouse

February 19, 2021 by 4 Comments

Let’s talk TCP. Specifically, how do the different TCP connections stay distinct, and how is a third party kept from interrupting a connection? One of the mechanisms that help accomplish this feat is the TCP sequence number. Each of the two endpoints of a TCP connection tracks an incrementing 32-bit number, corresponding to the bytes sent in the connection. It’s handy, because each side can use that value to track what parts of the data stream they have received. On missing packets, a message can be sent requesting bytes 7-15 to be resent, for instance.

Each side of the connection sets their own Initial Sequence Number (ISN), and it’s important that this number is unique, as collisions can cause stream confusion. That statement should make your security spidey sense tingle. If a collision can cause problems when it happens by chance, what can a hacker do with it intentionally? Potentially quite a bit. Knowing the current sequence number, as well as a couple other pieces of information, a third party can close a TCP stream or even inject data. The attack has been around for years, originally known as the Mitnick Attack. It was originally possible because TCP implementations used a simple counter to set the ISN. Once the security ramifications of this approach were understood, the major implementations moved to a random number generation for their ISNs.

Now to this week’s story: researchers at Forescout took the time to check 11 TCP/IP stacks for vulnerability to the old Mitnick Attack (PDF Whitepaper). Of the eleven embedded stacks texted, nine have serious weaknesses in their ISN generation. Most of the vulnerable implementations use a system time value as their ISN, while several use a predictable pseudorandom algorithm that can be easily reversed.

CVEs have been assigned, and vendors notified of “NUMBER:JACK”, Forescout’s name for the research. Most of the vulnerable software already has patches available. The problem with embedded systems is that they often never get security updates. The vulnerable network stacks are in devices like IP cameras, printers, and other “invisible” software. Time will tell if this attack shows up as part of a future IoT botnet.
Continue reading “This Week In Security: ISNs, Patch Tuesday, And Clubhouse” →

This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More

February 12, 2021 by 6 Comments

Code obfuscation has been around for a long time. The obfuscated C contest first ran way back in 1984, but there are examples of natural language obfuscation from way earlier in history. Namely Cockney rhyming slang, like saying “Lady from Bristol” instead of “pistol” or “lump of lead” instead of “head”. It’s speculated that Cockney was originally used to allow the criminal class to have conversations without tipping off police.

Code obfuscation in malware serves a similar purpose — hiding from security devices and applications. There are known code snippets and blacklisted IP addresses that anti-malware software scans for. If that known bad code can be successfully obfuscated, it can avoid detection. This is a bit of a constant game of cat-and-mouse, as the deobfuscation code itself eventually makes the blacklist. This leads to new obfuscation techniques, sometimes quite off the wall. Well this week, I found a humdinger of an oddball approach. Morse Code.

Yep, dots and dashes. The whole attack goes like this. You receive an email, claiming to be an invoice. It’s a .xlsx.hTML file. If you don’t notice the odd file extension, and actually let it open, you’re treated to a web page. The source of that page is a very minimal JS script that consists of a morse code decoder, and a payload encoded in Morse. In this case, the payload is simply a pair of external scripts that ask for an Office 365 login. The novel aspect of this is definitely the Morse Code. Yes, our own [Danie] covered this earlier this week, but it was too good not to mention here. Continue reading “This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More” →

This Week In Security: Perl.com, The Great Suspender, And Google’s Solution

February 5, 2021 by 46 Comments

Perl has been stolen. Well, perl.com, at least. The perl.com domain was transferred to a different registrar on January 27, without the permission of the rightful owner. The first to notice the hack seems to have been [xtaran], who raised the alarm on a Reddit thread. The proper people quickly noticed, and started the process of getting control of the domain again. It seems that several other unrelated domains were also stolen in the same attack.

I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.

The Great Suspender, Suspended

I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?

I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.

It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.

The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.

Libgcrypt

It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.

Android Botnet

A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.

Google Solution to Open-Source Security

Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.

Microsoft in My Pi

And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.

The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.

Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.

Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor

February 4, 2021 by 30 Comments

It’s long been common wisdom that one of the safest places to keep your cryptocurrency holdings is in a hardware wallet. These are small, portable devices that encrypt your keys and offer a bit more peace of mind than holding your coins in a soft or web wallet.

But of course, as we know, nothing is totally secure.

And we were reminded of this fact by Kraken Security Labs, when they showed us how they bypassed all of the safeguards in a popular wallet, the Trezor, to dump and decrypt it’s seed.

It’s worth noting that the hack does require physical access to the wallet — albeit only about fifteen minutes worth. And by “physical access” we mean that the hack leaves the device thoroughly mutilated. The Kraken team started by desoldering the heart of the wallet, a STM32 processor. They then dropped it into a socket on an interface board, and got to glitching.

The hack relies on an attack known as voltage glitching. Essentially, at a precisely-timed moment during the device’s boot sequence, the supply voltage is fluctuated. This enables the chip’s factory bootloader, which can read out the contents of it’s onboard flash memory. The memory is read-protected, but can be accessed 256 bytes at a time through a second voltage glitch. Neither of these attacks work 100% of the time, so if the device fails to boot or the memory remains locked, the FPGA performing the attacks simply tries again. After enough iterations, the Kraken team was able to fully dump the chip’s flash memory.

Continue reading “Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor” →

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

February 2, 2021 by 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 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 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” →