Drive-by attack shows mobile threat

As smartphones increasingly hold interesting data, attackers will target the devices using known vulnerabilities in common software packages.

One security researcher plans to show off just such an attack at next week's Black Hat Security Briefings in Las Vegas.

In a presentation at the conference, Neil Daswani, chief technology officer for Web security firm Dasient, will show off a proof-of-concept attack that demonstrates a drive-by attack on an Android phone using a vulnerability in the Webkit framework that powers the common browser for the platform. The attack opens up a channel through which Daswani exploits a vulnerability in Skype to read information from the application and eavesdrop on chat conversations.

"These attacks are possible, not only for us, but for cybercriminals as well," Daswani says. "We need to have a solid understanding of how this works, so we can protect against these attacks."

The presentation will cover recent research carried out by Dasient, including the creation of the attack prototype and runtime analysis of a random sample of 10,000 applications from the Android app store, which found that about 29 percent of applications request permission to access a device identifier known as the IMEI, or the international mobile equipment identity.

In a drive-by download attack, a cybercriminal convinces a user to surf to a malicious or infected Web site, which then exploits vulnerabilities within the browser or associated plugins to insert code into the device. While drive-by downloads are not prevalent on mobile devices yet, it is a vector that attackers are investigating, Daswani says.

Recent Android-focused malware -- such as DroidDream, DDLite, and Plankton -- have shown that cybercriminals are focused on researching ways of attacking the platform for profit. In addition, a survey of a random selection of 10,000 Android Marketplace apps found that about 800 sent a device identifier off to remote Internet servers. The company used behavioral analysis, rather than static code analysis, to determine what actions each app took in the first 30 seconds after installation.

Nearly 30 percent of applications requested access to both the device ID (IMEI) and the subscriber ID (IMSI), and a quarter of those sent off the IMEI while only 2 percent leaked the IMSI. In most cases, Dasient determined that the leak was not malicious but caused by the app developer using an ad framework that sent off the identifier by default. In most cases, however, the developer's intent was not clear cut, says Daswani.

"I wouldn't say that they were white; I wouldn't say that they were black -- I would say that they were grey," he says. "Some of the programs could be categorized as spyware, but most of the developers just weren't careful about how they handled IMEI numbers."

A measure that could potentially tip users off to a malicious program is the number of processes spawned by the application. In its analysis, Dasient found that the average Android app creates an average 58 processes, while the average instance of DroidDream, for example, created 660 processes.

(Source: infoworld.com)