Android uncovers master-key Vulnerability Analysis

0x00 background

The CTO of Bluebox, Jeff Forristal, reported a vulnerability in his official blog called the uncovering android master key, which generally does not tamper with the signature to modify the android code.

Link: http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/

Blog: I didn't talk too much about the details. Only discrepancies in how Android applications are cryptographically verified & installed (Android applications should use signature verification and install them differently) essentially allowing a malicous author to trick Android into believing the app is unchanged even if it has been (LET the andriod system think it should be modified) These two important information.

The rest shows a map for changing the baseband string:

Specific details of the release of blackhat at the end of July.

On October 21, July 8, A poc was released outside China. Rayh4c said it was done on Weibo. I analyzed it.

0x01 analysis

Before POC came out, I first checked the android signature mechanism and installation mechanism.

Signature mechanism: In simple terms, android implements sha1 (irreversible) signatures for all files in the app, and uses RSA (asymmetric encryption algorithm) for the signature) the private key is encrypted, and the client uses the public key for decryption during installation and verification.

Logically, this signature mechanism is completely correct for integrity and uniqueness verification. Many mainstream encryption methods are similar.

Installation mechanism:

The installation mechanism is complicated.

1. system application installation-completed at boot, no installation interface 2. download and install the application over the Internet-the application is installed through the market application. No installation interface is available. 3. install the ADB plugin tool-no installation interface. 4.3when installing the SDK, you can install the SDK packageinstaller.apk on the installation interface.

Installation Process: copy the APK installation package to the data/app directory, decompress and scan the installation package, and save the dex keystore file (Dalvik bytecode) to the dalvik-cache directory, and create the corresponding secret data directory under the data/data directory.

We can see that there is a high possibility of problems with the installation mechanism.

Looking back at the foreigner POC: https://gist.github.com/poliva/36b0795ab79ad6f14fd8

In linux, the error occurs after the command is executed again. This may be the reason for apk.

Simply port the poc to windows. First, the producer uses apktool to decompile the apk to a directory named apk_test.

Then the producer packs apk_test into a new apk.

Decompress the original apk to apk_old

Add all the snapshot files of apk_old to the new apk in zip compression mode. We use weibo.apk as an example:

It can be seen that the size of the two has changed, and apktool is inevitably different in The Decompilation process. The re-compiled apk does not contain signature files.

According to the pocmethod, I modified the poc. py file name from the Batch Processing Guide to 1.txt.

import zipfileimport sysf=open('1.txt','r')line=f.readline()test=[]while line:    test1=line.replace("\n","")    test.append(test1)    if not line:        break    line=f.readline()f.close()z = zipfile.ZipFile("livers.apk", "a")for i in range(0,len(test)):    print test[i]    z.write(str(test[i]))z.close()

It is almost doubled. It is installed on your mobile phone and successfully installed. View:

Multiple pairs of files with the same name appear. CRC verification is different. Check that two bytes are different.

Here, I tested to add only signature files or dex files, and none of them can pass verification.

It can be proved that the scan list does not properly process files with the same name when scanning directories or copying files.

0x02 Verification

Verify whether the source code can be changed and the native signature can be used. I changed the apk icon.

By the way, General decompilation changes:

1. decompile apktool or other tools including smalijava bytecode assembly and xml image files. 2. Decompress apkzip. 3. decompile dex into a java file. 4. Find the modified smali file or xml (AD link). 5. Package Apktool into an apk file. 6. Use autosign to sign the file. The original signature is not directly used for signature.

0x03 find the root cause

I downloaded the android 2.2 source code here and found the installation location where the obtained signature information is located.frameworks\base\core\java\android\content\pm\PackageParser.javaThis file,public boolean collectCertificates(Package pkg, int flags)Andprivate Certificate[] loadCertificates(JarFile jarFile, JarEntry je, byte[] readBuffer)This method is used to obtain signature information.

 Enumeration entries = jarFile.entries();            while (entries.hasMoreElements()) {                JarEntry je = (JarEntry)entries.nextElement();                if (je.isDirectory()) continue;                if (je.getName().startsWith("META-INF/")) continue;                Certificate[] localCerts = loadCertificates(jarFile, je,                        readBuffer);            。。。。。。                } else {                    // Ensure all certificates match.                    for (int i=0; i<certs.length; i++) {                        boolean found = false;                        for (int j=0; j<localCerts.length; j++) {                            if (certs[i] != null &&                                    certs[i].equals(localCerts[j])) {                                found = true;                                break;                            }                        }

The black box method is used to infer that the installation mechanism is to process the renamed file at the same time, but not overwrite the file:

if (certs[i] != null &&certs[i].equals(localCerts[j])) {    found = true;    break;} 

Both duplicate files have been verified. If one of them passes the verification, the verification is returned.

0x04 successor

I have not studied much about android. Most of them used to play reverse games. You can discuss it more. You are welcome to leave a message for discussion ~!

==================================

Updated at on March 31, July 11:

I did not see the hot topics discussed in the snow. I have read the Principle Analysis of zmworm from the snow. It should be more accurate.

Brief Introduction to Principle

Because the ZIP format allows two or more identical paths, Android does not consider this scenario.

In this case, the android package manager verifies that the signature is the hash of the last file, while the dex file loaded by running the APK is the first dex file in zip. Zookeeper

The package manager verifies the signature of the last file (with the same name.

1. parse all the entries in the zip file and save the result to HashMap (the key is the path and the value is the Entry ).

2. Because HashMap. put updates the value with the same key, the above HashMap must be stored as the Entry of the last file in the same path.

The indexing system loads the dex file, which is the first dex file. Zookeeper

Using keys 1. dexZipFindEntry is used to find dex entries. Bytes

2. The implementation of dexZipFindEntry is that only match is returned, so the first file is returned.

Zip can contain two files or paths with the same name. The default unzip mode is to overwrite the previous one.

HashMap. put should be written in a way that should directly overwrite the file (if the hash table conflicts are not properly handled, a major problem occurs). This is in line with the zip standard.

The method of loading dex is to load the first one first, so that the information is indeed inconsistent.

I have tested the black box before and thought that android loads both of them in the order of signature verification by default. The above class is not analyzed.

On the snow, I also discussed many posts to get an accurate analysis of the principles. We will discuss them together and brainstorm. Hack it, know it too.