The Bluetooth “device snooping bug” – what you need to know

“Curiouser and curiouser,” said Alice. “I wonder what all these security bulletins are for?”

That was how I felt this morning, seeing that a sea of Apple security announcements had dropped into my inbox overnight.

But a quick visit to Settings → General → Software Update on my iPhone took just a couple of seconds to confirm:

iOS 11.4.1
Your software is up to date.

I had a similar outcome on my Mac when I went Apple → About This Mac → Software Update....

On reaching my desk at Sophos HQ, the mystery deepened when I was asked to comment on the newly-published Carnegie Mellon’s CERT Vulnerability Note VU#304725, detailing a security hole dubbed CVE-2018-5383.

The CVE-2018-5383 bug has the full and imposing title:

Bluetooth implementations may not sufficiently validate elliptic curve parameters during Diffie-Hellman key exchange.

Simply put, a crook who is in the right place at the right time might be able to figure out the encryption key that one of your Bluetooth devices is using to talk to your laptop, or your bicycle computer, or your phone, or whatever it’s paired with.

This sounds serious – presumably, this sort of bug could allow crooks to listen to, or even to interfere with, data coming out of your Bluetooth devices, from heart rate monitors and bicycle power meters all the way to mice and keyboards.

Sniffed-out keyboard data could be used to get hold of passwords you just typed in; modified keyboard transmissions could be used to alter data you’d just entered, leaving you with wrongly-edited documents or taking you to websites you never intended to visit.

Diffie-Hellman is more correctly called Diffie-Hellman-Merkle (DHM) after its three co-inventors. Martin Hellman himself has urged that Ralph Merkle’s name ought to be included, and we agree, so DHM is how we shall refer to it here.

Sharing secret keys securely

Diffie-Hellman-Merkle was a breakthrough when it was published in the 1970s, because it was the first public and practical algorithm for sharing secret encryption keys without needing a pre-existing secure channel.

Imagine where internet commerce would be without a system like DHM – every time you wanted to do business with someone online, you’d have to visit their offices first with a USB drive so you could securely collect the encryption keys to use when you got back home.

In theory, even if crooks can intercept all the network data that’s exchanged at the start of a network session by a correctly implemented DHM algorithm , they won’t learn enough to be able to figure out the encryption key agreed upon for that session.

In other words, the crooks won’t subsequently be able to eavesdrop on or to tamper with the traffic that’s exchanged, even if they were there and listening in right from the start.

But CVE-2018-5383 is an implementation flaw discovered by Israeli cryptographers Lior Neumann and Eli Biham – some Bluetooth firmware has bugs that get in the way of the anti-snooping/anti-tampering properties of DHM.

A crook within Bluetooth range might be able to interfere with the device connection process – what’s called a Man-in-the-Middle, or MiTM, attack – in such a way as to extract the secret encryption key that each end of the Bluetooth session just agreed on.

What to do?

According to Carnegie Mellon’s vulnerability notice, Apple, amongst others, only published an update for this bug on 2018-07-23 – the date that the vulnerability was publicised, and the date of Apple’s latest wave of security bulletin emails.

Yet Apple’s own products will report that “your software is up to date” if you try to get this apparently important fix.

That’s because Apple’s latest security bulletin isn’t announcing that a fix is available, merely that this issue was already fixed – in the update before last, in fact, namely when iOS 11.4 and macOS 10.13.5 came out. (Current Apple version numbers are iOS 11.4.1 and macOS 10.13.6.)

So, it looks as though 2018-07-23 was merely the pre-arranged date for talking publicly about CVE-2018-5383, rather than the date at which vendors started fixing it.

Are you safe?

According to Cargnegie Mellon’s chart, Bluetooth code from Android, Microsoft and Apple is either already updated or was never affected…

…but you will need to check with your phone vendor or mobile carrier to make sure that the patches added to the Android Open Source Project have made their way to your handset.

In the meantime:

• To exploit this vulnerability, crooks need to be in range when you first connect to a Bluetooth device. As far as we can see, they can’t start snooping on a device that’s already connected, which limits the extent of any attacks.
• If you’re not using Bluetooth, turn if off. You’ll save battery and avoid any sort of unwanted pairings or connections, as well as neutralising any cryptographic attacks that might exist. You’ll also avoid inadvertently broadcasting your Bluetooth hardware address, a detail that makes you easier to track.