SweynTooth: Unleashing Mayhem over Bluetooth Low Energy

Matheus E. Garbelini1; Sudipta Chattopadhyay1; Chundong Wang1

1Singapore University of Technology and Design

1 Introducing SWEYNTOOTH

The Bluetooth Low Energy (BLE) is a wireless communica-tion technology specially designed to prolong battery life ofdevices with different power consumption and usage capabili-ties. BLE consists of a set of many standardised protocols thatprovide remote connectivity and security between a simpledevice (peripheral) and the user’s device (central) which isusually a smartphone or a notebook. The relevant interactionbetween both devices is presented in Figure 1.

SWEYNTOOTH captures a family of 12 vulnerabilities(more under non-disclosure) across different BLE softwaredevelopment kits (SDKs) of seven major system-on-a-chip(SoC) vendors. The vulnerabilities expose flaws in specificBLE SoC implementations that allow an attacker in radiorange to trigger deadlocks, crashes and buffer overflows orcompletely bypass security depending on the circumstances.

LL Encryption procedure

MTU length request / response

2connection

(request)

Data channel connectionversion request / response

feature request / response

length request / response

5

Peripheral/Slave Central/Master

Advertisements

Channels37

38

39

scan(response)

scan(request)

Pairing procedure

6

7

4

3

1

pairing request / response8

SMP Legacy pairing or

Secure Connections9

10

Link Layer encrypted

Keys distribution procedure 11

12ATT request / response

(GATT services discovery)

Figure 1: BLE messages exchange diagram

SWEYNTOOTH potentially affects IoT products in appli-ances such as smart-homes, wearables and environmentaltracking or sensing. We have also identified several medicaland logistics products that could be affected.

As of today, SWEYNTOOTH vulnerabilities are found inthe BLE SDKs sold by major SoC vendors, such as TexasInstruments, NXP, Cypress, Dialog Semiconductors, Mi-crochip, STMicroelectronics and Telink Semiconductor.By no means, this list of SoC vendors is exhaustive in terms ofbeing affected by SWEYNTOOTH. We have followed respon-sive disclosure during our discovery, which allowed almostall SoC vendors to publicly release their respective patches al-ready. However, a substantial number of IoT products relyingon the affected SoCs for BLE connectivity will still need toindependently receive patches from their respective vendors,as long as a firmware update mechanism is supported by thevendor.

SWEYNTOOTH highlights concrete flaws in the BLE stackcertification process. We envision substantial amendmentsto the BLE stack certification to avoid SWEYNTOOTH stylesecurity flaws. We also urge SoC vendors and IoT productmanufacturers to be aware of such security issues and toinitiate focused effort in security testing.

A proper classification of the vulnerability set is presentedin the next section.

1.1 Types of vulnerabilitiesWe have classified the SWEYNTOOTH vulnerabilities accord-ing to their types and their behaviours on the affected BLEdevices.

• Crash: Vulnerabilities in this category can remotelycrash a device by triggering hard faults. This happensdue to some incorrect code behaviour or memory cor-ruption, e.g., when a buffer overflow on BLE receptionbuffer occurs. When a device crash occurs, they usuallyrestart. However, such a restart capability depends onwhether a correct hard fault handling mechanism wasimplemented in the product that uses the vulnerable BLESoC.

• Deadlock: Deadlocks are vulnerabilities that affect theavailability of the BLE connection without causing ahard fault or memory corruption. Usually they occur dueto some improper synchronisation between user codeand the SDK firmware distributed by the SoC vendor,leaving the user code being stuck at some point. Crashesoriginated from hard faults, if not properly handled, can

1

become a deadlock if the device is not automaticallyrestarted. In most cases, when a deadlock occurs, theuser is required to manually power off and power on thedevice to re-establish proper BLE communication.

• Security Bypass: This vulnerability is the most criticalone. This is because the vulnerability allows attackersin radio range to bypass the latest secure pairing modeof BLE, i.e., the Secure Connections pairing mode [13].In summary, after the bypass is completed, an attackerin the radio range has arbitrary read or write access todevice’s functions. These functions, in turn, are onlymeant to be accessed by authorised users.

The summary of our findings and the affected vendors isdepicted in Table 1.

Table 1: Vulnerabilities type and affected vendors

Type Vulnerability Name Affected Vendors CVE

Crash

Link Layer Length OverflowCypress CVE-2019-16336 (6.1)NXP CVE-2019-17519 (6.1)

Truncated L2CAP Dialog Semiconductors CVE-2019-17517 (6.3)

Silent Length Overflow Dialog Semiconductors CVE-2019-17518 (6.4)

Public Key Crash Texas Instruments CVE-2019-17520 (6.6)

Invalid L2CAP Fragment Microchip CVE-2019-19195 (6.8)

Key Size Overflow Telink Semiconductor CVE-2019-19196 (6.9)

DeadlockLLID Deadlock

Cypress CVE-2019-17061 (6.2)NXP CVE-2019-17060 (6.2)

Sequential ATT Deadlock STMicroelectronics CVE-2019-19192 (6.7)

Invalid Connection Request Texas Instruments CVE-2019-19193 (6.5)

Security Bypass Zero LTK Installation Telink Semiconductor CVE-2019-19194 (6.10)

2 Vulnerable BLE chips

Table 2 lists the affected SoCs and the respective SDK ver-sions where the vulnerabilities were found. The qualificationID of each SoC, attributed to vendors after their SDK is certi-fied, allows to search for products using the SoC connectedto such ID on the Bluetooth Listing Search site [15]. A basicsearch on this site yields about 480 products listings usingthe affected SoCs from Table 2. Each listing may containmultiple products from the same vendor, which further in-creases the total number of different products affected. Thisdoes not mean, however, that all products are guaranteed tobe affected. This is because the impact of SWEYNTOOTHvulnerabilities depends on how the product software handlesBLE communication and how much it relies on affected SoCsto operate.

