NEW YORK – Mobile malware is real and attackers are using it to steal confidential business data stored on smartphones. But don’t let anyone fool you into believing there is a deep hacker think-tank at work, developing exploits for the latest mobile device vulnerabilities. Researchers such as Dan Guido have instead painted a clearer picture of the mobile malware landscape, and it’s frighteningly simple, and enabled quite nicely for the most part by Google’s Android security model.
There are 300 million Android devices out there, and most have never updated from the version they’re at today … There’s almost unlimited exposure.
Dan Guido, co-founder, CEO, Trail of Bits.
Guido, co-founder and CEO of research firm Trail of Bits, on Tuesday presented data at Information Security Decisions 2012 that suggests attackers are using a limited number of publicly known exploits to attack mobile phones, in particular the Android platform. And they’re doing so via malicious mobile applications that are enjoying success on app stores because of sub-standard vetting processes and code-signing practices.
“We found zero malware on the iOS [Apple] App Store and more than 30 on the Google Marketplace on dozens of applications, potentially impacting hundreds of thousands of users,” Guido said.
Attackers are keen on gaining privilege escalation on a mobile device in order to exfiltrate data to a server they control. Working on some simple economics, the cost of an attack has to be less than the potential revenue an attacker stands to gain. Factors figuring into the cost of an attack for a hacker include ease in which a device can be compromised, and the probability of getting caught, as well as the value of the targeted data and whether it can be monetized.
The best defense, Guido said, is to raise the cost for attackers to exploit devices. Apple, he said, has put in significant roadblocks to stop code execution. It signs all code submitted to its App Store and applications are given a unique ID and directory. Also, its Seatbelt sandbox restricts applications from accessing data from other applications, reducing the attack surface for the iOS kernel, Guido said.
Android’s security capabilities minimize costs for attackers, Guido said. Rather than code signing, Android employs No-eXecute or the NX bit, which limits areas in the operating system where code is allowed to execute. Guido said this is less effective than the code signing Apple falls back upon. Apple also patches vulnerabilities that lead to jailbreaks much quicker than Google does for Android, which means Android exploits have a much longer lifespan.
“There are 300 million Android devices out there, and most have never updated from the version they’re at today,” Guido said, adding that early generation Android devices won’t be able to update to the upcoming 4.0 version because of hardware limitations. “There’s almost unlimited exposure.”
Guido said there are no mobile browser attacks in the wild, no wireless attacks compromising devices, and no application-to-application exploits. “It’s all Android, and it’s all jailbreaks,” he said.
Instead, mobile malware attacks, such as Android DroidDream, follow a similar pattern. A public exploit is used to develop the malware, which is injected into a mobile application. The application is put online, most often into an application marketplace. Then the attacker begins to lure victims via text messages or email social engineering to download the malicious app. Once installed, the jailbreak exploit escalates privileges for the attacker who is then able to establish contact with a command-and-control server, where data is sent and then sold, or abused in other ways. “This is the systemic process all intrusions follow, otherwise they won’t make money at the other end,” Guido said. “If you’re able to disrupt it anywhere on the chain, the attack won’t be successful.”
Attacks via Android-based mobile applications are the attack vehicle of choice because of the lackluster security around the application submission process, Guido said; the trouble starts at the outset. Whether on the Google Play Android Developer Console or the iOS App Store, developers sign up with a credit card. On Google Play, your credit card number is your ID, while Apple requires either a driver’s license number or articles of incorporation. Both platforms do static application code reviews, but the key is that Apple does not allow runtime modifications of an application; whatever you submit to the App Store is what must be offered on the App Store. Google, meanwhile, allows runtime modifications of code. An attacker can push a malicious app through Google Play much easier than iOS because they are able to modify the application once it’s in the marketplace. This process is not easily repeatable on the Apple App Store; the code signing that is part of a security review is likely to catch a malicious app.
“You’d need a new ID every time and this gets costly for an attacker,” Guido said. “[For Android] you can steal credit card numbers by the hundreds and submit apps that are allowed to change after you submit them. The security review is much less effective and there are no repercussions. You can continue through the process until you’re successful.”
Boiling it down, there are very few active mobile exploits and those that exist target just one platform; it’s simple economics.
“There’s a disconnect between what the security industry is talking about and what the product community is coming up with,” Guido said. “There’s too much focus on possibilities, and not enough on [real] threats.”