Uncover SweynTooth vulnerabilities with Defensics fuzz testing

SweynTooth is a set of Bluetooth Low Energy vulnerabilities. We can reproduce many of these vulnerabilities using Defensics Bluetooth LE Test Suites.

Uncover SweynTooth Bluetooth vulnerabilities with Defensics fuzz testing

What is SweynTooth?

SweynTooth is a set of Bluetooth Low Energy vulnerabilities discovered and disclosed by Singapore University of Technology and Design researchers. These vulnerabilities were found in various Bluetooth LE software development kits from seven system-on-chip vendors. According to the researchers, the vulnerable SDKs have been used in over 480 end products. Because of the large number of SweynTooth vulnerabilities discovered and their risks and impacts on medical devices, the U.S. FDA has published a Safety Communication and is actively keeping tabs on potential SweynTooth attacks. Most affected vendors have already released security patches for their SDKs. It is strongly recommended that you update to the latest SDK version if your product is affected.

Introduction to Defensics and fuzzing

Defensics is an intelligent fuzz testing platform with over 250 prebuilt generational test suites. Its automated test methodology can be used to uncover new, unknown vulnerabilities by systematically sending invalid or unexpected inputs to the system under test. The Defensics engine comes with built-in knowledge on the input type, whether it’s an interface, protocol, or file format. Because the engine has a deep understanding of the rules that govern communication within the input type, it can deliver targeted test cases to exploit that input type’s potential security weaknesses. Defensics’ detailed testing and reporting capabilities allow it to identify the root cause of critical failures in a consistent manner that is easy to understand and can be shared with the stakeholders involved in the remediation process.

How to reproduce vulnerabilities with Defensics

Defensics Bluetooth LE Test Suites cover the host stack, such as ATT, SMP, and GATT profiles. During our initial analysis, we were able to reproduce several SweynTooth vulnerabilities using these test suites. Note that we did not verify test cases against the actual vulnerable devices. Below are a few types of SweynTooth vulnerabilities we detected through Defensics fuzzing.

Types of SweynTooth vulnerabilities detected with Defensics

Unexpected Public Key Denial of Service (CVE-2019-17520)

We detected this SweynTooth vulnerability in a legacy SMP implementation, where the stack was not expecting to receive a public key at all, using the Bluetooth LE SMP Client and Server Test Suites. Here is a specific test case where the Secure Connection Flag is set to 0 but Public Key is still sent.

Unexpected Public Key Crash (CVE-2019-17520) Bluetooth vulnerability

Sequential ATT Deadlock (CVE-2019-19192)

The device vulnerable to this SweynTooth attack was not able to handle a situation where the central device sent consecutive ATT request packets without waiting for an ATT response from the peripheral. We reproduced this vulnerability using the Defensics Bluetooth LE ATT Server and ATT Client Test Suites. Repeated messages are part of the default set of test cases. The screenshot below shows a test case where ATT Read Request is repeated seven times.

Sequential ATT Deadlock (CVE-2019-19192) SweynTooth vulnerability

Key Size Overflow (CVE-2019-19196)

We found that certain devices were vulnerable to this Key Size Overflow scenario because they did not validate the maximum encryption key size value they received in a pairing request.

Using the Defensics Bluetooth LE SMP Server Test Suite, we created test cases where we manipulated Maximum Encryption Key Size in a pairing request and then tried to start encryption regardless of the responses. The screenshot below shows a test case where Maximum Encryption Key Size is set to 252 bytes.

Key Size Overflow (CVE-2019-19196) Bluetooth vulnerability

Zero LTK Installation (CVE-2019-19194)

The Zero LTK Installation SweynTooth vulnerability means that in practice, an attacker can initiate a Secure Connections pairing procedure by sending a pairing request with the Secure Connection Flag set. The attacker waits for a pairing response to make sure the target is in a state where pairing has been initiated. Then the attacker requests to start encryption without first fully finishing the pairing and using an all-zeros long-term key (zero LTK).

You could achieve this kind of scenario with the Bluetooth LE SMP Server Test Suite, for example, by running a test case that omits the public key exchange and just tries to start encryption. Unfortunately, the Bluetooth LE SMP Server Test Suite does not actually check whether it could start encryption too early. So in theory, you should be able to trigger this vulnerability, but you may need to verify and validate the test results manually using Wireshark.

The screenshot below shows a test case where Public Key is omitted and the SMP Server Test Suite tries to start encryption too early using a zero LTK. Apparently, this device is not vulnerable, as it rejects the request with the error code “PIN or Key missing.”

Zero LTK Installation (CVE-2019-19194) SweynTooth vulnerability


According to our initial analysis, the Defensics Bluetooth LE Test Suites are extremely useful in helping uncover the above four types of SweynTooth vulnerabilities. We are continuously collaborating with IoT manufacturers to uncover new vulnerabilities with Defensics and get them fixed. We highly recommend that any new vulnerabilities found be reported immediately and documented properly, following the standard guidelines and disclosure process.

Learn more about Defensics fuzz testing

Matias Karhumaa

Posted by

Matias Karhumaa

Matias Karhumaa

Matias Karhumaa is a security-minded senior software engineer at Synopsys. He is developing new solutions for wireless device fuzzing, mainly for Bluetooth. In addition to breaking software, he enjoys mountain biking in his spare time.

More from Fuzz Testing