2.1 Attacks on IoTThe exploitation of the vulnerabilities translates to dangerousattack vectors against many IoT products released in 2018-2019. At first glance, most of the vulnerabilities affect prod-uct’s availability by allowing them to be remotely restarted,deadlocked or having their security bypassed. In order to raiseawareness of the threats and risks of potentially vulnerableproducts already on the market, we have performed attackson five representative IoT products which use the affected

Table 2: Vulnerabilities and SDK versions of the affectedSoCs.* indicates extra affected SoCs reported by the vendornot tracked by our team.

Vuln. SoC Vendor SoC Model SDK Ver. Qualification ID(s)BLE Version 5.0/5.1

6.1,6.2 Cypress (PSoC 6) CYBLE-416045 2.10 991586.5,6.6 Texas Instruments CC2640R2 3.30.00.20 94079

6.9,6.10 Telink TLSR8258 3.4.0 92269, 1360376.7 STMicroelectronics WB55 1.3.0 1116686.7 STMicroelectroncis BlueNRG-2 3.1.0 87428, 106700, 940756.4 Dialog DA1469X* 10.0.6 1008996.3 Dialog DA14585/6* 6.0.12.1020 91436

BLE Version 4.26.1,6.2 Cypress (PSoC 4) CYBL11573 3.60 62243, 136808, 79697, 82951, 794806.1,6.2 NXP KW41Z 2.2.1 84040

6.4 Dialog DA14680 1.0.14.X 87407, 84084, 71309, 75255BLE Version 4.1

6.5 Texas Instruments CC2540 1.5.0 23454, 1274186.3 Dialog DA14580 5.0.4 835736.8 Microchip ATSAMB11 6.2 73346

Table 3: Products verified to be vulnerableProduct Category BLE SoC Vulnerability Impact

Eve Energy Smart Home DA14680 (6.4) Silent Length Overflow CrashAugust Smart Lock Smart Home DA14680 (6.4) Silent Length Overflow Crash

Fitbit Inspire Wearables CY8C68237 (6.1) LL Length Overflow Crash(6.2) LLID Deadlock Crash

CubiTag Gadget Tracking CC2640R2 (6.6) Public Key Crash DeadlockeGeeTouch TSA Lock Security CC2540 (6.5) Invalid Connection Request Deadlock

SoCs (cf. Table 2) as their main processor. These productsare shown in Figure 2.

Figure 2: An illustration of some vulnerable products.

• Wearables: Fitbit Inspire - Latest 2018 smartwatchesline-up from FitBit uses the Cypress PSoC 6 as the mainprocessor. Hence they are vulnerable to Link Layer Over-flow and LLID Deadlock. To verify what happens tothe wearable when both issues are exploited, we havesent malicious packets to the Fitbit Inspire smartwatch(Figure 2a) through the BLE communication channel.

Once the malicious packets are sent to the device, it ispossible to trigger either a buffer overflow in device’smemory or deadlock its bluetooth stack temporarily. Theformer attack (exploiting Link Layer Overflow) imme-diately restarts the device whereas the latter (exploiting

2

LLID Deadlock) disables its bluetooth advertisement forabout 27 seconds before the smartwatch is automaticallyrestarted by the firmware.

In summary, the vulnerabilities only seem to temporarilyblock the availability of Fitbit. However, the Link LayerLength Overflow is a serious threat by itself. Specifically,such an overflow is a potential front door to remote ex-ecution once an attacker knows the memory layout ofthe firmware by means of reverse engineering it. Similarbehaviour is expected in Fitbit Charge 3 and Ace 2. Thisis because they embed Cypress PSoC 6 as their mainprocessor.

• Smart Home: Eve Systems - Many smart home prod-ucts from Eve Systems are vulnerable due to their re-liance on Dialog DA14680 as the main processor. Forinstance, Eve Light Switch, Eve Motion MKII, Eve Aqua,Eve Thermo MKII, Eve Room, Eve Lock, etc, are allprone to Silent Length Overflow. Specifically, it is pos-sible to crash such devices by sending a specific packetwhich overflows device’s reception buffer. When an at-tack occurs, the user can immediately experience hersmart products restarting or getting unstable. As an exam-ple, when performing the Silent Length Overflow againstthe Eve Energy (Figure 2b), the power on the smartplug is cut off when its processor crashes and restarts.As a consequence, we can momentarily cut the powerto anything connected in the socket by just sending amalicious packet within radio range of the smart socket.Furthermore, an attacker can use this simple attack tocause real damage to some equipment connected to theplug by intermittently cutting its power.

August Smart Lock - We have verified that the SilentLength Overflow also affects the popular August SmartLock (Figure 2c). Such a smart lock remotely controlsaccess to house doors. Hence, it is advisable that usersupdate their affected devices as soon as possible. This isto avoid a worst-case exploit, which could grant accesscontrol to a thief by means of remote execution.

• Tracking Gadget: CubiTag - The CubiTag Bluetoothtracker is a popular product that tracks the belongingsof a user (Figure 2d). When the tracker is near an ob-ject of interest, it can be found by using a mobile app,which searches for the tracker and starts an alarm onthe tracker. As a result, the user can hear the alarm andfind the object. However, CubiTag relies on a vulnerableTI CC2640R2 SDK. Out of two vulnerabilities on thisSDK, only the Public Key Crash affects availability ofCubiTag. The CubiTag immediately stops advertising it-self and is never found by the mobile app again; hence itis deadlocked. The CubiTag device only works again bymanually opening it with a screwdriver and re-insertingits battery. This is for the tracker SoC to reboot properly

