A brief test has shown that no public sandbox system can handle the APK correctly. Errors range from "No threat detected", over "no malicious activity detected" to "No executable file". The reason probably being that none of the systems actually managed to run the APK in the first place. To be fair, our analysis system wasn't able to handle the APK without an engine update either.
The first exploit: Incomplete/corrupt AndroidManifest.xml
The AndroidManifest.xml provided by the APK is actually incomplete, but it uses some weaknesses in the Android OS manifest checking code that installs and runs an APK even if certain key attribute names are missing, although it should be rejected. Of course, this is a major hurdle for sandboxing systems that rely on extracting key information from the manifest (e.g. the activity name, etc.). Here is a small excerpt of the original, incomplete AndroidManifest.xml:
As we can see, some important attribute namespaces and names are missing, such as "android:name" for the uses-permission tag or the "minSdkVersion" field in the manifest tag. So, in order to be able to run the APK in our system we updated our engine to fixup the AndroidManifest.xml with a best-effort approach. This is an excerpt of the same manifest after fixup:
Using the fixup our engine was able to properly extract static information and install the APK at the correct target device API level.
The second exploit: Inserting data into the instruction stream
The next problem we had was decoding and recompiling the classes.dex file (a necessary step as part of API call instrumentation), as the APK was modified in such a way that a packed data switch was inserted into the instruction stream. This in turn caused the DalvikVM verifier to reject our APK upon loading a specific sample class. A typical error of this type is:
VFY: encountered data table in instruction stream
VFY: rejecting opcode 0x00 at 0x002a
VFY: rejected Lcom/android/system/admin/oCIlCll;.oCIlCll ([B)[B
Verifier rejected class Lcom/android/system/admin/oCIlCll;This is a pretty neat exploit, as it uses a weakness in existing dedexer tools and thereby hinders repacking APKs for automatic analysis. In order to solve the problem, we had to update our preprocessor to move the packed data switch back to its proper location before recompiling the classes.dex file.
Dynamically analysing the APK
Before running the APK, we created two signatures that match on these two special APK characteristics (corrupt manifest and packed data switch exploit). After quickly implementing the signatures, we ran the APK with Joe Sandbox Mobile 1.0 and here are some of the results:
Corrupt Manifest Signature
Exploit Signature
Obfuscated Method Name Detection Signature (New!)
In no time flat we were able to find some interesting code locations with dynamic data and reproduce results found in the Kaspersky blogpost linked at the top. Check out some of our results:
Here we see the "decryptString" function call (instrumented by function signature generically) returning "su -c 'id'" and passing the string to Runtime.exec in an attempt to create a superuser shell. This really outlines the power of "Hybrid Code Analysis" (HCA) engine that we use in Joe Sandbox Mobile 1.0, which combines dynamic data with static code analysis (in this case, the disassembly of the function).
Checking internet connection:
"calling home" to androfox.com:
Building a JSON command with device specific data:
Internal DB structure used to save user data (the last 5 datasets are displayed by default).
Querying for device admin privileges:
All of the above information was extracted and discovered within minutes.
Posts
