Exploit YAML

Example:

name: "sweyntooth_dhcheck_skip" 
poc_source: "https://github.com/Matheus-Garbelini/sweyntooth_bluetooth_low_energy_attacks"
cve: "CVE-2020-13593"
affected: "Texas Instruments"
profile: "LE"
type: "DoS"
automated: true
max_timeout: 20
bt_version_min: 4.0
bt_version_max: 5.4
hardware: "hci, nRF52840"
command: "non_compliance_dhcheck_skip.py"
file_type: "python2.7"
parameters:
  - name: "port_nRF52840"
    name_required: False
    help: "Hardware port"
    required: true
    parameter_connector: ""
  - name: "target"
    name_required: False
    help: "Target MAC address"
    required: true
    parameter_connector: ""
directory: "sweyntooth/extras/"
description: "This exploit does..."

Fields:

• name [str, required]: the name of the exploit and the file name of the result-json and log file for the exploit, should be one coherent string
• poc_source [str, can be ""]: url to the exploit PoC, name of the author, ...
• cve [str, can be ""]: CVE identifier of the vulnerability
• affected [str, can be ""]: specific vendors, chips, bluetooth versions, etc. that are affected by the vulnerability
• profile [str, required]: the bluetooth profile that is affected by the vulnerability, can be "BR/EDR", "LE" or "BR/EDR + LE"
• type [str, required]: the type of the exploit, e.g. DoS, Crash, Sniffing, ... When the type is "DoS" a availability check will be performed after finishing the exploit. When the type is something like "PoC - Sniffing" please make sure to add Sbleedy Report Data in your PoC code
• automated [bool, required]: specifies if the exploit can be run without user intervention. When running sbleedy without the flag -wi or --withinput, only exploits with automated: True are executed. When using the flag -wi the tool will wait for your confirmation to be ready for exploits with automated: False
• max_timeout [int, required]: specifies the time period in seconds after which the execution of the exploit is terminated. If the timeout is set as -1, the exploit will run until it exits/finishes by itself
• bt_version_min and bt_version_max [float, required]: the minimum and maximum bluetooth version that is affected by the vulnerability. When running sbleedy, a bluetooth version check of the target device will be tried and if successfull, only exploits with the correct version frame will be executed
• hardware [str, required]: the hardware that is required for the exploit to work. Every hardware named has to have a profile in the hardware folder. When adding multiple hardware names they have to be separated by a comma. When no hardware is needed, use "" (empty string).
• command [str, required]: the name of the file that contains the PoC code for the exploit. If the code is C, the command should look like when you execute a binary (e.g. ./poc_badkarma). Even when you add a .c file (e.g. poc_badkarma.c) to the modules folder, the framework will check for a binary and compile the .c file with gcc if necessary.
• file_type [str, required]: the language (+ version) of the PoC code file. Currently available in the framework are "python2.7", "python3", "c" and "exe". The handling of other file types would have to be added in sbleedyCLI/engines/sbleedyEngine.py.
• parameters: the parameters that will be passed to the PoC code for the exploit
  • name [str, required]: the name of the parameter, e.g. "target" (add - or -- if necessary). If the parameter is for the port of the connected hardware, e.g. /dev/ttyACM0 for the nRF dongle, the name has to be "port_" followed by the correct hardware name (according to the hardware profile yaml). When the name of the parameter is "target" or "port_xxx", the corresponding value will be added by the framework (if e.g. hci0 should be passed as --hci, you can set the name of the param as port_--hci and the framework will pass the computed hci value as --hci). Additional parameter values can be passed when running sbleedy (e.g. "sbleedy -t AB:CD:EF:GH:IJ add_param test" passes an additional parameter with the name add_param and the value test).
  • name_required [bool, required]: True, if the parameter needs a name to be passed, e.g. "python poc_code.py --target AB:CD:EF:GH:IJ"
  • help [str, can be ""]: description of the parameter
  • required [bool, required]: True, if this parameter is required by the PoC code to run
  • parameter_connector [str, required]: the symbol between the parameter name and its value, e.g. " " (python poc_code.py --target AB:CD:EF:GH:IJ) or "=" (python poc_code.py --target=AB:CD:EF:GH:IJ)
• directory [str, required]: the path to the exploit PoC starting in the modules folder
• description [str, can be ""]: describes what the exploit does or how the underlying vulnerability works