Anonymity Android Vulnerabilities.

[Fixxx]

The Most Dangerous Android Vulnerabilities.​

According to Google's official statistics the most widespread version of Android is Nougat - the mobile platform edition numbered 7.0 and 7.1, installed on a total of 28.2% of devices. The second position is confidently held by Android 8.0 and 8.1 Oreo with a share of 21.5%. The sixth version, Marshmallow, has secured the third place - operating on 21.3% of devices. Android 5.0 and 5.1 Lollipop are collectively installed on 17.9% of devices and Android 4.4 KitKat closes the leader group with a share of 7.6% of users. According to information from cvedetails.com there are 2146 vulnerabilities in Android to date with the number of disclosed bugs beginning to exponentially increase around 2014. It's not easy to assess how many of the listed devices have received security patches in a timely manner to close vulnerabilities but clearly not all of them. Moreover, not all vulnerabilities are closed at all (especially in older versions that no longer receive official support). The problem is exacerbated by device manufacturers who often don't rush to release updates.

The first Android vulnerability was discovered back in October 2008 in the firmware of the HTC T-Mobile G1 communicator. While browsing web pages with specific content a software error allowed the execution of malicious code that tracked the use of the device's keyboard. Theoretically, this could be used to implement a keylogger capturing button presses and collecting user-entered information during web surfing. This vulnerability posed a threat only to a single model of communicator but it's presence vividly showed that Android isn't as secure and protected a system as previously believed. With the growing popularity of the operating system enthusiasts and researchers found new and new bugs in it's various versions. Of course, within the scope of one article we cannot cover all two thousand vulnerabilities discovered throughout the existence of Android. Therefore, we will focus only on the most interesting and dangerous ones, specifically - only in the currently relevant versions of Android (those that can still be encountered in real life). The fourth generation Android turned out to be the most "holey" starting from version 4.4 KitKat.

 

[Fixxx]

Here we will start our review of vulnerabilities,
Discovered at different times in this platform...

Blue Borne

CVE: CVE-2017-1000251, CVE-2017-1000250, CVE-2017-0781, CVE-2017-0782, CVE-2017-0785 and CVE-2017-0783.
Vulnerable 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.
Exploitation requirements: the attacker must be within ten meters of the vulnerable device, and Bluetooth must be enabled on the vulnerable device.
Possible outcome: executing arbitrary code with system kernel privileges, data leakage.

This isn't a separate vulnerability but a whole set of errors in the Bluetooth stack of modern operating systems including Android. Serious bugs are contained in the code of the system function l2cap_parse_conf_rsp of the Linux kernel and they can be found in all kernel versions starting from 3.3. If the stack overflow protection CONFIG_CC_STACKPROTECTOR is enabled in the system their use leads to a critical kernel error. Vulnerability CVE-2017-1000251 is identified in the kernel module called L2CAP which is responsible for the operation of the Bluetooth protocol stack. Another vulnerability in the stack of this protocol received the designation CVE-2017-0783. If the Bluetooth subsystem is enabled on the target device these vulnerabilities can be used to remotely transmit specially crafted information packets to it. Such packets may contain malicious code that will execute in Android with system kernel privileges. Moreover, to carry out the attack it will not be necessary to previously pair devices or enable discovery mode on them. It's sufficient for the attacker to be within ten meters of the vulnerable device. Since components interacting with the Bluetooth protocol have high system privileges by default exploiting these vulnerabilities theoretically allows full control over the attacked smartphone and tablet including access to stored data, connected networks and the file system. Also with Blue Borne it's technically possible to carry out man-in-the-middle attacks. Blue Borne also includes vulnerability CVE-2017-1000250 in the BlueZ Linux implementation of the Service Discovery Protocol (SDP). Exploiting vulnerability CVE-2017-1000250 can lead to data leakage. Vulnerabilities CVE-2017-0781, CVE-2017-0782 and CVE-2017-0785 relate to the Android OS itself with the first two allowing a malicious application to gain kernel privileges in the system and the last one enabling data leakage. To address the Blue Borne vulnerabilities on September 9, 2017 Google released a security update. These vulnerabilities are also not a threat to devices using Bluetooth Low Energy mode.

Extra Field

CVE: none.
Vulnerable Android versions: 2.3, 4.0, 4.1, 4.2, 4.3, 4.4.
Exploitation requirements: modified application.
Possible outcome: executing arbitrary code.

All Android applications are distributed in the .APK format and are essentially ZIP archives with the distinction that they have a special digital signature. Inside are the necessary components for operation which are extracted during the application installation process and their checksums are verified against reference values. Using the Extra Field vulnerability an attacker can modify the content of the APK installation package without damaging its digital signature. Inside the .APK archive is the classes.dex file which contains the compiled code of the application and a set of service fields. Among them are: a field storing the file name with an extension, file size, an Extra Field field containing the actual executable code, a table with a list of classes used by them. If the original value is written in the header field without the first three bytes the length value of the Extra Field field will also change allowing the insertion of arbitrary code, for example, listing classes used by the Trojan part of the application. After that in addition to the original classes.dex a malicious copy can be added to the archive part of whose code will be stored in the "extended" Extra Field field of the original classes.dex. During the installation of the program the system will read the contents of the modified fields and since the classes from the modified classes.dex are listed there, this specific file will be installed on the device. Thus, the vulnerability allows a Trojan horse to be "planted" in any legitimate application with a valid digital signature except that the size of the malicious module will be limited by the maximum file size of classes.dex at 65,533 bytes. The vulnerability was discovered in early July 2013 and was fixed in Android versions released after that date.

