What can an attacker do with Bluetooth and how should it be mitigated?

(Note: This answer is from 2013. A lot has changed in Bluetooth since then, especially the sharp rise in BLE popularity, new attacks, deprecated features. Having that said, most of it is still applicable.)

Introduction

I'll try to the best of my knowledge to approach your questions without touching the technical parts of the Bluetooth technology itself. I've learned a lot of the following while I had to write a security report to shape a BYOD policy. Knowing you, I won't have to lecture you on that there's nothing 100% secure, everything we do is just to make it harder for the bad guys.

What Bluetooth is NOT

• Bluetooth itself as a technology isn't secure, it's not only about the implementation, there are some serious flaws in the design itself.

• Bluetooth isn't a short range communication method - just because you're a bit far doesn't mean you're safe. Class I Bluetooth devices have a range up to 100 meters.

• Bluetooth isn't a mature communicate method (security-wise). With smart phones, it has turned into something totally different from what it was meant to be. It was created as a way to connect phones to peripherals. My advice: Don't use Bluetooth for anything serious.

How is Bluetooth being secured now?

• Frequency hopping like crazy: Bluetooth uses something called AFH (Adaptive Frequency Hopping). It basically uses 79 channels in the 2.4 Ghz ISM band and it keeps hopping between them on a rate of 1600 hops/s, while observing the environment and excluding any existing frequencies from the hopping list. This greatly reduces interference and jamming attempts.

• E0 cipher suite: Uses a stream cipher with a 128-bit key.

• Undiscoverability: Unless you set your device to "discoverable" it won't respond to scanning attempts and your 48-bit BD_ADDR (the address that identifies your Bluetooth-enabled device) won't be revealed.

• Pairing: Unless the devices are paired with the parties' consent they won't be able to communicate. A pairing request can only be made if you know the other device's BD_ADDR (through scan or previous knowledge).

Is it a good idea to remove & re-pair my devices on a set interval (thinking that this is changing the Bluetooth PIN)

Yes. It's a very good idea. You're eliminating the risks of being exploited by your trusted devices. Given that we usually pair devices for insignificant reasons (sending a file to an acquaintance, getting a VCard from a person you met somewhere..) it's very likely to build a huge list of "trusted" devices if you use Bluetooth a lot.

What is the security impact of making my device or computer "discoverable"?

The problem with making your device discoverable is that you're advertising your BD_ADDR to anybody asking for it. The only way to pair with another device is by knowing the BD_ADDR. In a targeted attack, it's gonna take some time to brute-force the 48-bit BD_ADDR.

In the normal case, knowing your BD_ADDR shouldn't be a big problem, but in case there's a vulnerability in your phone or the Bluetooth software on your computer, it's better to be under the radar. Another problem is the impact on privacy; by being discoverable you're letting unpaired (untrusted) parties know when you're around.

What kind of access does a Bluetooth enabled device get on my system?

In the normal case (no vulnerability to allow arbitrary code execution) it all depends on the Bluetooth profiles supported by your device. Usually, you can assume that your computer supports all profiles. I'll just list a few:

• BHIDP (Bluetooth Human Interface Device Profile) will give access to your mouse and keyboard event firing (moving the mouse and sending keyboard keys).
• BIP (Basic Imaging Profile) will give access to your camera.
• A2DP (Advanced Audio Distribution Profile) will give access to your MIC and to your audio output.
• OBEX (OBject EXchange) is what you usually need to worry about. Depending on the implementation, it could give access to your files, phonebook, messages, etc.

Are there Bluetooth security features that may (or may not be enabled)? How can I audit for the presence (or lack of) these features?

Prior to Bluetooth V2.1, when implementing the protocol itself, the developer has the options to use Security Mode #1, which means no security at all. Devices are allowed to communicate without the need of pairing, and encryption isn't used.

Bluetooth V2.1 and newer require encryption.

As a user, there are a few things you can do to make your Bluetooth usage more secure. (See below)

