https://wiki.elvis.science/api.php?action=feedcontributions&user=Cskallak&feedformat=atomEmbedded Lab Vienna for IoT & Security - User contributions [en]2024-03-28T22:38:06ZUser contributionsMediaWiki 1.37.2https://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11781BLE-Berry Project2023-10-02T21:02:22Z<p>Cskallak: /* BLE Berry */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
The BLE Berry takes a distributed three layer multi-user approach. At the lowest layer are the BLE Nodes. BLE Nodes are raspberry pis (3, 4 or Zero) that run a script to perform BLE operations, like interacting with a device, deploying a BLE server. The nodes can have a Sniffing USB accessory attached to perform sniffing operations (The current version only supports the Ubertooth One other ones are WIP). The Nodes interact with the frontend via MQTT messages. The frontend is a QT application that displays the collected data and lets the users command the BLE Nodes. Multiple frontend session can run at the same time, and they are only restricted by the amount of available BLE Nodes. The backend consists of three Docker containers. The database and MQTT Broker use the official Mosquitto and MySQL images, and the database agent is a python script running in an alpine container. The agent stores all gathered information in the database and provides the stored data to the front end when a session is reopened. <br />
<br />
<br />
[[File:BLE Berry Project Architecture.png|800px]]<br />
<br />
The following figure the how the MQTT topics look like for the BLE Berry Tool.<br />
[[File:BLE Berry Project MQTT.png|800px]]<br />
<br />
<br />
The MySQL database is shown in the figure below.<br />
[[File:BLE Berry Project Database.png|800px]]<br />
<br />
== Source Code and Thesis ==<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11780BLE-Berry Project2023-10-02T20:56:06Z<p>Cskallak: </p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
The BLE Berry takes a distributed three layer approach. At the lowest lay are the BLE Nodes. BLE Nodes raspberry pies (3, 4 or Zero) that run a script to perform BLE operation like interacting with a device, deploying a BLE server. The nodes can have a Sniffing USB accessory attached to perform sniffing operations. The Nodes interact with the frontend via MQTT messages. The frontend is a QT application that displays the collected data and lets the users command the BLE Nodes. Multiple frontend session can run at the same time and they are only restricted by the amount of available BL Nodes. <br />
<br />
<br />
[[File:BLE Berry Project Architecture.png|800px]]<br />
<br />
The following figure the how the MQTT topics look like for the BLE Berry Tool.<br />
[[File:BLE Berry Project MQTT.png|800px]]<br />
<br />
<br />
The MySQL database is shown in the figure below.<br />
[[File:BLE Berry Project Database.png|800px]]<br />
<br />
<br />
== Source Code and Thesis ==<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.</div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_Database.png&diff=11779File:BLE Berry Project Database.png2023-10-02T20:42:09Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_MQTT.png&diff=11778File:BLE Berry Project MQTT.png2023-10-02T20:41:44Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_Architecture.png&diff=11777File:BLE Berry Project Architecture.png2023-10-02T20:41:14Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11776BLE-Berry Project2023-10-02T20:39:19Z<p>Cskallak: /* BLE Berry */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
== Source Code and Thesis ==<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11775BLE-Berry Project2023-10-02T20:37:50Z<p>Cskallak: </p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
== Source Code and Thesis ==<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11774BLE-Berry Project2023-10-02T20:37:22Z<p>Cskallak: /* Summary */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
=== GitLab ===<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11773BLE-Berry Project2023-10-02T20:37:08Z<p>Cskallak: /* GitLab */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
=== GitLab ===<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11772BLE-Berry Project2023-10-02T20:36:28Z<p>Cskallak: /* GitLab */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
=== GitLab ===<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email [dessyboy@tutanota.com] address to get informed when the project gets accessible.<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11771BLE-Berry Project2023-10-02T20:36:15Z<p>Cskallak: /* GitLab */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
=== GitLab ===<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11770BLE-Berry Project2023-10-02T20:36:03Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Cross Transport Key Derivation ====<br />
Cross Transport Key Derivation (CTKD) is a protocol to cross derive a key from Bluetooth Classic and BLE used by devices that implement both communication protocols (dual-mode devices), e.g., smartphones. The problem is that dual-mode devices can only turn on both protocols in conjunction and even when one of them is in use, is the other one able to be connected to. This is abused by adversaries by connecting to the unused protocol and performing the CTKD. This results in a disconnect between the two legit device because the key is overwritten, and the connection overtaken by the adversary. <br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== BLE Berry ===<br />
<br />
<br />
=== GitLab ===<br />
https://git.fh-campuswien.ac.at/ble-berry-ma-thesis<br />
Sadly, the source code as well as the thesis can not made public <br />
the due to legal reasons until I finish my studies by passing my final exam, but you can contact this email dessyboy@tutanota.com address to get informed when the project gets accessible.<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11769BLE-Berry Project2023-10-02T20:22:00Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages for a long time period. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerabilities of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing requests that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using long deep sleep phases and short awake times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This is used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks resulting in denial of service.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== Machine in the Middle ====<br />
A machine in the middle attack creates a spoofed connection with both targets and tries to downgrade the connection to plain text to cause information disclosure.<br />
<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11768BLE-Berry Project2023-10-02T20:13:07Z<p>Cskallak: /* Bruteforcing Legacy Pairing Encryption Key */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing request that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using log deep sleep phases and short wake up times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This can be used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Brute-forcing Legacy Pairing Encryption Key ====<br />
The Legacy Pairing algorithm relied on a six-digit temporal key (TK) as the only secret parameter for the derivation of the short term key and link key. The six-digit passcode only provides an entropy of 20 bits and is therefore brute-forceable. Any device that use any BLE version after 4.2 relies on a secure paring authentication algorithm and is therefore not prone to this threat anymore.<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11767BLE-Berry Project2023-10-02T20:07:58Z<p>Cskallak: /* Downgrade Attacks */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing request that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using log deep sleep phases and short wake up times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This can be used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks.<br />
<br />
==== Downgrade Attacks ====<br />
Downgrade attacks downgrade either the used paring algorithm or the key size of the encryption key. This attack require a machine in the middle attack during the connection establishment and altering the input output capabilities, secure connections or key size field in connection request.<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11766BLE-Berry Project2023-10-02T20:04:09Z<p>Cskallak: /* Fuzzing */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing request that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using log deep sleep phases and short wake up times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This can be used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
Fuzzing is the act of sending arbitrary data or message with mutated lengths of fields. This can cause device failures and deadlocks.<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11765BLE-Berry Project2023-10-02T20:01:56Z<p>Cskallak: /* DoS due to Spoofed Connection */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing request that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using log deep sleep phases and short wake up times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
Older versions of BLE only allowed a peripheral device to only serve one connection at a time. This can be used by an adversary to prevent the legit central device from discovering the peripheral by connecting it and keeping the connection open. This restriction was lifted, but the ability to serve multiple connections must be configured by the device manufacturer and therefore is not used by most devices.<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11764BLE-Berry Project2023-10-02T19:42:20Z<p>Cskallak: /* Battery Draining Attacks */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
Battery drain attacks aim to preform a Denial of Service by draining the devices' battery. This can be either achieved by flooding a device by many pairing request that then don't get performed, or by connecting to the device and using its services and denying it to sleep. Many devices achieve a long battery life by using log deep sleep phases and short wake up times, which is prevented by an adversary in this case.<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11763BLE-Berry Project2023-10-02T19:37:40Z<p>Cskallak: /* IRK Stealing */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
The BLE provides a function to hide the address of and device by using private address. This security feature aims to prevent tracking of devices because they change their address periodically. The devices still can establish a connection by resolving the private address by calculating a hash with the usage of the Identity Resolving Key. This key gets distributed after a legit connection establishment. Therefore, can an adversary spoof another device and tell the target that it lost the long term key and initiate a new pairing process and gathers the IRK.<br />
<br />
==== Battery Draining Attacks ====<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11762BLE-Berry Project2023-10-02T19:31:16Z<p>Cskallak: /* Spoofing */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
Spoofing is the process of changing the Bluetooth address to another one to impersonate the other device. BLE Spoofing cannot be prevented and is one of the biggest vulnerability of the communication protocol. Furthermore, many BLE chip manufacturer provide the functionality to change the address with manufacturer specific host controller interface (HCI) commands, which is abused for spoofing.<br />
<br />
==== IRK Stealing ====<br />
<br />
==== Battery Draining Attacks ====<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11761BLE-Berry Project2023-10-02T19:26:45Z<p>Cskallak: /* Radio Jamming */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
Radio jamming aims to perform a Denial of Service (DoS) by disrupting sent data with interfering signals. Radio jamming can be performed on all channels at the same time (called full band jamming) or selective on a single channel. Furthermore, can be differentiated into persistent and reactive jamming. Persistent full band jamming can be detected easily because it interferes with all sent messages. Selective reactive jamming on the other hand is hard to detect because it only jams specific messages.<br />
<br />
==== Spoofing ====<br />
<br />
==== IRK Stealing ====<br />
<br />
==== Battery Draining Attacks ====<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11760BLE-Berry Project2023-10-02T19:19:45Z<p>Cskallak: /* Sniffing / Eavesdropping */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
* [https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
* [https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
* [https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
<br />
==== Spoofing ====<br />
<br />
==== IRK Stealing ====<br />
<br />
==== Battery Draining Attacks ====<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11759BLE-Berry Project2023-10-02T19:19:27Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE separates the Threats in the following six categories:<br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Threat Vectors ===<br />
<br />
==== Sniffing / Eavesdropping ====<br />
<br />
Sniffing or eavesdropping is performed with BLE by scanning the Radio for messages. This results in an information disclosure, but can be countered if encryption is used to provide confidentiality. The BLE standard itself provides AES-CCM encryption with message authentication by a key created with the usage of P256 ECDH. The commercial market provides some affordable USB Sniffing Accessories, which output pacap files that can be analyzed with [https://www.wireshark.org/ wireshark]:<br />
[https://greatscottgadgets.com/ubertoothone/ Ubertooth One]<br />
[https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le NordicRF Sniffer]<br />
[https://www.adafruit.com/product/2269 Adafruit Bluefruit LE Sniffer]<br />
<br />
==== Radio Jamming ====<br />
<br />
==== Spoofing ====<br />
<br />
==== IRK Stealing ====<br />
<br />
==== Battery Draining Attacks ====<br />
<br />
==== DoS due to Spoofed Connection ====<br />
<br />
==== Fuzzing ====<br />
<br />
==== Downgrade Attacks ====<br />
<br />
==== Bruteforcing Legacy Pairing Encryption Key ====<br />
<br />
==== DoS due to Key replacement ====<br />
<br />
==== Machine in the Middle ====<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11758BLE-Berry Project2023-10-02T19:00:31Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
STRIDE <br />
* Spoofing<br />
* Tampering<br />
* Repudiation<br />
* Information disclosure<br />
* Denial of Service<br />
* Elevation of Privilege <br />
<br />
<br />
[[File:BLE Berry Project STRIDE3.png|600px]]<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11757BLE-Berry Project2023-10-02T18:58:02Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
<br />
[[File:BLE Berry Project STRIDE3.png|800px]]<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_STRIDE3.png&diff=11756File:BLE Berry Project STRIDE3.png2023-10-02T18:57:51Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11755BLE-Berry Project2023-10-02T18:57:11Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
<br />
[[File:BLE Berry Project STRIDE.png|800px]]<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11754BLE-Berry Project2023-10-02T18:56:23Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
<br />
[[File:BLE Berry Project STRIDE2.png|800px]]<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11753BLE-Berry Project2023-10-02T18:53:48Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Model.png|800px]]<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
[[File:BLE Berry Project Threat Dependencies.png|800px]]<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
<br />
[[File:BLE Berry Project STRIDE.png|800px]]<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_STRIDE.png&diff=11752File:BLE Berry Project STRIDE.png2023-10-02T18:53:30Z<p>Cskallak: Cskallak uploaded a new version of File:BLE Berry Project STRIDE.png</p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_STRIDE.png&diff=11751File:BLE Berry Project STRIDE.png2023-10-02T18:52:11Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_Threat_Model.png&diff=11750File:BLE Berry Project Threat Model.png2023-10-02T18:47:50Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:BLE_Berry_Project_Threat_Dependencies.png&diff=11749File:BLE Berry Project Threat Dependencies.png2023-10-02T18:45:04Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11748BLE-Berry Project2023-10-02T18:42:25Z<p>Cskallak: /* Threat Model */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
xxxxx Image of Threatmodel xxxxx<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack relies on address spoofing and can benefit from Radio Jamming. The dependencies of the Threat is shown in the figure below.<br />
<br />
xxxxx Image of Dependencies xxxxx<br />
<br />
The STRIDE method was used to categorize the discovered Threats, as shown in the following table.<br />
<br />
xxxxx Stride xxxxx<br />
<br />
=== Step 1 ===<br />
<br />
==== Step 1.2 ====<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11747BLE-Berry Project2023-10-02T18:35:20Z<p>Cskallak: </p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool called BLE Berry to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
<br />
== Threat Model ==<br />
<br />
The Threat Model was performed by analyzing the BLE portion of the BLE Standard and gathering further information's from numerous white papers and scientific papers. The gathered Threats and Vulnerabilities got mapped to the Layer/Protocol they are performed on, as shown in the figure below.<br />
<br />
xxxxx Image of Threatmodel xxxxx<br />
<br />
Some of the Threats have use other Threats as an entry vector, e.g., a machine-in-the-middle attack rely <br />
<br />
<br />
The Threat Model is based on the STRIDE Method<br />
<br />
<br />
=== Step 1 ===<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11746BLE-Berry Project2023-10-02T18:24:30Z<p>Cskallak: /* Summary */</p>
<hr />
<div>== Summary == <br />
<br />
This Project is the result of a master’s thesis that created a Threat Model of the Bluetooth Low Energy (BLE) Standard and developing a tool to enable easier BLE Development and to perform basic pentesting operations.<br />
<br />
== Requirements ==<br />
<br />
* Operating system: Ubuntu 18.04 bionic amd64<br />
* Packages: git emacs<br />
<br />
In order to complete these steps, you must have followed [[Some Other Documentation]] before.<br />
<br />
== Description ==<br />
<br />
=== Step 1 ===<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=BLE-Berry_Project&diff=11745BLE-Berry Project2023-09-28T17:33:51Z<p>Cskallak: Created page with "== Summary == Description what this documentation is about. == Requirements == * Operating system: Ubuntu 18.04 bionic amd64 * Packages: git emacs In order to complete these steps, you must have followed Some Other Documentation before. == Description == === Step 1 === Enter these commands in the shell echo foo echo bar === Step 2 === Make sure to read * War and Peace * Lord of the Rings * The Baroque Cycle == Used Hardware == Device to be used with..."</p>
<hr />
<div>== Summary == <br />
<br />
Description what this documentation is about.<br />
<br />
== Requirements ==<br />
<br />
* Operating system: Ubuntu 18.04 bionic amd64<br />
* Packages: git emacs<br />
<br />
In order to complete these steps, you must have followed [[Some Other Documentation]] before.<br />
<br />
== Description ==<br />
<br />
=== Step 1 ===<br />
<br />
Enter these commands in the shell<br />
<br />
echo foo<br />
echo bar<br />
<br />
=== Step 2 ===<br />
<br />
Make sure to read<br />
<br />
* War and Peace<br />
* Lord of the Rings<br />
* The Baroque Cycle<br />
<br />
== Used Hardware ==<br />
<br />
[[Device to be used with this documentation]]<br />
[[Maybe another device to be used with this documentation]]<br />
<br />
== Courses ==<br />
<br />
* [[A course where this documentation was used]] (2017, 2018)<br />
* [[Another one]] (2018)<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=7372Exploiting the USB Ninja BLE Connection2021-05-28T13:49:47Z<p>Cskallak: </p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|600px]]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|600px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== References ==<br />
<br />
* https://www.greatscottgadgets.com/ubertoothone/<br />
* https://usbninja.com/<br />
* https://www.bluetooth.com/specifications/assigned-numbers/<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4820Exploiting the USB Ninja BLE Connection2020-11-12T17:39:34Z<p>Cskallak: /* References */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|600px]]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|600px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
== Conclusio is following soon ==<br />
<br />
== References ==<br />
<br />
* https://www.greatscottgadgets.com/ubertoothone/<br />
* https://usbninja.com/<br />
* https://www.bluetooth.com/specifications/assigned-numbers/<br />
<br />
[[Category:Documentation]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4819Exploiting the USB Ninja BLE Connection2020-11-12T17:35:12Z<p>Cskallak: /* Step Two: Ubertooth BLE Connection Sniffing */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|600px]]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|600px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
== Conclusio is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4818Exploiting the USB Ninja BLE Connection2020-11-12T17:34:54Z<p>Cskallak: /* Part 2 is following soon */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|400px]]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|400px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
== Conclusio is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4817Exploiting the USB Ninja BLE Connection2020-11-12T17:34:35Z<p>Cskallak: /* Step Two: Ubertooth BLE Connection Sniffing */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|400px]]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|400px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4816Exploiting the USB Ninja BLE Connection2020-11-12T17:34:14Z<p>Cskallak: /* Step Two: Ubertooth BLE Connection Sniffing */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
[[File:USBNINJAWIRESHARK.png|400px]<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
[[File:USBNINJACON.png|400px]]<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=File:USBNINJAWIRESHARK.png&diff=4815File:USBNINJAWIRESHARK.png2020-11-12T17:34:01Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=File:USBNINJACON.png&diff=4814File:USBNINJACON.png2020-11-12T17:33:43Z<p>Cskallak: </p>
<hr />
<div></div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4813Exploiting the USB Ninja BLE Connection2020-11-12T17:30:59Z<p>Cskallak: /* Step Two: Ubertooth BLE Connection Sniffing */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
After installing the Ubertooth functions and get the device running, I started to sniff the transferred data and piped it directly into wireshark<br />
<br />
Terminal A:<br />
mkfifo /tmp/pipe <br />
sudo wireshark -i /tmp/pipe<br />
<br />
<br />
Terminal B: <br />
ubertooth-btle -f E1:F1:22:F6:28:B5 -c /tmp/pipe<br />
<br />
** Wiresahrk image**<br />
<br />
The Wireshark output shows that the transmitter only interacts with the handle 0x22 and 0x25. I the following figure shows the connection in a simplified way.<br />
<br />
** Connection image**<br />
<br />
During the Connection establishment the exchange MTX gets discussed followed by a write request to the handle 0x22 with the value 0x0100. Then the USB Cable responds with an acknowledgement. I think that this operation causes the Error in interactive mode of the gatttool but I did use it in script of Step Three. <br />
<br />
When a button is Pressed it first send a write request to the handle 0x25 with the value 0x38383838. This value is the Password in plaintext but coded as hex (0x38383838 = 8888). Because of that it is possible to overtake the connection if the password got sniffed. After the acknowldgment its send either the value 0x413d4c0d0a (Button A) or 0x423d4c0d0a (Button A) to tirgger the corresponding Payload. Attentive observer will instandly recognize that the first hexpair 0x41 and 0x42 of the sent values are A and B in ASCII and indicate the used buttons.<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4812Exploiting the USB Ninja BLE Connection2020-11-12T16:03:42Z<p>Cskallak: /* Step Three: Writing a Contolling Python Script */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4811Exploiting the USB Ninja BLE Connection2020-11-12T16:03:07Z<p>Cskallak: /* Step Three: Writing a Contolling Python Script */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4810Exploiting the USB Ninja BLE Connection2020-11-12T16:01:06Z<p>Cskallak: /* Reverse Engeneering The Remote */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing | Step Two: Ubertooth BLE Connection Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallakhttps://wiki.elvis.science/index.php?title=Exploiting_the_USB_Ninja_BLE_Connection&diff=4809Exploiting the USB Ninja BLE Connection2020-11-12T15:58:10Z<p>Cskallak: /* Reverse Engeneering The Remote */</p>
<hr />
<div>== Summary == <br />
<br />
This documentation is a summary how I exploited the USB Ninja BLE Connection, so that it is able to Control the Bad USB cable with a raspberry pi an a simple python script that is linked in the sources.<br />
<br />
== Used Hardware and Software ==<br />
<br />
# The [[USB Ninja Pro-kit with Remote control]]<br />
## Containing 3 Bad USB cables (only one is needed).<br />
## Remote Control<br />
<br />
# Hacking Hardware<br />
## [[Raspberry Pi 3, Model B+, WLAN, BT]]<br />
## [[Ubertooth One, 2.4 GHz wireless development platform]]<br />
<br />
# Hacking Software <br />
## Hcitool (Linux preinstalled)<br />
## Gatttool (Linux preinstalled)<br />
## Ubertooth Tools (Too install them read: [[Bluetooth Sniffing with Ubertooth: A Step-by-step guide]])<br />
<br />
== USB Ninja Pro-kit ==<br />
<br />
[[File:USBNINJADEV.png|thumb|right|400px||USB Ninja]]<br />
<br />
The USB Ninja is a Rubberducky in a USB cable that comes in the flavours USB to USB micro, USB to USB-C and USB to Lightning. The bad USB cable can be programmed with two payloads. The payloads are developed under the usage of the Arduino IDE with the USBNinja libraries. During the attack phase its possible to start triggered payloads can be either by plugging the bad USB cable in or with the magnet or via the BLE 4.0 Remote. The trigger modes get defined by the way the c code is programmed.<br />
<br />
The Remote itself has a leaver to turn it on and off and the button A and button B, which activate their corresponding payload. There is also a USB micro input to charge the Remote or to edit the shared secret.<br />
<br />
The website states that the remote automatically connects to the bad USB cable if the defined passwords are the same. Where the Remote need a driver and a program to set the password, it can be directly done in the source code of the payload of the bad USB cable.<br />
<br />
Sadly the developers require that the user uses Windows based Operating systems because its only possible to update the password of the Remote with a windows program that can be downloaded on the manufacturers website in the help tab. Furthermore, this software gets treated as malicious software form Windows because it doesn't have a manufacturer certificate. So the users have to click threw the warning from windows defender to change the password. I personally would much more like to see a simple shell script for Linux and a batch script for Windows to do the job.<br />
<br />
Anyway, the standard password is <code>8.8.8.8</code> and as long as the user uses only one Remote at the same time it doesn't really matter. Enough background knowledge let's get to the pen testing.<br />
<br />
== Reverse Engeneering The Remote ==<br />
<br />
=== Step one: Standard BLE Actions ===<br />
<br />
As I started to test the USBNinja in a normal fashion, I got curios, how much information I can gather by using the standard the programmes that come with Linux. I shut down the Remote, so the bad USB Cable BLE Module can be found by devices. Then I run the <code>hcitool lescan</code> command that is used by the usual Linux BLE discovery function.<br />
<br />
sudo hcitool lescan<br />
<br />
LE Scan ...<br />
E1:F1:22:F6:28:B5 (unknown)<br />
E1:F1:22:F6:28:B5 Ninja<br />
XX:XX:XX:XX:XX:XX<br />
XX:XX:XX:XX:XX:XX (unknown)<br />
<br />
The Raspberry instantly found the BLE signal of the bad USB cable and i might be lucky to gather informaten with the gatttool. As I connected via the gatttool tho the USB cable it closed the connection after two seconds due to invalid file descriptor in the glib. This error makes the Interactive mode useless. <br />
<br />
gatttool -I<br />
<br />
[ ][LE]> connect E1:F1:22:F6:28:B5<br />
Attempting to connect to E1:F1:22:F6:28:B5<br />
Connection successful<br />
[E1:F1:22:F6:28:B5][LE]><br />
(gatttool:32016): GLib-WARNING **: 13:54:39.135: Invalid file descriptor.<br />
<br />
But the not interactive mode did succeed fast enough to work before the Error occurs. So I used the characteristics command form gatttool to list all discoverable characteristics of the device.<br />
<br />
gatttool -b E1:F1:22:F6:28:B5 --characteristics<br />
<br />
handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb<br />
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb<br />
handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb<br />
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002aa6-0000-1000-8000-00805f9b34fb<br />
handle = 0x000b, char properties = 0x20, char value handle = 0x000c, uuid = 00002a05-0000-1000-8000-00805f9b34fb<br />
handle = 0x000f, char properties = 0x02, char value handle = 0x0010, uuid = 00002a29-0000-1000-8000-00805f9b34fb<br />
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a24-0000-1000-8000-00805f9b34fb<br />
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a25-0000-1000-8000-00805f9b34fb<br />
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a27-0000-1000-8000-00805f9b34fb<br />
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a26-0000-1000-8000-00805f9b34fb<br />
handle = 0x0019, char properties = 0x02, char value handle = 0x001a, uuid = 00002a28-0000-1000-8000-00805f9b34fb<br />
handle = 0x001b, char properties = 0x02, char value handle = 0x001c, uuid = 00002a23-0000-1000-8000-00805f9b34fb<br />
handle = 0x001d, char properties = 0x02, char value handle = 0x001e, uuid = 00002a50-0000-1000-8000-00805f9b34fb<br />
handle = 0x0020, char properties = 0x10, char value handle = 0x0021, uuid = 0000fff1-0000-1000-8000-00805f9b34fb<br />
handle = 0x0024, char properties = 0x0e, char value handle = 0x0025, uuid = 0000fff2-0000-1000-8000-00805f9b34fb<br />
handle = 0x0027, char properties = 0x1c, char value handle = 0x0028, uuid = 0000fff3-0000-1000-8000-00805f9b34fb<br />
handle = 0x002c, char properties = 0x28, char value handle = 0x002d, uuid = 8ec90003-f315-4f60-9fb8-838830daea50<br />
<br />
So the characteristics are not encrypted and can be read without the key. Furthermore the first 13 of are well-known GATT Services defined by the Bluetooth Special Interest group. These handles and their values are listed in the table below:<br />
<br />
{| class="wikitable"<br />
! Handle !! Privileges !! Characteristic !! Value<br />
|-<br />
| 0x0003 || Read and Write || Device Name || USBNinja+<br />
|-<br />
| 0x0005 || Read || Appearance || Appearance Unknown<br />
|-<br />
| 0x0007 || Read || Pheripheral preffered connection Parameters || 08 00 08 00 00 00 f4 01 <br />
|-<br />
| 0x0009 || Read || Central Address Resolution || 01 <br />
|-<br />
| 0x0010 || Read || Manufacturer Name String || Proxgrind <br />
|-<br />
| 0x0012 || Read || Model Number String || Ninja <br />
|-<br />
| 0x0014 || Read || Serial Number String || 20190912 <br />
|-<br />
| 0x0016 || Read || Hardware Revision String || V2.0 <br />
|-<br />
| 0x0018 || Read || Firmware Revision String || V1.0 <br />
|-<br />
| 0x001a || Read || Software Revision String || v5.0 <br />
|-<br />
| 0x001c || Read || System ID || 64 00 00 00 00 9e 00 00 <br />
|-<br />
| 0x001e || Read || PnP ID || 01 d2 00 10 08 01 00<br />
|-<br />
|}<br />
<br />
The wellknown Services were easy to read and to decipher but the four custom services couldn't be reverse engineered by using only the gatttool. The rest of this paragraph is a listing of the commands used to create the table above and how to decode the values. So feel free to jump to the Ubertooth BLE connection sniffing part by klicking this link: [[Exploiting_the_USB_Ninja_BLE_Connection#Step_Two:_Ubertooth_BLE_Connection_Sniffing]].<br />
<br />
''' [1] [Device Name] [RW] handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 3 <br />
Characteristic value/descriptor: 55 53 42 4e 69 6e 6a 61 2b<br />
<br />
55 53 42 4e 69 6e 6a 61 2b hex = USBNinja+ ASCII<br />
<br />
char-write-req 3 4861636b6564<br />
Characteristic value was written successfully<br />
char-read-hnd 3<br />
Characteristic value/descriptor: 48 61 63 6b 65 64<br />
<br />
''' [2] [Appearance] [R] handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 5 <br />
Characteristic value/descriptor: 00 00<br />
<br />
0 -> Appearance Unknown<br />
<br />
''' [3] [Pheripheral preffered connection Parameters] [R] handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 7 <br />
Characteristic value/descriptor: 08 00 08 00 00 00 f4 01 <br />
<br />
''' [4] [Central Address Resolution] [R] handle: 0x0008, char properties: 0x02, char value handle: 0x0009, uuid: 00002aa6-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 9 <br />
Characteristic value/descriptor: 01<br />
<br />
''' [5] [Service Change] [Indication] handle: 0x000b, char properties: 0x20, char value handle: 0x000c, uuid: 00002a05-0000-1000-8000-00805f9b34fb '''<br />
<br />
Indication services are for notifications and can not be read that easily.<br />
<br />
''' [6] [Manufacturer Name String] [R] handle: 0x000f, char properties: 0x02, char value handle: 0x0010, uuid: 00002a29-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 10<br />
Characteristic value/descriptor: 50 72 6f 78 67 72 69 6e 64<br />
<br />
50 72 6f 78 67 72 69 6e 64 hex = Proxgrind ASCII<br />
<br />
''' [7] [Model Number String] [R] handle: 0x0011, char properties: 0x02, char value handle: 0x0012, uuid: 00002a24-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 12<br />
Characteristic value/descriptor: 4e 69 6e 6a 61<br />
<br />
4e 69 6e 6a 61 hex = Ninja ASCII<br />
<br />
''' [8] [Serial Number String] [R] handle: 0x0013, char properties: 0x02, char value handle: 0x0014, uuid: 00002a25-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 14<br />
Characteristic value/descriptor: 32 30 31 39 30 39 31 32<br />
<br />
32 30 31 39 30 39 31 32 hex = 20190912 ASCII<br />
<br />
''' [9] [Hardware Revision String] [R] handle: 0x0015, char properties: 0x02, char value handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 16<br />
Characteristic value/descriptor: 56 32 2e 30 <br />
<br />
56 32 2e 30 hex = V2.0 ASCII<br />
<br />
''' [10] [Firmware Revision String] [R] handle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 18<br />
Characteristic value/descriptor: 56 31 2e 30<br />
<br />
56 31 2e 30 hex = V1.0 ASCII<br />
<br />
''' [11] [Software Revision String] [R] handle: 0x0019, char properties: 0x02, char value handle: 0x001a, uuid: 00002a28-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1a<br />
Characteristic value/descriptor: 76 35 2e 30<br />
<br />
76 35 2e 30 hex = v5.0 ASCII<br />
<br />
''' [12] [System ID] [R] handle: 0x001b, char properties: 0x02, char value handle: 0x001c, uuid: 00002a23-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1c<br />
Characteristic value/descriptor: 64 00 00 00 00 9e 00 00<br />
<br />
''' [13] [PnP ID] [R] handle: 0x001d, char properties: 0x02, char value handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb '''<br />
<br />
char-read-hnd 1e<br />
Characteristic value/descriptor: 01 d2 00 10 08 01 00<br />
<br />
=== Step Two: Ubertooth BLE Connection Sniffing ===<br />
<br />
<br />
<br />
=== Step Three: Writing a Contolling Python Script ===<br />
<br />
After the BLE connection sniffing process, I started to write a Python script that mimics and the USB Ninja Remote and it instantly worked to print well-known characteristics of the device and to trigger the payload A. After a bit of bug fixing I figured out how to payload B and converted the simple script to an advanced application which will be publicly available on gitlab under this link soon.<br />
<br />
Usage:<br />
./USBNinja.py -m <mode> [options]<br />
<br />
Modes:<br />
r Remote: Mimics the USB ninja Remote <br />
c Converter: Converts ducky.txt payloads into USBNinja.c <br />
u TBA: TBA<br />
<br />
Remote:<br />
./USBNinja.py -m r -d <BDADDR><br />
<br />
Info Prints device info<br />
Button A Triggers payload A<br />
Button B Triggers payload B<br />
Quit Leaves interactive mode<br />
<br />
Converter:<br />
./USBNinja.py -m c -i <input file> -j <input file 2> -o <output file> -l <keyboard language> -t <triggermode><br />
<br />
TBA:<br />
... <br />
<br />
'''Example usage of the Remote mode:'''<br />
<br />
./USBNinja.py -m r -d E1:F1:22:F6:28:B5<br />
<br />
[E1:F1:22:F6:28:B5][LE]>info<br />
Device name: Ninja<br />
Model number string: Ninja<br />
Serial number string: 20190912<br />
Hardware revision string: V2.0<br />
Firmware revision string: V1.0<br />
Software revision string: v5.0<br />
System id: 00 00 00 00 9e 00 00<br />
PnP id: 01 d2 00 10 08 01 00<br />
[E1:F1:22:F6:28:B5][LE]>Button A<br />
Pressed Button A<br />
[E1:F1:22:F6:28:B5][LE]>Button B<br />
Pressed Button B [E1:F1:22:F6:28:B5][LE]>Quit<br />
<br />
== Part 2 is following soon ==<br />
<br />
== References ==<br />
<br />
* https://wikipedia.org<br />
* https://google.com<br />
<br />
Category:Documentation[[]]</div>Cskallak