and to establish normal BLE connection.

• Smart Locks: eGee Touch - The eGee Touch, shown inFigure 2e, is a smart luggage lock that can be remotelylocked or unlocked through a smartphone app. Duringour tests, as the device uses the TI CC2540 SoC, wecould lead the smart lock in a deadlock state by exploit-ing the Invalid Connection Request vulnerability. Whenan attack is carried out, the device hangs and the userneeds to manually press the power on button on the smartlock to re-interact with it. This is not a critical problemby itself. However, the worst-case scenario occurs whenthe user enables continuous advertisement on the smartlock. This prevents the device to automatically restartafter the attack, hence its batteries must be re-inserted toreboot its processor and restore functionalities back tonormal.

2.2 Other potentially vulnerable products

As mentioned in Section 2, the vulnerabilities discovered byour team are likely to affect a substantial number of productsthat rely on the affected SoCs. While it is difficult to con-firm the reach of such vulnerabilities for every product outin the wild, we provide an overview of the types of productspotentially affected by SWEYNTOOTH using the BluetoothListing Search site [15]. Figure 3 captures the total number ofproducts listings using the affected SoCs as of 8th February,2020.

1111

1048

531

2043

4307

0 50 100 150 200 250 300

PSoC 4/6KW41Z

BlueNRG-2ATSAMB11

TLSR8258DA1469XDA14680

DA14585/6DA14580

CC2640R2CC2540

Listing(s) count

Figure 3: Number of product listings for each SoC affectedas of February 8, 2020.

While the majority of products are listed under CC2540,we note several critical BLE products using the other affectedSoC vendors. These products are applied to logistics, med-ical, consumer electronics, smart home, wearables andother fields. Although it is impractical for our team to verifysuch a large number of products using the affected SoCs, weoutline some of the most notorious or popular products foundon Bluetooth Listing website [15]. These critical products areshown in Table 4.

3

Table 4: Some notorious products using SoCs affected by SWEYNTOOTH. The declaration ID references each product on theBluetooth Listing Search [15]. *Syqe Medical Ltd. has clarified that they did buy a BLE license for their product Syqe Inhalerv01, but they are not using the BLE technology.

The most critical devices that could be severely impactedby SWEYNTOOTH are the medical products. VivaCheck Labo-ratories, which manufacture Blood Glucose Meters, has manyproducts listed to use DA14580. Hence all these products arepotentially vulnerable to the Truncated L2CAP attack. Evenworse, the latest pacemaker related products from MedtronicInc. are potentially affected. While our team did not verify theextent to which SWEYNTOOTH affects such devices (e.g. theimpact of remotely restarting such devices or remote code ex-ecution in the worst case), it is highly recommended that suchcompanies update their firmware. This is to avoid any situa-tion that could pose life threatening risks to the patients usingthe respective medical products. Unfortunately, the securityissue found in Dialog DA14580 is still unpatched (cf. Table 5).Nonetheless, Dialog is working on an internal security patchfor DA14580 and will release it for general public in the nextSDK release. More details about patches are mentioned inSection 3.

Another complication arises for the IN180-13 from Swip-box International. This product uses the vulnerable KW41ZSoC from the vendor NXP semiconductor. According to thecompany page [16], the battery operated product is an au-tomatic parcel locker and has no display. Instead, it reliesentirely on a smartphone application communicating via BLEto unlock the parcel sent to the recipient. Similarly to what

happens to CubiTag, the KW41Z is vulnerable to a deadlock(LLID Deadlock). The KW41Z LLID deadlock vulnerabil-ity is particularly easy to trigger and allows an attacker inradio range to simply block anyone to connect to the parcellocker (unless the the parcel locker is automatically restarted).Fortunately, NXP has already released patches for the twovulnerabilities affecting KW41Z. Other potentially vulnerablepopular products include vendors such as August Home, EveSystems, Samsung and Anhui Huami Information Technol-ogy, among others.

It is worthwhile to note that the list in Table 4 is not exhaus-tive. Thus, we recommend each product vendor to update theSDK firmware of their products to the latest if available orcontact their SoC vendor to enquire on the status of the patch.

3 Security Patches

Update 17/03/2020: Table 5 has been updated. DialogSemiconductors has released hotfixes for DA14680/1/2/3and DA14585/6 SoCs. Patches for DA14580/1/3 areplanned for the end of March. You can read moreinformation in their advisory page [10]. Furthermore,Microchip has kindly self disclosed more devices to beaffected by multiple SweynTooth vulnerabilities [17].

4

Most of the affected vendors have released patches for theirrespective SoCs. One can get the latest patches by download-ing the newest SDK of each vendor referenced in Table 5.Product vendors (who use the affected SoCs), on the otherhand, are being independently contacted by each SoC vendorto inform about the security patches. However, we note thatsome SoCs did not receive a patch from their vendor yet. Thisis the case for Dialog, Microchip and STMicroelectroncs. Wewill be updating this section once vendors release the securitypatches for the affected SoCs.

We urge action from vendors due to the reliance of the BLEIoT market on such unpatched SoCs. For example, AugustHome Inc and Eve Systems products rely almost entirely onDA14680, which is still unpatched even after a responsivedisclosure period of more than 90 days.

During our contact with Dialog, they have confirmed thata patch is planned in the next SDK release for the affectedSoCs. We were also informed that the reason of such delay isdue to the affected code being stored in the read-only-memory(ROM) of such SoCs. Thus, the respective vulnerable BLEstack cannot be modified and it requires complex workaroundsfor publicly releasing a patch.

