Breaking BLE

Leland Teschler, Executive Editor

Despite built-in safe-guards, Bluetooth Low Energy IoT devices are vulnerable to hacks when they communicate over the air. Here are the basics of the problem.

If you eyeball internet-of-things items ranging from smart ac plugs to motion sensors you typically find connectivity via the Bluetooth Low Energy (BLE) standard.A lot of IoT devices use BLE because theprotocol is well suited for transferring small amounts of data while consuming littlepower. But though BLE incorporates several security measures, vulnerabilities in the protocol have emerged over time.

For example, BLE communications can be hacked via man-in-the-middle (MITM) attacks where an attacker secretly alters messages between parties who think they are communicating with each other. BLE credentials can also be sniffed using a sniffing device that examines data sent on the advertising channels used to let BLE devices find each other. In BLE spoofing, an attacker mimics the MAC address of a BLE device as a means of impersonation. Denial-of-service attacks are also possible because peripheral BLE IoT devices are usually designed to connect with only one master at a time. Bombarding the BLE device with connection requests in response to advertising packets can prevent legitimate users from connecting. In addition, unauthorized co-located apps can also hijack the connection between legitimate mobile apps and BLE devices.

Many vulnerabilities pertain to the process of pairing devices, verifying and authenticating the identity of BLE nodes wishing to connect up. Part of the problem is that there are several ways of pairing devices, and not all of them have a high level of security. Ditto for BLE traffic encryption. Data encryption is used to prevent MITM eavesdropping attacks on BLE links by making data unintelligible to all but the BLE master and slave devices forming the link. Earlier versions of BLE had communication modes that didn’t incorporate a public key exchange for encryption/decryption, probably because more computing power (and a faster battery drain) was involved in running encryption/decryption algorithms.

Recent versions of the BLE standard incorporate modes where users must enter credentials to connect with IoT devices. Unfortunately, researchers have found that many BLE IoT devices don’t implement applevel authentication properly.

In particular, numerous BLE IoT devices use “Just Works” for pairing (no invocation of app-device bonding at all), which allows any nearby attackers to arbitrarily connect and possibly do something devious.

To understand the problem with Just Works pairing, consider that there are four different pairing methods, but they all take place in three phases. In phase one, the two devices let each other know what pairing method is going to be used and what the BLE devices can do and expect. In phase two, a Short Term Key (STK) gets generated by having the devices agree on a Temporary Key (TK) mixed with some random numbers to yield the STK. The STK itself is never transmitted between devices. In phase three, the key from phase two is used to distribute other keys needed for communications.

What may be the most secure of the four pairing methods is called OutOfBand, OOB, so called because it involves authentication outside the BLE communication channel. The Apple Watch is a good example. For pairing, a swirling pattern of dots displays on the watch face. The user points the camera of the iPhone to be paired at the watch face to link the two.

Another strong pairing method is called Passkey Entry. Here a sixdigit value displays on one device and is entered manually into the other.

The two other pairing methods have more problematic security. With Numeric Comparison pairing, devices to be paired both display the same six-digit value. Pairing generally involves just hitting “OK” on both devices. The main purpose of Numeric Comparison is to identify devices to be paired rather than thwart bad actors. MITM attacks are possible. The last pairing method, called Just Works, is said to be the most widely used. It was intended for devices that lack a display. As in Numeric Comparison, a six-digit value gets passed, but the six digits are all zeros. Thus any nearby BLE device sending out a Just Works connection request can pair up with those nearby that use the same pairing scheme.

The Just Works method has come into wide use because it consumes less power than the other pairing methods. BLE schemes that employ Just Works pairing may build-in other security measures that are less power intensive, typically at the app level. For instance, the app can ask users to enter credentials and deliver them (through encryption) to the IoT devices to authenticate the connection.

Nevertheless, security researchers say vulnerabilities during pairing constitute a severe security risk. For example, researchers at The Ohio State University recently developed an automated app analysis tool and used it to identify 1,757 vulnerable free BLE apps in Google Play store. They also performed a field test in which 7.4% of 5,822 BLE devices were vulnerable to unauthorized access.

FINGERPRINTING

The Ohio State researchers also said their field test uncovered 5,509 BLE devices that were “finger printable” by attackers. The fingerprinting involves the universally unique identifier (UUID) from the advertisement packets broadcast by the BLE devices. UUIDs are typically 128-bit hexadecimal strings. The point of broadcasting UUIDs is so a BLE peripheral can advertise what services it provides, such as measuring a heart rate. Thus some of the information in the UUID-- i.e. that defining the predefined services-- is universal. Nearby mobile apps must know what the UUID means to discover the device sending it out. Also, UUID packets are not encrypted-- all other kinds of BLE packets are.

Ohio State researchers say this use of UUIDs is a design flaw. UUIDs can be obtained from not only the BLE traffic but also from the IoT companion mobile apps. Attackers can use UUID information to fingerprint a BLE device this way: Attackers bent on mischief would first scan all mobile apps in an app store, such as Google Play, to find all possible UUIDs, allowing them to fingerprint all BLE devices statically. It is likely that multiple apps use the same scheme-specific BLE chip or UUID configuration, preventing any nearby attackers from precisely knowing which device the victim is using. To further narrow things down, attackers can inspect the next layer UUIDs (because BLE devices often organize UUIDs in a hierarchical structure) and use the structure of the UUIDs to fingerprint a victim BLE device. With the fingerprinted UUID information, they can sniff all advertising packets nearby (e.g., a metropolitan area such as New York City) to locate these devices. If mobile apps also tell them Just Works or weak pairing is in use, attackers can directly exploit these BLE devices.

