Features of BLE:Bit v1

Posted on by ShellWanted Team

BLE:Bit : The first of its kind Bluetooth Low Energy Penetration Testing Security Assessment Device.

What is BLE:Bit – The state of the art in Bluetooth Low Energy Hacking

Often penetration testers wish to make a quick check, automated check of IoT devices that support multiple protocols. There are different stacks and libraries that can be used, multiple vendors, and the most important: different firmware each time.

If you are working as a professional penetration tester, you already know that there is not enough time. With BLE:Bit you can gain time as a penetration tester by automating your BLE Tasks. If you are a rebel, ethical hacker, or a researcher BLE:Bit may enhance your achievements in what you can do with BLE devices.

By using BLE:Bit the user becomes able to interact quickly to any BLE device either by using the BLE:Bit SDK’s API (Java), or by using the default command line suite created by ShellWanted. Additionally, an android application is available to download in order to provide easy access to the functionality of any BLE:Bit device. The android application is developed only to provide the core functionalities, but for harnessing the full potentials of the device, the SDK must be used.

Simulate BLE Services

BLE:Bit helps to create a Peripheral (Equivalent of Access Point in 802.11), or a Central (Equivalent of Client in 802.11). Also, BLE:Bit can create any service or characteristic and can achieve real-time interaction with the peer device. The characteristics may have a custom UUID or a UUID defined by the Bluetooth SIG Standard, both 16-bit and 128-bit are supported. Additionally, each characteristic may have custom properties or permissions.

Access to encryption keys

Many devices and software bundles exist out-there which allow interaction with Bluetooth devices but none of the current solutions offer the options of BLE:Bit at that price. In a real scenario where a device supports encryption, all other solutions out there fail to support all-in-one features, including data encryption. The BLE:Bit supports encryption and multiple simulations of Input/Output Capabilities such as Keyboard and Display capabilities (a capability that is vital to the pairing procedure of any two devices that wish to bond and encrypt their traffic). The BLE:Bit can return the Long-Term-Key of the communication of two peers in order to inspect the traffic using a BLE Traffic Sniffer – That assumes the BLE:Bit works as a proxy. This is very important to a penetration tester that wishes to monitor and inspect the traffic in real-time.

Unlike any other tool, the BLE:Bit supports the following pairing methods:

  • No-Encryption – Pairing Method: Just Works
  • Encryption (No IO, Keyboard-Only, Display-Only, Keyboard-and-Display)
  • Encryption & MiTM (No IO, Keyboard-Only, Display-Only, Keyboard-and-Display)

Detect new attacks, miss-configurations or vulnerabilities

By using the BLE:Bit is easier to find new vulnerabilities and even implement a PoC within minutes. The vulnerabilities CVE-2020-15509, CVE-2020-13425 were discovered with the help of The BLE:Bit Mark 1.0 Prototype Version !!. It is now easier for a tester to discover misconfigurations as the device provides informational events in the process of the whole procedure of connecting, pairing, disconnecting, or while sending and receiving data. Each event can be logged and displayed with meaningful status and error codes which will eventually help a tester to identify a bug.

Proxy Device

BLE:Bit is more than just a simulator. By using two BLE:Bit devices (central and peripheral) one can set it up as an active proxy device and simulate the same services of the original device. Additionally, the user may set a custom MAC Address, an option that is impossible or difficult to set on other solutions. Having the option to select a custom MAC Address, advertise the same data, and simulate the same services and characteristics completes the profile of any BLE Device out-there.

Cloning

The features that BLE:Bit provides can help in the automatic device cloning. That is, the complete automation of cloning of services and mac address of any device exists out-there. The BLE:Bit device can automatically clone all services of a particular BLE device, in real-time, and also clone the original MAC Address, and therefore start advertising with the same original address. BLE:Bit can be configured to advertise in a more frequent window than the original device in order to have the chance of locking the target. Also, the BLE:Bit is optimized for an antenna of 1/2 of a wavelength which will help to have enough gain and RF Transmission (50 m in line of sight).

Configuration Parameters

The user has a number of configuration options available. The user may configure the following parameters:

  • Minimum Connection Interval in milliseconds
  • Maximum Connection Interval in milliseconds
  • Supervision Interval in milliseconds
  • Slaves Interval
  • Scan Timeout
  • Advertisement Timeout
  • Advertisement Frequency Interval in milliseconds
  • Scan Window in milliseconds

Automatic construction of advertisement payload

Many applications or centrals are configured to connect automatically to peripherals that contain specific custom data. Our device may build the payload of advertisement automatically in contrast to the different solutions that exist out-there. In addition, in case that an option is not available the user may add custom data as well.

  • Service Data
  • Solicited UUIDs
  • Complete UUIDs
  • Incomplete UUIDs
  • Manufacturer Data
  • TX Power
  • Device Name (Also support for shortened device name)
  • Flags
  • MAC Address
  • Custom Advertisement Data

If the configuration of the advertisement payload is not enough, we are not over yet. Our device allows the user to send separate data for scan responses. Scan payload can also be built automatically. It can include the exact same features of advertisement data.

Full control over pairing procedure

The user may choose when to disconnect or when to avoid disconnection (for example because of an invalid PIN). In that way you may discover patterns or misconfiguration of the other peer device.

Hooking on reading

On each read, the user is able to pause the request, inspect the read request, replace the value, and then allow a response to pass to the peer device. This is very important because the user is informed when the peer device has the characteristic’s value being read, so as to set a value depending on the current conditions of the test the penetration tester is using!

Send and Receive Notifications

Notifications in Bluetooth Low Energy are very important. Notifications allow peers to send events when the value has changed. BLE:Bit can send any notification event at any time with any given value. Additionally, when a peer device sends a notification, the peer device may read the notifications with the correct order, the characteristic and the handle of such characteristics.

Enforce-repairing

Many solutions out-there have very limited options and provide high-level abstractions to Bluetooth Low Energy. BLE:Bit supports bonding enforced repairing. This is important as it may change the flow and process of the encryption procedure. Many BLE Software stacks fail to check corner cases and BLE:Bit is here to help.

Portability

The mindset of BLE:Bit is to allow to be used in real-life scenarios in order to be used as Proof-of-concept in a red team penetration test environment.

A scenario could be the following: an existing target in a building is having a smartphone with Bluetooth left enabled, and, at the same time the peripheral device (e.g. CAR, HomeLock) is somewhere else. Many mobile applications rely only on the detection of mac addresses, and thus, while those applications are scanning for the peripheral device and once a known address is found, the app connects to the devices automatically.

The BLE:Bit can be configured so the two separate devices (BLE:Bit Peripheral and BLE:Bit Central) can be set in two different physical locations. That is because they are developed with the mentality that the two target devices will not be always at the same location! Because of that, the BLE:Bit devices are pre-configured as peripheral or central and so the accompanied SDK contains a separate controller for each one of the devices. In that way, two servers can be configured, and placed in two different physical locations. By connecting the two devices to the internet, the two servers can communicate and the cloning and Man-in-The-Middle procedures can be achieved.

Disable Advertisement Channels

When performing a security assessment there are times that sniffing is necessary (for debugging reasons). Even though, in order to capture all three channels, three devices are needed for optimal performance. By using BLE:Bit, one can disable advertising on specific channels, and thus sniffing on a single advertising channel is possible. Therefore, one device is enough for sniffing and thus a capture is always possible to be achieved.

More information @ https://docs.blebit.io