Table 5: Patches available by the SoC vendors (17/03/2020).SoC Vendor SoC Model Vendor Patches

Cypress (PSoC 6) CYBLE-416045 [4] BLE_PDL 2.2Cypress (PSoC 4) CYBL11573 [3] BLE Component 3.63NXP KW41Z/31Z [8] 2.2.1 (2019-11-28)NXP KW37/8/9 [9] 2.6.2 (2019-12-20)NXP KW34/5/6 [9] 2.2.2 (2019-12-06)Texas Instruments CC2640R2 [7] v3.40.00.10Texas Instruments CC2640/50 [7] Pending (Early April)Texas Instruments CC13X2/26X2 [7] v3.40.00.02Texas Instruments CC13x0 [7] Pending (Early April)Texas Instruments CC2540/1 [6] v1.5.1Telink TLSR8258 [18] v3.4.0 (SMP fix)Telink TLSR8232 [20] v1.3.0 (SMP fix)Telink TLSR826x [19] v3.3 (SMP fix)Dialog DA1469X [10] 10.0.6Dialog DA14585/6 [10] Hotfix availableDialog DA14680/1/2/3 [10] Hotfix availableDialog DA14580/1/3 [10] Pending (March 20, 2020)Microchip ATSAMB11 [17] PendingMicrochip WINC3400 [17] PendingMicrochip IS1870/1 [17] PendingMicrochip BM70/1 [17] PendingMicrochip RN4870/1 [17] PendingMicrochip BTLC1000 [17] PendingMicrochip IS1677/8 [17] PendingMicrochip BM77/8 [17] PendingMicrochip RN4677/8 [17] PendingMicrochip IS2062/3/4/6 [17] PendingMicrochip BM62/3/4 [17] PendingMicrochip IS2083 [17] PendingMicrochip BM83 [17] PendingSTMicroelectronics WB55 PendingSTMicroelectroncis BlueNRG-2 Pending

4 Non-compliance in the wild!

In recent years, Bluetooth design has been under scrutiny dueto several security flaws such as KNOB [1], BlueBorne [11]and Invalid ECC Attack [2]. In contrast, little to no researchhas been carried out on the security of the diverse Bluetoothimplementations out in the wild. The current practice is toleave the implementation tests to the Bluetooth certificationprocess. This is with the mindset that once the design issound, hardly anything can break in the implementation ofthe Bluetooth stack.

Our findings expose some fundamental attack vectorsagainst certified and recertified BLE Stacks which are sup-posed to be “safe" against such flaws. We carefully investi-gated the reasons that might explain the presence of SWEYN-TOOTH vulnerabilities on the affected SoCs. We believe this isdue to the imposed isolation between the link layer and otherBluetooth protocols, via the Host Controller Interface (HCI)protocol [13]. While such a strategy is reasonable for hard-ware compatibility, this adds complexity to the implementa-tion. Moreover, it overly complicates the strategies to system-atically and comprehensively test Bluetooth protocols. Specif-ically, during testing, it is complex to send arbitrary LinkLayer messages during other protocol message exchanges.Such added complexity is likely the reason for inadequatesecurity testing of BLE stack implementation.

We carefully read and investigated relevant parts of theController and Host volume of the Core Specification, whichallow us to understand the main interaction of two devices(c.f., Figure 1). A natural question that arises for anyone look-ing a sequence diagram of the overall pairing procedure is“what happens if the LL encryption starts in the middle ofthe pairing procedure?". It can be argued that the Zero LTKinstallation, Key size overflow and Public Key Crash flawswere facilitated due to this question not being answered onthe Core Specification itself, leaving it for vendors to decidehow to handle such situation. When attempting to answerthis question, we have received highly different behavioursacross most SoCs we have tested. In addition, several otherimplementation details, which are explicitly imposed by theCore Specification [14], are also not followed by SoC vendorsin reality.

It is worthwhile to mention that every SoC BLE SDK goesthrough the certification process before going into market.Thus, our findings expose that improvements should be madeon the certification process to avoid at least simple devia-tions such as the LLID deadlock: It takes exactly one fieldto be zero to lead the device into a deadlock. Furthermore,devices from Telink responds to version requests multipletimes, going against [Vol 6] Part B, Section 5.1.5 of CoreSpecification [14], which defines that the peripheral shouldonly respond a version request a single time during the samecentral-peripheral connection. Similarly, all devices we havetested accept a connection request with the“hopIncrement"

5

field value of less than five. This behaviour goes against [Vol6] Part B, Section 2.3.3.1, which dictates the valid range ofsuch field to be within 5-16. Moreover, all the vulnerabili-ties we have discovered go against [Vol 1] Part E, Section2.7 (Responding to malformed behaviour). This part of thespecification provides directives and few examples to handleinvalid or malformed packets.

In conclusion, we strongly believe that the Bluetooth SIGshould improve and significantly expand Section 2.7 (thesection is less than one page!!!) and add more basic tests tothe Bluetooth certification to avoid zero-day vulnerabilitiessuch as the ones captured by SWEYNTOOTH.

5 Why SWEYNTOOTH?

The insight behind the name SweynTooth arrives from SweynForkbeard, the son of King Harald Bluetooth (after whom theBluetooth Technology was originally named). Sweyn revoltedagainst Harald Bluetooth and this forced King Harald to hisexile. The exile lead to the death of King Harald shortly.We envision that if SweynTooth style vulnerabilities are notappropriately handled by BLE vendors, then the technologycan become a breeding ground for attackers. This may, in turn,lead the Bluetooth technology to be obsolete.

The SweynTooth logo is designed based on the combina-tion of letter "S" (abbreviating Sweyn) and letter "T" (abbre-viating Tooth) from the Elder Futhark alphabet – one of theoldest Runic alphabets.

