Google pulled over 20 malicious apps from the Android Marketplace today. The inevitable has happened. 2011 has become the year of mobile malware. All the pieces of the malware ecosystem puzzle that researchers have been warning about are falling into place..
[...]
The malicious apps that were pulled were legitimate apps that were pirated, modified by the attackers, and republished. To downloaders of these apps they behaved and looked like well-functioning apps. There was no reason for these users to rate these apps poorly in the Android Marketplace’s reputation system or to leave comments that the apps were suspicious. This shows that reputation systems are a poor method of ensuring an app store is free of malware.
To Google’s credit they did remove the apps and have, or will, wipe the apps from users’ devices but this is too little, too late. The mobile devices are already compromised as the malware took advantage of kernel vulnerabilities to root the devices and download more malware that didn’t come through the app store. Anyone who ran the malicious apps now has a compromised device running software with root permissions that Google cannot wipe.
The exact same thing could happen tomorrow even though we know what Android kernel exploit code was used and there are new versions of Android that fix these issues. This is because many Android phones cannot be updated to the new versions of Android, 2.2.2 and 2.3, that fix the root holes. Many Android phone providers have customized their versions of Android so up to half of Android phones running 2.0, 2.1, 2.2 are sitting ducks to the same problem tomorrow.
-------------------------------------------------------------------------------------------------
Android Malware DroidDream: How it Works
http://blog.mylookout.com/2011/03/android-malware-droiddream-how-it-works/
When the host application—Bowling Time, in this case—is launched by a user, DroidDream will start by sending sensitive data to a command and control server. The sensitive data includes: IMEI, IMSI, Device Model & SDK Version.
[...]
DroidDream is configured to perform at least one successful check-in with the command and control server, at which point the command and control server will respond and acknowledge the presence of malware on the infected device. We found that the DroidDream authors have configured the malware to make sure the device is not already infected with another variant of DroidDream. If the device is already infected, the malware will not re-infect it.
When DroidDream attempts to infect a device, it uses two known exploits, exploid and rageagainstthecage, to break out of the Android security container. Both of the vulnerabilities being exploited were patched by Android 2.3 (Gingerbread). If exploid fails to root the device, the malware will attempt to use rageagainstthecage. Once the phone is rooted, DroidDream is configured to searched for a specific package named com.android.providers.downloadsmanager. If the malware does not find this package on the device, it will silently install a second malicious application without the user’s knowledge. If DroidDream does find the downloadsmanager package, it will not continue infecting the device with the second malicious application.
At Lookout, we are currently in the process of confirming what this second application is capable of, but our initial analysis shows that it appears to be able to send additional sensitive information to a remote server. The second malicious application also appears that to have the capability to silently install other applications.
No comments:
Post a Comment