The attack vector "Blueborne" exposes almost every connected devices
Overview
In September 2017 the BlueBorne attack vector was disclosed by Armis Labs. BlueBorne allows
attackers to leverage Bluetooth connections to penetrate and take complete control over major mobile, desktop, and IoT operating systems, including Android, iOS, Windows, and Linux, and the devices using them. The new vector is dubbed “BlueBorne”, as it spread through the air (airborne) and attacks devices via Bluetooth. Armis has also disclosed eight related zero-day vulnerabilities, four of which are classified as critical. BlueBorne allows attackers to take control of devices, access corporate data and networks, penetrate secure “air-gapped” networks, and spread malware laterally to adjacent devices. In the meantime, the BlueBorne attack vector can also be used to conduct a large range of offenses, including remote code execution as well as Man-in-The-Middle attacks.
Threats
The BlueBorne attack vector has several qualities which can have a devastating effect when combined. By spreading through the air, BlueBorne targets the weakest spot in the networks’ defense - and the only one that no security measure protects. Spreading from device to device through the air also makes BlueBorne highly infectious. Moreover, since the Bluetooth process has high privileges on all operating systems, exploiting it provides virtually full control over the device.
Unfortunately, this set of capabilities is extremely desireable to a hacker. BlueBorne can serve any malicious objective, such as cyber espionage, data theft, ransomware, and even creating large botnets out of IoT devices like the Mirai Botnet or mobile devices as with the recent WireX Botnet. The BlueBorne attack vector surpasses the capabilities of most attack vectors by penetrating secure “air-gapped” networks which are disconnected from any other network, including the internet.
The BlueBorne attack vector can potentially affect all devices with Bluetooth capabilities, estimated at over 8.2 billion devices today. Bluetooth is the leading and most widespread protocol for short-range communications, and is used by devices of all kinds, from regular computers and mobile devices to IoT devices such as TVs, watches, cars, and even medical appliances. The latest published reports show more than 2 billion Android, 2 billion Windows, and 1 billion Apple devices in use. Gartner reports that there are 8 billions connected or IoT devices in the world today, many of which have Bluetooth.
What's New About BlueBorne
BlueBorne concerns us because of the medium by which it operates. Unlike the majority of attacks today, which rely on the internet, a BlueBorne attack spreads through the air. This works similarly to the two less extensive vulnerabilities discovered recently in a Broadcom Wi-Fi chip by Project Zero and Exodus. The vulnerabilities found in Wi-Fi chips affect only the peripherals of the device, and require another step to take control of the device. With BlueBorne, attackers can gain full control right from the start. Moreover, Bluetooth offers a wider attacker surface than WiFi, almost entirely unexplored by the research community and hence contains far more vulnerabilities.
Airborne attacks, unfortunately, provide a number of opportunities for the attacker. First, spreading through the air renders the attack much more contagious, and allows it to spread with minimum effort. Second, it allows the attack to bypass current security measures and remain undetected, as traditional methods do not protect from airborne threats. Airborne attacks can also allow hackers to penetrate secure internal networks which are “air gapped,” meaning they are disconnected from any other network for protection. This can endanger industrial systems, government agencies, and critical infrastructure.
Finally, unlike traditional malware or attacks, the user does not have to click on a link or download a questionable file. No action by the user is necessary to enable the attack.
Affected Devices
The vulnerabilities disclosed by Armis affect all devices running on Android, Linux, Windows, and pre-version 10 of iOS operating systems, regardless of the Bluetooth version in use. This means almost every computer, mobile device, smart TV or other IoT device running on one of these operating systems is endangered by at least one of the eight vulnerabilities. This covers a significant portion of all connected devices globally.
Android
All Android phones, tablets, and wearables (except those using only Bluetooth Low Energy) of all versions are affected by four vulnerabilities found in the Android operating system, two of which allow remote code execution (CVE-2017-0781 and CVE-2017-0782), one results in information leak (CVE-2017-0785) and the last allows an attacker to perform a Man-in-The-Middle attack (CVE-2017-0783).
Examples of impacted devices:
Google Pixel
Samsung Galaxy
Samsung Galaxy Tab
LG Watch Sport
Pumpkin Car Audio System
Google has issued a security update patch and notified its partners. It was available to Android partners on August 7th, 2017, and made available as part of the September Security Update and Bulletin on September 4, 2017. We recommend that users check that Bulletin for the latest most accurate information. Android users should verify that they have the September 9, 2017 Security Patch Level.
Windows
All Windows computers since Windows Vista are affected by the “Bluetooth Pineapple” vulnerability which allows an attacker to perform a Man-in-The-Middle attack (CVE-2017-8628).
Microsoft issued has security patches to all supported Windows versions on July 11, 2017, with coordinated notification on Tuesday, September 12. We recommend that Windows users should check with the Microsoft release at here for the latest information.
Linux
Linux is the underlying operating system for a wide range of devices. The most commercial, and consumer-oriented platform based on Linux is the Tizen OS.
All Linux devices running BlueZ are affected by the information leak vulnerability (CVE-2017-1000250).
All Linux devices from version 2.6.32 (released in July 2009) until version 4.14 are affected by the remote code execution vulnerability (CVE-2017-1000251)
Examples of impacted devices:
Samsung Gear S3 (Smartwatch)
Samsung Smart TVs
Samsung Family Hub (Smart refrigerator)
Patches to Linux vulnerabilities have been pushed to the upstream projects. The information leak vulnerability was patched here, and the remote code execution was patched here Linux distributions have started to push updates as well, please look for specific updates made by your distribution.
iOS
All iPhone, iPad and iPod touch devices with iOS 9.3.5 and lower, and AppleTV devices with version 7.2.2 and lower are affected by the remote code execution vulnerability (CVE-2017-14315). This vulnerability was already mitigated by Apple in iOS 10, so no new patch is needed to mitigate it. We recommend you upgrade to the latest iOS or tvOS available.
If you are concerned that your device may not be patched, we recommend disabling Bluetooth, and minimizing its use until you can confirm a patch is issued and installed on your device.
Amazon Echo and Google Home
These devices were identified as impacted by BlueBorne. Please click here to read the report on BlueBorne’s impact on the voice activated Personal Assistants.
BlueBorne attack on Android
In this blog we are going to focus on the attack on Android devices. There are totally four vulnerabilities that can be exploited.
Information Leak Vulnerability (CVE-2017-0785)
The first vulnerability in the Android operating system reveals valuable information which helps the attacker leverage one of the remote code execution vulnerabilities described below. The vulnerability was found in the SDP (Service Discovery Protocol) server, which enables the device to identify other Bluetooth services around it. The flaw allows the attacker to send a set of crafted requests to the server, causing it to disclose memory bits in response. These pieces of information can later be used by the attacker to overcome advanced security measures and take control over the device. This vulnerability can also allow an attacker to leak encryption keys from the targeted device and eavesdrop on Bluetooth communications, in an attack that very much resembles heartbleed.
Android’s SDP server defines a similar continuation state structure:
In this case, only a continuation offset (that has similar meaning to the index used in BlueZ) is sent in the continuation struct. Although the code of Android’s SDP server search request handler does perform some validations on cont_offset, an information leak is still achievable. In the following excerpt, num_rsp_handles will hold the total number of handles (that are the sdp records) of the SDP response:
The code holds a copy of the cont_offset in its connection object (p_ccb), and validates that the received cont_offset is equal to the current state of the connection. So a simple abuse of cont_offset is not achievable (as done in BlueZ). However, since each continuation request is essentially a new request which only has a continuation state appended to it, the code can be led to a state confusion by changing the parameters of the request between two consecutive requests.
The num_rsp_handles is calculated each time a request is received, based on the total size of the specific response. The response’s size may vary based on the requested service search that is being performed, and unlike cont_offset, num_rsp_handles is not saved in the connection object and validated to remain the same throughout the reading of the response fragments.
The code assumes that num_rsp_handles, and cont_offset both refer to the same response that is being sent in fragments. Due to the induced state confusion, and since r em_handles is uint16_t, the code will now assume a very large response is needed (up to 64KB) - and the for-loop that follows will copy out of bounds bytes from rsp_handles to an outgoing response packet.
To sum up, this info leak can be triggered by an attacker in this flow:
1. A search request is performed to some service.
2. Due to this request, a response is returned with a continuation state. The size of this response will be defined by the MTU of the connection, as seen in the code excerpt above, so an attacker holds some control over the fragments’ size as well.
3. A second request is performed to a different service, and the continuation state from the previous response will be prepended to this request. This second search request will be of a service that will return a smaller response size than the previous response - and this will lead to the described state confusion.
4. A validation of cont_offset will be attempted, but it will pass successfully (since the same cont_offset was appended to the second request).
5. Due to fact num_rsp_handles in this second request is smaller than the one in the first request, an underflow of rem_handles will be achieved.
6. The code will now assume a very large response is needed - and the for-loop that follows would copy bytes from rsp_handles to an outgoing response packet.
7. From this point on, an attacker can repeat sending the same request, and prepend the returned cont_offset - continuing to read more and more out of bound bytes from rsp_handles.
Similar to the information leak vulnerability in BlueZ, this vulnerability can lead to the disclosure of a large part of the memory - in this instance from the process stack. This data can potentially include encryption keys, address space and valuable pointers (of code, or data), that can be used to bypass ASLR while exploiting a separate memory corruption vulnerability.
Remote Code Execution Vulnerability #1 (CVE-2017-0781)
This vulnerability resides in the Bluetooth Network Encapsulation Protocol (BNEP) service, which enables internet sharing over a Bluetooth connection (tethering). Due to a flaw in the BNEP service, a hacker can trigger a surgical memory corruption, which is easy to exploit and enables him to run code on the device, effectively granting him complete control. Due to lack of proper authorization validations, triggering this vulnerability does not require any user interaction, authentication or pairing, so the targeted user is completely unaware of an ongoing attack.
To be specific, the first vulnerability lies in the following call to memcpy:
The above code flow is the process of handling incoming BNEP control messages. The BNEP_FRAME_CONTROL is the switch case for BNEP control messages. This specific flow is an attempt to handle a unique use case: since multiple control messages may pass in a single L2CAP message (using the extension bit), the state of the BNEP connection may change between one control message to the other. If for example a SETUP_CONNECTION_REQUEST is sent as the control message, any following control messages might expect to be parsed while the code is in CONNECTED state (and not its initial state which is IDLE). Switching to the CONNECTED state requires the a successful completion of the authentication process (as described in the previous section), and since this process is asynchronous, the state in this context will still be IDLE. The solution for this problem is to parse the remaining control messages at a later time - once the authentication process is complete, and the state of connection has transitioned to CONNECTED.
For this purpose, the above code saves the remaining unparsed message for later use (in p_pending_data ). However, a simple mistake lies in this code: First the p_pending_data buffer is allocated on the heap, with size rem_len . Later, a memcpy is made to p_pending_data + 1 with the size rem_len . Thus the memcpy will overflow the buffer by sizeof (p_pending_data) bytes! One may wonder how such a mistake can go unnoticed, as it causes a heap corruption every time this code is triggered. Additionally, this causes an inherent memory leak since the previous p_pending_data pointer is never freed before another allocation occurs. It is very likely that this code did never actually run, not during real world usage, and probably not even during coverage testing.
The field p_pending_data is of type BT_HDR , which is 8 bytes long. Additionally, rem_len , which controls the size of the allocation, is under the attacker’s control, since it’s the length of the remaining un-parsed bytes in the packet, as well as the source for the memcpy ( p ) which points to the attacker-controlled packet.
Remote Code Execution vulnerability #2 (CVE-2017-0782)
This vulnerability is similar to the previous one, but resides in a higher level of the BNEP service - the Personal Area Networking (PAN) profile - which is responsible for establishing an IP based network connection between two devices. In this case, the memory corruption is larger, but can still be leveraged by an attacker to gain full control over the infected device. Similar to the previous vulnerability, this vulnerability can also be triggered without any user interaction, authentication or pairing.
Specificly, the second vulnerability also appears in a flow that occurs under bnep_data_ind . This one lies in the following integer underflow of rem_len in the function bnep_process_control_packet :
This function handles the processing of all BNEP control messages, and the extension header to parse additional sub-messages passed inside a parent control message. The BNEP specification allows unrecognized extension messages to be ignored by the receiving side, and thus the 'default' case above tries to skip unrecognized control messages using the extension length from the extension header.
The integer rem_len is defined as a 16-bit unsigned short and represents the actual amount of remaining unparsed bytes in an attacker-controlled packet. The value of e xt_len is 8 bits unsigned, and is part of the extension header that is also attacker-controlled. Thus a proper rem_len can suddenly be underflowed to almost any value above 0xff00, making any further handling of the packet that depends on rem_len unsafe.
In the bnep_data_ind code, after the call to bnep_process_control_packet , the (now unsafe) rem_len is indeed used in a dangerous way:
The resulting underflowed rem_len is then directly set to the l en of the p_buf (the actual packet structure). Additionally, the offset field of p_buf is affected. This is the offset of the first not-yet parsed byte in the packet. Together, these fields define the amount of bytes left in the packet for upper layers to handle.
Immediately after, a call to bnep_cb.p_data_ind_cb (an upper layer handling callback) occurs with the malformed p_buf as input. It’s thus possible to reach the following code path using the crafted packet:
The Bluetooth Pineapple - Man in The Middle attack (CVE-2017-0783)
Man-in-The-Middle (MiTM) attacks allow the attacker to intercept and intervene in all data going to or from the targeted device. To create a MiTM attack using Wi-Fi, the attacker requires both special equipment, and a connection request from the targeted device to an open WiFi network. In Bluetooth, the attacker can actively engage his target, using any device with Bluetooth capabilities. The vulnerability resides in the PAN profile of the Bluetooth stack, and enables the attacker to create a malicious network interface on the victim's device, re-configure IP routing and force the device to transmit all communication through the malicious network interface. This attack does not require any user interaction, authentication or pairing, making it practically invisible.
Information Leak Vulnerability (CVE-2017-0785)
The first vulnerability in the Android operating system reveals valuable information which helps the attacker leverage one of the remote code execution vulnerabilities described below. The vulnerability was found in the SDP (Service Discovery Protocol) server, which enables the device to identify other Bluetooth services around it. The flaw allows the attacker to send a set of crafted requests to the server, causing it to disclose memory bits in response. These pieces of information can later be used by the attacker to overcome advanced security measures and take control over the device. This vulnerability can also allow an attacker to leak encryption keys from the targeted device and eavesdrop on Bluetooth communications, in an attack that very much resembles heartbleed.
Android’s SDP server defines a similar continuation state structure:
The num_rsp_handles is calculated each time a request is received, based on the total size of the specific response. The response’s size may vary based on the requested service search that is being performed, and unlike cont_offset, num_rsp_handles is not saved in the connection object and validated to remain the same throughout the reading of the response fragments.
The code assumes that num_rsp_handles, and cont_offset both refer to the same response that is being sent in fragments. Due to the induced state confusion, and since r em_handles is uint16_t, the code will now assume a very large response is needed (up to 64KB) - and the for-loop that follows will copy out of bounds bytes from rsp_handles to an outgoing response packet.
To sum up, this info leak can be triggered by an attacker in this flow:
1. A search request is performed to some service.
2. Due to this request, a response is returned with a continuation state. The size of this response will be defined by the MTU of the connection, as seen in the code excerpt above, so an attacker holds some control over the fragments’ size as well.
3. A second request is performed to a different service, and the continuation state from the previous response will be prepended to this request. This second search request will be of a service that will return a smaller response size than the previous response - and this will lead to the described state confusion.
4. A validation of cont_offset will be attempted, but it will pass successfully (since the same cont_offset was appended to the second request).
5. Due to fact num_rsp_handles in this second request is smaller than the one in the first request, an underflow of rem_handles will be achieved.
6. The code will now assume a very large response is needed - and the for-loop that follows would copy bytes from rsp_handles to an outgoing response packet.
7. From this point on, an attacker can repeat sending the same request, and prepend the returned cont_offset - continuing to read more and more out of bound bytes from rsp_handles.
Similar to the information leak vulnerability in BlueZ, this vulnerability can lead to the disclosure of a large part of the memory - in this instance from the process stack. This data can potentially include encryption keys, address space and valuable pointers (of code, or data), that can be used to bypass ASLR while exploiting a separate memory corruption vulnerability.
Remote Code Execution Vulnerability #1 (CVE-2017-0781)
This vulnerability resides in the Bluetooth Network Encapsulation Protocol (BNEP) service, which enables internet sharing over a Bluetooth connection (tethering). Due to a flaw in the BNEP service, a hacker can trigger a surgical memory corruption, which is easy to exploit and enables him to run code on the device, effectively granting him complete control. Due to lack of proper authorization validations, triggering this vulnerability does not require any user interaction, authentication or pairing, so the targeted user is completely unaware of an ongoing attack.
To be specific, the first vulnerability lies in the following call to memcpy:
For this purpose, the above code saves the remaining unparsed message for later use (in p_pending_data ). However, a simple mistake lies in this code: First the p_pending_data buffer is allocated on the heap, with size rem_len . Later, a memcpy is made to p_pending_data + 1 with the size rem_len . Thus the memcpy will overflow the buffer by sizeof (p_pending_data) bytes! One may wonder how such a mistake can go unnoticed, as it causes a heap corruption every time this code is triggered. Additionally, this causes an inherent memory leak since the previous p_pending_data pointer is never freed before another allocation occurs. It is very likely that this code did never actually run, not during real world usage, and probably not even during coverage testing.
The field p_pending_data is of type BT_HDR , which is 8 bytes long. Additionally, rem_len , which controls the size of the allocation, is under the attacker’s control, since it’s the length of the remaining un-parsed bytes in the packet, as well as the source for the memcpy ( p ) which points to the attacker-controlled packet.
Remote Code Execution vulnerability #2 (CVE-2017-0782)
This vulnerability is similar to the previous one, but resides in a higher level of the BNEP service - the Personal Area Networking (PAN) profile - which is responsible for establishing an IP based network connection between two devices. In this case, the memory corruption is larger, but can still be leveraged by an attacker to gain full control over the infected device. Similar to the previous vulnerability, this vulnerability can also be triggered without any user interaction, authentication or pairing.
Specificly, the second vulnerability also appears in a flow that occurs under bnep_data_ind . This one lies in the following integer underflow of rem_len in the function bnep_process_control_packet :
The integer rem_len is defined as a 16-bit unsigned short and represents the actual amount of remaining unparsed bytes in an attacker-controlled packet. The value of e xt_len is 8 bits unsigned, and is part of the extension header that is also attacker-controlled. Thus a proper rem_len can suddenly be underflowed to almost any value above 0xff00, making any further handling of the packet that depends on rem_len unsafe.
In the bnep_data_ind code, after the call to bnep_process_control_packet , the (now unsafe) rem_len is indeed used in a dangerous way:
Immediately after, a call to bnep_cb.p_data_ind_cb (an upper layer handling callback) occurs with the malformed p_buf as input. It’s thus possible to reach the following code path using the crafted packet:
As expected, there are no good checks on offset and len at this point. The only check here verifies that offset is smaller than size of( tBTA_PAN_DATA_PARAMS ) (that is 24), which is not a problem. The osi_malloc, however, allocates a buffer p_new_buf of size PAN_BUF_SIZE (which is 4096) and the memcpy copies p_buf -> len bytes into it, which were caused to become 0xffff earlier. In short, this results in an overflow of 0xf000 bytes on the heap, following a 4096 bytes sized buffer.
The source bytes of the overflowing memcpy are not under direct control of the attacker, as they exceed the boundaries of the original packet by far. However, since they are copied from the same area on the heap as the original packet, it should be trivial to create a heap-spray (in advance) since the bytes of the received packets are indeed attacker-controlled. As a result, grooming of the heap prior to the overflow can allow this vulnerability to cause remote code execution.
Man-in-The-Middle (MiTM) attacks allow the attacker to intercept and intervene in all data going to or from the targeted device. To create a MiTM attack using Wi-Fi, the attacker requires both special equipment, and a connection request from the targeted device to an open WiFi network. In Bluetooth, the attacker can actively engage his target, using any device with Bluetooth capabilities. The vulnerability resides in the PAN profile of the Bluetooth stack, and enables the attacker to create a malicious network interface on the victim's device, re-configure IP routing and force the device to transmit all communication through the malicious network interface. This attack does not require any user interaction, authentication or pairing, making it practically invisible.
Comments
Post a Comment