Closed dennisarmbruster95 closed 4 years ago
Hi, thank you very much. It's weird, I have already performed this kind of attacks using ble_mitm and ble_crack without problems. Have you checked if the MASTER_SPOOFING parameter is set to "yes" and if the BLE dongle you are using supports BD address modification ? You need two dongles supporting the BD address modification (if you have only one, another way could be to use a scenario to perform two different pairings for both sides of the communication, but the pairing will be wrong if you try to connect your master to your slave without MiTM). The initiator / responder addresses are both involved in the pairing process, so it could explain the wrong values of random / confirm.
Hey RCayre, i apologize for my late reply, but I only work on this project on Wednesdays and Thursdays. I checked the MASTER_SPOOFING parameter (SLAVE_SPOOFING also). The used BLE dongle are from Logilink and should support BD address modification. This is shown with the bt_info module:
┌───────────┬───────────────────┬─────────────┬──────────────────────────────────────────────────┬────────────────────┐
│ Interface │ BD Address │ Local Name │ Manufacturer │ Changeable Address │
├───────────┼───────────────────┼─────────────┼──────────────────────────────────────────────────┼────────────────────┤
│ hci1 │ D1:10:54:17:94:78 │ CSR8510 A10 │ Qualcomm Technologies International, Ltd. (QTIL) │ yes │
└───────────┴───────────────────┴─────────────┴──────────────────────────────────────────────────┴────────────────────┘
and i can see the modifiaction in the output from ble_mitm:
[INFO] Entering WAIT_CONNECTION stage ...
[INFO] Connection Parameter Update Request (from slave) : slaveLatency = 44 / timeoutMult = 216 / minInterval = 6 / maxInterval = 9
[INFO] Sending a response to slave ...
[INFO] Updating connection handle : 69
[SUCCESS] Master connected : 67:CD:CC:63:4C:A3
[INFO] Slave disconnected !
[INFO] Changing HCI Device (hci1) Random Address to : 67:CD:CC:63:4C:A3
[SUCCESS] BD Address successfully modified !
[INFO] Connecting to slave D1:10:54:17:94:78...
I also tested pairing without MITM attack and it is successful. So it shouldn't be an error of my Android device or presenter.
Hey @RCayre, it seems to me that a2mEmmitter has made a mistake. When measuring, I observed that the initiator and responder calculated with different address types.
Below is a screenshot of values in Mirage during debugging, which shows that the responder has a random address type.
In this screenshot of Wireshark you can see how the real master sees the types of connection setup.
For testing i manipulated the following lines in your ble_mitm.py file:
if utils.booleanArg(self.args["SLAVE_SPOOFING"]) and address != self.a2mEmitter.getAddress():
self.a2mEmitter.setAddress(address)
to
if utils.booleanArg(self.args["SLAVE_SPOOFING"]):
self.a2mEmitter.setAddress(address, random=addrType)
In debugging i can see that the value of addrType is True and so it should give the emitter the random adress type, but nothing changed for the real master. So it look like an error from an internal module or something like this.
best greetings
FIX:
During the clone stage you need to configure the advertisement parameters with adding oaType=addrType
also.
Old:
if utils.booleanArg(self.args["SLAVE_SPOOFING"]) and address != self.a2mEmitter.getAddress():
self.a2mEmitter.setAddress(address)
self.a2mEmitter.setScanningParameters(data=dataResponse)
self.a2mEmitter.setAdvertisingParameters(data=data, intervalMin=intervalMin, intervalMax=intervalMax, daType = addrType)
New:
if utils.booleanArg(self.args["SLAVE_SPOOFING"]) and address != self.a2mEmitter.getAddress():
self.a2mEmitter.setAddress(address, random=addrType)
self.a2mEmitter.setScanningParameters(data=dataResponse)
self.a2mEmitter.setAdvertisingParameters(data=data, intervalMin=intervalMin, intervalMax=intervalMax, daType=addrType, oaType=addrType)
If you wish @RCayre i would make a pull request for this.
Hey RCayre, first of all, i really like your project.
I am currently study various BLE devices for vulnerabilities. One of these devices is the Logitech R500 Laser Presenter. I would like to connect between the device and another test device (for example, an Android device) via the BLE_MITM module.
Information about the Bluetooth communication: The BT devices use LE legacy pairing with JustWorks.
I have had the problem with the Logitech R500 and other devices that the TK could not be calculated successfully and the module BLE_CRACK does not deliver a result. I could handle the problem so much that I set the TK to
b'\x00'*16
by means of a scenario. JustWorks sets the TK to this value. After much trial and error and comparing recorded test data, it looks like the data in the BLEPairingRandom package is not correct. I modified my scenario so that it calculates the MasterRandom itself and then uses it as in the regular process. This allows the TK to be calculated again via the BLE_CRACK module.However, I can not get on now, because the pairing always fails with the following reason: Confirm Value Failed
Part of my scenario:
Output: