Security Hacks

964 Articles

Burning Things With Big Lasers In The Name Of Security

January 29, 2020 by 1 Comment

Several fields of quantum research have made their transition from research labs into commercial products, accompanied by grandiose claims. Are they as good as they say? We need people like Dr. Sarah Kaiser to independently test those claims, looking for flaws in implementation. At the 2019 Hackaday Superconference she shared her research on attacking commercially available quantum key distribution (QKD) hardware.

Don’t be scared away when you see the term “quantum” in the title. Her talk is very easy to follow along, requiring almost no prior knowledge of quantum research terminology. In fact, that’s the point. Dr. Kaiser’s personal ambition is to make quantum computing an inviting and accessible topic for everyone, not just elite cliques of researchers in ivory towers. You should hear her out in the video below, and by following along with the presentation slide deck (.PPTX).

Quantum Key Distribution

So why is QKD is so enticing? Unlike existing methods, the theoretical foundation is secure against any attacker constrained by the speed of light and the laws of physics.

Generally speaking, if your attacker is not bound by those things, we have a much bigger problem.

But as we know well, there’s always a difference between the theoretical foundation and the actual implementation of cryptography. That difference is where exploits like side-channel attacks thrive, so she started investigating components of a laser QKD system.

As a self-professed “Crazy Laser Lady”, part of this investigation examined how components held up to big lasers delivering power far outside normal operating range. This turned up exciting effects like a fiber fuse (~17:30 in the video) which is actually a plasma fire propagating through the fiber optic. It looks cool, but it’s destructive and useless for covert attacks. More productive results came when lasers were used to carefully degrade select components to make the system vulnerable.

If you want to learn more from Dr. Kaiser about quantum key distribution, she has a book chapter on the topic. (Free online access available, but with limitations.) This is not the first attempt to hack quantum key distribution, and we doubt it would be the last. Every generation of products will improve tolerance to attacks, and we’ll need researchers like our Crazy Laser Lady to find the reality behind advertised claims.

Continue reading “Burning Things With Big Lasers In The Name Of Security” →

Factory Laptop With IME Disabled

January 28, 2020 by 29 Comments

Unfortunately not all consumers place high value on the security of their computers, but one group that tends to focus on security are businesses with a dedicated IT group. When buying computers for users, these groups tend to have higher demands, like making sure the Intel Management Engine (IME) has been disabled. To that end, Reddit user [netsec_burn] has outlined a pretty simple method to where “normal people” can purchase one of these IME-disabled devices for themselves.

For those unfamiliar with the IME, it is a coprocessor on all Intel devices since around 2007 that allows access to the memory, hard drive, and network stack even when the computer is powered down. Intel claims it’s a feature, not a bug, but it’s also a source of secret, unaudited code that’s understandably a desirable target for any malicious user trying to gain access to a computer. The method that [netsec_burn] outlined for getting a computer with the IME disabled from the factory is as simple as buying a specific Dell laptop, intended for enterprise users, and selecting the option to disable the IME.

Of course Dell warns you that you may lose some system functionality if you purchase a computer with the IME disabled, but it seems that this won’t really effect users who aren’t involved in system administration. Also note that this doesn’t remove the management engine from the computer. For that, you’ll need one of only a handful of computers made before Intel made complete removal of the IME impossible. In the meantime, it’s good to see that at least one company has a computer available that allows for it to be disabled from the factory.

This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability

January 24, 2020 by 5 Comments

A critical security bug was fixed in Chrome recently, CVE-2020-6378. The CVE report is still marked private, as well as the bug report. All we have is “Use-after-free in speech recognizer”. Are we out of luck, trying to learn more about this vulnerability? If you look closely at the private bug report, you’ll notice it’s in the Chromium bug tracker. Chrome is based primarily on the Chromium project, with a few proprietary features added. Since Chromium is open source, we can go find the code change that fixed this bug, and possibly learn more about it.

Off to the Chromium source, mirrored on Github. We could look at every commit, and eventually find the one we’re looking for, but Chromium commit messages usually include a reference to the bug that is fixed by that commit. So, we can use Github’s search function to find a commit that mentions 1018677. Just like that, we’ve found a single commit and more information.

The shutdown mentioned in the commit message is possibly referring to the browser being closed, but could also refer to the tab doing the speech recognizing, or even the speech system itself. Because multiple parts are being unloaded in parallel, there is a race condition between calling the abort object, and that object being unloaded from memory. This race can result in a classic use-after-free, jumping code execution to a memory location that’s already been freed.

All interesting, but how does this warrant a Critical rating? Enter the Web Speech API. I’m speculating just a bit, but it’s likely that this API uses the speech recognizer code in question. It may even be interacting with the security prompt that triggers the crash. Imagine that an attacking page attempts to use the speech API, and then releases the API object before the user can respond to the prompt. That *might* be the scenario that was discovered, though we’re deep into speculation, now. Continue reading “This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability” →

Bringing The Blockchain To Network Monitoring

January 22, 2020 by 14 Comments

If you need to make sure your computer isn’t being messed with, you’ll have a look at the log files. If something seems fishy, that’s grounds for further investigation. If you run a large network of computers, you’ll probably want to look over all of the logs, but you won’t want to run around to each computer individually. Setting up a central server to analyze the logs exposes an additional attack surface: the logs in transit. How do you make sure that the attackers aren’t also intercepting and sanitizing your log file reports?

