COVID-tracing Framework Privacy Busted By Bluetooth

September 3, 2020 by Elliot Williams 60 Comments

[Serge Vaudenay] and [Martin Vuagnoux] released a video yesterday documenting a privacy-breaking flaw in the Apple/Google COVID-tracing framework, and they’re calling the attack “Little Thumb” after a French children’s story in which a child drops pebbles to be able to retrace his steps. But unlike Hänsel and Gretl with the breadcrumbs, the goal of a privacy preserving framework is to prevent periodic waypoints from allowing you to follow anyone’s phone around. (Video embedded below.)

The Apple/Google framework is, in theory, quite sound. For instance, the system broadcasts hashed, rolling IDs that prevent tracing an individual phone for more than fifteen minutes. And since Bluetooth LE has a unique numeric address for each phone, like a MAC address in other networks, they even thought of changing the Bluetooth address in lock-step to foil would-be trackers. And there’s no difference between theory and practice, in theory.

In practice, [Serge] and [Martin] found that a slight difference in timing between changing the Bluetooth BD_ADDR and changing the COVID-tracing framework’s rolling proximity IDs can create what they are calling “pebbles”: an overlap where the rolling ID has updated but the Bluetooth ID hasn’t yet. Logging these allows one to associate rolling IDs over time. A large network of Bluetooth listeners could then trace people’s movements and possibly attach identities to chains of rolling IDs, breaking one of the framework’s privacy guarantees.

This timing issue only affects some phones, about half of the set that they tested. And of course, it’s only creating a problem for privacy within Bluetooth LE range. But for a system that’s otherwise so well thought out in principle, it’s a flaw that needs fixing.

Why didn’t the researchers submit a patch? They can’t. The Apple/Google code is mostly closed-source, in contrast to the open-source nature of most of the apps that are running on it. This remains troubling, precisely because the difference between the solid theory and the real practice lies exactly in those lines of uninspectable code, and leaves all apps that build upon them vulnerable without any recourse other than “trust us”. We encourage Apple and Google to make the entirety of their COVID framework code open. Bugs would then get found and fixed, faster.

Continue reading “COVID-tracing Framework Privacy Busted By Bluetooth” →

This Week In Security: XCode Infections, Freepik, And Crypto Fails

August 28, 2020 by Jonathan Bennett 8 Comments

There is a scenario that keep security gurus up at night: Malware that can detect software compilation and insert itself into the resulting binary. A new Mac malware, XCSSET (PDF), does just that, running whenever Xcode is used to build an application. Not only is there the danger of compiled apps being malicious, the malware also collects data from the developer’s machine. It seems that the malware spreads through infected Xcode projects.

WordPress Plugins

WordPress has a complicated security track record. The core project has had very few serious vulnerabilities over the years. On the other hand, WordPress sites are routinely compromised. How? Generally through vulnerable plugins. Case in point? Advanced Access Manager. It’s a third party WordPress plugin with an estimate 100,000 installations. The problem is that this plugin requires user levels, a deprecated and removed WordPress feature. The missing feature had some unexpected results, like allowing any user to request administrator privileges.

The issue has been fixed in 6.6.2 of the plugin, so if you happen to run the Advanced Access Manager plugin, make sure to get it updated. Beyond that, maybe it’s time to do an audit on your WordPress site. Uninstall unused plugins, and make sure the rest are up to date, along with the WordPress installation itself. Continue reading “This Week In Security: XCode Infections, Freepik, And Crypto Fails” →

FBI Reports On Linux Drovorub Malware

August 22, 2020 by Al Williams 26 Comments

The FBI and the NSA released a report on the Russian-based malware that attacks Linux known as Drovorub (PDF) and it is an interesting read. Drovorub uses a kernel module rootkit and allows a remote attacker to control your computer, transfer files, and forward ports. And the kernel module takes extraordinary steps to avoid detection while doing it.

What is perhaps most interesting though, is that the agencies did the leg work to track the malware to its source: the GRU — Russian intelligence. The name Drovorub translates into “woodcutter” and is apparently the name the GRU uses for the program.

A look inside the code shows it is pretty mundane. There’s a server with a JSON configuration file and a MySQL backend. It looks like any other garden-variety piece of code. To bootstrap the client, a hardcoded configuration allows the program to make contact with the server and then creates a configuration file that the kernel module actively hides. Interestingly, part of the configuration is a UUID that contains the MAC address of the server computer.

The rootkit won’t persist if you have UEFI boot fully enabled (although many Linux computers turn UEFI signing off rather than work through the steps to install an OS with it enabled). The malware is easy to spot if you dump raw information from the network, but the kernel module makes it hard to find on the local machine. It hooks many kernel functions so it can hide processes from both the ps command and the /proc filesystem. Other hooks remove file names from directory listings and also hides sockets. The paper describes how to identify the malware and they are especially interested in detection at scale — that is, if you have 1,000 Linux PCs on a network, how do you find which ones have this infection?

