From avoiding awkward bus conversations to tether-less keyboards, Bluetooth is the magic sauce that frees us from the draconian bondage of wired peripherals. Who among us has not been enjoying some gnarly tunes and experienced the moment the music died when your headphone cord caught on a doorknob? That irrational split-second of rage followed by overwhelming concern that your beloved cans have been irreparably damaged (quality cans are user-serviceable, come at me audiophiles) is quickly becoming an experience of the past. Bluetooth, having come of age, has shown us the way of the future. It is good and wire-free. Unfortunately, as with many protocols that have grown up along with maturing cryptographic schemes and increasingly-sophisticated attacks (looking at you, DNS), a fundamental weakness in the protocol’s design has been uncovered – and published.
Professor Eli Biham and graduate Student Lior Neumann, at Technion’s Hiroshi Fujuwara Cyber Security Research Center & Computer Science Department at the Israel Institute of Technology, published their paper detailing an attack on the Bluetooth protocol last week. The Fixed Coordinate Invalid Curve attack targets the key exchange process when two devices are paired, giving attackers a privileged position in the chain of communication.
“The technology we developed reveals the encryption key shared by the devices and allows us, or a third device, to join the conversation. We can eavesdrop on or sabotage a conversation. As long as we do not actively participate, the user has no way of knowing that there is a third party listening in.”
– Prof. Biham, quoted in the paper’s press release.
A little history:
Bluetooth was developed as a wireless alternative to RS-232 in 1994 by Jaap Haartsen, an electrical engineer working for Ericsson. The standard uses the 2.4-2.485ghz wireless spectrum range for communication and can form peer-to-peer connections, piconets and personal area networks (PANs). Today, the Bluetooth Special Interest Group (SIG) manages development of the protocol and defines the standards manufacturers must meet to sell products as a “Bluetooth” device. What began as a low-bandwidth, limited protocol has blossomed into a well-rounded and indispensable technology.
Did I mention encryption? Bluetooth supports two security modes and four security levels. These can be mixed-and-matched by manufacturers to achieve a desired level of security. Check out Duo Security’s excellent article, “Understanding Bluetooth Security”, which takes a deep dive into the structure and implications of these options.
Wait, didn’t I read about a serious Bluetooth vulnerability a while ago?
Yes, yes you did. In April 2017 security firm Armis discovered BlueBorne, a collection of vulnerabilities in the Bluetooth implementation in Windows, Linux, iOS and Android. This attack was serious business – just about every device with Bluetooth was vulnerable (estimated at 8.2 billion devices by Armis). Exploiting these vulnerabilities allowed attackers to connect to devices and systems without authentication, even if the target device was not already paired with the attacker’s or in a discoverable state. This bypass of security measures gave attackers to have full control over compromised devices.
Armis worked with affected companies to produce patches before publishing their research, as did Biham and Neumann. Responsible disclosure practices help keep users safe while allowing security researchers to receive credit where it’s due. Discovering and documenting vulnerabilities often represents a massive investment in time, resources and passion. Researchers deserve to be recognized for their contributions – by finding and responsibly disclosing vulnerabilities they greatly reduce the potential for damage.
A number of Bluetooth vulnerabilities have been discovered over the years. Some have been addressed with OS patches, others with improvements to the protocol. Consider this: if you have a device that’s unsupported or hasn’t been updated since mid-2017, you’re vulnerable to BlueBorne attack as well as the new Fixed Coordinate Invalid Curve attack.
How the Fixed Coordinate Invalid Curve works:
When devices are paired they use elliptic curve cryptography (Diffie-Hellman protocol) to secure the exchange of Bluetooth’s encryption keys. Each device generates a public DH key pair. These public keys are exchanged and used to generate the session key, which is used protect the Bluetooth traffic. This initial DH key exchange where the attacker must intervene.
The FCIC attack exploits a flaw in the way that devices validate solutions for the elliptic curve mathematical equation. Unpatched Bluetooth implementations don’t do a great job with this and allow an attacker to set a solution for the math problem that falls outside the curve. This attack has a success rate of 50% for pairing attempts.
With this vulnerability, the attacker is able to force devices to use a pre-determined key rather than one that was randomly-generated. Since the attacker knows the encryption key in use they can eavesdrop on data in a passive attack or issue commands and manipulate information in an active attack.
“In both cases, our attack recovers the session encryption key on success, while on failure our attack causes a denial of service.”
– Section 1.4 of Biham and Neumann’s research paper
In a successful attack, the attacker’s presence is undetectable as long as they’re only listening in on the conversation. In an unsuccessful attack the user would see the standard behavior presented by their device when pairing fails. This behavior is dependent on the software implementation in use. Android and iOS, for example, will have similar but distinct UI responses. We’ve all had this happen as users – you grumble about technology and move through the prompts to restart the pairing process. This presents the attacker with another opportunity to manipulate the conversation.
The fix for this vulnerability requires that the device verify the elliptic curve key being used is a valid solution (that it falls on the curve). If the key doesn’t fit, the devices will use a different key that does. The attacker won’t know the key being used and can’t eavesdrop on the conversation.
What you can do:
Fortunately, the mitigation for this attack is very straightforward: only one of the paired devices must be patched. For example, updating your smartphone protects the connection between it and a speaker or headset.
Take inventory of devices and software. Knowing what you have is the first step in mitigating the threat this vulnerability poses. This process isn’t limited to enterprise environments – take a look around and think about the devices paired with your phone, tablet, computer… it’s likely a longer list than you thought and you’ll probably find a few surprises.
Update your software. For consumers, there is NO REASON to postpone updating your devices for more than a week. Bugs in patches will be found and fixed quickly. If you’re a company, being more cautious is prudent as IT services support the departments generating revenue. No computers, no money. No matter who you are, always ensure that your critical data is backed up before applying patches.
Leave computing devices that can’t be updated in the dust. The key here is to make sure at least one of the paired devices is patched. There’s no need to dump your beloved old Bluetooth speaker as long as the device it’s connected to is up to date. But if that Android tablet is stuck on KitKat and will never see an update, it’s time to: