Security Hacks

1528 Articles

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 25 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” →

Take Security Up A Notch By Adding LEDs

January 12, 2020 by 14 Comments

All computers are vulnerable to attacks by viruses or black hats, but there are lots of steps that can be taken to reduce risk. At the extreme end of the spectrum is having an “air-gapped” computer that doesn’t connect to a network at all, but this isn’t a guarantee that it won’t get attacked. Even transferring files to the computer with a USB drive can be risky under certain circumstances, but thanks to some LED lights that [Robert Fisk] has on his drive, this attack vector can at least be monitored.

Using a USB drive with a single LED that illuminates during a read OR write operation is fairly common, but since it’s possible to transfer malware unknowingly via USB drives, one that has a separate LED specifically for writing operations will help alert a user to any write operations that might be trying to fly under the radar. A recent article by [Bruce Schneier] pointed out this flaw in USB drives, and [Robert] was up to the challenge. His build returns more control to the user by showing them when their drive is accessed and in what way, which can also be used to discover unique quirks of one’s chosen operating system.

[Robert] is pretty familiar with USB drives and their ups and downs as well. A few years ago he built a USB firewall that was able to decrease the likelihood of BadUSB-type attacks. Be careful going down the rabbit hole of device security, though, or you will start seeing potential attacks hidden almost everywhere.

This Week In Security: Camera Feeds, Python 2, FPGAs

January 10, 2020 by 6 Comments

Networked cameras keep making the news, and not in the best of ways. First it was compromised Ring accounts used for creepy pranks, and now it’s Xiaomi’s stale cache sending camera images to strangers! It’s not hard to imagine how such a flaw could happen: Xiaomi does some video feed transcoding in order to integrate with Google’s Hub service. When a transcoding slot is re-purposed from one camera to another, the old data stays in the buffer until it is replaced by the new camera’s feed. The root cause is probably the same as the random images shown when starting some 3D games.

Python is Dead, Long Live Python

Python 2 has finally reached End of Life. While there are many repercussions to this change, the security considerations are important too. The Python 2 environment will no longer receive updates, even if a severe security vulnerability is found. How often is a security vulnerability found in a language? Perhaps not very often, but the impact can be far-reaching. Let’s take, for instance, this 2016 bug in zipimport. It failed to sanitize the header of a ZIP file being processed, causing all the problems one would expect.

It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2.
Continue reading “This Week In Security: Camera Feeds, Python 2, FPGAs” →