Identify the SoC and host stack, then check the published vulnerability corpus

Mechanism

A large share of real-world BLE compromise is not a novel cryptographic break but an unpatched component with a known, named, CVE-tracked flaw. The flaw can live in either of two places, and identifying which is the whole point of this step:

• The controller (the BLE SoC / radio firmware). SweynTooth is the canonical example: a family of link-layer flaws across BLE SoCs from multiple silicon vendors — deadlocks, crashes, buffer overflows, and the Zero-LTK Installation, which forces an encryption setup with a zero-filled Long Term Key and thereby bypasses LE Secure Connections [garbelini2020sweyntooth]. The CISA ICS alert names the affected vendors (NXP, Cypress, Telink, Dialog, Microchip, STMicroelectronics, Texas Instruments) [cisa2020sweyntooth], and the Telink Zero-LTK instance is tracked as CVE-2019-19194 (CVSS 8.8) [cve-2019-19194]. BLEEDINGBIT is a second controller case: a remote code-execution buffer overflow reachable from a malformed advertising packet in TI CC2640/CC2650 BLE-STACK firmware (CVE-2018-16986, CVSS 8.8) [cve-2018-16986].
• The host stack (the OS Bluetooth implementation). BleedingTooth is the canonical example: improper L2CAP input validation in the Linux BlueZ stack lets an adjacent, unauthenticated attacker escalate privilege without pairing (CVE-2020-12351, CVSS 8.8) [cve-2020-12351]. BLESA sits at the host-stack/standard boundary: the BLE reconnection procedure does not mandate authentication, so several stacks (BlueZ, Android, iOS) let an attacker impersonate a previously-paired peer after forcing a reconnect [wu2020blesa].

A third category is the standard itself, independent of any one chip: KNOB downgrades BR/EDR encryption key entropy to as little as one byte during negotiation, making the session key brute-forceable (CVE-2019-9506, CVSS 8.1) [antonioli2019knob][cve-2019-9506].

BSAM already provides mature, dedicated controls for exactly this triage: controller lifecycle status (BSAM-IG-01), controller vulnerabilities (BSAM-IG-02), host-stack vulnerabilities (BSAM-IG-03), and standard vulnerabilities (BSAM-IG-04). RFSAM does not re-derive them. This control exists to place the step in the RF assessment flow and to supply the one thing the RF assessor is best positioned to produce: the component inventory. That inventory comes from the label/FCC-ID and teardown for the silicon, and from a passive advertising fingerprint for the version and stack hints — the RF-capture prerequisite this control owns. The named-attack corpus above is representative, not exhaustive — it dates fast, so always check current vendor advisories and the Bluetooth SIG erratum feed against the components you actually identify. (For reference, the SweynTooth disclosure reports 11 new vulnerabilities under 13 CVE IDs; this control names only the canonical few rather than enumerating the family. BLESA is cited from its USENIX WOOT 2020 paper [wu2020blesa]; only the Apple instance carries a distinct CVE — CVE-2020-9770 — whose NVD entry does not name BLESA, so no CVE is asserted in this control’s attacks[].cve for it.)

Procedure

All steps below are passive (discovery, advertising capture, label inspection). Run them only against devices you are authorised to assess.

1. Read the silicon off the label / FCC ID. Find the FCC ID on the device and look it up; the internal photos and test report usually name the module or SoC.

   # Open the FCC ID search and enter the grantee code + product code from the label
   xdg-open "https://fccid.io/"

   Expected: the module/chip part number (e.g. a Nordic nRF52, TI CC26xx, Telink TLSR8x5x), which maps directly onto the BSAM-IG-02 controller-vulnerability lookup.

2. Passively discover and fingerprint from the air. Bring up a host BLE adapter and run a passive scan to capture the advertised name, service UUIDs and manufacturer-specific data (the company-ID prefix in manufacturer data identifies the vendor).

   sudo bettercap -eval "ble.recon on; sleep 20; ble.show; q"

   Expected: a table of nearby devices with MAC, address type (public vs random/RPA), advertised name and vendor — the advertising fingerprint (RFSAM-RES-04). Note the address type: a fixed public address is trackable; a rotating Resolvable Private Address is not.

