Android "Parasitic beast" vulnerability technical analysis

I. About the app's cache code

Android app apk file is a zip compressed file, the APK file contains the Classes.dex file equivalent to the app's executable file, when the app is running, the system will optimize the Classes.dex, generate the corresponding Odex format files .

The Odex file is equivalent to the cached code of the app's executable file, and the system-generated Odex file is stored in the /data/dalvik-cache directory when the Android system is first loaded to run the APK.

:

You can see that the files in this directory only have write permissions for the system user, and you can write to the Odex file only if you have system permissions.

two. Popular plug-in mechanism

Because the upgrade of Android application needs to reinstall the program, frequent upgrade to the user experience and development has brought inconvenience, so the market app has started to use plug-in mechanism, using plug-in mechanism can be seamlessly upgraded and extended functionality, the app only need to introduce the corresponding plug-in files can be added or upgraded, No need to reinstall the program.

The implementation of the app plug-in mechanism is to write the relevant functions into a separate apk or jar file, and then dynamically load with Dexclassloader while the program is running, making reflection calls. Let's take a look at the definition of Dexclassloder

 Public Dexclassloader (String Dexpath, String optimizeddirectory, String LibraryPath, ClassLoader parent) Dexpath: is the jar to be loaded /apk path optimizeddirectory: path to target Odex LibraryPath: dependent native library (so file) path Parent: Parents loader

The following is a common code snippet that calls Dexclassloader

String Dexpath = environment.getexternalstoragedirectory () + File.separator +  "Output.jar" This  newnullthis. getClassLoader ());

As shown, the drozer.apk plug-in is called Drozer.dex cache file, note that Dex is the Odex format, and this directory is the private directory of the app.

three. Attack points introduced by the plug-in mechanism

In 2013, foreign MWR Labs gave an attack case of using an intermediary to hijack the app upgrade plugin, referring

https://labs.mwrinfosecurity.com/blog/2013/11/20/applovin-ad-library-sdk-remote-command-execution-via-update-mechanism/

A few years ago, most of the plug-in app, before loading the plug-in file integrity check, resulting in the hacker can be hijacked by the intermediary to replace the app's upgrade plug-in, embedded in the plug-in malicious code control user's app and phone.

Today, most apps that use plug-ins have enhanced security, such as apps that were first developed using plug-ins, which verify the signature of plug-in files before they can be downloaded using plugins, and hackers can't replace plug-in attacks with middlemen.

four. Plug-in mechanism new attack point

Recently, foreign NowSecure company announced a loophole of Samsung input method, using the process to replace the system app's Odex cache code directly. Reference: https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/

Samsung Input method is the system with the highest level of privileges, you can directly replace any app cache files. is the Android app plugin's cache code as arbitrary as the cache code generated directly by the app's main program?

We went to the Android source code to verify that, through the Dexclassloader () load jar/apk file, eventually through the native Interface opendexfilenative () into the native layer.

Corresponds to the dalvik_dalvik_system_dexfile_opendexfilenative in Android-4.2.2_r1/dalvik/vm/native/dalvik_system_dexfile.cpp () method, in the native layer to do a series of validation of several parameters, if the second parameter is detected to specify the Odex file exists, it will call Dvmopencacheddexfile () directly open, the code at the call is as follows:

1 fd = dvmopencacheddexfile (fileName, Cachedname,2 dexgetzipentrymodtime (&  Archive, entry),3 dexGetZipEntryCrc32 (&Archive, entry),4/*  createifmissing=*/true);

It is obvious that the 3 and 4 parameters correspond to the time stamp and CRC checksum value of the Classes.dex before optimization. Will eventually call

true, Modwhen, CRC, Expectverify, Expectopt)

If the CRC, the Modwhen parameter is correct, the file handle of the Odex is returned, and if the CRC, Modewhen checksum error, attempt to delete the wrong odex and rebuild the new Odex. Therefore, if the attacker wants to inject the target Odex, the modified Odex file's CRC and Modwhen will need to be modified.

The following is a modified Odex file instance, Dex_old is the modified Odex file, Dex_new is the modified Dex file, two files md5 different, but CRC and Modwhen is the same, This allows you to bypass the Dexclassloader checksum .

Five. The real harm of the "parasitic beast" loophole

The code caching mechanism of the Android app is that the program will load the running cache code when it executes, while Google only makes the weak checksum of the cached code that can be forged , which is obviously a serious breach of the security architecture implementation.

The vast majority of app developers in the use of plug-in mechanism to develop the app can do the integrity of the plug-in files, and the system generated cache code is not effective protection, once the attacker injected malicious code into the cache code, the developer of the app plug-in file protection will be invalidated . This kind of attack is difficult to detect, even after the shutdown, the malicious code will run as soon as the app is running, and the security software is almost zero in checking and defending the piece.

Six. In the real world "Parasitic beast" loophole Attack Cases

(1) Overwrite cache code with ZIP decompression vulnerability

