Initially created to support hands-free headsets, Bluetooth in 2017 is far from a simple wireless technology standard. It has evolved into a much different technology than today’s standard Wi-Fi wireless protocols.
Researchers Ben Seri and Gregory Vishnepolsky of Armis Labs examine how complicated the Bluetooth implementation has become by navigating the complex protocol implementations in their BlueBorne disclosure white paper, which also includes eight new CVEs, several containing unauthenticated remote code execution and man-in-the-middle (MitM) attacks.
As of Sept. 12, 2017, much of the code vulnerable to these attacks is unpatched. This means that firms should immediately disable Bluetooth on all unpatched managed devices. Although the researchers sent prior notifications to each company affected by the findings, many vendors, including Google and Android phone makers, will not be rolling out security patches until they can confirm the issues have been remediated.
Examining the BlueBorne vulnerabilities
With the unveiling of Bluetooth 5 in June 2016, the wireless packet standard appears to be evolving into a complex maze of overcomplicated specifications and features. Owing to the many junctions the Bluetooth standard faces, each fragmentation of the implementation creates more legacy features and packet types—all while remaining current with newly released standards.
Researchers at Armis Labs looked for ways to sidestep security standards. In doing so, they found an alarming implementation in the security management protocol (SMP) layer that allowed them to bypass standard PIN code exchanges seen in traditional Bluetooth pairings—particularly, the “just works” implementation of the “numeric comparison with automatic confirmation” key exchange mechanism on Android. Here, the mechanism was found to auto-accept the connection and bypass authentication entirely on the victim’s device.
Additionally, researchers found information leaks in the commonly used Linux Bluetooth stack (BlueZ), stack overflows in several locations of common Bluetooth drivers for Android, Linux, and Apple, buffer underflows in the BNEP control messages, and a method to MitM Windows machines from a vulnerable Bluetooth device.
Figure 1: Unpatched Samsung S8 as of Sept. 12, 2017
Immediate impact and mitigation
As the CVEs imply, these disclosed vulnerabilities may result in full remote code execution or a virtually invisible MitM attack on Windows. The immediate remediation for these issues is to enforce a Bluetooth-disabled policy on all devices affected by the attack. In addition, all devices should be updated to their latest patch versions. Armis Labs released an Android application to monitor for vulnerable devices. However, it was discovered this tool checks only the Android security patch date and the OS run by each Bluetooth device in discoverable mode.
Figure 2: ro.build.version.security_patch before Aug. 1, 2017, triggers a vulnerable alert
Long-term impact and breach likelihood
Although the Android application is a good starting point to determine discoverable Bluetooth devices, this type of scan does not eliminate the attack vector or find all vulnerable devices. As the BlueBorne researchers stated in their white paper, a Bluetooth MAC address is often the same as the device’s Wi-Fi MAC address, or incremented by 1.
A determined attacker can easily guess corporate devices’ Bluetooth addresses and launch attacks against these devices without the need for a Bluetooth device to expose itself via discoverable mode. Currently no public proofs of concept have been developed for the vulnerabilities disclosed. However, it is only a matter of time before a malicious payload turns up in the wild. Additionally, the researchers noted that this might be only the “tip of the iceberg,” as focus on the Bluetooth stack implementations could reveal many other critical flaws and vulnerabilities.
Preventing vulnerabilities in the SDLC
As the researchers stated, many of these issues are due to common C vulnerabilities such as stack overflows, underflows, and off-by-one mistakes in the BlueZ Linux kernel implementation. These are the issues that static analysis tools such as Coverity are built to find, demonstrating the importance of integrating these tools into a code development process.
Through logic analysis and best practice security reviews, these tools identify memory leaks such as incorrect function arguments and pointer-incrementing code, as well as many other security vulnerabilities.
The Bluetooth stack is a great example of a complex protocol to fuzz test, with many logic branches and legacy-supported steps to break. Security testing should not end at code review or production release but should continue for the entire life span of the product.
What’s next?
The BlueBorne disclosures have an immediate impact on all vulnerable Bluetooth-enabled devices. Companies must proactively respond by changing Bluetooth policies for affected devices.
Continue Reading
Introducing fAST Dynamic: Streamlining dynamic application security testing
Mar 19, 2024 / 3 min read