Assuming encryption is a security feature that can be enabled, is it required or is it optional?

As in the previous question, it's implementation-dependeant. Usually encryption is used by default in PC-PC, smartphone-smartphone, and PC-smartphone communication. As of Bluetooth V2.1, encryption is enabled by default.

What can an attacker do once a malicious device is paired with mine?

Basically, anything that your device supports. To demonstrate this, just use an application called Super Bluetooth Hack, you'll see very scary things including:

- Ringing: playing sounds of incoming call, alarm clock.
- Calls: dialing number, ending a call.
- Keys, Pressed keys: pressing and watching pressed keys
- Contacts
- Reading SMS
- Silent mode: turning on or off
- Phone functionality: turning off the network / phone
- Alarms
- Clock: change date and time
- Change network operator
- Java: start, delete java applications
- Calendar
- Memory status
- Keylock

So what's wrong with Bluetooth?

• Complete trust in the paired device: A paired device has access to virtually all of the profiles supported by the other device. This includes OBEX and FTP (File Transfer Profile).

• Profiles have too much freedom: Profiles are allowed to choose whatever security mode they want. You're even able to implement your own version of OBEX without Bluetooth requiring you to use encryption or authentication at all. (Prior to Bluetooth V2.1)

• Weaknesses in E0: Since 1999, E0 vulnerabilities started to show. It was proven that it's possible to crack E0 with 2⁶⁴ rather than the 2¹²⁸ previously believed. Year after year, researchers have discovered more vulnerabilities, leading to the 2005 attack by Lu, Meier and Vaudenay. The attack demonstrated the possibility to recover the key with 2³⁸ operations.

• Pairing is loosely defined: Devices are allowed to implement their own pairing methods, including a 4-digit PIN which can be cracked in no time.

Finally, for good practice guidelines:

I'll list some of the important NSA Bluetooth Security Recommendations (I've modified some of them and added some of my own):

• Enable Bluetooth functionality only when necessary.
• Enable Bluetooth discovery only when necessary.
• Keep paired devices close together and monitor what's happening on the devices.
• Pair devices using a secure long passkey.
• Never enter passkeys or PINs when unexpectedly prompted to do so.
• Regularly update and patch Bluetooth-enabled devices.
• Remove paired devices immediately after use.

Update: An hour ago I was diving in the Bluetooth V4.0 specs, and, to my surprise, it appears they're still using E0 for encryption, and there were no good changes to the pairing mechanism. What's even worse is that they're pushing forward the number-comparison pairing mechanism, in which the users are shown a six-digit number on the two devices and asked to verify if they're the same. Which, in my opinion, opens huge doors for social engineering attacks.

For pairing scenarios that require user interaction, eavesdropper protection makes a simple six-digit passkey stronger than a 16-digit alphanumeric character random PIN code.

Source

Update 2: It seems like this "Just Works" 6-digit PIN is indeed problematic. Mike Ryan has demonstrated an attack on BLE and released the code as his tool "crackle" to brute-force the temporary key and decrypt the traffic.

Device security is limited to the type of device.

What are the security risks of Bluetooth and what technologies and best practices should be used to protect my device?

