New vulnerability in Android allows attackers to modify applications without affecting their signatures.

A serious vulnerability (CVE-2017-13156) in Android allows attackers to change the code in applications without affecting their signatures. The root of the problem is that the file can be a valid APK file and a valid DEX file at the same time. They called him the vulnerability of Janus in honor of the Roman god of duality.

Janus Vulnerability

The vulnerability of Janus is related to the possibility of adding additional bytes to APK and DEX files. On the one hand, the APK file is a zip archive that can contain arbitrary bytes at the beginning, before its zip records (in general, between its zip records). The JAR signature scheme only considers zip entries. It ignores any extra bytes when calculating or verifying the application signature. On the other hand, a DEX file may contain arbitrary bytes at the end, after regular sections of lines, classes, method definitions, etc. Thus, the file can be a valid APK file and a valid DEX file at the same time.


')
Another key element is the seemingly innocuous feature of the Dalvik / ART virtual machine. Theoretically, the Android runtime loads an APK file, extracts its DEX file, and then runs its code. In practice, the virtual machine can load and execute both APK files and DEX files. When he receives an APK file, he still looks at the magic bytes in the header to decide what type of file it is. If it finds a DEX header, it loads the file as a DEX file. Otherwise, it downloads the file as an APK file containing a zip entry with a DEX file. Thus, it may misinterpret DEX / APK files.

An attacker can use this duality. It can add a malicious DEX file to the APK file without affecting its signature. Then, the Android runtime accepts the APK file as a valid update of the legitimate earlier version of the application. However, Dalvik VM loads the code from the attached DEX file.

Threat

Although Android apps are self-signed, signature verification is important when updating Android apps. When a user downloads an application update, the Android runtime compares his signature with the signature of the original version. If the signatures match, the Android runtime continues to install the update. The updated application inherits the permissions of the original application. Therefore, attackers can use a Janus vulnerability to mislead the update process and get unverified code with powerful permissions installed on unsuspecting users' devices.

There are several serious scenarios. An attacker could replace a trusted application with high privileges (for example, a system application) with a modified update in order to abuse its permissions. Depending on the target application, this may allow a hacker to access confidential information stored on the device, or even completely capture the device. Alternatively, an attacker could pass a modified clone of a sensitive application as a legitimate update, for example, in the context of banking or communications. A cloned application may look and behave like the original application, but introduce malicious behavior.

The zip file format is archaic and is prone to issues such as master key vulnerability and Janus vulnerability. Ambiguous mail files probably lead to similar vulnerabilities in different contexts and in different systems. The main reason is redundancy in the format. When designing data formats, protocols, data structures, and code in general, you should always strive to avoid redundancy. Any discrepancies lead to mistakes or worse.

Scope and mitigation

Any script still requires the user to install a malicious update from a source outside the Google Play store. It may be relatively easy to fool some users, because the application may still look exactly the same as the original application, and has the appropriate signature. For experts, general reverse engineering tools do not show the code entered. Users should always be vigilant when downloading applications and updates.

Janus vulnerability affects the latest Android devices (Android 5.0 and newer). Applications signed using the APK v2 subscription scheme and running on devices that support the latest subscription scheme (Android 7.0 and later) are protected from this vulnerability. Unlike the v1 scheme, this v2 scheme considers all the bytes in the APK file. Older applications and newer applications running on older devices remain susceptible. Developers should at least always use the v2 signature scheme.

Android applications that use the DexGuard unauthorized access detection mechanism are better protected from cloning attacks. The mechanism performs additional checks to ensure that the protected applications have not been modified in any way. We recommend using unauthorized access detection and other levels of DexGuard protection against reverse engineering and cloning.