6 Detailed Description

In this section, we provide a detailed description of eachvulnerability, the affected system-on-chip (SoC) models andthe SDKs.

6.1 Link Layer Length Overflow(CVE-2019-16336, CVE-2019-17519)

The Link Layer Length Overflow vulnerability was identifiedin Cypress PSoC4/6 BLE Component 3.41/2.60 (CVE-2019-16336) and NXP KW41Z 3.40 SDK (CVE-2019-17519). Bothimplementations are susceptible to the same vulnerability.Such a vulnerability allows attackers in radio range to triggera buffer overflow by manipulating the LL Length Field. Theoverflow occurs when the attacker, acting as the central device,sends a packet to the peripheral, which is padded to includemuch more bytes than expected from its type (opcode). Anexample is shown in Figure 4. In this case, a version requestis just five bytes of length, but can be falsely extended to247 bytes when LL Length field value is increased. When theunderlying BLE stack processed such a packet, more bytesthen the expected are allocated in memory, which causedinstabilities and ultimately crashing the peripheral.

Impact: This vulnerability initially causes denial of service(DoS). However, due to its characteristic, attackers could re-verse engineer products firmware to possibly leverage remoteexecution. A concrete evidence of this risk is exemplifiedby the BleedingBit vulnerability [5], which allowed remoteexecution on certain Texas Instruments devices by meansof manipulating the same LL length field, albeit in a moreconstrained context. Specifically, BleedingBit exploited thecentral implementation of the SoC during the advertisementphase.

2connection

(request)

Data channel connectionpadded version request

Peripheral/Slave Central/Master

Advertisements

Channels37

38

39

scan(response)

scan(request)

4

3

1

4 Bytes 1 Byte 247 0x03 3 BytesLL Control PDU

Data Channel Packet – Link Layer Length overflow

1 Byte 1 Byte 2 Bytes 242 Bytes1 Byte

Figure 4: Link Layer Length Overflow vulnerability

6.2 Link Layer LLID deadlock(CVE-2019-17061, CVE-2019-17060)

This critical, yet simple vulnerability can render Cypress(CVE-2019-17061) and NXP devices in a deadlock state(CVE-2019-17060). We have discovered that if a CypressPSoC4/6 or NXP KW41Z device receives a packet with theLLID field cleared, then both devices simply enter in a faultystate. Specifically, this state prevents the BLE stack fromworking correctly in posterior connections. The details ofthe vulnerability are shown in Figure 5. It turns out that thisattack confuses the SDK implementation in a manner that anyreceived packet from the central is handled improperly or sim-ply ignored. For example, NXP KW41Z peripheral may sendresponses completely out of order to the central. In addition,no hard faults are triggered in the firmware of the device. This,in turn, prevents auto recovery by means of simply employingwatchdog timer on the product’s firmware.

Impact: The availability of BLE products is critically im-paired, requiring the user to manually perform a power cycleon the product to re-establish BLE communication. Furthercomplication arises, as the peripheral continues to advertiseitself after the attack. This makes it difficult for the user toeven notice the existence of the problem. The availability is-sue is only exposed when the user connects to the peripheral,revealing a never ending connection or pairing process.

6

2connection

(request)

Data channel connectionInvalid version request

Peripheral/Slave Central/Master

Advertisements

Channels37

38

39

scan(response)

scan(request)

4

3

1

4 Bytes 1 Byte 1 Byte 0x03 3 BytesUp to 247 Bytes

1 Bit0x00 (2 Bits) 1 Bit 1 Bit

Data Channel Packet – Deadlock attack

LL Header zoom

Figure 5: Link Layer LLID deadlock vulnerability

6.3 Truncated L2CAP(CVE-2019-17517)

The Truncated L2CAP vulnerability is present on DialogDA14580 devices running SDK 5.0.4 or earlier. The flaw re-sults due to a lack of checks during processing an L2CAPpacket. If the total length of the packet (i.e. LL Length) hasa value lower than L2CAP Length+ 4 for a valid payload,then the truncated bytes are copied beyond the underlyingreception buffer. Figure 6 shows an example of a maxi-mum transmission unit (MTU). The MTU captures a lengthrequest, which has LL Length of seven bytes and L2CAPLength of three bytes. If the peripheral receives a maliciousMTU length request with LL Length of five bytes instead,the L2CAP reception buffer is overflown by two bytes (i.e.L2CAP Length+4−LL Length). Therefore, the attacker canselectively choose the number of bytes to overflow by sendingthe correct L2CAP payload and the malformed LL Lengthcombination to the peripheral.

Impact: An attacker in radio range can use this attack toperform denial of service and crash the device. However, acareful sequence of packets could be sent by the attacker toforce the peripheral into writing certain contents to peripheralmemory adjacent to the L2CAP reception buffer. In the worst-case scenario, this attack could be a front door to performremote execution on products using Dialog DA14580 SoC.

6.4 Silent Length Overflow(CVE-2019-17518)

This attack is similar to Link Layer Length Overflow (cf. Sec-tion 6.1). In Dialog DA14680 devices, it was identified thatthe peripheral responded to packets from the central withunexpectedly large LL Length. While this behaviour is notcompliant to BLE Core specifications [13], it does not appearto affect the peripheral at first. Nonetheless, when a certain

Truncated MTU length request

Data channel connectionversion request / response

feature request / response

length request / response

5

Peripheral/Slave Central/Master

6

7

4

4 Bytes 1 Byte 0x05 0x03

Data Channel Packet – Truncated L2CAP Overflow

3 BytesL2CAP

0x0003 ATT (0x0004) 0x02 2 Bytes

L2CAP Header (4 Bytes) L2CAP payload (3 Bytes)

Limited to 5 bytes

.

.

.

Data Ch. Payload zoom

Figure 6: Truncated L2CAP vulnerability

packet payload with higher than expected LL Length is sent,the peripheral crashes. This indicates that an overflow on thereception buffer had occurred for certain packet types such aspairing request.

Impact: An attacker in radio range can mostly use this attackto perform denial of service and crash the device. Given thata buffer overflow is being triggered depending on the packet,a remote execution scenario is a possibility. Furthermore,the SoCs affected by this vulnerability are known to be usedin a large number of smart home products, which increasesthe reachability and risk of a more serious exploit of thisvulnerability.

6.5 Invalid Connection Request(CVE-2019-19193)

We identified that sample applications provided in Texas In-struments CC2640R2 BLE-STACK SDK (v3.30.00.20 andprior) and CC2540 SDK (v1.5.0 and prior) do not properlyhandle some connection parameters when the central attemptsa connection to the peripheral. Instead, the peripheral createsa connection with the central, but fails at a later stage andmoves the peripheral state to idle (i.e., stops advertisement).If the idle state is not handled correctly in the product’s code,the device does not go back to the advertisement stage again.

During the initial phase of a BLE connection, the centraldevice scans for advertisements packets from the peripheraland sends a connection request packet, which contains rel-evant parameters such as connection interval and timeout.These two parameters control the cadence of packet exchangeand timeout between peripheral and the central device, respec-tively. Their values must represent a non-zero time period inmilliseconds when multiplied by a factor of 1.25. However,

7

if the central device sends an invalid connection request withthe fields interval or timeout as zero, then the peripheral stopsadvertisement. During reception of an invalid connection re-quest, the BLE stack sends a connection request fail event tothe application code (bleGAPConnNotAcceptable) and uponreceiving this fail status, the sample application enters in idlestate by default, thus stopping advertisements. This behaviouris not the flaw alone, as idle state is a common state in BLEand should be handled by the application, due to other statetransitions that can occur during application operation.

Nevertheless, we have discovered that this state changeunder reception of invalid parameters is not sufficiently doc-umented in TI SDK, which may lead product developers tonot handle idle state. The mishandling of this state can leadproducts such as eGeeLock to stop advertisement and hencerequiring user intervention. An illustration of this attack isgiven in Figure 7.

Interestingly, CC2540 also accepts connection requestswith packet length lower than expected (truncated), whichtriggers the same behaviour (i.e., Figure 7) due to its imple-mentation assuming zero bytes for truncated fields.

Impact: An attacker in radio range can exploit the phe-nomenon observed in Figure 7 to easily perform DoS inproducts using the vulnerable SoCs. Furthermore, if the prod-uct vendor does not implement mechanisms to detect sucha faulty behaviour, the device can be driven into a deadlockstate. This, in turn, requires the user to manually restart thedevice. In general, the impact on such affected products issimilar to the LLID Deadlock (cf. Section 6.2).

2

Invalid connection request

Peripheral/Slave Central/Master

Advertisements

Channels37

38

39

scan(response)

scan(request)

3

1

4 Bytes 1 Byte 1 Byte 0x03 3 BytesUp to 37 Bytes

6 Bytes

Data Channel Packet – Connection request DoS attack

6 Bytes ............. .......Interval=0x00 ... Timeout=0x00

Connection request PDU zoom

Figure 7: Invalid Connection Deadlock

6.6 Unexpected Public Key Crash(CVE-2019-17520)

This vulnerability was found on Texas Instruments CC2640R2BLE-STACK-SDK (v3.30.00.20 and prior versions). Specif-ically, the vulnerability is present in the implementation ofthe legacy pairing procedure which is handled by the Secure

Manager Protocol (SMP) implementation. When the periph-eral performs the legacy pairing procedure, it is possible tocause a hard fault in device’s memory by sending an SMPpublic key packet before the SMP pairing procedure starts(Step 9 in Figure 1). Normally, the peripheral should ignorethe reception of a public key if secure connection is not en-abled in the pairing request/response exchange. During ourcoordination with the vendor, Texas Instruments informed usthat the hard fault is triggered because the peripheral acceptsthe public key and tries to copy it to a null target address.Normally, this address corresponds to a valid allocated bufferif secure connection is properly indicated during the pairingrequest/response process. We illustrate the vulnerability inFigure 8 (SC means secure connection).

Impact: An attacker in radio range can exploit the aforemen-tioned behaviour to perform DoS and possibly restart productsusing the CC2640R2 SoC for the main application. On thebright side, it is not possible to perform a buffer overflowin the peripheral’s memory. This is because the unexpectedpublic key is always copied to a null address, which is beyondthe control of the attacker. It is worthwhile to mention thatthis vulnerability can also lead to a deadlock. This is exem-plified by our evaluation on the CubiTag bluetooth tracker.The product CubiTag does not properly handle hard faultsand hence enters a deadlock state. This requires the user ofthe tracker to manually restart it.

Peripheral/Slave Central/Master...

Paring Procedurepairing request, no SC

9SMP Legacy PairingPublic Key

Central forces SecureConnections pairing

Peripheral accepts public keyand triggers a hard fault

8pairing response, no SC

Figure 8: Unexpected Public Key Crash

6.7 Sequential ATT Deadlock(CVE-2019-19192)

In STMicroelectronics WB55 SDK V1.3.0 and earlier, it ispossible to deadlock the peripheral by sending just two con-secutive ATT request packets in each connection event. Nor-mally, each ATT request sent from a central device is followedby an ATT response from the peripheral. This happens in atime period multiple of the connection interval ∆t. However,it is possible that a rogue central device sends multiple and

