Affect tens of millions of APP the Android APP“parasitic beast”vulnerability technical analysis-vulnerability warning-the black bar safety net

2015-07-01T00:00:00
ID MYHACK58:62201564205
Type myhack58
Reporter 佚名
Modified 2015-07-01T00:00:00

Description

3 6 0 mobile security research team vulpecker recently discovered a new Android app security vulnerabilities, the market tens of millions of apps are affected by the vulnerability. The vulnerability once attacker, it can be directly on the user's mobile phone implanted Trojans to steal the user's SMS, photos as well as banks, PayPal, etc. account password, vulpecker to“parasitic beast”named this vulnerability. Currently vulpecker team has been through the correction of the balance station will be related to details of the notification to each of the safety Emergency Response Center, but also to the affected by the major manufacturers were informed, this is to remind users concerned about the APP vendor repair processes, and timely download updates install the latest APP. Parasitic beast is the Japanese author Yan Ming are the creation of the comic the parasitic beast of a monster, the initial form is a bug, will got into the creature's body and captured the brain, due to human environmental pollution and birth, the vulnerability to attack in a manner similar to the parasitic beast of the infection, long-term resident in the victim's phone, this article will be a detailed analysis of this vulnerability, uncover the vulnerability of the secret. 0x01 about app cache code Android app apk file is in zip compression format of the file, the apk file contained in the classes. dex file corresponds to the app's executable file, when the app is running after the system of classes. dex is optimized to generate the corresponding odex File format. odex file corresponds to the app's executable file to the caching code, General Android system in the first loaded run of the apk will be system-generated odex files stored in the/data/dalvik-cache directory. As shown in Figure ! You can see the directory in the file only the system user has write permissions, and only have the system privileges to the odex file for the write operation. 0x02 widely popular plug-in mechanism Since the Android app upgrade will need to re-install the program, Frequent upgrades to the user experience and development have brought inconvenience, so the market app to start using the plug-in mechanism, the use of plug-in mechanism can do seamless upgrades and extended functionality, the app requires only the introduction of the corresponding plug-in files that can be done to add functionality or upgrade, without having to re-install the program. app plug-in mechanism of the implementation is to put related functions into a separate apk or jar file, and then at runtime use DexClassLoader to dynamically load, the reflection call. We look at DexClassLoder definition public DexClassLoader (String dexPath, String optimizedDirectory, String library Path, ClassLoader parent) dexPath: is to load the jar/apk path optimizedDirectory: target odex path libraryPath: a dependent native library(so file)path parent: the parent loader The following are common calling DexClassLoader code snippet String dexFiles = "/data/data/com. test. dexload/app_al_sdk/drozer. apk"; final File optimizedDexOutputPath = appcontext. getDir("outdex", 0); appcontext. getClassLoader(); DexClassLoader classLoader = new DexClassLoader(dexFiles, optimizedDexOutputPath . getAbsolutePath(), null, ClassLoader. getSystemClassLoader()); ... As shown in Figure drozer. apk plug-in is invoked after became drozer. dex cache file, note this file is the odex format. ! ! 0x03 plug-in mechanism into the point of attack In 2 0 1 3 years, abroad mwr lab shows the use of a middleman way to hijack the app to upgrade the plug-in attack of the case, with reference to the 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 using plug-in mechanism of the app, while loading the plug-in before without the plug-in file integrity check, resulting in the hacker can be through an intermediary hijacking of a way to replace the app upgrade plug-ins in the plug-in to embed malicious code to control the user of the app and the phone. Today, the most used plug-in mechanism of the app are to strengthen the security, such as the earliest use of plug-in development mode of the wechat app, download the use plugin before the check plug-in signature file, the hacker has been unable to through the intermediary of the way to replace the plug-in attack app. 0x04 plug-in mechanism the new point of attack Recently, foreign nowsecure company announced the Samsung keyboard of a vulnerability, the use of the process direct replacement for a system app odex cache code. Reference: https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/ The Samsung keyboard is with the system the highest level of system permissions, you can directly replace any of the app cache files. That Android app plugin cache code is and APP the main program generated directly by the caching code can be arbitrarily replaced? We go to the android source code to verify it, through DexClassLoader() to load the jar/apk file, and ultimately through the native interface openDexFileNative() into the native layer. Corresponds to the android-4.2. 2_r1/dalvik/vm/native/dalvik_system_DexFile. cpp in Dalvik_dalvik_system_DexFile_opendexfilenative() method in the native layer on several parameters to do a range check, if the detected second parameter specifies the odex file exists, it will call dvmOpenCachedDexFile() directly to open, call the code as follows: fd = dvmOpenCachedDexFile(fileName, cachedName, dexGetZipEntryModTime(&archive, entry), dexGetZipEntryCrc32(&archive, entry), isBootstrap, &newFile, /createIfMissing=/true); Obviously, the first 3, The 4 parameters corresponding to the before optimization classes. dex the time stamp and crc check value. Will eventually call dvmCheckOptHeaderAndDependencies(fd, true, modWhen, crc, expectVerify, expectOpt) If the crc, modWhen argument is correct, it returns the odex file handle; if the crc, when a parity error, then try to delete the wrong odex and re-built new odex it. So, the attacker if you want to inject the target odex, the need for the modified odex file of the crc and the modWhen make changes. The following is a modified odex file example, dex_old is to modify the front of the odex file, dex_new is the modified dex file, the two files of md5 is not the same, but the crc and modWhen is the same, so that you can bypass the DexClassLoader the check. !

[1] [2] next