-
Notifications
You must be signed in to change notification settings - Fork 141
FAQ
The tool creates exact copy of attacked device in Bluetooth layer, and then tricks mobile application to interpret its broadcasts and connect to it instead the original device. At the same time, it keeps active connection to the device, and forwards to it the data exchanged with mobile application. In this way, acting as “Man-in-the-Middle”, it is possible to intercept and/or modify the transmitted requests and responses.
Most mobile applications initiate connection to device by looking for advertising packets broadcasted by device. Usually battery-powered devices optimize advertising intervals in order to minimize power consumption. The attacker however can broadcast the relevant advertisements with minimal intervals (much “quicker”). The mobile application will interpret the first received advertisement - and in this case it will most probably be the spoofed one. Additionally, as most devices do not broadcast advertisements during active connection, the attacker can just constantly keep connected to original device and thus prevent it from broadcasting.
Currently the tool works for devices which do not implement Bluetooth LE link-layer pairing/encryption. However there is surprisingly lot of such devices.
Possible attacks against encrypted connections are described in attached whitepaper
The “central” module (ws-slave.js) listens for advertisements, scans the device’s services for cloning in “peripheral”, and forwards the read/write/notification messages exchanged during active attack.
The “peripheral” module (advertise.js) loads device specification (advertisement, services, characteristics, descriptors) collected by “central” module, and acts as the device “emulator”.
Optional hook functions allow to tamper requests and responses.
Helper script scan.js scans for devices and creates JSON files with advertisements and device's services+characteristics.
Additionally, a BlueRadios AT interface script is attached in standalone/blueRadiosCmd.js.
The components can be run on the same box (with at least two Bluetooth 4 interfaces), or on separate ones. They connect to each other using websockets. By running on the same box, you may experience some unstability, like kernel-level device mismatch (to be debugged). Switching devices with one another usually helps.
By running components on separate boxes, you can interact with devices remotely, e.g. have one box close to a smart lock and another one close to the owner's phone in separate location. In this way it is possible to abuse auto-unlock proximity features.
The software runs on any recent Linux, including Raspberry Pi. Each module (“central”, “peripheral”) requires a Bluetooth Low Energy adapter. The most popular, CSR 8510-based USB dongle is available for about $10, and is confirmed with stable MAC address changing using the Bluez bdaddr tool.
In many cases, where mobile application relies only on advertisement contents - not. But many mobile applications match the MAC address of the device. In order to successfully intercept such communication, you need to clone the MAC address. It is possible to do using Bluez bdaddr tool (attached for your convenience in In such case, the attribute’s handle numbers, by which the devices exchange GATT data, must match exactly the original device’s ones. Otherwise the mobile OS’s GATT cache will not match and prevent the communication.
Set up hook functions, see README.
Yes, thanks to modular design, it is possible to chain the websocket transmission – for example to manipulate the BLE requests as JSON text in a web intercepting proxy, e.g. Burp Suite. In order to intercept the traffic, simply set the proxy between modules. IP is configured in config.env, default port is 0xB1e (BLE) = 2846. You can easily change the port variable in nodejs source code (listening: ws-slave.js, connecting: lib/wsclient.js).
In the websocket transmission between components you will see the JSON-formatted requests and responses. There will be control commands (e.g. "start scanning", "connect to specified peripheral", "subscribe to/read/write specific characteristic" etc.), and their responses. Depending on command, the fields include device id (MAC), service UUID, characteristic UUID, characteristic value, other (e.g. status, list of all services+characteristics...). The characteristic values are transmitted as hexstring.