Exploit YAML DSL – Advanced Configurations For Bluetooth Vulnerability Testing

Dives into the intricate world of YAML-based Domain Specific Language (DSL) used for defining and managing exploits in security testing environments.

This article explores how YAML DSL facilitates precise configuration and automation of tools targeting Bluetooth vulnerabilities, showcasing examples like Internalblue and Braktooth to illustrate practical applications.

Stay tuned for an in-depth analysis of cutting-edge security exploitation techniques.

name: "internalblue_CVE_2018_5383_Invalid"
author: "Internalblue team"
type: "PoC"
mass_testing: true
max_timeout: 30
bt_version_min: 2.0
bt_version_max: 5.2
hardware: "nexus5"
command: "./internalblue_CVE_2018_5383_Invalid.sh"
parameters:
  - name: "target"
 name_required: false
 type: "str"
 help: "Target MAC address"
 required: true
 is_target_param: true
 parameter_connector: " "
  - name: "directory"
 name_required: false
 type: "str"
 help: "Directory to save output"
 required: true
 is_target_param: false
 parameter_connector: " "
log_pull:
  in_command: true
  pull_parameter: "directory"
directory:
  change: true
  directory: "modules/tools/custom_exploits"

name: "invalid_feature_page_execution"
author: "Braktooth team"
type: "PoC"
mass_testing: true
bt_version_min: 4.0
bt_version_max: 5.4
hardware: "esp32"
command: "./bin/bt_exploiter --host-port=/dev/ttyUSB1 --exploit=invalid_feature_page_execution --random_bdaddress"
parameters:
  - name: "--target"
 type: "str"
 name_required: true
 help: "Target MAC address"
 required: true
 is_target_param: true
 parameter_connector: "="
log_pull:
  in_command: false
  from_directory: true
  relative_directory: true
  pull_directory: "modules/tools/braktooth/wdissector/logs/Bluetooth"
directory:
  change: true
  directory: "modules/tools/braktooth/wdissector"

• name – is a name and a reference to the exploit, should be unique, type – str
• author – author or authors of the exploit, type – str
• type – “PoC” currently not used, but reserved for distinguishing between different types of exploits and validation of the results, type – str
• mass_testing – determines whether the exploit should be tested in “test all exploits” functionality. If it doesn’t make sense to use it in a fully automated manner – set it to false. It still would be possible to call it individually, type – bool
• max_timeout – determines the number of seconds the toolkit would wait until the payload times out. Useful for the DoS proof of concepts. type – int
• bt_version_min – float value defining the minimum required Bluetooth version that exploits supports, type – float
• bt_version_max – float value defining the maximum required Bluetooth version that exploits supports, type – float
• hardware – hardware profile name that needs to be available for exploit to work, type – str
• command – bash CLI-style command that calls a script or binary that runs an exploit, type – str
• parameters – a list of parameters that are supported or needed for the exploit to function, in case the exploit doesn’t need any parameters the value should be set to [] as in the example EXAMPLE #2. In addition to that, all parameters have a special structure and also have some special parameters that define a directory to save the output or logs and another one defining a target MAC address. Each parameter should have the following parameters set:
  • name – unique name of the parameter as it should be passed to the script or binary being called. For example, it could be set to “-t”, “–target”, or “target”. If you don’t need a parameter name use the following parameter name_required. type – str
  • name_required – value that determines whether or not to include a parameter name in the command. If set to false, the parameter value would be added without a parameter name, type – str
  • type – describes a Python 3 type of the parameter, type – str
  • help – value that provides help description for operators, type – str
  • is_target_param – parameter, that if set to true takes its value from the –target parameter of the toolkit, and passes it to the command with this parameter name, type – bool
  • parameter_connector – value that is used to concatenate parameter name and parameter value, in the example it is set to a space ” “, type – str
• log_pull – parameters that describe, functionality related to pulling logs
  • in_command – parameter that is used to determine whether or not the log pulling functionality is done in the script or binary of the exploit, type – bool
  • pull_parameter – set to a parameter name that is used to pull logs, type – str
  • from_directory – needed only when in_command is set to false. parameter that determines whether or not the logs should be pulled from the whole directory or not. In the case set to true, will copy an entire directory to a new location, type – bool
  • relative_directory – needed only when in_command is set to false. parameter that determines whether or not the pull_directory parameter is a relative directory to the toolkit base path or not.
  • pull_directory – needed only when in_command is set to false and relative_directory set to true. The parameter that has a value of the relative pull location inside the toolkit path.
• directory – parameters that describe functionality related to changing the current working directory to execute an exploit
  • change – value used to determine whether or not to change a current working directory for exploit execution. The directory will be changed back to the one the toolkit had after the exploit has finished. type – bool
  • directory – value of the relative to the base path of the toolkit directory path that should be changed, type – str