Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to carry out the early warning analysis of Janus Android signature loopholes. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Background introduction of 0x00

GuardSquare reported a signature vulnerability to Google on July 31, 2017 and received a confirmation on the same day. Google fixed the vulnerability this month under the serial number CVE-2017-13156.

Through 360CERT analysis, it is confirmed that the problem does exist and the impact is serious. An attacker can bypass the signature verification mechanism to construct a malicious program to update the original program.

Overview of 0x01 events

The root cause of this vulnerability is that only the APK part of the file is verified when the signature is verified after splicing the DEX file and APK file, but the DEX part of the file is executed by the virtual machine, which leads to the occurrence of the vulnerability. Because of the duality of both APK file and DEX file, the vulnerability is named Janus vulnerability due to the duality of Janus, the god of Roman duality.

0x02 event impact

Affects all versions of Android5.0-8.0 and APK files signed with Android V1.

0x03 event details

1. Technical details

Android supports two application signature schemes, one is based on JAR signature scheme (v1 scheme), and the other is APK signature scheme v2 (v2 scheme) introduced in Android Nougat.

The v1 signature does not protect some parts of APK, such as ZIP metadata. The APK validator needs to deal with a large number of untrusted (unverified) data structures, and then discards data that is not protected by signatures. This can lead to a considerable area of attack. In addition, the APK validator must extract all compressed entries, which takes more time and memory. In order to solve these problems, APK signature scheme v2 is introduced into Android7.0. During verification, the v2 scheme treats the APK file as Blob and checks the signature of the entire file. Any changes made to APK, including changes to ZIP metadata, invalidate the APK signature. This form of APK validation is not only much faster, but also can detect a variety of unauthorized modifications.

It will not affect if developers only check V1 signature, but the more secure V2 signature verification method will not be used on 7.0; only V2 signature below 7.0 cannot be installed normally, and V2 verification will be used if V2 signature is above 7.0; if V1 and V2 are checked at the same time, all models will be fine. The problem this time is the V1 signature scheme. To put it simply, a new file is constructed before attaching the modified dex file to the V1 signed apk file. The V1 scheme only verifies the apk part of the new file, while the virtual machine executes only the dex part of the new file according to the magic header.

Let's take a look at the published principles of POC (https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156)). Janus.py accepts dex files and apk files as input and combines them for output.

Read the dex file:

Read the apk file:

Apk is actually a zip. In a nutshell, the zip file format consists of a file data area, a central directory structure, and a central directory ending section.

The end section of the central directory has a field that holds the offset of the central directory structure. The fixed closing tag x06054b50 in the code that searches for the end section of the central directory locates to the offset of the central directory structure and adds the size of the dex file because we are inserting the dex file in front of the apk.

Next, update the deHeaderOffset field in the central directory structure array, that is, the relative displacement field of the local file header. The file offset of the file data area structure of the corresponding file can be directly obtained through the deHeaderOffset field, and the compression data of the corresponding file can be obtained directly. It is also because the dex file is inserted in front, so add the size of the dex file directly.

Finally, update the file_size field in the dex section to the size of the entire dex+apk, and update the checksum and signature fields using the alder32 algorithm and the SHA1 algorithm.

Let's do a very simple test.

Write a toast that pops up Hello in the APK file, and sign with V1 signature scheme:

Install it on the phone:

Decompress the compiled apk to get the dex file, baksmali.jar decompiled the dex file to get the smali code, and randomly change the hello to another string:

Compile it back into a dex file with smali.jar, and package the dex file with the original apk to generate out.apk using the provided script:

Installed on the phone successfully passed the signature verification and executed the modified dex code:

If I use the V2 signature scheme on my android8.0 unpatched phone, I will not be able to update the original normal program if it is not affected by this vulnerability:

two。 Patch analysis

The patch is very simple and forces the verification of zip's frSignature:

0x04 repair recommendation

1. Developers check V2 signature scheme when developing applications

2. All manufacturers should issue patches in time to ensure that users update the system as soon as possible.

3. Users should download programs in the formal application market.

The above is the early warning analysis of Janus Android signature loopholes shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.