Bluetooth Security: Flaws Expose Wireless Access Points to Hackers
It has been recently reported that security researchers have found two severe vulnerabilities affecting several popular wireless access points. These vulnerabilities could could allow an attacker to compromise enterprise networks, if properly exploited.
As it was covered by techcrunch, the two bugs are found in Bluetooth Low Energy chips built by Texas Instruments, which networking device makers — like Aruba, Cisco and Meraki — use in their line-up of enterprise wireless access points. Although the two bugs are distinctly different and target a range of models, the vulnerabilities can allow an attacker to take over an access point and break into an enterprise network or jump over the virtual walls that separate networks.
After such an important disclosure, we have invited commentary from several security experts at Synopsys.
Here are their insights about this security vulnerability and how it can affect to these popular wireless access points that most people use in an every day basis:
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.”