In the use of Samsung Input Method vulnerability, the author used the zip decompression vulnerability under Android, the vulnerability is a separate vulnerability, and the origin of long, in Google's official document has been warned that the problem is the Zipentry.getname () method, Let's take a look at the description of the function in Google Docs:

Links: Http://developer.android.com/reference/java/util/zip/ZipEntry.html#getName ()

 This zipentrysecurity note:entry names can represent relative paths. Foo/. /bar or.. /bar/Baz, for example. If the entry name is being used to construct a filename or as a path component, it must being validated or sanitized to Ensur E that files is not written outside of the intended destination directory.

You can see that Google has given a security hint to the method, prompting the developer if the return value of the method contains a ". /"Jump character, you need to be careful not to write files outside of the destination folder. if not ". /"Jump to filter, it is possible to traverse the directory, when extracting the zip file with the permissions of the app to overwrite any file."

Here is a common code snippet for an Android Zip decompression:

1 New ZipFile (ZipFile); 2  for (Enumeration entries = zip.entries (); entries.hasmoreelements ();) {3     zipentry zipentry = ( ZipEntry) entries.nextelement (); 4     New File (outputdirectory + file.separator+ zipentry.getname ()); 5     ... .. 6 }

If the zipentry.getname is not checked, the blind decompression creates the file, and the file will be created through the directory:

After our detection, we found that almost all the applications using the ZIP decompression feature are vulnerable to the "parasitic beast" vulnerability attack, which is divided into three categories:

APP Associated File Classes

This kind of vulnerability mainly affects the skin function of the app, such as input method, browser class app. Many apps do the Zip class file association in manifest, if the registered file format is clicked, the corresponding app will start extracting files. is an example of an app registration file association

1 2     <action android:name= "Android.intent.action.VIEW"/>     3     <category android:name= " Android.intent.category.DEFAULT "/>     4     <data android:mimetype=" */* "></data>      5     6 </intent-filter>

This XML to the application and the SSF format of the file association, in fact, the format of the file is a zip compression format, the user in the phone download open SSF file, will launch the corresponding app automatically extract files, the file contains malicious code can overwrite the app's cache code .

Verify an Input Method App vulnerability video

APP Self-upgrade class

This type of vulnerability mainly affects the automatic upgrade download Zip class file features of the app, in the app download files can be hijacked by man-in-the-middle attack, we found that the Map class app and SDK plug-in is the most vulnerable to attack, the app in the process of downloading the extracted resources file is attacked

Verifying a video of a map app bug

APP Default Decompression class

This type of vulnerability primarily affects apps that have the ability to unzip the zip file by default, such as when the browser directly downloads the zip file and the app is infected with the cache code.

To verify a browser vulnerability video:

(2) Overwrite cache code with ADB backup

If the developer does not specify allowbackup= "false" in the manifest, the data in the app's private directory can be backed up and restored without the need for root privileges . If the app uses a plug-in mechanism, the corresponding plugin's Odex file will also be backed up. An attacker could use ADB backup to back up user data, modify the backed-up Odex file, and then revert back with ADB restore to replace the normal Odex file, resulting in code hijacking.

(3) Other possible app data read and write

If a trojan virus using root privileges to implement "parasitic beast" vulnerability attack mode, will be able to implement the hidden apt Trojan attack mode, long-term latent in the user's mobile phone class, security software is difficult to find the app's cache code is infected.

seven. Protective scheme for "parasitic beast" vulnerability

"Parasitic beast" the core of the vulnerability has two points, one is that Google did not consider Odex security issues require developers to do their own protection, the other is to block the vulnerability of the attack access and use of the way, here we give some protection recommendations to mitigate the vulnerability of the attack.

(1) Integrity check for Odex files

Since the Odex is generally automatically generated by the system (Dexclassloader), and Odex and Apk/jar are relatively independent, the developer can not know Odex file MD5 and other information, so it is difficult to MD5 check and other means to protect the integrity of Odex; The Dexclassloader function of the system simply verifies the CRC, Modwhen fields in the Odex, and can be easily bypassed.

Therefore, the current protection of Odex can only be done by the app itself, you can clear the existing Odex before each run Dexclassloader;

In addition, after the first generation of Odex, the MD5 value of the Odex file is stored and Odex checksum is MD5 for each subsequent call to Dexclassloader .

(2) fix for possible attack ingress vulnerability of hijacking Odex

For a zip decompression vulnerability, you only need to filter the "." In the return value when calling Zipentry.getname (). /"Jump character .

For the reference of the third-party zip library also need to be aware that the above test case can be used to test whether the third-party library has a zip decompression vulnerability;

When calling Dexclassloader dynamically loading Dex, the second parameter is not specified on the sdcard;

Specify allowbackup= "false" in manifest to prevent the app data backup from overwriting.

This article transferred from: http://appscan.360.cn/blog/?p=159

Android "Parasitic beast" vulnerability technical analysis