SweynTooth: Bluetooth in the spotlight

Introduction to previous works on Bluetooth

The Bluetooth protocol has been previously addressed in the INCIBE-CERT blog, covering the cybersecurity aspects that affect this protocol and the possible attacks that may be carried out taking advantage of its vulnerabilities. The article “Analyzing Bluetooth” discussed the various technologies related to Bluetooth, their use in control systems, some security problems and their possible mitigation. To round out the information provided by that article, “Bluetooth Security: Strengths and Weaknesses” was published, in which different attacks on Bluetooth communications were carried out via laboratory tests in order to ultimately set out some security recommendations.

However, all of the security measures presented in those two articles or in the guide “Cybersecurity in Wireless Communications in Industrial Environments” and all the security configurations the protocol may have are not valid if the problem is due to a failure in the implementation of the technology in the communication chips themselves. This is the source of a set of vulnerabilities grouped under the name SweynTooth and that affect BLE (Bluetooth Low Energy) technology.

Explanation of SweynTooth vulnerabilities

Not long ago, various researchers from the Singapore University of Technology and Design published the report “SweynTooth: Unleashing Mayhem over Bluetooth Low Energy” in which the deficiencies and vulnerabilities of Bluetooth are addressed and they clarify that unless these vulnerabilities are addressed, the protocol is in great danger of becoming abandoned and obsolete.

SweynTooth is made up of a total of 12 vulnerabilities that affect the Software Development Kits (SDK) of six of the main Bluetooth chip manufacturers, which in turn are used by many manufacturers in their devices. In the industrial world, devices affected by these problems have been identified in the medical sector (with manufacturers such as VivaCheck Laboratories, Syqe Medical or Medtronic) and in building automation (Eve Systems or August Home, in addition to almost all manufacturers of IIoT devices) mainly, although other sectors have also been affected.

The vulnerabilities discussed here are classified in errors within the traffic flows, connection errors or the evasion of security methods. The vulnerabilities in detail are those shown bellow, none are remotely exploitable. (Source: ASSET Research Group and CISA):

• Crash from Link Layer Length Overflow (CVE-2019-16336, CVE-2019-17519): An attacker could carry out a denial of service condition by modifying the length of the link layer field (LL). Attackers could even reverse engineer the firmware and perform a command injection.
• Link Layer LLID deadlock (CVE-2019-17061, CVE-2019-17060): An attacker could manipulate the packets until the implementation of the SDK discards all the packets received by the user's device, concluding in a denial of service by not processing the information correctly.
• Crash from Truncated L2CAP (CVE-2019-17517): An attacker could send a specific sequence of commands to a device until it manages to write to memory positions close to the L2CAP buffer, thus generating a denial of service condition.
• Crash from Silent Length Overflow (CVE-2019-17518): This overflow is similar to the previous one. In this case, a peripheral responds to the user's device with packets of unexpected LL length. The consequences would be a denial of service, although command execution is also possible.
• Unexpected Public Key Crash (CVE-2019-17520): This vulnerability occurs when using an old security management protocol (SMP). The device using this SMP sends the public key before the pairing procedure starts. It is possible that a memory failure is generated in the device leading to a denial of service condition.
• Sequential ATT Deadlock (CVE-2019-19192): Sending two ATT (Attribute Protocol) requests sequentially in each connection can block a device. If there is no watchdog mechanism to reset in case of a lockout, the device will be locked and a denial of service will occur.
• eadlock from Invalid Connection Request (CVE-2019-19193): The request codes in the connection establishment phase are not properly interpreted, and the peripherals may be left in a "waiting" state by the user's device. If this state is not properly managed on the devices, they can remain permanently in this state without trying to make a new connection.
• Security bypass from Zero LTK Installation (CVE-2019-19194): This is a variation of the overflow by key size. This time a request for encryption is sent outside the options with LTK (Long Term Key) at zero. The keys are then validated by the user's device, allowing the established authentication security mechanisms to be bypassed.
• Crash from Invalid L2CAP Fragment (CVE-2019-19195): The minimum and maximum size of L2CAP packets is defined. However, it is possible to send a different size (size equal to 1) and cause a receiver failure and consequently a denial of service condition.
• Crash from Key Size Overflow (CVE-2019-19196): The origin of this vulnerability is due to several deficiencies in the matching system. The first is the acceptance of a key size greater than the maximum established (16 bytes), to be later rejected with an anomalous behavior. The second is the use of the LL encryption procedure, prior to the matching procedure.

Vulnerability protection and mitigation

Those mainly affected by this problem are already striving to put measures in place and developing security patches in order to correct and resolve all vulnerabilities.

Nonetheless, it is advised to follow some protection and mitigation measures in the event that our control devices may be affected. Below are some points all industry sectors should follow, especially health care and building automation:

• Contact the manufacturers of the devices that use Bluetooth and those that have this technology, although they don’t use it, in order to determine which may be affected.
• Check the manufacturers’ websites in order to learn about the latest patches or published versions of firmware.
• Monitor the devices in order to detect abnormal or unusual behaviour.
• Carry out a risk analysis in order to determine the impact and be able to prioritize actions.

In the case of medical devices specifically, the majority are implants or devices that patients use, so therefore it’s convenient to monitor them:

• Inform patients and identify those that may have vulnerable equipment.
• Patients should report any abnormal behaviour in their device.
• Patients should try to stay away from environments with other Bluetooth transmissions.

Until the corresponding patches are developed and they can be installed in devices, following the appropriate patch installation procedures as explained in “Management of Patches in Control Systems”, it’s advisable to assess the need to use Bluetooth communications and their possible deactivation and substitution by other equivalent protocols.

Conclusion

Wireless communications greatly favour operation in certain environments. It is the job of each industrialist to configure the security options required in each device in order to ensure maximum security of its infrastructure. However, there is little that end customers can do in the face of a weakness of the manufacturers themselves.

This type of vulnerabilities highlights the weakness of some operating tests done on devices, making it necessary to incorporate security controls in these tests, not just functional tests. The tandard IEC 62443-4-2 will help to improve the security tests of all products to be integrated in a control system.