Thyrasec Blog / Guide

A Guide to Bluetooth Man-In-The-Middle (MITM)

One of the more challenging aspects of Bluetooth security is dealing with practical attacks. Man-In-The-Middle attacks represent some of the challenging attacks on Bluetooth and BLE that product developers deal with.

One of the major reasons developers choose Bluetooth is the baked in security in the protocol. Even though Bluetooth security has been attacked and multiple vulnerabilities have been uncovered, products greatly benefit from using good proven security provided by the protocol. With that said, it’s often the case that products aren’t taking full advantage of the features.

What is a Bluetooth Man-In-The-Middle Attack?

A Man-in-the-Middle attack happens when a malicious actor intercepts communications between two parties without their knowledge. In the case of Bluetooth, a MITM attack involves an attacker positioning themselves near two Bluetooth devices.

A good example is a Bluetooth keyboard. A keyboard can send important information like passwords or code that an attacker can user for further attacks.

A Bluetooth attacker performing a MITM attack in the example above creates two connections:

  • A connection between the attacker and the keyboard – Central
  • A connection between the attacker and the computer – Peripheral

An attacker forces the devices to connect indirectly through it, and each device ends up encrypting data using an encryption key that the attacker knows.

Performing a successful MITM attack on Bluetooth requires actively sending packets.

Risks Associated with Bluetooth MITM Attacks

  1. Data Interception: Perhaps the most obvious risk is the interception of sensitive data. Bluetooth connections often transmit personal information, such as contact lists, messages, or financial data. Intercepting this data can lead to identity theft, financial loss, or unauthorized access to personal accounts.
  2. Device Compromise: MITM attacks can also lead to the compromise of connected devices. By intercepting communication between a smartphone and a smart lock, for example, an attacker could gain unauthorized access to the lock, compromising the security of the premises.
  3. Malware Injection: In addition to intercepting data, attackers can inject malware into the communication stream. This malware could then infect the connected devices, leading to further exploitation or data exfiltration.

Vulnerabilities in Legacy Pairing

Bluetooth legacy pairing is vulnerable not only to active attacks like MITM, but to passive attacks as well where an attacker is just capturing packets from the air.

To avoid Legacy Pairing, you must use the Bluetooth Secure Connections and Secure Simple Pairing features. These will prevent passive packet capture from working. Let’s understand why.

Why Bluetooth needs specific MITM protection?

Assuming you’re using LE Secure Connections or BR/EDR Secure Connections, Bluetooth will leverage Elliptic Curve Diffie Hellman (ECDH) cryptography to perform key exchange.

ECDH allows two devices who have a private/public key combination to establish a shared secret over an insecure channel. In the case of Bluetooth, it’s a series of keys and ultimately the Long Term Key (LTK).

Even though Asymmetric Key crypto (like ECC and RSA) can be used for encrypting and decrypting, they’re typically inefficient. So the main use of asymmetric crypto is to exchange a key that will be used by symmetric cryptography, in this case AES.

So we have two devices, they each have a private and public key, can communicate and exchange information and establish keys via ECDH. But there’s a problem. How do you know that the public key you’re being presented with belongs to the party you want to talk to? After all, an attacker can easily present you with any public key.

This is the core issue that enables MITM attacks, and the reason why MITM protection is more complex on Bluetooth.

This issue isn’t unique to Bluetooth. On the Web, this same issue is resolved by the way of a Public Key Infrastructure and certificates. Modern browsers and operating systems come with a set of certificates belonging to trusted entities such as Microsoft Root Authority, Thawte Timestaming CA, and many others.

These certificates provide a chain of trust, so that when your browser is presented with a certificate of a website, you know that the certificate is valid because it was signed by a trusted party. You implicitly trust that the authority has gone to some lengths to ensure the certificate is properly owned by the right entity.

In the case of Bluetooth, there are no certificates, root of trust or a public key infrastructure. This is because supporting X.509 certificates is complicated, and since Bluetooth runs on small embedded devices, there may not be enough memory to support this.

Even worse, Bluetooth devices are oftentimes limited in their interface. Most devices have nothing more than a button. Others have keyboard or display, maybe both. A perfect example is a Bluetooth headset that has no display or keyboard.