Fake ID

CVE: N/A.
Vulnerable Android versions: 2.2, 2.3, 4.0, 4.1, 4.2, 4.3, 4.4.
Exploitation requirements: Application signed with a specially crafted digital signature.
Possible outcome: Installation and execution of malicious applications, data leakage.

This vulnerability was discovered in Android 2.2 and remained relevant until version 4.4. The error corresponding to this vulnerability with internal number 13678484 was primarily addressed by patches released by the device manufacturers themselves. As previously mentioned all .APK files in Android use a digital signature. The application signature may be associated with the digital signature of the program publisher. All these signatures use the Public Key Infrastructure (PKI) framework of public keys. Through the digital signature the operating system determines the capabilities and privileges of the application, with which OS components it can interact, which system functions it can use, whether it has the right to download and install updates and so on. During the application signature verification process the operating system uses the developer's program's public key. To ensure the validity of this key the corresponding certificate of the certifying authority must be verified. This is called a certificate chain verification. The vulnerability lies in the fact that earlier versions of Android didn't perform such verification during the application installation process. As a practical implementation of the vulnerability consider this example: if an application is signed with two digital certificates - genuine and fake, during its installation, a digital signature using both certificates will be created. As a result the application can, for instance, download and install malicious updates that will not be security-checked if the developer signs them with the same untrustworthy certificate.

Janus

CVE: CVE-2017-13156.
Vulnerable Android versions: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2.
Exploitation requirements: Modified application.
Possible outcome: Installation and execution of malicious applications, data leakage.

Another vulnerability identified by CVE-2017-13156 dealing with Android application digital signatures is only relevant for newer OS versions: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1 and 7.1.2. Using Janus an executable dex file can be injected into an .APK archive while retaining the original digital signature of the application. The flaw lies in the JAR-based digital signature verification system which was replaced with the Signature Scheme v2 technology in Android 7.0. However, even in the seventh and partially eighth generation of Android old applications not applying the new verification method and some programs downloaded from sources other than the official Google Play Store can exploit this vulnerability.

ObjectInputStream Serialization

CVE: CVE-2014-7911.
Vulnerable Android versions: 1.0–4.4.4.
Exploitation requirements: Special application or application module.
Possible outcome: Critical system processes crashing.

This vulnerability affecting all Android versions up to 5.0 is denoted as CVE-2014-7911. The error lies in the mechanism of verifying the serialization of received objects by the system component luni/src/main/java/java/io/ObjectInputStream. Serialization is the ability of certain objects to transform into a byte sequence from which they can later be restored to their original form (the reverse procedure is called deserialization). Serialization is typically used for data preservation, transfer to another process or transmission over a network. By exploiting the vulnerability any object with an open parameter-less constructor can be deserialized even if it doesn't meet the serialization criteria. If this object uses the finalize method, upon its removal, the garbage collector will call this method resulting in the execution of the code stored within the object. This can be used to attack Android system processes, causing them to crash, including killing critical system processes.

OpenSSLX509Certificate

CVE: CVE-2015-3837.
Vulnerable Android versions: 4.3–5.1.
Exploitation requirements: Special application or application module.
Possible outcome: Execution of arbitrary code with system privileges.

The OpenSSLX509Certificate vulnerability also known as CVE-2015-3837 affects Android versions from 4.3 to 5.1 inclusively. Through this bug the privileges of a malicious process can be escalated. The error in the system component OpenSSLX509Certificate allows compromising the system process system_server and executing any code with system privileges (UID 1000). This could, for example, replace any previously installed application (except OS components) with another program.

 

[Fixxx]

PendingIntent

CVE: CVE-2014-8609
Vulnerable Android versions: 4.0–4.4.4
Exploitation requirements: Special application or application module
Possible outcome: Execution of any command in the system

This vulnerability with CVE-2014-8609 was identified in Android 4.0–4.4.4. The error lies in the addAccount method of the AddAccountSettings.java file (located in src/com/android/settings/accounts/) which is part of the application account management subsystem. Certain Android applications may use user account data for automatic authentication in various internet services. In this scenario users only need to input their login and password once which are then registered in a special section of system settings called "Accounts" which the application accesses whenever authentication is required. When creating such an account the OS passes various parameters to the application including a PendingIntent parameter. Due to an error in the implementation of the addAccount method called during account registration the system doesn't validate the values of this field. Thus, a malicious actor can pass virtually any command into the PendingIntent which will be executed with the same privileges as the directing application "Settings" - system privileges. Commands could be crafted to delete files stored on the device or a sequence of bytes that the system interprets as an incoming SMS message. For instance, if the PendingIntent parameter receives the command android.intent.action.MASTER_CLEAR Android will obediently perform a full system reset wiping all stored information on the device.

