We reverse engineered 16k apps, here’s what we found

Written by fallible | Published 2017/01/15
Tech Story Tags: api | security | information-security | startup | favorites

TLDRIn Nov’16, we created an [online tool] to reverse engineer any android app to look for secrets. Out of 16,000 apps, most of the apps didn’t have any sort of key or secret in it. Roughly 2500 apps were found to have either a key or a secret of a third party service hardcoded.via the TL;DR App

In Nov’16, we created an online tool to reverse engineer any android app to look for secrets. This tool was built because of an internal need — we were constantly required to reverse engineer apps for our customers to examine it from a security standpoint. We felt the process could be automated to a point where we could create a web based tool which could be used by anyone. Couple of months after releasing it, users have reverse engineered approximately 16,000 apps and here are some of the interesting findings.

Out of 16,000 apps — apps with keys or secrets

Out of 16,000 apps, most of the apps didn’t have any sort of key or secret in it. Roughly 2500 apps were found to have either a key or a secret of a third party service hardcoded in the app. Some keys are harmless and are required to be there in the app for example Google’s API key but there were lots of api secrets as well which definitely shouldn’t have been in the apps. There were 304 such apps.

These secrets belonged to a lot of different 3rd party services, for example Uber’s secret which can be used to send in-app notification via the uber app.

Sample reminder triggered using Uber API

Then there were AWS secrets too hardcoded in the apps. Some of them had full privilege of creating/deleting instances.

Following is the list of popular services whose secrets were found in the apps.

Popular services whose secrets were found

Takeaways

For app developers reading this, whenever you hardcode any API key/token in the app, think hard if you really need to hardcode this, understand the API usage and the read/write scope of the tokens before putting it in the apps.

For 3rd party services, clearly warn/instruct the developers to not to put these secrets in the apps. Create multiple API secrets with different scopes if required.


Published by HackerNoon on 2017/01/15