Bluetooth security flaws expose wireless access points to attack

It has been reported that security researchers have found two severe vulnerabilities affecting several popular wireless access points, which, if exploited, could allow an attacker to compromise enterprise networks. Please see below for commentary from several security experts at Synopsys.

http://brn.firetrench.com

Thomas Richards, associate principal consultant at Synopsys’ Software Integrity Group:

Bluetooth has been added to Wireless APs to extend the technology available to wireless devices on the network.  It allows organisations to develop applications that support BLE devices including location-aware applications.

The flaws appear to be very serious.  If exploited, an attacker could run arbitrary code on the affected devices.  This could lead to compromise of the devices or denial of service attacks.  Taken from the vulnerability website: “…an attacker who acquired the password by sniffing a legitimate update or by reverse-engineering Aruba’s BLE firmware can connect to the BLE chip on a vulnerable access point and upload a malicious firmware containing the attacker’s own code, effectively allowing a completely rewrite its operating system, thereby gaining full control over it. From this point, the malicious potential is identical to that achieved by the first vulnerability.

Hardware devices typically need to be patched manually or through a management dashboard.  The difficulty of patching will depend on if the organisation has centralised control over the wireless APs.”

Travis Biehn, technical strategist – research lead at Synopsys:

I’m concerned about the technical details about how you’d pivot from the BLE microcontroller to the microcontroller controlling the executive router functions. This will be arbitrary for each affected device.

So, intrinsically, the TI chips seem to have vulnerabilities that give attackers the ability to compromise their runtime on those TI chips, an attacker needs to identify another vulnerability between the TI chip and the main access point microcontroller to achieve the level of access described by these security researchers (and this is the likely source of TI’s response.)

 

Patching this will depend on whether A) the TI BLE Microcontrollers have a method for updating their firmware, and B) the Access Point Microcontroller has functionality and connectivity to do reach TI’s firmware update routine.”

 

Nick Murison, managing consultant at Synopsys’ Software Integrity Group:

 

As the researchers point out, the vulnerability is not in the protocol, but rather in the way the protocol has been implemented on the affected chipsets. This underscores the importance for vendors to test that their implementations not only adhere to the protocol specification, but also respond in a secure manner when presented with malformed traffic. It seems like a rather obvious product placement, but protocol fuzzing tools such as Synopsys’ Defensics are designed to do just this.

 

Of course, there are other steps one can take much earlier in the development lifecycle to prevent such implementation bugs from surviving all the way through to production. Using static code analysis during development can identify unsafe use of buffers, integer overflows and many other similar types of issues. Unit and integration test suites can be written to not only execute positive functional tests, but also perform negative and boundary testing. Most companies that do any significant level of software development these days will be leveraging Continuous Integration pipelines to automatically build and test software from a quality perspective; such pipelines can easily be adapted to also include security-specific testing, such as static analysis and fuzzing.

 

On an even more proactive level, companies should be looking to ensure developers understand the repercussions of such implementation bugs through a diverse training offering that fits around the developers’ working style. As part of the design phase, companies should also be looking at threat modelling or architecture risk analysis to identify potential security weak spots, and look for opportunities to make the overall solution secure by design.”