{"lastseen": "2020-09-29T14:42:01", "references": ["https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/", "https://www.bluetooth.com/specifications/bluetooth-core-specification/", "https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/reporting-security/"], "description": "### Overview\n\nDevices supporting both Bluetooth BR/EDR and LE using Cross-Transport Key Derivation (CTKD) for pairing are vulnerable to key overwrite, which enables an attacker to to gain additional access to profiles or services that are not restricted by reducing the encryption key strength or overwriting an authenticated key with an unauthenticated key. This vulnerability is being referred to as [BLURtooth](<https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>).\n\n### Description\n\nAs detailed in both the Bluetooth Core Specification versions [4.2](<https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=441541>) and [5.0](<https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043>), Bluetooth CTKD can be used for pairing by devices that support both Low Energy (BLE) and Basic Rate/Enhanced Data Rate (BR/EDR) transport methods, which are known as \"dual-mode\" devices. CTKD pairing allows the devices to pair once using either transport method while generating both the BR/EDR and LE Long Term Keys (LTK) without needing to pair a second time. Dual-mode devices using CTKD to generate a LTK or Link Key (LK) are able to overwrite the original LTK or LK in cases where that transport was enforcing a higher level of security.\n\n### Impact\n\nSeveral potential attacks could be performed by exploiting [CVE-2020-15802](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15802>), including a Man in the Middle (MITM) attack. The vulnerability is being referred to as BLURtooth and the group of attacks is being referred to as the BLUR attacks. Vulnerable devices must permit a pairing or bonding to proceed transparently with no authentication, or a weak key strength, on at least one of the BR/EDR or LE transports in order to be susceptible to attack. For example, it may be possible to pair with certain devices using [JustWorks](<https://www.bluetooth.com/blog/bluetooth-pairing-part-4/>) pairing over BR/EDR or LE and overwriting an existing LTK or LK on the other transport. When this results in the reduction of encryption key strength or the overwrite of an authenticated key with an unauthenticated key, an attacker could gain additional access to profiles or services that are not otherwise restricted.\n\n### Solution\n\nThe Bluetooth SIG has released [recommendations](<https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>) for mitigating this issue that include additional conformance tests to ensure that the overwrite of an authenticated key or a key of a given length with an unauthenticated key or a key of reduced length is not permitted in devices supporting Bluetooth Core Specification version 5.1 or greater. They also recommend that potentially vulnerable implementations introduce the restrictions on CTKD mandated in Bluetooth Core Specification versions 5.1 and later. Implementations should disallow overwrite of the LTK or LK for one transport with the LTK or LK derived from the other when this overwrite would result in either a reduction of the key strength of the original bonding or a reduction in the MITM protection of the original bonding (from authenticated to unauthenticated). This may require that the host track the negotiated length and authentication status of the keys in the Bluetooth security database.\n\nThe Bluetooth SIG further recommends that devices restrict when they are pairable on either transport to times when user interaction places the device into a pairable mode or when the device has no bonds or existing connections to a paired device. In all cases, it is recommended that devices restrict the duration of pairing mode and overwrite an existing bonding only when devices are explicitly in pairing mode.\n\n### Acknowledgements\n\nThanks to the reporter who wishes to remain anonymous.\n\nThis document was written by Madison Oliver.\n\n### Vendor Information \n\n589825\n\nFilter by status: All Affected Not Affected Unknown\n\nFilter by content: __ Additional information available\n\n__ Sort by: Status Alphabetical\n\nExpand all\n\n### Bluetooth SIG Affected\n\nNotified: 2020-06-09 Updated: 2020-09-09 **CVE-2020-15802**| Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Barracuda Networks Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-23\n\n**Statement Date: September 16, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Belden __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: August 31, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nBelden devices do not support Bluetooth and are not affected by this vulnerability.\n\n### Brocade Communication Systems __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-23\n\n**Statement Date: September 15, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nNo Brocade Fibre Channel Products from Broadcom are currently known to be affected by this vulnerability.\n\n### Ceragon Networks Inc Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-11\n\n**Statement Date: September 10, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### F5 Networks Inc. __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: September 01, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nF5 products do not include/support Bluetooth.\n\n### Fastly Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-23\n\n**Statement Date: September 11, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Infoblox Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: August 28, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Intel Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: August 31, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Juniper Networks __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-11\n\n**Statement Date: September 10, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nBased on our investigation we confirm that there are no platforms/products which are affected from these vulnerabilities.\n\n### lwIP Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-25\n\n**Statement Date: September 25, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Microchip Technology __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: September 07, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nMicrochip Bluetooth Dual Mode solutions do NOT implement Cross-Transport Key Derivation (CTKD), Microchip solutions are NOT affected by BLURtooth vulnerability\n\n### Miredo Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: August 28, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### NetBSD Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-29\n\n**Statement Date: September 29, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### VMware __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-23\n\n**Statement Date: September 14, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nVmware is not affected by the above issues directly.\n\n### VMware Carbon Black Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: September 09, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Wind River __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-23\n\n**Statement Date: September 22, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n#### References\n\n * [https://support2.windriver.com/index.php?page=cve&amp;on=view&amp;id=CVE-2020-15802](<https://support2.windriver.com/index.php?page=cve&on=view&id=CVE-2020-15802>)\n\n### Zyxel __ Not Affected\n\nNotified: 2020-08-28 Updated: 2020-09-09\n\n**Statement Date: September 09, 2020**\n\n**CVE-2020-15802**| Not Affected \n---|--- \n \n#### Vendor Statement\n\nZyxel products are NOT affected either because they don\u2019t support Cross Transport Key Derivation or do not support Bluetooth at all.\n\n### Actelis Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Aerohive Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### AhnLab Inc Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Akamai Technologies Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Alcatel-Lucent Enterprise Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Allied Telesis Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### ANTlabs Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Arista Networks Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Atheros Communications Inc Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Avaya Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Belkin Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Bell Canada Enterprises Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### BoringSSL Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Broadcom Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Cambium Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Cirpack Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### CISA Industrial Control Systems Vulnerability Management and Coordination Unknown\n\nUpdated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Cisco Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### CMX Systems Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Commscope Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Cricket Wireless Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Cypress Semiconductor Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Deutsche Telekom Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Devicescape Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Digi International Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### D-Link Systems Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### EfficientIP Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Ericsson Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Espressif Systems Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Extreme Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Force10 Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Foundry Brocade Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### FreeBSD Project Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### GFI Software Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Google Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Grandstream Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### HCC Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Hewlett Packard Enterprise Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Hitachi Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Honeywell Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### HP Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Huawei Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### IBM Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### ICASI Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### InfoExpress Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Inmarsat Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### INTEROP Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### IP Infusion Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Lantronix Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Lenovo Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### LG Electronics Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### LibreSSL Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### LiteSpeed Technologies Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Lynx Software Technologies Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### m0n0wall Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Marvell Semiconductor Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### MediaTek Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Medtronic Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Metaswitch Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Microsoft Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Muonics Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### NetBurner Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### NETSCOUT Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### netsnmp Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### netsnmpj Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Nokia Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### OleumTech Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### OpenConnect Ltd Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### OpenSSL Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Oracle Corporation Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Oryx Embedded Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Paessler Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Palo Alto Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Philips Electronics Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Proxim Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Pulse Secure Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### QLogic Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Quadros Systems Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Qualcomm Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Riverbed Technologies Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Ruijie Networks Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### SafeNet Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Samsung Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Samsung Semiconductor Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### SEIKO EPSON Corp. / Epson America Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### SmoothWall Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Sonos Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Sophos Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### TCPWave Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Tenable Network Security Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### TippingPoint Technologies Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Toshiba Commerce Solutions Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Untangle Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Vertical Networks Inc. Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### WizNET Technology Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### wolfSSL Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### Zebra Technologies Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\n### ZTE Corporation Unknown\n\nNotified: 2020-08-28 Updated: 2020-09-09 **CVE-2020-15802**| Unknown \n---|--- \n \n#### Vendor Statement\n\nWe have not received a statement from the vendor.\n\nView all 116 vendors __View less vendors __\n\n \n\n\n### References \n\n * <https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>\n * <https://www.bluetooth.com/specifications/bluetooth-core-specification/>\n * <https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/reporting-security/>\n\n### Other Information\n\n**CVE IDs:** | [CVE-2020-15802 ](<http://web.nvd.nist.gov/vuln/detail/CVE-2020-15802>) \n---|--- \n**Date Public:** | 2020-09-09 \n**Date First Published:** | 2020-09-09 \n**Date Last Updated: ** | 2020-09-29 13:16 UTC \n**Document Revision: ** | 6 \n", "reporter": "CERT", "published": "2020-09-09T00:00:00", "type": "cert", "title": "Devices supporting Bluetooth BR/EDR and LE using CTKD are vulnerable to key overwrite", "enchantments": {"dependencies": {"references": [{"type": "cve", "idList": ["CVE-2020-15802"]}, {"type": "threatpost", "idList": ["THREATPOST:A520224EBE48A5883B0AFBB0E8EEA0C2"]}, {"type": "thn", "idList": ["THN:750045FB46D70C83ECBE5EC982B33A42"]}], "modified": "2020-09-29T14:42:01", "rev": 2}, "score": {"value": 6.0, "vector": "NONE", "modified": "2020-09-29T14:42:01", "rev": 2}, "vulnersScore": 6.0}, "bulletinFamily": "info", "cvelist": ["CVE-2020-15802"], "modified": "2020-09-29T13:16:00", "id": "VU:589825", "href": "https://www.kb.cert.org/vuls/id/589825", "viewCount": 57, "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}

{"cve": [{"lastseen": "2020-09-21T13:58:30", "description": "Devices supporting Bluetooth before 5.1 may allow man-in-the-middle attacks, aka BLURtooth. Cross Transport Key Derivation in Bluetooth Core Specification v4.2 and v5.0 may permit an unauthenticated user to establish a bonding with one transport, either LE or BR/EDR, and replace a bonding already established on the opposing transport, BR/EDR or LE, potentially overwriting an authenticated key with an unauthenticated key, or a key with greater entropy with one with less.", "edition": 3, "cvss3": {"exploitabilityScore": 2.2, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "HIGH", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "baseScore": 5.9, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 3.6}, "published": "2020-09-11T14:15:00", "title": "CVE-2020-15802", "type": "cve", "cwe": ["CWE-287"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "NONE", "integrityImpact": "PARTIAL", "baseScore": 4.3, "vectorString": "AV:N/AC:M/Au:N/C:N/I:P/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15802"], "modified": "2020-09-16T14:55:00", "cpe": [], "id": "CVE-2020-15802", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15802", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}, "cpe23": []}], "threatpost": [{"lastseen": "2020-09-17T21:43:29", "bulletinFamily": "info", "cvelist": ["CVE-2020-15802"], "description": "A high-severity Bluetooth vulnerability has been uncovered, which could enable an unauthenticated attacker within wireless range to eavesdrop or alter communications between paired devices.\n\nThe flaw ([CVE-2020-15802](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15802>)), discovered independently by researchers at the \u00c9cole Polytechnique F\u00e9d\u00e9rale de Lausanne (EPFL) and Purdue University, [is being referred](<https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>) to as \u201cBLURtooth.\u201d The issue exists in the [pairing process](<https://cert.civis.net/en/index.php?action=alert&param=CVE-2020-15802>) for Bluetooth 4.0 through 5.0 implementations. This pairing process is called Cross-Transport Key Derivation (CTKD).\n\n\u201cDevices\u2026 using [CTKD] for pairing are vulnerable to key overwrite, which enables an attacker to gain additional access to profiles or services that are not restricted, by reducing the encryption key strength or overwriting an authenticated key with an unauthenticated key,\u201d according [to a security advisory](<https://kb.cert.org/vuls/id/589825>) on Wednesday by the Carnegie Mellon CERT Coordination Center.\n\n## **The \u2018BLURtooth\u2019 Attack**\n\nThere are two types of Bluetooth protocols related to the attack \u2013 the older Bluetooth Classic (also known as Bluetooth Basic Rate/Enhanced Data Rate, or BR/EDR) and newer Bluetooth Low Energy (BLE). While BR/EDR are mainly used for audio applications such as wireless telephone connections, wireless headphones and wireless speakers, BLE is more often seen in wearable devices, smart IoT devices, fitness monitoring equipment and battery-powered accessories such as a keyboard.\n\n[](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)\n\nClick to Register\n\nThe process of CTKD is utilized when two dual-mode devices pair with each other \u2013 \u201cdual-mode\u201d meaning that they support both BLE and BR/EDR. The process means the devices only need to pair over either BLE or BR/EDR to get the encryption keys \u2013 called Link Keys \u2013 for both transport types in one go.\n\nHowever, a hole in CTKD makes it possible to lower the \u201cstrength\u201d of these Link Key encryption keys (further technical details on where specifically the vulnerability exists within CTKD \u2014 as well as specific steps needed to exploit the flaw \u2014 are not yet available). That in turn paves the way for an attacker to pair their own devices to the target\u2019s device, with no authentication needed.\n\nFor this attack to be successful, an attacker would need to be within wireless range of a vulnerable Bluetooth device. That can vary from 330 feet for Bluetooth 4.0 devices, to 800 feet for Bluetooth 5.0.\n\nTo be vulnerable, a device would need to support both BR/EDR and BLE transports and also support CTKD. It must also permit a pairing or bonding to proceed transparently with no authentication, or a weak key strength, on at least one of the transport types; that allows attackers to interfere between the two transports by impersonating a previously paired device. Thus, it enables their non-authenticated encryption keys to replace the authenticated keys.\n\n\u201cIf a device spoofing another device\u2019s identity becomes paired or bonded on a transport, and CTKD is used to derive a key which then overwrites a pre-existing key of greater strength or that was created using authentication, then access to authenticated services may occur,\u201d according to a [security advisory on Wednesday](<https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>) by the Bluetooth Special Interest Group (SIG), the organization that oversees the development of Bluetooth standards. \u201cThis may permit a man-in-the-middle (MITM) attack between devices previously bonded using authenticated pairing when those peer devices are both vulnerable.\u201d\n\nThe attacker could then sniff out communications between the two devices \u2013 allowing them to spy on messages or potentially even alter them.\n\n## **Bluetooth Mitigations**\n\nThe Bluetooth SIG is recommending that potentially vulnerable Bluetooth implementations introduce the restrictions on CTKD that have been mandated in Bluetooth Core Specification versions 5.1 and later. These restrictions prevent the overwrite of an authenticated key or a key of a given length with an unauthenticated key or a key of reduced length.\n\n\u201cThe Bluetooth SIG is also broadly communicating details on this vulnerability and its remedies to our member companies and is encouraging them to rapidly integrate any necessary patches,\u201d according to Bluetooth. \u201cAs always, Bluetooth users should ensure they have installed the latest recommended updates from device and operating system manufacturers.\u201d\n\nSeveral Bluetooth-based attacks have cropped up over the past year. In May, academic researchers [uncovered security vulnerabilities](<https://threatpost.com/bluetooth-bugs-impersonation-devices/155886/>) in Bluetooth Classic that could have allowed attackers to spoof paired devices and capture sensitive data. In February, meanwhile, a critical vulnerability in the Bluetooth implementation on Android devices [was discovered that could allow](<https://threatpost.com/critical-android-bluetooth-bug-enables-rce-no-user-interaction-needed/152699/>) attackers to launch remote code-execution (RCE) attacks \u2013 without any user interaction.\n\n[**On Wed Sept. 16 @ 2 PM ET:**](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)** Learn the secrets to running a successful Bug Bounty Program. **[**Register today**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** for this FREE Threatpost webinar \u201c**[**Five Essentials for Running a Successful Bug Bounty Program**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)**\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this **[**LIVE**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** webinar.**\n", "modified": "2020-09-10T16:39:05", "published": "2020-09-10T16:39:05", "id": "THREATPOST:A520224EBE48A5883B0AFBB0E8EEA0C2", "href": "https://threatpost.com/bluetooth-bug-mitm-attacks/159124/", "type": "threatpost", "title": "Bluetooth Bug Opens Devices to Man-in-the-Middle Attacks", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}], "thn": [{"lastseen": "2020-09-10T21:44:00", "bulletinFamily": "info", "cvelist": ["CVE-2020-15802"], "description": "[](<https://thehackernews.com/images/-thAMpcqNwSM/X1qZhjL1xlI/AAAAAAAA3Sw/v0btKQ_mHQQudTn-juKYqX675Vk4qhkRwCLcBGAsYHQ/s728-e100/Blutooth-attack.jpg>)\n\nBluetooth SIG\u2014an organization that oversees the development of Bluetooth standards\u2014today issued a [statement](<https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/blurtooth/>) informing users and vendors of a newly reported unpatched vulnerability that potentially affects hundreds of millions of devices worldwide. \n \nDiscovered independently by two separate teams of academic researchers, the flaw resides in the Cross-Transport Key Derivation (CTKD) of devices supporting both \u2014 Basic Rate/Enhanced Data Rate (BR/EDR) and Bluetooth Low Energy (BLE) standard. \n \nCross-Transport Key Derivation (CTKD) is a Bluetooth component responsible for negotiating the authenticate keys when pairing two Bluetooth devices together, also known as \"dual-mode\" devices. \n\n\n[](<https://go.thn.li/contrast> \"cybersecurity\" )\n\n \nDubbed 'BLURtooth' and tracked as **CVE-2020-15802**, the flaw exposes devices powered with Bluetooth 4.0 or 5.0 technology, allowing attackers to unauthorizedly connect to a targeted nearby device by overwriting the authenticated key or reducing the encryption key strength. \n \n\"Dual-mode devices using CTKD to generate a Long Term Keys (LTK)or Link Key (LK) are able to overwrite the original LTK or LK in cases where that transport was enforcing a higher level of security,\" the researchers explain. \n \n\"Vulnerable devices must permit a pairing or bonding to proceed transparently with no authentication, or a weak key strength, on at least one of the BR/EDR or LE transports in order to be susceptible to attack.\" \n \nIn other words, the flaw leverage ability under specific implementations of the pairing process that could allow devices to overwrite authorization keys when the transport enforces a higher level of security. \n \nAccording to an [advisory](<https://www.kb.cert.org/vuls/id/589825/>) published by Carnegie Mellon CERT Coordination Center, the flaw can lead to several potential attacks, grouped as 'BLUR attacks,' including man-in-the-middle attack. \n\n\n \n\"If a device spoofing another device's identity becomes paired or bonded on a transport and CTKD is used to derive a key which then overwrites a pre-existing key of greater strength or that was created using authentication, then access to authenticated services may occur,\" Bluetooth SIG warned of the same. \n \n\"This may permit a Man In The Middle (MITM) attack between devices previously bonded using authenticated pairing when those peer devices are both vulnerable.\" \n \nBesides recommending to introduce restrictions on CTKD mandated in [Bluetooth Core Specification](<https://www.bluetooth.com/specifications/bluetooth-core-specification/>) versions 5.1 and later as primary mitigation, Bluetooth SIG has also started coordinates with affected device manufacturers to help them release necessary patches rapidly. \n \n\"The Bluetooth SIG further recommends that devices restrict when they are pairable on either transport to times when user interaction places the device into a pairable mode or when the device has no bonds or existing connections to a paired device,\" the researchers said. \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2020-09-10T21:37:22", "published": "2020-09-10T21:37:00", "id": "THN:750045FB46D70C83ECBE5EC982B33A42", "href": "https://thehackernews.com/2020/09/new-bluetooth-vulnerability.html", "type": "thn", "title": "New Unpatched Bluetooth Flaw Lets Hackers Easily Target Nearby Devices", "cvss": {"score": 0.0, "vector": "NONE"}}]}