Mobile Bug Bounty Hunting? Enter BLE

An overview of BLE Security Vector and Bug Bounty Hunting

Bug Bounty Hunter?

If you are hunting mobile bug bounties you must know by now how difficult it can be to find new kind of vulnerabilities. Common vulnerabilities become less and less attractive as more people join the party. Beside that, more and more companies start using automated vulnerability discovery tools and even out-source the security to penetration testing companies.

There is an area though, which is pretty much unknown by many bug bounty hunters and penetration testers. This area is the communication part between the mobile applications and other devices. The communication can be done via the local WiFi network, indirectly – by connecting to the server through internet, or via Bluetooth.

In this article, we will discuss the attack vectors of Bluetooth Low Energy which affects the security posture of the application and the BLE device.

What BLE is?

BLE stands for Bluetooth Low Energy. BLE for short, is a variation of the Bluetooth protocol, which focuses on low-power consumption and is often used by gadgets, wearable and home automation systems.

How an android application and a device communicate over BLE?

Any modern operating system exposes its API to the developers to communicate with the underlying BLE subsystem. The mobile application developers are not aware much of the details of the protocol as the API abstracts a lot of the heavy work.

Moreover, developers may not use the operating system’s API directly, but instead use a BLE library – a library that may be potentially vulnerable.

So the developers must know how the API/library works. Whats next?

For developers being aware of how the library works is not enough. The developers must understand the profile of the device they wish to communicate with. There are known profiles defined by Bluetooth SIG (organization defined and maintain the Bluetooth protocol). Also, there are custom profiles defined by the vendor of the hardware device. Keep in mind, that the developer and hardware vendor may be the same entity. Most of the time the vendors define their own interfaces which means the developer must implement a custom protocol to communicate with. And this is where you come into the play.

Why does BLE implementation needs testing?

Applications that talk to any kind of hardware device via BLE must be tested for various reasons. First of all, even if no custom protocol is implemented, the configuration must be tested (unencrypted communication and BLE-specific misconfigurations).

Then, if any custom protocol is implemented it must be tested in order to uncover any vulnerabilities in the protocol. The protocol or misconfigurations could lead to denial-of-service, access control issues, Personal Identifiable Information leakage and more.

If you are completely unfamiliar with BLE, here is an introductory post regarding Bluetooth Low Energy.

I don’t have the device required by the app. How can I test the app without it?

It is true that BLE security is a very specialized area which requires a lot of dedication and possibly spending some time in the reverse engineering of the application and some money purchasing tools or the device needed by the app. About the RE, there are patterns one can follow to optimize the time needed to understand what the application does. About the extra purchases: may also need to purchase a hardware device the application needs to communicate in order to trigger the right methods and have a Proof-of-Concept. Also, such devices tend to be expensive. For example, you test a smartwatch application, which needs to talk with the smartwatch – which you don’t have. There is a solution though! You may re-create the device without even having the device. A few good articles doing exactly that can be found here and here.

The Custom Application Protocol

The custom application protocol is the upper layer of BLE, defined by the vendor of the hardware device, and is commonly avoided for testing because of the difficulties of the protocol, the reverse engineering work needed and the lack of knowledge of how things works in BLE.

The application protocol is what can make the device – or application – vulnerable. The application communicates with certain interfaces – named characteristics – which can be left unprotected and may lack security mechanisms. Such interfaces though, are found on the device and therefore, bug bounties must include hardware in their scope so you can be eligible for the bounty. But in case they do, I can assure you very few bug bounty hunters, if any, gets their hands dirty with BLE. If the hardware testing is out-of-scope, the application though, might still be on-scope. On the application-side, the custom protocol must be implemented by the developer and the parsers must be securely implemented and not introduce any vulnerabilities.

Even if you not don’t find any BLE vulnerability in the device or to the application you may find vulnerabilities in the back-end. By playing around with BLE you may trigger endpoints on the back-end which can be vulnerable. Such endpoints would not be triggered otherwise. Such an example can be found here.

In this article we won’t cover how BLE works or how to test a BLE device. We wanted to let you know how much more can be done in bug bounty hunting of mobile applications that connect to IoT devices. We can guide you to the right direction to start this journey the right way. A lot of people have tried but failed to enter this area as they found-out that it’s a daunting task when you have none to tell you where to go and just looking around the internet.

Let us introduce you to the protocol properly and show you how you may start testing BLE apps and devices. Jump into this by subscribing below.

The email series contains the following topics. As soon it is over you are automatically unsubscribed:

• Introduction to the BLE Protocol – A gentle introduction to the BLE protocol

• Enumeration Phase – How you can enumerate a BLE device using specialized tools

• Testing a BLE Device – How you may conduct basic tests

• BLE App Misconfigurations – What kind of misconfigurations are found in BLE-related Apps

• Mastering BLE Security – The path you need to follow to master in BLE Security.