Why wait for an Android patch? While a new full access (root) privilege escalation bug spreads like wildfire, iovation already offers root detection in our Android mobile SDK.

Truth be told, this vulnerability has existed for more than nine years, allowing an attacker to gain "elevated privilege" in about five seconds, at most. Proof-of-concept source code is now being widely distributed via Git and other repositories, both on and off the deep web.

Coupled with existing Android-based attacks, this promises to be a real brain-freeze for businesses that aren’t adequately prepared, as it is massively fortuitous for attackers seeking to exploit your customers’ mobile devices in support of their ongoing fraud activities

What’s even worse, many Android devices can lag behind in security patches by months, so many of your customers will likely remain vulnerable to this attack vector for an extended period.

In this particular case, waiting for a patch is a recipe for disaster, and potentially costly for our subscribers

What’s the good news?

iovation can help subscribers detect and counter this threat right now with functionality that's already part of our mobile SDK.

The very first thing an attacker would do is "root" the Android device to hide their own tracks, and then gain full control over the Android system. You don’t want that to happen, to put it mildly.

So how do you stop it?

Here’s what we recommend:

  • Deploy the mobile SDK (if you haven’t already done so). This gives you greater breadth and depth of collected device attributes. Across all of our subscribers, about 50% of iovation transactions are mobile-based.
  • Set up rules that detect devices that have been rooted. Data from our Device Intelligence Platform shows a distinct correlation between rooted devices and increased risk (see below).


The chart above shows daily Root Detection Rule Triggers (blue) since June 2016 and three evidence types indicating the number of transactions that have a device or account associated to that type of evidence. The evidence types are:

Red: owned_evidence:

  • The transaction originated from Subscriber_A
  • The transaction triggered the Root Detection rule
  • The device and/or account paired with the transaction was associated (either directly or indirectly) to evidence placed by Subscriber_A.

Yellow: other_subscriber_evidence:

  • The transaction originated from Subscriber_A
  • The transaction triggered the Root Detection rule
  • The device and/or account paired with the transaction was associated to evidence placed by Gambling_Subscriber_B (i.e. Subscriber_A did not place the evidence, but sees the device/account is associated to evidence from another subscriber.)

Green: both_subscriber_evidence:

  • The transaction originated from Subscriber_A
  • The transaction triggered the Root Detection rule
  • The device and/or account paired with the transaction had evidence placed by BOTH Subscriber_A and Subscriber_B (i.e. these are the most high-risk, as two different subscribers have placed evidence on the associated device or account).
What’s the cost / benefit?

The cost of SDK deployment is roughly 1.5 FTE (full-time resource) for about three weeks. Our data shows a 2.6x increase in efficacy when subscribers use the mobile SDK, deploy our mobile SDK to protect their mobile-based commerce, and deploy just the five rules listed below. They are generally 30x more likely to see transactions associated with evidence placement

  • Devices Per Account
  • ISP Organization Watch List
  • Subscriber Evidence Exists
  • Timezone/Geolocation Mismatch
  • TOR Exit Node IP

This new vulnerability is just another example of what makes our mobile SDK so vital for businesses that offer a mobile app. If you have one now, make sure you’re using our mobile SDK. If you plan to build an app in the near future, the SDK should be an integral part of it from the start.