Because of these limitations, the Bluetooth SIG created several approaches to help secure devices against MITM, if possible. These approaches require some form of Input/Output (IO). For devices that don’t have any protection, there can’t be any MITM protection using Bluetooth without creating a custom security scheme. Let’s go over these approaches.

Bluetooth Secure Simple Pairing (SSP) and LE Secure Connections Association Models for MITM

Remember that our goal to be able to ensure that we’re talking to the right device.

Both LE Secure connections and Secure Simple Pairing (used in BR/EDR) use basically the same association models. These are the modes that the pairing association is established and allows a system to be secure against MITM attacks.

  • Just Works – When one of the devices has no I/O capabilities, then this is the only possibility. Just works uses Numeric Comparison, but uses 0 as the. With Just Works there is no MITM protection
  • Passkey Entry – Used when one device has an input ability to enter digits but doesn’t have a display. For example, a keyboard can enter a passkey but can’t display the results. This model provides MITM protection
  • Numeric Comparison – When the two devices connecting both have a display capable of showing the six digit number and a button able to confirm or reject the number. This Model provides MITM protection
  • Out of Band – This mechanism allows sending the keys via an out of band methodology that’s implementation specific. The security of this approach depends on the mechanism. This is a relatively rare approach from our experience because it requires custom implementation and a communications method.

The purpose of the association models is to help a user confirm they’re talking to the right device. this doesn’t even have to be only for security – in a place with multiple identical products, making sure that you’re connecting to the right device is critical.

The Table above shows the combination of IO capabilities and possible model to use. It’s important to note that MITM protection depends on the capabilities of both devices. If either device has no I/O or no button, then Just Works, which doesn’t provide any protection, is the only option.

How practical are Bluetooth Man-In-The-Middle Attack?

Even though the Bluetooth specification considers active MITM attacks to be difficult, the reality is that doing these attacks is not that difficult in practice. In fact, we perform them all the time and the equipment doesn’t need to be sophisticated

  • You need hardware capable of acting as both BLE Central and Peripheral. This can be a Linux device, or an embedded board
  • If the devices being attacked are connected, they can be made to disconnect, or an attacker can wait for a moment when the connection stops

Just to remind you, the Bluetooth MITM mitigation reduces the possibility of an MITM attacker being successful to about 1 in 10^16, which is extremely low.

A huge problem for Bluetooth devices is that many of them have no ability to counter MITM attacks because they have no IO. That makes it possible to attack many devices because they rarely implement any additional security to compensate for these limitations.

Additional Factors in MITM attacks

Our assumption above in attacking Bluetooth devices is that we can force the devices to connect to us instead of two each other. That’s relatively easy when the devices have never before connected because we can attack them when that happens.

When two devices have already connected, our success depends partially in forcing the devices to ignore or delete the keys they previously used, or allow for a new connection. This isn’t always possible. Whether a Bluetooth device allows this to happen depends on the system design.

One of the features that can be exploited is the repairing mechanism. Assume that a user replaced a keyboard, then the user must be allowed to connect a new keyboard to the PC. However, this mechanism may not be easy to exploit because it could require that the user to manually perform this step. For example, deleting a Bluetooth device or pressing a button on the keyboard.

Mitigating MITM Attacks

While Bluetooth MITM attacks pose a significant threat, there are several measures that users and manufacturers can take to mitigate the risk:

  1. Use Secure Pairing: Utilize Bluetooth pairing methods that offer stronger security, such as Secure Simple Pairing (SSP), Numeric Comparison and LE Secure Connections (LESC) and avoid Legacy Pairing which offers no security
  2. Leverage Display, Keyboard, and IO
  3. Stay Vigilant: Be cautious when connecting to unfamiliar Bluetooth devices. Verify the identity of devices before pairing and avoid sharing sensitive information over Bluetooth in untrusted environments. When critical, perform the pairing in a secure location.

Custom MITM Mitigation

In cases where protecting against MITM is a must but the product design won’t allow the right I/O combination, then a custom security authentication mechanism can be implemented. For example, the use of a certificate exchange with a pre-established PKI is one approach that we have implemented in medical devices.

Conclusion

Bluetooth MITM attacks represent a serious threat to the security and privacy of Bluetooth-enabled devices. By understanding the risks associated with these attacks and implementing appropriate security measures, users and manufacturers can mitigate the threat and safeguard against potential exploitation. As Bluetooth technology continues to evolve, so too must our efforts to protect against emerging security threats.