Exploiting Apps vulnerable to Janus (CVE-2017–13156)
CVE-2017–13156
A serious vulnerability in Android allows attackers to inject a DEX file into an APK file without affecting the signatures. (i.e. modify the code in applications without affecting their signatures.)
This can be exploited due to the problem, that a Android Package file can be a valid APK file and a valid DEX file at the same time.
This problem was named as Janus, after the Roman god of duality.
Janus vulnerability
Janus vulnerability comes from the possibility to add extra bytes to APK files and to DEX files.
On the one hand, an APK file is a zip archive, which can contain arbitrary bytes at the start, before its zip entries (actually more generally, between its zip entries).
The JAR signature scheme only takes into account the zip entries. It ignores any extra bytes when computing or verifying the application’s signature.
On the other hand, a DEX file can contain arbitrary bytes at the end, after the regular sections of strings, classes, method definitions, etc. A file can, therefore, be a valid APK file and a valid DEX file at the same time.
In theory, the Android runtime(ART) loads the 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.
i.e. When it gets an APK file, it still looks at the magic bytes in the header to decide which type of file it is. If it finds a DEX header, it loads the file as a DEX file. Otherwise, it loads the file as an APK file containing a zip entry (A zip entry is a representation of each file in a zip file) with a DEX file. It can thus misinterpret dual DEX/APK files.
Exploitation
An attacker can leverage this duality. He can prepend a malicious DEX file to an APK file, without affecting its signature. The Android runtime then accepts the APK file as a valid update of a legitimate earlier version of the app. However, the Dalvik VM loads the code from the injected DEX file.
Consequences
Although Android applications are self-signed, signature verification is important when updating Android applications.
When the user downloads an update of an application, the Android runtime compares its signature with the signature of the original version. If the signatures match, the Android runtime proceeds to install the update.
The updated application inherits the permissions of the original application. Attackers can, therefore, use the Janus vulnerability to mislead the update process and get unverified code with powerful permissions installed on the device of unsuspecting users.
One can imagine a few severe scenarios. An attacker can replace a trusted application with high privileges (a system app, for instance) by a modified update to abuse its permissions.
Depending on the targeted application, this could enable the hacker to access sensitive information stored on the device or even take over the device completely.
Alternatively, an attacker can pass a modified clone of a sensitive application as a legitimate update, for instance in the context of banking or communications. The cloned application can look and behave like the original application but inject malicious behavior.
Affected Versions
Currently there are 4 different signature schemes v1-v4.
Janus affects Android devices (Android 5.0 < 8.1) when signed with v1 signature scheme.
Applications that have been signed with APK signature scheme v2 and that are running on devices supporting the latest signature scheme (Android 7.0 and newer) are protected against the vulnerability.
Android patch 2017 December 01 was released to fix the vulnerability on lower Android versions.
Unlike scheme v1, this scheme v2 considers all bytes in the APK file. Older versions of applications and newer applications running on older devices remain susceptible. Developers should at least always apply signature scheme v2.
Practical Exploitation
- In brief, Application that are signed only with v1 when installed on devices having android version(5.0–8.0) are vulnerable to Janus Vulnerability.
- Application that are signed with v1 and also v2, v3 or both when installed on devices having android version(5.0–7.0) are vulnerable to Janus Vulnerability.
- To exploit this vulnerability we need to have a device running vulnerable version of android and android patch level should be less then 2017 December 01.
For now, let us use manual approach to exploit the vulnerability. At the end of the article, i’ve made a small script to automate the exploitation process.
For demo, We will be using a simple browser application called as H5(click here to download the apk).
According to this,
In brief, Application that are signed only with v1 when installed on devices having android version(5.0–8.0) are vulnerable to Janus Vulnerability.Let us start by finding out the signature schemes used to sign the H5 application which we downloaded earlier.
We use apksigner tool to find the signature schemes used by the application
apksigner verify -verbose h5.apk
As we can see that apk has been signed only with v1, no v2 or v3 signature scheme has been used to sign the application, we will use this application to exploit the Janus vulnerability.
Before that we need to make sure that this application can be made to run on vulnerable Android versions 5.x, 6.x, 7.x & 8.0(i.e., api level 21–26).
let us use apktool to find the min android version on which we can run this application “apktool -s d h5.apk && cat h5/apktool.yml | grep minSdk ”.
Application can be run on API Level 15(Android 4.0.4 Ice Cream Sandwich), so we can choose any device from 5.x, 6.x, 7.x & 8.0 to exploit it.
According to Janus Vulnerability:
A serious vulnerability in Android allows attackers to inject a DEX file into an APK file without affecting the signatures.So we need a dex to inject into our vulnerable application, so lets download any apk (i took whatsapp, you can choose) from here. And extract classes.dex file from the whatsapp.apk using “apktool -s d WhatsApp.apk && mv WhatsApp/classes.dex .”
Now, we have classes.dex file from whatsapp and h5 our target application.
To Inject this classes.dex file into our h5 application, we use this exploit code from VEO’s repo. Copy the code and create new file named janus.py and paste into it.
Use VEO’s exploit code to inject dex file into apk “python janus.py classes.dex h5.apk kal-h5.apk”
Now, we will see how this h5 browser looks like before exploiting it. I am using Android 8.0 as my vulnerable device to install the h5 application. “adb install h5.apk”
We have seen how our vulnerable application looks like, now let us update the application with our injected apk. we can directly install the update using adb “adb install -r kal-h5.apk” or manually by copying the injected apk into sdcard.
from mobile, open file manager, goto sdcard and click on kal-h5.apk
Click install, to install the update and select “Open”.
We have successfully exploited the h5 application. “h5" is crashed, because we injected dex file of whatsapp into h5 and h5 doesn’t understand how to use it.
we can extract the dex file of target application, modify it and can inject back into the application to see the changes we have made.
NOTE:We have created a small script to automate the entire process and is hosted on this GitHub repoAnd POC video clip is also available using the script we created in the repo.
Brief on Janus exploitation
NOTE:
1) On device running android version 5.X & 6.X, Apk signature was verified using only v1 scheme
Janus vulnerability was found in v1 signing scheme and google released a patch on 2017 December 01 to fix Janus on these android versions.
so even though apk is signed only with v1 which can be run on 5.x & 6.x, if 2017 December 01 patch is installed in the device Janus cannot be exploited.2) After releasing the patch for Janus, Google released v2 signing scheme and prioritized device to use v2 scheme over v1 scheme if v2 was used along with v1 scheme but they did not integrate the patch into the system until android 8.1.
This made possible to exploit Janus on android 7.x & 8.0 also, as long as 2017 December patch is not installed.3) Applications signed with v2 or v3 along with v1 are also vulnerable to Janus if they are made to run on android versions 5.x & 6.x as it verifies only v1 scheme without installing the patch.4) Finally v1 scheme was removed and V4 scheme has been introduced in Android 11, Applications that are only signed with v1 scheme will not run on Android 11