3. Capture raw advertising PDUs (optional, for manufacturer data). Use a Sniffle-class sniffer via catnip to record the advertising channels into a PCAP for offline inspection in Wireshark.

   catnip sniff --board catsniffer --protocol ble --output adv.pcap

   Expected: an adv.pcap whose BTLE advertising frames carry the AdvData fields; the manufacturer-specific data’s leading 2-byte Company Identifier resolves to the SoC/module vendor.

4. Infer the BLE version and stack hints. From the captured advertising — extended advertising and the 2M/Coded PHYs imply BLE 5.x; LE Legacy-only advertising implies an older controller. Combine with the host OS where known (a phone/gateway behind the device implies its stack — e.g. Android Fluoride, Linux BlueZ, Apple). Expected: a (controller, host-stack, BLE version) tuple — the input the BSAM-IG controls need.

5. Run the BSAM Information-Gathering controls against the identified components. This is where the judgement is made; RFSAM hands off here.

   • BSAM-IG-01 — controller lifecycle status (is the SoC end-of-life / unpatchable?).
   • BSAM-IG-02 — controller vulnerabilities (e.g. SweynTooth, BLEEDINGBIT against the identified SoC).
   • BSAM-IG-03 — host-stack vulnerabilities (e.g. BleedingTooth against the identified stack).
   • BSAM-IG-04 — standard vulnerabilities (e.g. KNOB / spec-level reconnection issues).

6. Carry the result forward as scoping input to the RFSAM SP/PHY/LL capture controls. An end-of-life, unpatchable SoC with a published Zero-LTK bypass may make further dynamic RF testing moot — that finding is already decisive.

Field case

A representative engagement against a connected door-lock module:

• Step 1 (label): the FCC ID’s internal photos showed a Telink TLSR8253 module. That part appears in the SweynTooth disclosure’s affected list, immediately raising the Zero-LTK question (CVE-2019-19194) under BSAM-IG-02.
• Step 2 (air): bettercap saw the lock advertising under a static random address with manufacturer-specific data whose Company Identifier matched the module vendor — consistent with the label, and the device advertised LE-Legacy-only (no extended advertising), implying a pre-BLE-5 controller.
• Step 5 (BSAM): running BSAM-IG-01/IG-02 against “Telink TLSR8253, firmware [FILL: SDK version read from the device / vendor]” is the decisive step. If the firmware predates the Telink fix, the device is exposed to the Zero-LTK Secure-Connections bypass regardless of how strong the pairing looks.

The value RFSAM adds here is sequencing, not a new finding: the cheap, passive component inventory from this step scopes which SP/PHY/LL capture controls are worth running at all.

This field case is a representative example illustrating the workflow, not a measured engagement. The [FILL: …] firmware-version placeholder is intentional: replace it only with a value actually read from a device before claiming a specific finding.

Remediation

Developer (device firmware / SoC integration). Track your BLE SoC vendor’s advisory feed and the Bluetooth SIG erratum feed; ship the controller-firmware fixes for the named controller flaws (SweynTooth Zero-LTK / CVE-2019-19194 [cve-2019-19194], BLEEDINGBIT / CVE-2018-16986 [cve-2018-16986]). Enforce LE Secure Connections and reject a zero or out-of-order LTK install. Do not select an end-of-life SoC with no patch path for a new design.

Integrator (host / OS stack). Keep the host Bluetooth stack patched — BleedingTooth (CVE-2020-12351) is a BlueZ/kernel fix, so patch the kernel, not just the application [cve-2020-12351]. Enforce reconnection authentication so a forced reconnect cannot be impersonated (the BLESA class) [wu2020blesa]. Set and enforce a minimum encryption key size to defeat KNOB-style downgrade [antonioli2019knob][cve-2019-9506].

Operator (deployment / fleet). Maintain a component inventory (SoC + host stack + firmware version) per deployed device so a newly published CVE can be matched to the fleet quickly. Treat any controller that is end-of-life with no patch path as high-risk and plan replacement. Follow the remediation of the cited BSAM Information-Gathering controls (BSAM-IG-01…04), which own the formal judgement this control defers to.