Each device provides a level of services. The services provided create the restrictions or limitations to access and exploit. The best protection is to keep Bluetooth turned off (if you're paranoid). Couple of interesting reads on Symantec's site and on Dark Reading.

What can an attacker do once a malicious device is paired with mine?

A few things that could happen:

• Someone could: steal phone books, photos, videos, calendars, or allow make phone calls, send and read e-mails, make appointments, and send SMS messages.

• After exploiting a mobile phone you could potentially send SMS message with a bomb threat to the local police station. The billing records would certainly point directly to you as the phone owner and the real sender of the SMS. It really depends on the target system's implementation of the Bluetooth standard. Norton

• They could also potentially listen to phone calls (if they've spoofed a headset) and control your mouse cursor on your desktop (if they spoofed your mouse).

I had a little fun with a car stereo at a Nissan dealership while I was bored waiting for my service to be done. The stereo in one of the demo cars was discoverable, so I paired during a demo when the salesman was showing the new features to a potential buyer, they paired with my device, then when the potential customer indicated that their pairing had failed they tried again (we were both paired). Then after the sales staff walked away I "possessed" the stereo, streaming random songs and controlling the volume. Someone would walk away from the car, the stereo would get louder. Someone would walk toward the car, then the stereo would get quieter. This was all fun until I received a phone call and the stereo auto-answered and almost blew my cover (I ignored the call).

Is it a good idea to remove & re-pair my devices on a set interval (thinking that this is changing the Bluetooth PIN)

Since the system is easily exploitable, doing this doesn't remove the original vulnerabilities that exist in the target hardware's communication limitations with other devices (its trust level). dark reading

What is the security impact of making my device or computer "discoverable"?

By making your system "discoverable" you allow someone to impersonate your device by renaming their device to match. This is unavoidable on some devices.

What kind of access does a Bluetooth enabled device get on my system?

This depends on the restrictions in place on the system itself. If your system assumes that all wireless mice or wireless headsets behave the same way because the software developer didn't take the time to secure the exchanges and someone impersonates your wireless mouse, they could have access to everything allowed in your system's services. On Windows apparently this might mean full control.

How can I control the scope of access a Bluetooth device has? (if my phone were compromised I'd want to limit the exposure my PC has)

Any bluetooth system can potentially be compromised in its own ways because of the limitations in security implementation. Someone within range can just as easily compromise your "discoverable" desktop or laptop as they can your mobile phone, your headset, your mouse, your bluetooth enabled refrigerator, etc. Unpair and disable Bluetooth when you're not using it. Switch off dumb devices when not in use.

Are there Bluetooth security features that may (or may not be enabled)? How can I audit for the presence (or lack of) these features?

This depends on the device. Devices such as wireless mice will not have a log of activity. Desktops may. Some mobile phones do not.

Assuming encryption is a security feature that can be enabled, is it required or is it optional? (moreover could an SSL Strip for Bluetooth be created?)

Encryption can only be handled by devices that support it. In the initial handshake if you indicate your device doesn't have encryption capabilities, then the system will not try to encrypt transactions. Wireless mice for instance will not transmit secure signals.

Mac Bluetooth vulnerability exploited for Trojan deployment Windows vulnerabilities

An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. This vulnerability only affects systems with Bluetooth capability.

Linux Bluetooth exploit includes memory stack manipulation and reading.

Good luck.

This answer may be incomplete or incorrect as my knowledge on the topic is limited, but my understanding of Bluetooth is that it is a fairly loose stack on which different protocols (called profiles) can be developed. A lot of the particulars of security are going to depend on the particular Bluetooth stack and profile that you have on your hardware.

Assuming that your Bluetooth stack (the drivers for your hardware) don't have any security flaws, having a device discoverable shouldn't make any difference so long as auto-pairing is off. The worst someone could do is make a pairing request which you could then deny.

The level of access that a Bluetooth device gets to a system is entirely determined by how the Bluetooth stack and profiles are implemented and configured, so it isn't really possible to answer this part of the question directly.

Perhaps the best parallel would be to think of Bluetooth like a little server that provides a variety of different services over a short range radio link. The services offered and how the services are implemented can differ greatly, but the protocol used for each type of profile is consistent. (For example, headset audio is a common profile, as is AVRCP (audio/video remote control protocol)).

As for pairing, during the pairing process, a shared secret key is developed to be used in the future. As long as the shared secret is not leaked by either device, another device could not impersonate that pair. Also, as long as communications are encrypted with that key, rather than just a handshake, then the communications themselves would be secure.

According to Wikipedia, encryption was optional in Bluetooth prior to 2.1 and could be easily broken if used for more than about a day, however 2.1 and newer versions of Bluetooth fix this by requiring encryption on anything other than service discovery and better shared key management.