Tricking Android Smart Lock With Bluetooth

The Smart Lock Feature allows Android users (Android version 5.0 and later) to automatically unlock their smartphone whenever a trusted device, Wi-Fi network or geo location is in close proximity. Trusted devices could either be NFC tags or Bluetooth devices. Looking at Bluetooth devices, it turned out that the Smart Lock implementation had at least one security issue that got resolved. Early implementations of Smart Lock implied that when a trusted Bluetooth device was connected to the phone it was safe to unlock the respective device. The method upon which the connected Bluetooth device was identified did miss an important point, though.

As many people know, every Bluetooth device has a unique Bluetooth device address (6 bytes) that is very similar to the MAC address of Ethernet interfaces. Spoofing Ethernet MAC addresses can be done by means of standard tools and can trigger (un-)desired behavior in some network components. Bluetooth device addresses can also be spoofed.

As you might guess, spoofing the Bluetooth device address of a trusted device does the trick with early versions of Smart Lock. But in order to unlock an Android device with Smart Lock, the trusted Bluetooth device needs to be connected to the smartphone. Connecting to a paired Bluetooth device requires a valid link key to be in place on both sides of the connection. The Bluetooth link key is generated by the Bluetooth pairing process. The pairing process requires the user to interact with the smartphone and – depending on the pairing mode – with the device to be paired. Assuming that the link key cannot be easily be obtained from the trusted device, the existence of the link key on the device in question does verify its authenticity to the device on the other side of the connection.

Proof of Concept

Early Smart Lock implementations rely on the implicit authenticity based on the existing link key that has to be present in order to establish an encrypted connection. Depending on the Bluetooth device mode and the different services and profiles that a Bluetooth host offers, not every connection has to be encrypted, though. In order to attack old versions of Smart Lock, adversaries need to set the Bluetooth device address of a trusted device and have to establish an unencrypted connection to the Android phone in order to unlock it.

As presented in the video, the attacker spoofs a Bluetooth headset which is set as a trusted device. By issuing an (unencrypted) connection to query the SDP records of the system, the Smart Lock application unlocks the device. At this point, also other unencrypted connections would have done the trick (e.g an unencrypted connection to the OBEX Push profile).

In order to spoof the address of a trusted Bluetooth device, adversaries have to know it. This can be achieved by scanning for visible devices or detect the device (with a little luck) by using specialized tools like Michael Ossmann’s Ubertooth One.

Spoofing a device address is done with the bdaddr tool which is part of the BlueZ stack.
# bdaddr -i hci0 -t -r 00:11:22:33:44:55
Use the bdaddr with the -t parameter in order to set the address temporarily. The -r switch will do a reset so that the newly configured BDADDR will take affect immidiately. In this example the BDADDR 00:11:22:33:44:55 is the address of the trusted Bluetooth device. Not every chipset is supported by the bdaddr tool. The tool is known to work with chips of the manufacturer CSR.

In order to establish the unencrypted connection, the following command can be used.
# sdptool records 00:11:22:FF:FF:FF
In the above example 00:11:22:FF:FF:FF is the address of the attacked phone. The sdptool records command establishes an unencrypted connection to the smartphone and iterates through all possible service numbers. By trying every possible handle, the command executes longer than the “sdptool browse” command, which increases the time that the attacker is able to unlock the phone without PIN.
Alternatively, attackers could establish an unencrypted connection to the OBEX push profile which would result in a lager time window that allows unlockung without PIN.

Check out the Video on Youtube!

Formal severity rating (SCAP)

The CVSS v2 base score is calculated with 6.8 (AV:L/AC:L/Au:S/C:C/I:C/A:C)

Affected products are:
cpe:/a:google:play_services_sdk:7.3.26 (and earlier)
on
cpe:/o:google:android:5.0.0
cpe:/o:google:android:5.0.1
cpe:/o:google:android:5.0.2

CVE ID: Pending

Solution

The issue here is, that early versions of Smart Lock do not check whether the Bluetooth connection from a trusted device was encrypted or not. In other words: the implicit authenticity of the connected device is not verified. In order to solve this, two modifications were necessary:

• The Bluetooth API had to be extended in order to check whether a Bluetooth connection is encrypted (Android 5.1 Changelog (line 8883))
• The Google Play Services Framework also had to undergo some changes (Fixed Version: Google Play Services 7.3.27)

Responsible Disclosure

The Vulnerability was disclosed to Google (Google Vulnerability Reward Program) in the end of January 2015. A fix was provided by the Google Security team by the beginning of April 2015.

People Involved

For questions about this vulberability, feel free to ask Martin Herfurt.