StageFright

CVE: CVE-2015-1538.
Vulnerable Android versions: 2.2–5.1.1.
Exploitation requirements: Transmit specially crafted MP4 file to the device.
Possible outcome: Execution of arbitrary code with system privileges.

This vulnerability affects all Android versions from 2.2 to 5.1.1. The flaw was found in the Stagefright system library responsible for playing media files in MP4 format. If a specially crafted MP4 file is successfully delivered to a vulnerable device (e.g., via an MMS message) an error in the SampleTable.cpp handler within this file will execute arbitrary code embedded with system privileges even if the user simply opens the folder containing such a file.

StageFright 2.0

CVE: CVE-2015-6602.
Vulnerable Android versions: 4.1–5.1.1.
Exploitation requirements: Transmit specially crafted MP3 or MP4 file to the device.
Possible outcome: Execution of arbitrary code with system privileges.

Despite the similar name this vulnerability resides in a different component - the mediaserver application, specifically in the ID3v2 tag handler. Android versions from 4.1 to 5.1.1 are vulnerable. To exploit this vulnerability it's sufficient to deliver a specially modified MP3 or MP4 file to the targeted device. When reading the ID3v2 tags contained in such a file a buffer overflow occurs resulting in the execution of embedded arbitrary code with system privileges.

SIM Toolkit

CVE: CVE-2015-3843.
Vulnerable Android versions: 5.1.
Exploitation requirements: Special application or application module.
Possible outcome: Intercepting and altering commands sent by the SIM card to the OS.

Android includes a built-in SIM Application Toolkit (STK) framework that enables the SIM card to execute a specific set of commands within the system. This facilitates the creation of the operator's SIM menu among other functionalities. The vulnerability allows intercepting commands sent by the SIM card to the OS and altering them. A malicious application can pass a specially crafted parcelable object to the com.android.stk.StkCmdReceiver class. The receiver doesn't authenticate the sender and the action android.intent.action.stk.command isn't declared as secure in the manifest allowing the emulation of SIM card command transmissions. For example, if the SIM card displays a user action confirmation message on the device screen with an OK button such messages are used to confirm the sending of USSD requests, transactions, actions with contacts stored on the card and so forth. The malicious application can trigger the android.intent.action.stk.command action and display a fake window on top of the actual one containing arbitrary text. When the OK button is pressed the sendResponse() method is called with a true flag and this event - the button press - is transmitted to the SIM card awaiting the user's response. The event will be processed as if it came from a genuine dialog window.

ToastOverlay

CVE: CVE-2017-0752.
Vulnerable Android versions: 4.0–7.1.2.
Exploitation requirements: Application with BIND_ACCESSIBILITY_SERVICE permission.
Possible outcome: Gaining full control over TYPE_TOAST windows.

This vulnerability was discovered in 2017 and affects all Android versions from 4.0 to 7.1.2. The error was made in the overlay subsystem - windows capable of displaying on top of other screen forms. An application exploiting this vulnerability only needs to declare one permission in the manifest - BIND_ACCESSIBILITY_SERVICE. Normally, to display windows of TYPE_TOAST used for showing system notifications an application would require a SYSTEM_ALERT_WINDOW request. However, due to an error in the Android AOSP permission and operation check processing the malicious program can bypass these formalities. The component simply doesn't perform access checks when handling the SYSTEM_ALERT_WINDOW request for TYPE_TOAST. As a result, the application exploiting the vulnerability can draw its windows over other program windows without consequence and record screen touches. It gains full control over the TYPE_TOAST window and the content displayed in this window depends solely on the imagination of the malware authors.

Cloak and Dagger

CVE: CVE-2017-0752.
Vulnerable Android versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2.
Exploitation requirements: Application with SYSTEM_ALERT_WINDOW and BIND_ACCESSIBILITY_SERVICE permissions.
Possible outcome: Keystroke logging, data leakage.

This vulnerability is relevant for Android versions up to 7.1.2. Due to an error in the SDK a malicious application utilizing the SYSTEM_ALERT_WINDOW and BIND_ACCESSIBILITY_SERVICE permissions can gain almost complete control over the operating system and access to the user's confidential information as well as record keystrokes. In essence, the SYSTEM_ALERT_WINDOW permission allows displaying a "system window" on the screen - a View element that will appear above any other interface element even if it's an Activity from a third-party application. The overlaid Activities are unaware of this and continue to function as if nothing has happened. Any application can do this if the SYSTEM_ALERT_WINDOW permission is declared in its manifest. By placing several "invisible" system windows on top of each other and capturing interactions with them a malicious actor can create a keystroke logger. With the BIND_ACCESSIBILITY_SERVICE permission the malicious program can access other OS objects and data stored on the device.

Conclusion.​

As you can see, throughout the history of Android there have been many interesting vulnerabilities and in this article we have only scratched the surface - highlighting the most important, notorious and visually striking vulnerabilities. If you dig deeper you will discover many more small and large possibilities.