BlueBorne and wireless risk: Going beyond NIST and standard frameworks

The most recent cyber scare around the BlueBorne vulnerability has both public- and private-sector organizations racing to evaluate their environments for associated risks -- and with good reason. Bluetooth is an incredibly insecure technology, and the vulnerability applies to nearly every cellular phone with Bluetooth.

That said, there are a couple of crucial factors to note: First, there have been no actual exploits of this vulnerability in the wild to date (though that does not mean organizations can rest easy or default to inaction). Second, there are many more areas of concern with wireless security beyond Bluetooth, which haven’t gotten the media attention, and thus the focus on patches and remediation.

Wireless security is rife with undiscovered vulnerabilities and insecure protocols that have draw scarce little attention despite some having been successfully exploited. I will review what is known about BlueBorne, as well as some of the other wireless security concerns organizations should consider in the wake of this most recent wireless cybersecurity wakeup call.

First, the good news:  The more stringent supply-chain controls and security regulations exercised in the government  sector help isolate such threats as the BlueBorne vulnerability. However, manufacturers include these technologies automatically in their default configurations unpatched and unconfigured. Another major risk is the unintentional insider threat employees pose when they bring in and use unapproved, potentially unsecured peripherals in the enterprise environment.

The BlueBorne vulnerability has been identified as affecting most smartphones from the Apple iPhone to the latest Android. The underlying security vulnerability doesn’t reside in the phone itself but rather the programming library (programming code) that runs the Bluetooth radio inside of the device (detailed analysis is provided by Armis in its research paper).

This library, like most, is shared among different computing platforms. Thankfully, the BlueBorne vulnerability was disclosed responsibly, giving manufacturers plenty of time to develop patches and distribute them. Most government agencies will be able to patch and deploy new images quickly and easily; but likely the rest of the industry will be chasing around that last 5 percent of unpatched devices for months. Armis Technologies also posted a scanner to identify vulnerable devices – users' own  as well as other devices in the area. Unfortunately, the scanner’s logic and function might be used to create a ransomware that spreads via Bluetooth.

Security frameworks such as the National Institute of Standards and Technology  SP 800-53, 800-121, and Department of Defense 8500 security requirements rely mostly on FIPS 140-2 and are stringent and unforgiving to insecure protocols such as wireless -- specifically, Bluetooth and other 802.15 protocols. Unfortunately, these requirements are frequently overlooked and the features get included in phones. 

The other overlooked peripherals that pose risk are 2.4 GHz keyboards and mice. Thankfully, bring-your-own-device policies have not caught on or been encouraged in the public sector to the degree they have in the private sector. This type of cost-cutting strategy can end up costing the organization more money in the long run when it must address compromises on unmanaged BYOD devices containing enterprise data.

The MouseJack vulnerability has the same effect without the huge distribution potential as the BlueBorne bug in iPhones and Android devices (for more information, read “Mousejack: Injecting Keystrokes into Wireless Mice,” Marc Newlin, Bastille Threat Research Team, February 2016).

This vulnerability has existed since 2016 and received no real attention. Compromising an entire enterprise network or dataset only requires one vulnerable host, and it’s typically accessible from outside a building or in the lobby. From recent assessments conducted by my company, Coalfire Labs, the Mousejack vulnerability was successful on nine different sites with 100 percent success rate at least twice at every site. Unfortunately, the broad policy of telling employees not to bring their own peripherals is frequently overlooked by the employee who is attached to her bedazzled mouse or the system administrator with the most ergonomic keyboard. These two examples were seen and exploited recently, and they exist in every organization.  

Most federal entities don’t audit or assess their wireless risk because of their overarching policy banning 802.11 wireless networks entirely. This is an oversight, since these peripherals have been crawling into government workspaces. Regular wireless audits and assessments are needed to identify and mitigate risks, because there is no real automated way of scanning for these devices as with standard Wi-Fi networks with rogue access point detection and wireless intrusion prevention systems.

For these reasons, agencies should consider banning these types of wireless devices due to lack of monitoring. While this might seem drastic, it is the only path to security until proper mitigation and deployment strategies are formulated for these peripherals.

At the end of the day, not every vulnerability like BlueBorne will get a fancy logo and make splashy headlines.  But every vulnerability is one too many for an agency's  critical data.