Rooting Exploit for Android Works Silently

In our last blog about Android malware, we discussed the expanding threat landscape for Android malware. Recently, we received an Android package in our collection and observed that this malicious application uses a rooting exploit that targets Android devices running OS Versions 2.3 or earlier to gain root privileges on the compromised device.

The malware binary is packaged with a legitimate application. In this case, the malicious exploit code comes with “Daily Beauties,” which showcases pictures of celebrities that are updated periodically. Attackers use this repacking approach to hide their malware within genuine applications, which users will download and install.

The following image represents the repacking a legit application with malicious code. These repackaged applications are made available in Android black markets and third-party markets.

                          

Figure 1: Repackaged application

This malicious application requires the following user permissions:

Figure 2: User permissions required by the malicious application

From the preceding list of permissions requested by the malicious application, I was curious about two in particular.

• android.permission.MOUNT_UNMOUNT_FILESYSTEMS
• android.permission.WRITE_OWNER_DATA

Why would an application that displays pictures of celebrities require permission to write user data and mount/unmount file systems?

Upon opening the malicious application we see the names of celebrities, as shown in the below figure. The victims would see the pictures, but they wouldn’t see the malicious service running in the background.

Figure 3: A picture of the celebrity showcased by the application

So how does the exploit work? The malicious application has four files bundled along with the legit application. They can be found in the asset folder of the application package. The file names appear in Figure 4:

Figure 4: Malicious files in the asset folder of the Android application package

The file gbfm.png carries the exploit code; the others are script/shell files. all four masquerade as PNG image files, although they are originally ELF (gbfm.png, runme.png) and shell script (install.png, installsoft.png) files.

When the required services start, the malicious application renames the .png extension to .sh and executes the exploit as shell script.

Figure 5: Renaming the .png extension to .sh extension

The malicious application first checks for the version of the Android OS and then exploits it:

Figure 6: Malware checks for the Android OS version and executes the exploit

The malware next checks for the Unix user identifier of the currently running process and stores it. Then it triggers the exploit (gbfm.sh). If it’s successful, the malware will elevate the device to the root privilege.

When the device is successfully rooted, it will run the install.sh script, which will set the appropriate file permissions (chmod 4775) to the system partition and copies the shell from the bin folder /system/bin/sh to the folder created by the malicious application /system/xbin/appmaster. Thus the shell can be accessed whenever it wishes and the system partition is remounted.

Figure 7: Setting up the file permissions

After a while, the malware executes the installsoft.sh script, which silently downloads more APK files in the background and installs them by executing the “pm install” command in the root shell.

Figure 8: Installing APK files in the background

The malware retrieves the following information from the compromised device and sends that information to a remote site:

Figure 9: User information retrieved by the malicious file

The exploit will work only when the device has an SD card installed. If not, it will not run. McAfee products detect this malware in our latest DATs as Linux/Exploit-Lotoor.

nb : mcafee