As you know, operating systems are developed by people. Some people, however, are confident that Android created reptilians, but this is not true: many errors were found in the Google mobile platform, which could only be made by representatives of the homo sapiens species. Some of these bugs are full of vulnerabilities and can be used for unauthorized access to the file system of the smartphone, and for the spread of malware.
If check the official statistics of Google, today among the versions of Android, the most common is Nougat – the editors of the mobile platform number 7.0 and 7.1 are set to 28.2% of devices in aggregate.
The second position is confidently occupied by Android 8.0 and 8.1 Oreo with a rate of 21.5%. In third place, the sixth version of Marshmallow is fixed – it works on 21.3% of devices. Android 5.0 and 5.1 Lollipop installed a total of 17.9% of devices, and closes the group of leaders Android 4.4 KitKat with an indicator of 7.6% of users.
According to information from the site cvedetails.com, today Android has 2146 vulnerabilities, and the number of detected bugs has begun to grow exponentially around 2014.
According to information from the site cvedetails.com, today Android has 2146 vulnerabilities, and the number of detected bugs has begun to grow exponentially around 2014.
It is not so easy to estimate how many of the listed devices received security patches in time, which cover vulnerabilities, but this is by no means all of them.
Moreover, not all vulnerabilities are generally closed, especially in older versions, official support for which has been discontinued. The problem is exacerbated by device manufacturers, who are often in no hurry to release updates.
The very first Android vulnerability was discovered back in October 2008 in the firmware of the communicator HTC T-Mobile G1. When browsing web pages with specific content, an error in the software made it possible to execute malicious code that tracks the use of the keyboard of the gadget.
The very first Android vulnerability description:
Theoretically, in this way, it was possible to implement a keylogger that captures keystrokes, and collect information entered by the user when surfing the web. This vulnerability posed a danger only for a single model of the communicator, but its very presence clearly showed that Android is not as secure and protected as previously thought.
With the increasing popularity of the operating system, enthusiasts and researchers have searched for more and more new bugs in its various versions.
Extra field
CVE: no
Vulnerable versions of Android: 2.3, 4.0, 4.1, 4.2, 4.3, 4.4
For operation required: modified application
Possible result: arbitrary code execution
All Android applications are distributed in the .APK format and are a ZIP archive with the difference that they have a special digital signature. Inside there are the components necessary for the operation, which are extracted during the installation of the application, and their checksums are checked against reference values.
With the help of the Extra Field vulnerability, an attacker can change the contents of the APK installation package without damaging his digital signature.
Inside the .APK archive is the classes.dex file, which contains the compiled application code and a set of utility fields. Among them are:
- the field that stores the file name with the extension
- file size
- an Extra Field field in which the executable code itself is recorded
- table with a list of classes used by it
If the initial value is written in the header field without the first three bytes, the Extra Field length value also changes, making it possible to add an arbitrary code there, for example, to list the classes used by the Trojan part of the application.
After that, you can add to the archive, in addition to the original classes.dex, its malicious copy, part of the code of which will be stored in the “extended” Extra Field of the original classes.dex. When the program is installed, the system will read the contents of the modified fields, and since they list the classes from the modified classes.dex, this file will be installed on the device.
Thus, the vulnerability allows the Trojan to be “hooked” into any legitimate application with a valid digital signature, except that the size of the malicious module will be limited to the maximum size of the classes.dex file of 65,533 bytes. The vulnerability was discovered in early July 2013 and was eliminated in Android versions released after this date.
BlueBorne
CVE: CVE-2017-1000251, CVE-2017-1000250, CVE-2017-0781, CVE-2017-0782, CVE-2017-0785 and CVE-2017-0783
Vulnerable versions of Android: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0
Operation requires: the attacker must be within ten meters from the vulnerable device, and Bluetooth must be enabled on the vulnerable device
Possible result: execution of arbitrary code with privileges of the system kernel, data leakage
This is not a separate vulnerability, but a whole set of bugs in the Bluetooth stack of modern operating systems, including Android. Serious bugs are contained in the code of the l2cap_parse_conf_rsp system kernel of the Linux kernel, and they can be found in all versions of the kernel, starting with 3.3. If the system has CONFIG_CC_STACKPROTECTOR stack overflow protection enabled, their use leads to a critical error in the kernel.
Vulnerability CVE-2017-1000251 is revealed in a kernel module called L2CAP, which is responsible for the operation of the Bluetooth protocol stack. Another vulnerability in the stack of this protocol was designated CVE-2017-0783.
If the Bluetooth subsystem is enabled on the attacked device, they can be used to remotely transfer information packets to it in a special way. Such packages may contain malicious code that runs on Android with kernel privileges of the system. At the same time for the implementation of the attack does not need to pre-interface the device or enable them to detect mode. It is enough that the attacker was at a distance of no more than ten meters from the vulnerable device.
Since the OS components interacting with the Bluetooth protocol have high system privileges by default, exploiting these vulnerabilities theoretically allows you to gain complete control over the attacking smartphone and tablet, including access to data stored on the device, connected networks and the file system. Also, using BlueBorne, it is technically possible to implement man-in-the-middle attacks.
BlueBorne also includes the CVE-2017-1000250 vulnerability in the BlueZ stack of the Linux-based implementation of the Service Discovery Protocol (SDP). Operating the CVE-2017-1000250 vulnerability could lead to data leakage.
Vulnerabilities CVE-2017-0781, CVE-2017-0782 and CVE-2017-0785 relate to the Android OS itself, with the help of the first two malicious applications can get kernel privileges in the system, and the latter allows you to implement data leakage.
To eliminate the vulnerabilities of BlueBorne, on September 9, 2017, Google released a security update. Also, they are not afraid of devices that use the Bluetooth Low Energy mode.
Janus
CVE: CVE-2017-13156
Vulnerable versions of Android: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2
For operation required: modified application
Possible result: installation and launch of a malicious application, data leakage
Another vulnerability, number CVE-2017-13156, operating with digital signatures of Android applications, it is only relevant for more recent versions of the operating system – 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1 and 7.1.2. Using Janus, you can embed an executable .dex file into the .APK archive, while maintaining the original digital signature of the application.
The hole lies in the JAR-based digital signature verification system, which was replaced by the Signature Scheme v2 technology in Android 7.0. Nevertheless, even in the seventh and partly the eighth generation of Android vulnerability can use old applications that do not use the new verification method, as well as some programs that are not downloaded from the official Google Play catalog.
OpenSSLX509Certificate
CVE: CVE-2015-3837
Vulnerable versions of Android: 4.3–5.1
For operation required: a special application or application module
Possible result: execution of arbitrary code with system privileges
OpenSSLX509Certificate, CVE-2015-3837, is vulnerable to Android versions 4.3 through 5.1 inclusive. With this bug, you can enhance the privileges of the malicious process.
Error in the system component OpenSSLX509Certificate allows you to compromise the system process system_server and run any code with system privileges (UID 1000). Thus, you can, for example, replace any previously installed application (except OS components), saving another program instead.
Cloak and dagger
CVE: CVE-2017-0752
Vulnerable versions of Android: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2
For operation required: an application with the permissions SYSTEM_ALERT_WINDOW and BIND_ACCESSIBILITY_SERVICE
Possible result: keystroke recording (keylogging), data leakage
This vulnerability is relevant for Android up to 7.1.2. Due to an error in the SDK, a malicious application, using the permissions SYSTEM_ALERT_WINDOW and BIND_ACCESSIBILITY_SERVICE, can get almost complete control over the operating system and access to the user’s confidential information, as well as capture keystrokes. Hacker has already written in detail about this vulnerability, and the experts who discovered it even created a special website about it.
In short, the bottom line is that the SYSTEM_ALERT_WINDOW permission allows you to display a “system window” – a View-element that appears on top of any other interface element, even if it is an Activity from a third-party application. At the same time, the overlapped Activity will not know about it and will continue to work as if nothing had happened. Any application can do this if the SYSTEM_ALERT_WINDOW permission is stated in its manifest.
By placing several “invisible” system windows on top of each other and processing clicks on them, an attacker can create a keylogger. And with the help of the BIND_ACCESSIBILITY_SERVICE permission, the malicious program is able to gain access to other OS objects and data stored on the device.
SIM Toolkit
CVE: CVE-2015-3843
Vulnerable versions of Android: 5.1
For operation required: a special application or application module
Possible result: interception and substitution of commands sent by the SIM card to the operating system
Android has a built-in SIM Application Toolkit (STK) framework, which allows a SIM card to execute a certain set of commands in the system. Thus, in particular, the operator’s SIM-menu is formed.
The vulnerability allows you to intercept commands sent by the SIM card to the operating system, as well as replace them. A malicious application can pass a specially created parcelable object to the com.android.stk.StkCmdReceiver class. The recipient does not verify the authenticity of the sender, and the action android.intent.action.stk.command is not declared as protected in the manifest, so you can emulate sending commands by the SIM card.
For example, if the SIM card generates a message on the device screen confirming user actions, it will contain an OK button. Such messages are used to confirm the sending of USSD requests, transactions, actions with contacts stored on the card, and so on.
The malicious application can trigger the android.intent.action.stk.command action and display on the screen over this a fake window containing arbitrary text. When you click the OK button, the sendResponse () method is called with the true flag, and this event — the button click — is transmitted to the SIM card waiting for the user to respond. In this case, the event will be processed as if it came from this dialog box.
