This folder does not contain new extra attacks. It contain scripts that trigger non-compliances found in some SoC vendors and additional tests for some SweynTooth vulnerabilities. The intention of this folder is to contain PoCs of other BLE vulnerabilities not covered by SweynTooth such as Knob (BLE variant - downgrade to 7 bytes of key entropy).
This test requires the use of a Linux distribution to work (Tested on Ubuntu 18.04). The following non-compliance test scripts are available:
| Script | Non-compliance | Description |
|---|---|---|
| (A0) - DHCheck Skip | [Vol 3] Part H, Section 2.3.5.6.5 | Verifies if the DHCheck can be skipped by starting the encryption setup before the DHCheck message is sent to the peripheral (script uses the LTK calculated upon receiving the peripheral random nonce). TI CC2640 devices were found to be affected by such behaviour (not exploitable via MitM due to previous phase 2 security). |
| (A1) - anomaly_unexpected_encryption_start.py | Non-specified | Tests if each message during the SMP Legacy and Secure Connections pairing can be interrupted by the encryption setup procedure. If the peripheral answers with a LL_ENC_START_REQ whenever the encryption setup happens during the SMP, the peripheral is mostly likely using an unknow STK/LTK. Currently, the spec. does not clarify or restrict what happens when the encryption setup preempts the pairing procedure (phase 2), yielding a undefined behaviour. This script helps vendors to detect whether their implementation exhibits potentially dangerous behaviour such Zero LTK Installation and DHCheck skip. |
| (A2) - non_compliance_nonzero_ediv_rand.py | [Vol 3] Part H, Section 2.4.4.1 | Verifies if the peripheral accepts a non-zero ediv or non-zero rand during the pairing procedure (between phase 2 and 3). According to the spec, the peripheral shall only accept a zero ediv and rand on the first encryption setup in order to complete the pairing procedure. The correct (i.e., non-zero) ediv and rand are negotiated only after the completion of the key exchange (phase 3) between peripheral and central (see captures folder. |
| (A3) - non_compliance_multiple_version.py | [Vol 6] Part B, Section 5.1.5 | Tests if peripheral responds to multiple LL_VERSION_IND during the same connection (i.e., accepts version indication more than once). Telink Semiconductor devices were found to infinitely reply to version requests during the same connection (see captures folder). |
| (A4,A5) non_compliance_data_during_encryption_setup.py | [Vol 6] Part B, Section 5.1.3.1 and [Vol 6] Part B, Section 2.4.2 | Tests if the peripheral responds to data packets during the encryption setup by starting encryption setup simultaneously with the SMP. According to the spec., once the encryption setup started, the peripheral shall not respond to packets unrelated to encryption setup. Telink Semiconductor devices were found to respond to SMP packets during the encryption setup (A4) and to send an unknown LL control PDU to the central (A5). |
| (A6) CC2540_truncated_connection_success.py | [Vol 6] Part B, Section 2.3.3.1 | Forces TI CC2540 peripheral to perform successful connection under a truncated connection request with 28 bytes. The peripheral "assumes" the following for the missing parameters: channel map=0x0000000001 hop increment=0 SCA=0 After the connection, the peripheral will keep sending LL PDUs on channel 1 (see captures folder). |
| (A7) Microchip_and_others_non_compliant_connection.py | [Vol 6] Part B, Section 2.3.3.1 | Performs a successful connection with the peripheral by using a non-compliant parameter: hop increment=0 If for some reason the peripheral rejects the connection, just change this parameter to 1-4. When the connection is successful, the peripheral accepts a non-compliant range (which shall be 5-16 according to the spec.) for the hop interval. |
Currently, the following extra tests are available:
| Script | Test Type | Description |
|---|---|---|
| knob_tester_ble.py | Vulnerability | Check if the BLE peripheral accepts its key size to be reduced to 7 bytes. This is application dependent as some devices may be programmed to allow the key to be within the standardized BLE key size (7-16). More secure applications strictly rejects any key size lower than 16. (Unpatched Telink SDKs allowed key sizes higher than 16, which is non-compliant) |
| CC2540_connection_req_crash_truncated.py | Non-compliance Vulnerability |
Truncates the connection request to 26 bytes. Triggers CVE-2019-19193 due to non-compliance (TI CC2540 Peripheral accepts truncated packet and assumes 0 for the missing connection parameters). |
| DA14680_att_mtu_length_5_malformed_accepted.py | Non-compliance | Sends a truncated ATT MTU request (Link Layer Length = 5). The peripheral responds to the non-compliant malformed request (see captures folder) |
| DA14680_att_mtu_length_114_silent_overflow_accepted.py | Non-compliance | Sends an ATT MTU request padded to 114 bytes (Link Layer Length = 114). The peripheral responds to the non-compliant malformed request (see captures folder) |
| DA14680_att_read_100_silent_overflow_crash.py | Vulnerability | Sends an ATT READ request padded to 114 bytes (Link Layer Length = 114). Triggers CVE-2019-17518 |
| DA14680_truncated_l2cap_crash.py | Vulnerability | Sends a truncated ATT READ request (Link Layer Length = 5). Triggers CVE-2019-17517 |