In tests, the researchers discovered 168,093 UUIDs, 13,566 of which were unique, when they analyzed free BLE apps in Google Play. They also point out that there are special receivers available that can be used to sniff BLE signals up to 1 km away, though BLE signals typically travel only up to 100 m. To prove their point, the OSU researchers built their own BLE sniffing device using not much more than a Raspberry Pi and a BLE antenna. This DIY sniffer identified 431 vulnerable devices, including 369 units where the researchers could eavesdrop on conversations, within an area of just 1.28 square-miles.

Work by the OSU researchers shows what steps attackers must take when trying to decipher UUIDs. Sometimes UUIDs are directly hardcoded in the app. In this case, they may be extracted simply by looking for regular strings of characters (grepping) in the decompiled app code.

UUIDs associated with an IoT device also typically have a hierarchical structure. A service UUID can have “children” UUIDs derived from its characteristics. Such a UUID hierarchy could provide information useful for determining which IoT app maps to a particular BLE device. One complicating factor is that no structural rules define relationships between parent and children UUIDs, so some educated guessing may be involved.

OSU researchers also explain the general approach attackers would likely take in figuring out whether an app itself is insecure. The only way a nearby attacker can sniff vulnerable IoT devices paired via Just Works is to figure out whether the app involved uses flawed or insecure authentication. To implement proper authentication, the app must use cryptography to prevent a relay attack either by encrypting the authentication token with nounces (arbitrary numbers used only once to ensure communications can’t be reused) or by using an additional layer of encryption of the traffic atop BLE link-layer encryption. Thus to check the app for security, the approach is to look at the disassembled app code for any use of cryptography. If there’s no cryptography, the conclusion is the channel is not secure, and both passive/active sniffing and unauthorized access can be successful.

Even in apps employing cryptography, flawed authentication can rear its ugly head. One such flaw is the hardcoding of all credentials in the app, potentially discernible by disassembling the code. However, OSU researchers say it can be challenging to identify authentication flaws because there is no specific code pattern for implementing app authentication. Thus there’s no documented APIs to identify for extraction of the hardcoded credentials.

It turns out that flawed authentication involving hardcoded credentials can be identified systematically. The key insight is that to securely authenticate a mobile app to a BLE device, the app must provide a credential that comes from the external input, such as letting the user enter a password. OSU researchers say this opens up the possibility of using a data flow analysis algorithm to identify such apps. This approach, if used for nefarious purposes, implies an extremely determined attacker: The technique would likely involve creating data-flow equations for each node of the app’s control flow graph and solving them by repeatedly calculating the output from the input locally at each node.

In particular, researchers say data sent out to BLE peripheral must go through low-level APIs, allowing use of program slicing-basically looking at a subset of program statements that affect a variable of interest--to trace back to the source of the data. If none of the data sources are external inputs (e.g., received from the BLE network or user inputs), then the app has used hardcoded commands including possible passwords to interact with the BLE devices

Researchers also note that further intelligence may be gained by knowing where the UUIDs are used (i.e., the execution context). There are seven documented APIs defined by the Android BLE framework that carry the UUIDs as parameters, to generate the instances for accessing the related service, characteristic and descriptor in the paired BLE devices. While an app could have multiple UUIDs, their usage may have dependencies that can be exploited.

COUNTERMEASURES

To head off vulnerabilities, researchers say the app should encrypt the data sent with no hard-coding of any factors involved in the encryption. Developers should also hide the authentication credentials in the cloud or let users enter them in the app.

The root vulnerability that enables UUID fingerprinting is that BLE devices must broadcast advertised packets to inform nearby apps. The UUID can be sniffed either from the advertisement packets or by browsing for services after the connection has happened. In addition, UUIDs are fixed values and do not change over time.

The fingerprinting attack relies on mobile app analysis to reveal the UUIDs and their hierarchies, So anything that discourages this sort of analysis can be helpful.

Researchers also say that although protection methods in the app-level are seemingly plausible, they can’t fundamentally prevent the UUIDs from being reverse engineered from mobile apps. Obfuscation and encryption can only make it more difficult for attackers to retrieve UUIDs because the app will work with plain-text UUID somewhere along the line. Storing UUIDs outside the mobile app can prevent the UUIDs from being statically reverse engineered, but attackers can still obtain the plaintext UUIDs at run-time.

Researchers additionally advocate the piecing out of UUIDs as they get transmitted in the BLE RF channel. In this way, attackers can only see segments of UUIDs instead of continuous signals, The downside is that this approach probably entails use of additional hardware.

Another fundamental countermeasure would be to construct one-time dynamic UUIDs. The OSU researchers claim this scheme only requires an update of both the app and device firmware. Because multiple users can access one BLE device, they suggest using the cloud help synchronize the UUIDs among users. Then once an app has successfully connected with an IoT device for the first time, it negotiates a dynamic UUID for future communication. To prove this scheme actually works, the OSU team says they implemented a prototype using a real BLE chip in a software development board which provides programming interfaces to configure UUIDs for advertisement packets, services, characteristics, and descriptors.

Clearly it would take a determined hacker willing to spend time parsing through disassembled app code to exploit some of the vulnerabilities the OSU researchers uncovered. That’s probably beyond the capabilities of casual mischief makers, but not out of the question for state-sponsored hackers and criminals.

References: Automatic Fingerprinting of Vulnerable BLE IoT Devices with Static UUIDs from Mobile Apps, https://dl.acm.org/doi/10.1145/3319535.3354240

Bluetooth SIG Inc., https://www.bluetooth.com/ specifications/protocol-specifications/