This is a modern spy story, but not quite what we’ve come to expect in Bond movies. “Well, Moneypenny, it appears Spectre is using the POCO library to generate UUIDs,” is hard to work into a trailer. We prefer the old days when high-tech spying meant nonlinear junction detectors, hacking Selectrics, moon probe heists, and passive bugging.

This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by Jonathan Bennett 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →

Eavesdropping On Satellites For Fun And Profit

August 20, 2020 by Dan Maloney 8 Comments

Geosynchronous satellites, girdling the Earth from their perches 36,000 km above the equator, are remarkably useful devices. Depending on where they’re parked, they command views of perhaps a third of the globe at a time, making them perfect communications relays. But as [James Pavur] points out in his DEF CON Safe Mode talk, “Whispers Among the Stars”, geosynchronous satellite communication links are often far from secure.

[James], a D. Phil. student in Systems Security at Oxford University, relates that his exploits rely on the wide areas covered by the downlink signals from the satellites, coupled with security as an afterthought, if it was even thought of at all by satellite service providers. This lackadaisical approach let him use little more than a regular digital satellite TV dish and a tuner card for a PC — off-the-shelf stuff that you’d really have to try hard to spend more than $300 on — to tap into sensitive information.

While decoding the digital signals from satellites into something parseable can be done with commercial applications, [James] and his colleagues built a custom tool, GSExtract, to pull data from the often noisy signals coming down from on high. The setup returned an amazing bounty of information, like maritime operators relaying the passport information of crew members from ship to shore, point-of-sale terminal information from cruise ships in the Mediterranean, and in-flight entertainment systems in jet airliners. The last example proved particularly alarming, as it revealed an exploitable connection between the systems dedicated to keeping passengers content and those in the cockpit, which clearly should not be the case.

We found [James’] insights on these weaknesses in satellite communications fascinating, and it’s well worth the 45 minutes to watch the video below and perhaps try these exploits, which amount to side-channel attacks, for yourself.

Continue reading “Eavesdropping On Satellites For Fun And Profit” →

Give A Man A Phish, And You Entertain Him For A Day

August 16, 2020 by Sven Gregori 11 Comments

With millions of phishing attempts happening daily, we’ve probably all had our fair share of coming across one. For the trained or naturally suspicious eye, it’s usually easy to spot them — maybe get a good chuckle out of the ridiculously bad ones along the way — and simply ignore them. Unfortunately, they wouldn’t exist if they weren’t successful enough in the big picture, so it might be a good idea to inform the targeted service about the attempt, in hopes they will notify users to act with caution. And then there’s [Christian Haschek], who decided to have some fun and trying to render the phished data useless by simply flooding it with garbage.

After his wife received a text message from “their bank”, [Christian] took a closer look at the URL it was pointing to, and found your typical copy of the real login form at a slightly misspelled address. As the usual goal is to steal the victim’s credentials, he simply wrote a shell script that sends random generated account numbers and PINs for all eternity via cURL, potentially lowering any value the attackers could get from their attempt.

As the form fields limit the input length of the account number and PIN, he eventually wondered if the server side will do the same, or whether it would crash if longer data is sent to it. Sadly, he’ll never know, because after he modified the script, the site itself returned a 404 and had disappeared.

In the quest against phishing attacks, this should count as a success, but as [Christian] seemed to enjoy himself, he yearned for more and decided to take a look at a similar attempt he saw mentioned earlier on Reddit. Despite targeting the same bank, the server-side implementation was more sophisticated, hinting at a different attack, and he definitely got his money worth this time — but we don’t want to give it all away here.

Rest assured, [Christian Haschek] continues the good fight, whether by annoying attackers as he did with ZIP-bombing random WordPress login attempts or battling child pornography with a Raspberry Pi cluster. Well, unless he’s busy hunting down an unidentified device hooked up in his own network.

(Banner image by Tumisu)

This Week In Security: DEF CON, Intel Leaks, Snapdragon, And A Robot Possessed

August 14, 2020 by Jonathan Bennett 6 Comments

Last weekend, DEF CON held their “SAFE MODE” conference: instead of meeting at a physical venue, the entire conference was held online. All the presentations are available on the official DEF CON YouTube channel. We’ll cover a few of the presentations here, and watch out for other articles on HaD with details on the other talks that we found interesting.
Continue reading “This Week In Security: DEF CON, Intel Leaks, Snapdragon, And A Robot Possessed” →