The answer to this question, and nearly everything else, is blockchain! Or maybe it’s not, but in this short presentation from the 2019 Hackaday Superconference, Shanni Prutchi, Jeff Wood, and six other college students intend to find out. While Shanni “rolls her eyes” at much of blockchain technology along with the rest of us, you have to admit one thing: recursively hashing your log data to make sure they’re not tampered with doesn’t sound like such a bad idea. Continue reading “Bringing The Blockchain To Network Monitoring” →

A Kill Cord To End Laptop Skulduggery

January 21, 2020 by 60 Comments

In our community it is common for ancient laptops to be used way beyond their usual service life, held together by stickers and lovingly upgraded to their maximum capabilities. We hope it’s unusual for such a venerable machine to be stolen, but it seems that grab-and-run thefts are very much a thing for owners of much shinier hardware. [Michael Altfield] has a solution to this problem, in the form of a kill cord that when broken by the crook making off with the loot, triggers a set of scripts that can wipe the device or otherwise make it useless.

Hardware-wise it’s simple enough, a USB magnetic breakaway adapter and a USB extension cable to a drive clipped to the laptop owner’s belt. On the software side it’s as straightforward as a udev rule to launch the disaster script of your choice. Perhaps you could link it to something like a glitter bomb and fart spray. But we can’t help worrying that it might be too easy to get up and accidentally detach yourself from the laptop, making it deploy whatever anti-theft measure you’d installed in error. If this goes some way to reducing theft though, it has to be worth a second look.

Thanks [bluewraith] for the tip.

Building A Better BitTorrent Client In Go

January 18, 2020 by 24 Comments

When it comes to peer-to-peer file sharing protocols, BitTorrent is probably one of the best known. It requires a client implementing the program and a tracker to list files available to transfer and to find peer users to transfer those files. Developed in 2001, BitTorrent has since acquired more than a quarter billion users according to some estimates.

While most users choose to use existing clients, [Jesse Li] wanted to build one from scratch in Go, a programming language commonly used for its built-in concurrency features and simplicity compared to C.

Client-server versus peer-to-peer architecture
Client-server versus peer-to-peer architecture

The first step for a client is finding peers to download files from. Trackers, web servers running over HTTP, serve as centralized locations for introducing peers to one another. Due to the centralization, the servers are at risk of being discovered and shut down if they facilitate illegal content exchange. Thus, making peer discovery a distributed process is a necessity for preventing trackers from following in the footsteps of the now-defunct TorrentSpy, Popcorn Time, and KickassTorrents.

The client starts off by reading a .torrent file, which describes the contents of the desired file and how to connect to a tracker. The information in the file includes the URL of the tracker, the creation time, and SHA-1 hashes of each piece, or a chunk of the file. One file can be made up of thousands of pieces – the client will need to download the pieces from peers, check the hashes against the torrent file, and finally assemble the pieces together to finally retrieve the file. For the implementation, [Jesse] chose to keep the structures in the Go program reasonably flat, separating application structs from serialization structs. Pieces are also separated into slices of hashes to more easily access individual hashes.

The bitfield explained as a coffee shop loyalty card.
The bitfield explained as a coffee shop loyalty card.

Next, a GET request to an `announce` URL in the torrent file announces the presence of the client to peers and retrieves a response from the tracker with the list of peers. To start downloading pieces, the client starts a TCP connection with a peer, completes a two-way BitTorrent handshake, and exchanges messages to download pieces.

One interesting data structure exchanged in the messages is a bitfield, which acts as a byte array that checks which pieces a peer has. Bits are flipped when their respective piece’s status changes, acting somewhat like a loyalty card with stamps.

While talking to one peer may be straightforward, managing the concurrency of talking to multiple peers at once requires solving a classically Hard problem. [Jesse] implements this in Go by using channels as thread-safe queues, setting up two channels to assign work and collect downloaded pieces. Requests are later pipelined to increase throughput since network round-trips are expensive and sending blocks individually inefficient.

The full implementation is available on GitHub, and is easy enough to use as an alternative client or as a walkthrough if you’d prefer to build your own.

This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt

January 17, 2020 by 18 Comments

Nicely timed to drop on the final day of Windows 7 support, Windows 10 received a fix to an extremely serious flaw in crypt32.dll. This flaw was reported by the good guys at the NSA. (We know it was the good guys, because they reported it rather than used it to spy on us.) It’s really bad. If you’re running Windows 10, go grab the update now. OK, you’re updated? Good, let’s talk about it now.

The flaw applies to X.509 keys that use elliptic curve cryptography. We’ve discussed ECC in the past, but let’s review. Public key encryption is based on the idea that some calculations are very easy to perform and verify, but extremely difficult to calculate the reverse operation.

The historic calculation is multiplying large primes, as it’s unreasonably difficult to factorize that result by a conventional computer. A true quantum computer with enough qubits will theoretically be able to factorize those numbers much quicker than a classical computer, so the crypto community has been searching for a replacement for years. The elliptic curve is the solution that has become the most popular. An agreed-upon curve and initial vector are all that is needed to perform the ECC calculation.

There are potential weaknesses in ECC. One such weakness is that not all curves are created equal. A well constructed curve results in good cryptography, but there are weak curves that result in breakable encryption.

With that foundation laid, the flaw itself is relatively easy to understand. An X.509 certificate can define its own curve. The Windows 10 implementation doesn’t properly check the curve that is specified. A malicious curve is specified that is similar to the expected curve — similar enough that the checks in crypt32 don’t catch it. Continue reading “This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt” →