We all know that Google Maps is used at places when there's a requirement to integrate Maps in websites/apps, or when companies want to search the locations entered by users in the Address fields.
Most of the devs even expose their API keys either through their source code or in one of the requests being sent from their applications. This is not even considered a serious issue because all an attacker can do is send requests to Maps API endpoints using their keys.
A lot of reports can also be seen on Bug bounty platforms that either mark the accidental exposure of these API keys as Informative or as an Accepted Risk.
The thing which they don't consider is the impact it might have on their budget because these keys have a pay-as-you-go billing cycle. The below-shown pricing table for Google Maps API explains it pretty well.
These 1000 requests can be sent easily using Burp Suite's Intruder in a few seconds, now imagine the effect this might have on the organization if it's left running for a few hours.
But Google also has few restriction options to prevent unauthorized usage of these keys, they are -
- HTTP referrers: restricts usage to one or more URLs and is intended for keys that are used in websites and web apps. This type of restriction allows you to set restrictions to a specific domain, page or set of pages in your website.
- IP addresses: restricts usage to one or more IP addresses, and are intended for securing keys used in server-side requests, such as calls from web servers and cron jobs.
- Android and iOS app restriction: restricts usage to calls from an Android app with a specified package name.
The Proof of Concept
This is a Unique case of how I bypassed some of the restrictions placed by an Android app to their API Keys.
There are two parts to this PoC, the first one explains finding the API key and the second explains the restriction bypass.
Finding the API Key
First and foremost recon in an Android application starts with decompiling the APK. (Also MobSF).
I'll be using apktool to decompile it with this command
apktool d filename.apk
A folder with the name of the apk will be generated.
Now I had to go inside the folder and look for any leaked keys. Usually, there are some constants inside strings.xml file which is located in /res/values directory. I'll use grep to search for any keys.
grep "key" strings.xml
As you can see, well, there are lots of API keys in here.
When tried to use it normally ( super helpful - https://github.com/streaak/keyhacks) it gave me this error which hinted that it might be a Referer restriction but when tried with the referer of the app api.redacted.com it didn't work as well so there was some other kind of restriction here.
Now comes the bypassing part.
The Bypass
LUCKILY, while browsing the android app, I came across this one ongoing request that had two unique headers which caught my attention. They were -X-Android-Cert and X-Android-Package
X-Android-Cert contained some kind of SHA1 hash and from the name, it looked like it was of the app's certificate. To test it out -
I extracted the APK using an archive manager and went inside the path /META-INF which contains the certificate file. To view information related to the certificate, I used keytool.
keytool -printcert -file CERT.RSA
This confirmed that the value in the header X-Android-Cert was indeed it's SHA1 hash.
The second header looked already familiar and is pretty descriptive with the name X-Android-Package. It had the package name of the APK - com.redacted.app
Now using these two headers in my API request to Google Map, I was finally able to bypass the restrictions placed by the app on it's API Keys.
Also, It was marked as an accepted risk.