8

consecutive ATT requests separated by the connection inter-val ∆t (Figure 9). In such a case, the peripheral does not getsufficient time to respond to the first ATT request. The re-sulting behaviour is a fault in the coprocessor that runs theBLE SDK inside WB55, preventing certain BLE event flagsto be cleared. This leads to a deadlock of the WB55 user code.Specifically, the faulty code potentially gets stuck in a whileloop, which waits for a never finishing BLE event.

Impact: Similar to several other vulnerabilities discussed inthis work, the exploitation of this vulnerability can leave theproduct in a deadlock state if a stability mechanism, suchas the watchdog timer, is not employed by the vendor inproduct’s firmware. If such a mechanism is present, the attackis still guaranteed to remotely restart the device.

ATT request

Peripheral/Slave Central/Master...

Repeated ATT requests

Link Layer encrypted

While(!ble_event){

…

}

Keys exchange procedure 11

12

Peripheral routine

𝚫𝐭

𝚫𝐭 = 𝐜𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐨𝐧_𝐢𝐧𝐭𝐞𝐫𝐯𝐚𝐥

Sequential ATT fault

Figure 9: Sequential ATT Deadlock

6.8 Invalid L2CAP fragment(CVE-2019-19195)

During the communication between the central device and pe-ripheral, the Bluetooth 4.0-4.1 Core specification dictates thatthe minimum and maximum link layer PDU size of L2CAPpackets should be in the range 4-31 [12], considering that theL2CAP header is four bytes. Packets outside this boundaryshould be discarded as they are invalid. However, we discov-ered that such is not the case for devices running MicrochipATMSAMB11 BluSDK Smart v6.2 and earlier. Following Fig-ure 10, it was discovered that if an link layer PDU of lengthone is sent to the peripheral, then the device crashes due tothe L2CAP header being truncated to just one byte. It alsohappens that this byte corresponds to the L2CAP length field.Thus, sending a higher value for this byte may lead to a bufferoverflow and subsequently, crash the device.

Impact: The watchdog mechanism is enabled by default inthe SDK, which reduces the risk for products relying on AT-SAMB11 BLE solution to exhibit deadlock behaviour. There-fore, this vulnerability mostly affects the availability of thedevice by remotely restarting them.

Invalid L2CAP fragment

Data channel connectionversion request / response

feature request / response

length request / response

5

Peripheral/Slave Central/Master

6

7

4

4 Bytes 1 Byte 0x01 0x03 3 BytesL2CAP

.

.

.

Figure 10: Invalid L2CAP fragment

6.9 Key Size Overflow(CVE-2019-19196)

The Key Size Overflow vulnerability was found in all TelinkSemiconductor BLE SDKs. This causes an overflow in thedevice memory, resulting in a crash. However, the problemthat allows this vulnerability is a combination of multipleissue found during the pairing procedure of devices usingTelink SMP implementation.

During the start of the pairing procedure, the central de-vice sends a Pairing request packet containing the maximumallowed key size to be negotiated at the end of the pairing pro-cedure. The maximum key size is standardised to be within7 to 16 bytes and any deviation from that should be rejectedwith a pairing failure response. However, Telink peripheralactually accepts a maximum encryption key size up to 255 byanswering the central device with a paring response instead.Despite this first problem, the peripheral rejects the pairingduring at later exchanges of the pairing procedure without ab-normal behaviour. The second and final problem that finallytriggers the vulnerability, arises because the peripheral ac-cepts the LL Encryption procedure to occur before the pairingprocedure even starts, albeit failing at later stage.

By combining the two mentioned problems it is possible toforce the peripheral into allocating the over sized key bufferlength which was negotiated during the pairing request. De-picted in Figure 11, the central device sends the invalid pairingrequest, waits for pairing response and sends an encryptionrequest. The request is accepted and a buffer overflow occursin peripheral’s memory as its firmware tries to allocate theoversized key.

Impact: This vulnerability allows an attacker in radio to per-form buffer overflow and crash Telink SoCs products withpairing support enabled, which is a common practice in sev-eral BLE products. While this vulnerability doesn’t exposeeasy control over the overflown buffer, an exploit could becarefully constructed to overwrite memory contents adjacentto the key buffer if the the memory layout of the product’sfirmware is known. In the worst case, it could be possible to

9

overwrite buffers that store encryption nonce would allow theattacker to bypass encryption and leak user information.

Peripheral/Slave Central/Master...

Paring Procedurepairing request

8

pairing response

10

LL Encryption procedureencryption request

4 Bytes 1 Byte 1 Byte 0x03 3 BytesL2CAP

4 Bytes 0x01 1 Byte 1 Byte 1 Byte 253 (0xFD)

SMP Pairing request zoom

Central skips pairingand starts encryption

Peripheral accepts out of order encryption

request and crashes

2 Bytes

Peripheral acceptsKey size of 253

Figure 11: Key Size Overflow

6.10 Zero LTK Installation(CVE-2019-19194)

This critical vulnerability is a variation of one of the KeySize Overflow. It affects all products using Telink SMP imple-mentation with support for secure connection enabled. It wasverified that when the Telink peripheral accepts an out of orderencryption request from the central, the encryption procedureis successful with a LTK which is zero. The LTK size, usuallyof 16 bytes, is agreed during the pairing request/responseexchange.

