Vulnerabilities > CVE-2017-13156 - Unrestricted Upload of File with Dangerous Type vulnerability in Google Android
Attack vector
LOCAL Attack complexity
LOW Privileges required
LOW Confidentiality impact
HIGH Integrity impact
HIGH Availability impact
HIGH Summary
An elevation of privilege vulnerability in the Android system (art). Product: Android. Versions: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0. Android ID A-64211847.
Vulnerable Configurations
Part | Description | Count |
---|---|---|
OS | 7 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Accessing Functionality Not Properly Constrained by ACLs In applications, particularly web applications, access to functionality is mitigated by the authorization framework, whose job it is to map ACLs to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application or can run queries for data that he is otherwise not supposed to.
- Privilege Abuse An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources. If access control mechanisms are absent or misconfigured, a user may be able to access resources that are intended only for higher level users. An adversary may be able to exploit this to utilize a less trusted account to gain information and perform activities reserved for more trusted accounts. This attack differs from privilege escalation and other privilege stealing attacks in that the adversary never actually escalates their privileges but instead is able to use a lesser degree of privilege to access resources that should be (but are not) reserved for higher privilege accounts. Likewise, the adversary does not exploit trust or subvert systems - all control functionality is working as configured but the configuration does not adequately protect sensitive resources at an appropriate level.
Exploit-Db
id | EDB-ID:47601 |
last seen | 2019-11-08 |
modified | 2019-11-08 |
published | 2019-11-08 |
reporter | Exploit-DB |
source | https://www.exploit-db.com/download/47601 |
title | Android Janus - APK Signature Bypass (Metasploit) |
Metasploit
description | This module exploits CVE-2017-13156 in Android to install a payload into another application. The payload APK will have the same signature and can be installed as an update, preserving the existing data. The vulnerability was fixed in the 5th December 2017 security patch, and was additionally fixed by the APK Signature scheme v2, so only APKs signed with the v1 scheme are vulnerable. Payload handler is disabled, and a multi/handler must be started first. |
id | MSF:EXPLOIT/ANDROID/LOCAL/JANUS |
last seen | 2020-06-12 |
modified | 2019-11-06 |
published | 2019-08-23 |
references | |
reporter | Rapid7 |
source | https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/android/local/janus.rb |
title | Android Janus APK Signature bypass |
Packetstorm
data source | https://packetstormsecurity.com/files/download/155189/janus.rb.txt |
id | PACKETSTORM:155189 |
last seen | 2019-11-08 |
published | 2019-11-07 |
reporter | h00die |
source | https://packetstormsecurity.com/files/155189/Android-Janus-APK-Signature-Bypass.html |
title | Android Janus APK Signature Bypass |
Seebug
bulletinFamily | exploit |
description | A serious vulnerability (CVE-2017-13156) in Android allows attackers to modify the code in applications without affecting their signatures. The root of the problem is that a file can be a valid APK file and a valid DEX file at the same time. We have named it the Janus vulnerability, after the Roman god of duality. ### Janus vulnerability The Janus vulnerability stems 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. ![](https://images.seebug.org/1512958000633) Another key element is a seemingly harmless feature of the Dalvik/ART virtual machine. In theory, the Android runtime 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. 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 with a DEX file. It can thus misinterpret dual DEX/APK files. 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. ### Threats 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 devices 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. The zip file format is archaic and prone to problems like the Master Key vulnerability and this Janus vulnerability. Ambiguous zip files likely give rise to similar vulnerabilities in different contexts and on different systems. The root cause is redundancy in the format. When designing data formats, protocols, data structures and code in general, one should always strive to avoid redundancy. Any discrepancies lead to bugs or worse. ### Scope and mitigation We have created a simple internal tool to create Janus applications as a proof of concept. At this time, we have not seen any such applications in the wild. Any scenario still requires the user to install the malicious update from a source outside the Google Play store. It may be relatively easy to trick some users because the application can still look exactly like the original application and has the proper signature. For experts, the common reverse engineering tools do not show the injected code. Users should always be vigilant when downloading applications and updates. The Janus vulnerability affects recent Android devices (Android 5.0 and newer). 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. 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. Android applications using [DexGuard](https://www.guardsquare.com/dexguard)'s tamper detection mechanism are better hardened against cloning attacks. The mechanism performs additional checks to make sure the protected applications have not been modified in any way. We recommend the use of tamper detection and DexGuard's other layers of protection against reverse engineering and cloning. ### Disclosure and resolution We have reported this issue to Google on July 31, 2017, and received acknowledgment the same day. Google has released a patch to its partners in November. They have published the bug (CVE-2017-13156) in the [Android Security Bulletin](https://source.android.com/security/bulletin/2017-12-01) on December 4, 2017. |
id | SSV:96956 |
last seen | 2017-12-25 |
modified | 2017-12-11 |
published | 2017-12-11 |
reporter | Root |
source | https://www.seebug.org/vuldb/ssvid-96956 |
title | New Android vulnerability allows attackers to modify apps without affecting their signatures(CVE-2017-13156) |
The Hacker News
id | THN:F6C4A3E667EA7E2DC245D873F1C57018 |
last seen | 2018-01-27 |
modified | 2017-12-09 |
published | 2017-12-08 |
reporter | Mohit Kumar |
source | https://thehackernews.com/2017/12/android-malware-signature.html |
title | Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures |