seemoo-lab / internalblue

Bluetooth experimentation framework for Broadcom and Cypress chips.
678 stars 85 forks source link

KNOB PoC on Raspberry Pi 3 #41

Closed tim-acki closed 3 years ago

tim-acki commented 3 years ago

Hello,

I am trying to use the provided example for the KNOB attack on a Raspberry Pi 3 (BCM43430A1), running the latest Raspbian version. I followed all installation instructions and running the KNOB_PoC.py script on my Raspberry Pi 3 works fine. When pairing the RPI3 with an old IPhone 3GS everything seems to work fine, the device does not warn about the encryption key size and establishes a connection successfully. When pairing with an IPhone SE (2016), IOS gives a warning that an insecure connection is about to be established, but after allowing the connection establishment, everything works fine and the devices are connected. While there seems to be no issue with IOS, I am not able to connect any Android device after installing the KNOB patch. I tried connecting a Motorola MotoG3 (the same that was used in the original KNOB attack) and a Samsung Galaxy S3, which is even older and should therefore also be vulnerable to the KNOB attack. The problem occurs when trying to connect after pairing, and on every connection that is initiated by either device after a successful pairing. Without the KNOB patch everything works fine with these Android devices.

During Pairing i get the following Error Message: Connection Failed - GDBus.Error.org.bluez.Error.Failed: Resource temporarily unavailable. Try to connect manually.

btmon gives the following output while pairing:

2021-01-19-171344_1920x1080_scrot

It always seems that there is a short time interval where the devices are connected, but they seem to disconnect immediately. After pairing it seems as if the MotoG3 is rejecting the reduced key size which I suppose should not be the case as the device should be vulnerable. On every further connection request it seems as if the connection is aborted before the key exchange starts.

btmon gives the following output when trying to connect:

2021-01-19-171412_1920x1080_scrot

I have no idea what to do to make the devices connect successfully, so help would be appreciated here.

In addition to that I am not able to get wireshark or btmon to follow LMP packets in detail, to see what the actual problem is. I tried both the wireshark plugin from this repository (h4bcm_wireshark_dissector) and the wireshark plugin from the original KNOB repository but there are no LMP packets in the capture. I also tried to enable diagnostics for BlueZ (with echo 1 > /sys/kernel/debug/bluetooth/hci0/vendor_diag) but the file vendor_diag does not exist.

Do you have any suggestions on how to make LMP packets visible either using wireshark or some other tool?

Thank you in advance.

jiska2342 commented 3 years ago

Hi @tim-acki,

I guess even without the KNOB patch, the Android devices won't connect for long?

Android (i.e. Android 6.0.1 on my Nexus 5) only keeps a connection if it has a purpose. So, for example, if you enable tethering or pair a keyboard, the connection is left open. Otherwise, the connection is closed within a few seconds. What you can try is to run your Android smartphones as mobile hotspots and connect via BNEP tethering... but I've never tried that on Linux, only between Androids and iPhones, so I don't know if the BlueZ stack supports that or not.

btmon uses a feature in the BlueZ stack to get the diagnostic messages. As you wrote correctly, this is via the vendor_diag interface. However, the BlueZ stack is somewhat broken and acts differently depending on if it sees a USB or UART device for whatever reason. BlueZ is a bit of a mess ;) Instead of fixing this part of the stack, Daniele directly hardcoded diagnostic messages (basically starting with 0x7 instead of 0x1-0x4 like normal HCI/ACL/SCO messages) into the kernel. So, if you want to use that patch, you can try the official KNOB repository.

I definitely saw btmon working on Linux and showing diagnostic messages on a BlueZ stack without doing anything else than echoing into vendor_diag using a stock Ubuntu from a live stick... on a MacBook xD I never saw it working on a Raspberry Pi :(

So I'd recommend to use my patch within InternalBlue to get KNOB running in general on your Raspberry Pi (just two lines of code configuring key sizes instead of Daniele's PoC) and do the same modification to the Linux kernel as Daniele to observe LMP messages.

Happy hacking :)

tim-acki commented 3 years ago

Hi @jiska2342

Thank you for the fast reply. I already tried giving the connections a purpose by using the Android device as a Bluetooth Terminal for the Raspberry Pi. I used Serial Bluetooth Terminal (https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=de&gl=US), which also supports Bluetooth classic connections. I set it up using the guide here: https://scribles.net/setting-up-bluetooth-serial-port-profile-on-raspberry-pi/ It works on the Raspberry Pi with standard Bluetooth and connections are alive until they are manually canceled, but as soon as I install your KNOB patch, it won't connect anymore. The output of btmon in this case is the same as in the post above, so I suppose the error does not happen because the connection has no purpose.

I am not quite sure which modifications to the Linux kernel you mean. Do you mean the ones that were mentioned here?

jiska2342 commented 3 years ago

The changes you need to apply are contained in the BIAS repo for the Linux kernel 4.14.111: https://github.com/francozappa/bias/tree/master/linux-4.14.111

To make it a bit easier, I extracted a diff such that you can build your own custom kernel that supports this. You can find it here: https://github.com/seemoo-lab/internalblue/blob/master/linux/bias_linux-4.14.111.diff