Following Figure 10, the rogue central sends a pairing re-quest with secure connections pairing indicated and waits fora pairing response. Next, the central skips the secure connec-tions pairing procedure and starts the encryption procedure bysending a encryption request. Due to the lack of validation inperipheral’s implementation, the central receives a encryptionstart from the peripheral and sends an encrypted encryptionresponse back. This response is relevant because the periph-eral validates it against the session key SK, which is derivedfrom a valid LTK. Interestingly, the peripheral’s LTK is initial-ized as zero. This allows the central to easily derive the SK tosend the correct encrypted encryption response to the periph-eral, hence successfully completing the encryption procedure.The SK (hiddenly mentioned in Bluetooth Core Specificationas sessionKey [13]) is generated by the cryptographic functionof Equation 1.

SK = AESECB(Key = LTK,Plaintext = SKD) (1)

The Session Key Diversifier (SKD) is a random 16 byte

Peripheral/Slave Central/Master...

Paring Procedurepairing request, SC supported

encryption response

10LL Encryption procedureencryption request

Central skips pairingand starts encryption

Client accepts encryption request and installs zero LTK

encryption start

8pairing response, SC supported

Link Layer encrypted (zero LTK)

[encrypted] encryption response

[encrypted] encryption response

Central sends encrypted response with LTK=0

12ATT request / response(GATT services discovery)

Keys distribution procedureis completely bypassed

Figure 12: Zero LTK Installation

number obtained via the encryption request/response ex-change, therefore, guessing the correct LTK allows the centraldevice to send a encrypted encryption response with a validSK. As an aggravating factor, the Keys distribution procedureis completely bypassed after the attack is performed.Impact: An attacker in Radio range can abuse this vulnera-bility to completely bypass security in a BLE products whichrely in secure connections pairing to protect user privacy. Fur-thermore, device’s functionalities which were only allowed tobe accessed by an authorized user, can be trivially bypassed.In short, this vulnerability allows an attacker full communica-tion control over a protected BLE application.

As a side note, this vulnerability only affects Telink devicesthat allows secure connection pairing. In reality, affected prod-ucts that disable secure connections pairing (the currently se-cure BLE pairing mode) and enable only the insecure legacypairing mode, are in fact more secure due to this vulnerability.

Contact

Feel free to reach us by email: sweyntooth@gmail.com

Acknowledgements

This research was partially supported by Keysight Technolo-gies. We also want to thank all the involved vendors for theirsupport during the coordination process and Ezekiel O. Sore-mekun for coining the term SWEYNTOOTH.

10

References

[1] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper B.Rasmussen. The KNOB is broken: Exploiting lowentropy in the encryption key negotiation of BluetoothBR/EDR. In 28th USENIX Security Symposium(USENIX Security 19), pages 1047–1061, Santa Clara,CA, August 2019. USENIX Association.

[2] Eli Biham and Lior Neumann. Breaking the bluetoothpairing–the fixed coordinate invalid curve attack. InInternational Conference on Selected Areas inCryptography, pages 250–273. Springer, 2019.

[3] Cypress. Component Datasheet - Bluetooth LowEnergy (BLE), February 2020. https://www.cypress.com/documentation/component-datasheets/psoc-creator-component-datasheet-bluetooth-low-energy-ble.

[4] Cypress. Component Datasheet - Bluetooth LowEnergy (BLE_PDL), February 2020.https://www.cypress.com/documentation/component-datasheets/bluetooth-low-energy-blepdl.

[5] Armis Inc. Bleedingbit vulnerability.https://armis.com/bleedingbit/, 2018.

[6] Texas Instruments. Invalid connection request advisory,February 2020. http://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/881881.

[7] Texas Instruments. Public Key Crash advisory,February 2020. https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/881879.

[8] NXP. MCUXpresso Software Development Kit (SDK),January 2020. https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuxpresso-software-development-kit-sdk:MCUXpresso-SDK?tab=Design_Tools_Tab.

[9] NXP. SweynTooth Advisory, March 2020.https://community.nxp.com/community/

wireless-connectivity/security-updates/blog/2020/03/03/bluetooth-low-energy-vulnerabilities-sweyntooth.

[10] Dialog Semiconductor. SweynTooth Advisory,February 2020. https://www.dialog-semiconductor.com/sweyntooth-bluetooth-low-energy-vulnerability.

[11] Ben Seri and Gregory Vishnepolsky. Blueborne. Armis.https://www.armis.com/blueborne/, 2017.

[12] Bluetooth SIG. Bluetooth Core Specification v4.2,December 2014. https://www.bluetooth.com/specifications/bluetooth-core-specification.

[13] Bluetooth SIG. Bluetooth Core Specification v5.0,December 2016. https://www.bluetooth.com/specifications/bluetooth-core-specification.

[14] Bluetooth SIG. Bluetooth Core Specification v5.1,January 2019. https://www.bluetooth.com/specifications/bluetooth-core-specification.

[15] Bluetooth SIG. View previously qualified designs anddeclared products, January 2020.https://launchstudio.bluetooth.com/Listings/Search.

[16] Swipbox. Swipbox Infinity Product page, January 2019.https://www.swipbox.com/products_infinity.html.

[17] Microchip Technology. SweynTooth Advisory, March2020. https://www.microchip.com/design-centers/wireless-connectivity/bluetooth/sweyntooth-ble-vulnerability.

[18] Telink. Telink wiki - Kite BLE SDK V3.4.0, February2020. http://wiki.telink-semi.cn/tools_and_sdk/BLE_SDK/8x5x_SDK/ble_sdk.zip.

[19] Telink. Telink wiki 826x Ble SDK v3.3, February 2020.http://wiki.telink-semi.cn/tools_and_sdk/BLE_SDK/826x_SDK/ble_sdk.rar.

[20] Telink. Telink wiki TLSR8232 SDK V1.3.0, February2020. http://wiki.telink-semi.cn/tools_and_sdk/BLE_

SDK/823x_SDK/ble_sdk.zip.

11