Mobile fraud is a dangerous plague on Android apps

By Phi Tran Comment

iovation fraud report

Mobile apps rely on their operating system for more than just code development. Usually, the choice between iOS and Android can result in very different levels of sales and profit, but it can also mean varying degrees of vulnerability. Android vulnerability makes for fairly frequent news events, and it’s not surprising considering that Android apps carry a 4% risk of dangerous mobile transactions (graphics above). Compare that to 6% from Windows and Blackerry, and Apple’s 2% for iPad and 3% for iPhone.

The numbers come from a study with Iovation that studies mobile trends and impacts. The fraud cases included anything from spam to account takeovers. For the most part, mobile apps are less vulnerable than the mobile web:

It’s interesting that iovation’s data shows high-risk  transaction percentages are still greater on mobile web  than mobile applications. When we compare Android  and iOS mobile application transactions, Android is  four times more likely to have high-risk transactions.  This seems to support the industry consensus that  iOS is a safer environment than Android, although no  mobile device is completely risk-free.  The iOs platform was just as susceptible to credit card fraud, spam, and identity theft.

This isn’t the only sign of mobile’s dangerous vulnerability on Android. On June 25, we shared data from Swrve indicating that 21% of all in-app purchases on the Android platform are fraudulent, meaning, developers were likely not getting compensation for in-app purchases, most likely made by hackers. Just yesterday, a serious Android crypto key vulnerability was disclosed. Unfortunately, only devices operating KitKat can fix the error. It’s thought to affect at least 10% of Android users. In an advisory published earlier this week. IBM security researchers detailed the vulnerability, which can give hackers access to passwords and personal data.

Successfully exploiting this vulnerability leads to a malicious code execution under the keystore process. Such code can:

  1. Leak the device’s lock credentials. Since the master key is derived by the lock credentials, whenever the device is unlocked, ‘Android::KeyStoreProxy::password’ is called with the credentials.
  2. Leak decrypted master keys, data and hardware-backed key identifiers from the memory.
  3. Leak encrypted master keys, data and hardware-backed key identifiers from the disk for an offline attack.
  4. Interact with the hardware-backed storage and perform crypto operations (e.g., arbitrary data signing) on behalf of the user.