Here is the second part of a two-part blog based on my paper for AVAR 2013.
Continuing from the first part of my paper…
Exploits for Android
This section would demonstrate few of the major security vulnerabilities in the Android OS.
Master Key Vulnerability:
This vulnerability has attracted a lot of interest from both security researchers and from the news media. This vulnerability resides in the cryptographic signature verification of Android Application Packages (APK). The problem here is that the files in the APK (Zip archive) are parsed (unzip of a file) and verified using Java ZipFile implementation from libcore, whereas the code that loads the data from the package is from a different C re-implementation2. The way in which these implementations handle multiple files with the same name differs, which results in verifying signature for one file with a name as per Java and installing the contents of a different file with the same name as per C.
In general, a zip format will not allow two or more files with the same name to be within an archive. But this can be circumvented with the help of some utilities available or a bit of tweaking. For example, the Android malware called Andr/MstrKey-A (Sophos) travels across with two copies of files named “AndroidManifest.xml” and “classes.dex”.
Figure 3: Malware APK with multiple files of same name
While the AndroidManifest.XML of size 2644 bytes and classes.dex of size 45228 bytes are the original files, the other two files were added by the malware author.
Manifest and Dex2Jar Vulnerability:
Android malware Backdoor.Android.Obad, called to be the most sophisticated, was found to exploit more than one vulnerability in the system to achieve the malevolent behaviour. The dexguarded Obad is seen to engage three of the vulnerabilities in the system to send out premium rate SMS without user’s knowledge.
Apparently, dexguard protection on this malware encrypts the strings and the class names involved, making static analysis challenging.
The figure below is a code snippet of Obad backdoor sample in Java format, highlighting some of the encrypted strings and class names.
Figure 4: Java code snippet of Backdoor Obad sample
The AndroidManifest.xml is a file which defines an application’s structure, permissions required and the launch parameters. This file plays a vital role during the installation process of the application. OBAD targets an error in the processing of AndroidManifest.XML file by modifying the XML file in such a way that it does not comply with Google standards but still gets executed properly and installs the application as usual, which stands as the first vulnerability availed.
Secondly, the Dex2Jar utility, that helps researchers to convert .dex to .jar files, has an error that it fails to convert the dex to jar properly, which takes the second place in the vulnerability order.
As third one, this malware registers as a device admin and utilises a vulnerability that it does not appear in the administrator list. By Android Framework, only user level applications (non-administrators) can be uninstalled by the user through uninstall option under settings whereas for the device administrators, uninstallation is possible only from the device administrator list. As this malware does not have any icon and runs in the background, absence of the application name in the administrator list makes it tough for an end user to identify the infection and delete the application.
It is also under discussion that because of the flaw in the XML encoding in dexguard 5.2.00 and the fact that the application is missing the associated label, which is required to display the application name in the Device administrators list, this malwares enjoying the administrator privileges without being listed under the administrators. Even though the malware does not aim at hiding itself or exploiting a vulnerability in the system, the vulnerabilities in the development environment and the supporting tools, may make it relatively tough to statically analyse a malware.
Privilege Escalation Vulnerability:
To procure the root access, there were malware instances that invoked other application in the victim’s device that require root access or driving the user to grant the root access to the application. As a step ahead, exploiting vulnerability in the Android OS to acquire administrative rights was also witnessed in case of Android TrojanSpy Droiddream that carries Exploid and RageAgainsttheCage.
The daemon process, Android Debug Bridge in Android, when started runs with the root permissions but later, the daemon drops its root permissions with the help of setuid() to run as a user process.The problem arises when there are maximum number of user processes are already running in the system.
Exactly the same happens in case of the malware Android Droiddream where RageAgainsttheCage confirms the max count of user processes (RLIMIT_NPROC) and forges the required number of processes to reach its limit. Now the exploit kills one of the processes and restarts the adb process. But as the target user’s process had already reached its maximum (RLIMIT_NPROC), setuid() fails. However, setuid() function’s return value is not verified and the adbd also fails to drop its privileges and continues to run as root.
Technical Analysis of Droiddream malware describes that RageAgainsttheCage is tried first and at the failure of which, is called Exploid, an udev exploit. This second exploit executes by using hotplug that is run by changing the state of the wi-fi adapter and resuming to its original state. Successful execution of these exploits aids the malware with root access.
The above described vulnerabilities had a huge impact on the malware approach to silently have venomous actions in the compromised device.
Android OS Update
According to Google’s architecture for OS update, a user will receive updates from the respective device manufacturers/carriers. The reason behind is to aid the handset manufacturers/OEM versions to customize the updates for their device design. But many a time, the update process is slow that it resulted in a delay for a user to receive updates or at times the user could miss the update at all, that leaves them exposed to the dangerous vulnerabilities. Considering the data security of an Android user, Google should release increased and regular security updates without waiting for any upcoming GUI/OS update. Also it is debated many a times that updates should be directly available to the user instead of routing through the device company. User responsibility also has a share in this topic, to regularly check for updates and update the device, if any to avoid any uncool situations.
Risk Mitigation
Apparently, to mitigate the risk of vulnerability, there should be technology improvements in the Android OS that enhances the security context. The implementation of most awaited deployment SELinux3, Mandatory Access control (MAC) in Android OS could help solve the problem. With SELinux, MAC layer can control the user access to both their and the system data. Interestingly, with extra layer of security, it is possible to define system-wide policies, applicable for Super User (root) even.
It works by defining policies that describes the type of interactions a process is allowed to. For example, if a daemon process has a system-wide policy defined to access only a file with a specific label, then the process cannot access any other file. This acts as a solution to the privilege escalation vulnerability, but unfortunately SELinux is implemented only in the permissive mode. Removing the permissive mode and imposing the SELinux along with the regular OS/Security update with no delay could reduce the opportunities for exploits in the malware spread. Eventually, Google could come up with a vulnerability scanner for different versions of Android OS, which the users can make use of and proceed further to their carriers to patch the unpatched device.
Conclusion
Evidently, there is a rise in the smartphone usage around the world in both personal and business sectors. As quoted earlier, Google’s Android also contains vulnerabilities. It is a known fact that there are mobile malware in the rounds targeting the OS vulnerabilities to accomplish their noxious activities. These malware, even though, avail exploitation techniques to infect a device, their ultimate aim is at financial benefits by stealing user’s banking details, or stealing user data or personal information. Victimizing smartphones that are engaged in business communication can still intricate the situation. It is demonstrated already by Android malware to adapt to advanced evasion technique, which is expected to continue in the future as well. Hence, to overcome this scenario, regular security and/or OS updates should be made available to the user, to patch the disclosed vulnerability(s). With the enforcement of the SELinux technique in Android could considerably reduce the vulnerability risk in the system.
References:
2. http://www.saurik.com/id/17
3. http://source.android.com/devices/tech/security/se-linux.html
Images courtesy of:
Moneycrashers.com
V.Dhanalakshmi
Senior Threat Researcher, K7TCL
If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
https://labs.k7computing.com/feed/
