BlueDucky automates exploitation of Bluetooth pairing vulnerability that leads to 0-click code execution

In January 2024 Marc Newlin published prove of concept script that exploits 0-click Bluetooth vulnerability tracked as CVE-2023-45866. The exploit tool is called hi_my_name_is_keyboard. By exploiting this security issue, it is possible to inject keystrokes to any unpatched Android and Linux device in Bluetooth proximity by impersonating Bluetooth keyboard. Marc’s PoC script was designed only to exploit the issue. I was able to successfully test this exploit against vulnerable Android smartphones, Google Chromecast TV, Meta Quest 3, Linux based smart TV, and I shared results in exploiting 0-click Android Bluetooth vulnerability to inject keystrokes without pairing blog. However, problem is that a user first needs to manually discover and enter MAC address of targeted Bluetooth device and also understand the script to change the code to change injected keys. These two problems were solved by BlueDucky.

In the video below you can see a demonstration of running BlueDucky, on Rapsberry Pi 4 and Android smartphone with NetHunter, to exploit 0-click Bluetooth vulnerability.

BlueDucky benefits

BlueDucky is developed by Opabinia and published on GitHub. It’s a handy toolkit that utilizes the hi_my_name_is_keyboard PoC with benefits. I was able to run it on Raspberry Pi 4 running Kali Linux and on rooted Android running Kali NetHunter (OnePlus 7 Pro).

After start, BlueDucky automatically starts a scan for Bluetooth devices in vicinity and provides an option to select one of them. Names and MAC addresses of all discovered devices are locally stored in known_devices.txt file. User can either select one of them, or scan for devices in vicinity. In Figure 1 you can see an example of stored devices. This list contains all found devices, not only vulnerable.

These devices can be then used as targets, even thought they might be no longer visible, but have Bluetooth still enabled. This can apply to smartphones not in discoverable mode anymore, which means they don’t advertise their MAC address any longer but they are present in vicinity.

After exploitation, BlueDucky executes Rubber Ducky script that is saved in payload.txt file, so there is no need to edit the python script anymore.

If you would like to use an external Bluetooth adapter, then it is still necessary to make changes in the blueducky.py since the adapter would be recognized as hci1 device. However, there is a trick that helps. Plug-in external adapter to device such as Android or Raspberry Pi, and reboot it. Once booted, external device will be automatically recognized as hci0 device and built-in Bluetooth chip as hci1. Because of that, you don’t need to make any code changes.

If we would like to talk about true automation, then it would be possible to edit the script to make BlueDucky discover devices in the loop and try to exploit them one by one and log the results. Based on my experience, if device is vulnerable, then the script finishes successfully. If device is already patched or not affected, then it crashes.

Prevention

If you are running Android 11 and above, the best course of action is to patch your device.

If you have Android 10 and below, the security patch is unfortunately not available, and based on the original Marc Newlin post, it will not be patched.

The good news is that an attacker in the vicinity cannot automatically receive the Bluetooth MAC address of Android devices. It is possible only if the device is in discoverable mode. In case attacker already has the MAC address and the device is not patched, the safest thing to do is to turn off Bluetooth.