CISA Adds Vulnerabilities Exploitable Via Bluetooth to KEV

Recently, CISA added four vulnerabilities for Owl Labs Meeting Owl devices to its Known Exploited Vulnerabilities (KEV) catalog. These vulnerabilities are exploitable via Bluetooth Low Energy (BLE). This means an attacker would need to be physically near the device in order to exploit it.

On September 18, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added eight vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, including four vulnerabilities for Owl Labs Meeting Owl.

The CVSS vectors for these vulnerabilities indicate the Attack Vector component is “Adjacent.” These four vulnerabilities are exploitable via Bluetooth Low Energy (BLE). This means an attacker would need to be physically near the device in order to exploit it. This is unusual for KEV entries.

What does it mean when CISA adds something to KEV?

CISA posted a blog on September 18 detailing how it prioritizes additions to the KEV catalog. It cites three criteria:

1. There must be a CVE
2. CISA must have credible evidence of exploitation in the wild
3. There needs to be some sort of effective mitigation

The first and the third are fairly straightforward. For the second, the CISA blog notes that its “analysts need evidence that threat actors are actively exploiting the vulnerability in the wild. This evidence needs to be from a credible source — a known industry partner, a trusted security researcher, or a government partner.”

(Image source: Owl Labs, Sept. 22, 2022)

What are the Owl Labs vulnerabilities?

The vulnerabilities were identified by modzero on June 3, 2022 and affect the Meeting Owl device itself. Specifically, versions up to 5.4.2.3 are:

• Access point / tethering mode with hardcoded credentials (CVE-2022-31460, added to the CISA KEV more than a year ago on June 8, 2022) — Owl will create a local WiFi network with hardcoded WPA passphrase and bridge that network to a corporate network. Write {"c":150} to the BLE characteristic 39D6B333-ADAD45C8-B6EE-EAC6C4CD0101 to enable AP mode. If a corporate network is configured, it will be bridged.

• In access point mode, the internal switchboard port is exposed (no CVE issued, not added to the CISA KEV) — while in AP mode for setup TCP port 6300 is exposed on the AP interface. This service is used internally for IPC calls and may be exploitable. I believe that the steps to exploit CVE-2022-31460, above, will enable AP mode for this vulnerability. It’s unclear if the AP tethering mode is the same as the AP mode indicated here used for device setup, but it seems like it is.

• The passcode is not required for Bluetooth commands (CVE-2022-31463) — The passcode is only validated in the companion app, but not on the device itself. Therefore, sending the same commands that the app uses via raw BLE will be successful without a passcode/PIN.

• Hardcoded backdoor passcode (CVE-2022-31462) — the hardcoded backdoor passcode can be calculated via available information. The SHA-1 hash of the backdoor passcode is exposed via BLE.

• Deactivation of passcode without authentication (CVE-2022-31461) — the user defined passcode for the device can be disabled via BLE. Write {"c":"11","v":{"p":"","reset":0}} to an unspecified BLE characteristic to reset the passcode where is the SHA-1 of the passcode. Or write {"c":"11","v":{"p":"","reset":1}} to an unspecified BLE characteristic to remove the passcode entirely. Note that ‘unspecified BLE characteristics’ are either the characteristics noted elsewhere in the document or are easily discoverable by simply enumerating BLE characteristics.

• Passcode hash can be retrieved via Bluetooth (CVE-2022-31459) — this is similar to hardcoded backdoor above. The SHA-1 user set passcode can be retrieved and since it is only made up of digits it can be brute-forced rapidly. Writing {"c":10} to BLE characteristic 39D6B333-ADAD-45C8-B6EE-EAC6C4CD0101 allows the SHA-1 of the already set passcode to be read via 39D6B333-ADAD-45C8-B6EE-EAC6C4CD0001.

As you can see, these vulnerabilities all require an attacker to be within BLE distance of a device. Owl Labs documentation mentions that all of its devices are Bluetooth Class 1, which has an effective range of 330 feet. So, the distance within which these can be exploited may be substantial.

Owl Labs vulnerability timeline

Interestingly, these vulnerabilities were discovered over a year ago. In fact, CISA added one of them to KEV at that time.

What would exploitation look like?

Since exploitation necessitates a device that is near the Meeting Owl, we can assume two paths: a malicious actor sitting nearby or a compromised device in the same vicinity. The first scenario is risky for the threat actor, but at a projected range of 330 feet, a parking lot or sidewalk below an office building could provide cover. A compromised device may be more likely. Laptops and cell phones are often compromised and often accompany people to meetings.

An attacker with full control of a network-connected device (e.g., laptop / cell phone) can easily exploit TCP/IP vulnerabilities, but exploiting BLE vulnerabilities is not as trivial. Traditional TCP/IP vulnerabilities can usually be exploited with commonly used tools already on the compromised device. Netcat, builtin bash functions, curl, Powershell’s Invoke-WebRequest, and more can all easily be used on a compromised computer to exploit a remote IP-based vulnerability. Attackers could use BLE enumeration apps or install command-line tools like hcitool or gatttool to dive deeper into BLE exploration, but these are not installed by default on most laptops or mobile devices. So, malware wanting to exploit BLE vulnerabilities in a remote device would need to include such capabilities or an attacker would need to write some code to use BLE APIs exposed on the compromised device. These vary across operating systems and architectures.

Credible knowledge of exploitation?

While CISA indicates it must have credible evidence that exploitation occurred before adding vulnerabilities to KEV, I’m not currently aware of any BLE vulnerabilities actually exploited in the wild. I’m also not aware of any malware that contains Bluetooth or BLE functionality. Evidence would probably look like either logs from the device or a sample of the malware with this capability. If this is true, it likely marks the first time we have such evidence of exploitation of BLE vulnerabilities.

Conclusion

These vulnerabilities are interesting and may mark the first time there’s evidence of BLE device exploitation in the wild. Their appearance on KEV should also prompt the review of the security of devices in sensitive locations like meeting rooms.

• In a blog post, Owl Labs notes that “If your Meeting Owl (Pro or 3) is connected to Wi-Fi, you will automatically receive this update” so these devices are likely already updated. If they aren’t, make sure to patch them.
• Consider evaluating the placement of devices that facilitate meetings in your conference rooms. Most of these devices have cameras and microphones and can access potentially sensitive information. Make sure they are kept patched and evaluate their attack surface to proximal attack.
• Protect your endpoints. An exposure management strategy will help ensure that devices in your fleet can’t participate in an attack on proximal equipment.

Learn More

• Read how Tenable can help with vulnerabilities on the KEV catalog: https://www.tenable.com/blog/cisa-directive-22-01-how-tenable-can-help-you-find-and-fix-known-exploited-vulnerabilities
• Review Nessus plugins for vulnerabilities on the KEV catalog: https://www.tenable.com/plugins/search?q=cisa_known_exploited%3A%28%22references.id.keyword%22%29&sort=&page=1