Unauthorized Google Maps API Key Usage Cases, and Why You Need to Care
Note from 2022: Please note that most of the bug bounty platforms marking this vulnerability type as informational/low impact. So please make sure that the platform or program is accepting this kind of issues before reporting.
For the ones who do not have any information about this service and its API Key’s, Google Maps API is a paid service which allows applications to embed & search from the Google Maps Database and use it on their own applications. While some of the services was free at the back times of Early 2018, they changed their usage plan after that date. Since then, developers need to use an API key or client-id solution for all of the API’s they are using from.
These API keys have some security configurations for blocking unauthorized usage for malicious people which does not comes by default. Developers need to configure this security controls within their own decisions. While these API keys are designed as public API keys and does not have any impact in terms of customer data confidentiality/integrity, this security configurations still need to be implemented for blocking unauthorized usage. Here is the list of this configurations:
- HTTP Referrers: Restricts apps via HTTP Referrer headers which are defined to. Wildcards can be used for multiple domains/paths such as *.example.com/*. However be careful when using, because some bypass techniques can be used if the wildcard is defined such as *example.com or example.com*, within the payloads of ozguralpexample.com and example.com.ozguralp.com domains in order.
- IP Addresses: If the key will be used for just one application such as server-to-side solutions, this configuration could have been best fit for you.
- Android/iOS Apps: If you are going to use the key via mobile apps, this restrictions will also work for you.
However, the client-id mechanism is more secure than API key, because it uses an additional signature parameter on the requests which is generated on the back-end of the application within a private URL Signing Secret key. Within this solution, it is becoming nearly impossible to use unauthorized the service. (Note from 2024: It seems that Google deprecated client-id mechanism and no longer accepting new customers for this, so it is no longer available. Old reference: https://developers.google.com/maps/premium/authentication/client-id/request-signing)
Impact
If the API keys are not met with these security configurations, below scenarios may be conducted by a malicious user:
- Consuming the company’s monthly quota or can over-bill with unauthorized usage of this service and do financial damage to the company, if the company does not have any limitation settings on API budgets.
- Conduct a denial of service attack specific to the service if any limitation of maximum bill control settings exist in the Google account. While this could not be too dangerous if used the application parts of such “Contact Us” pages, however it could be really dangerous if the main business/functionality of the app is handled within these maps such as Uber (Finding/tracking rides via Maps) and Booking (Searching hotels via Maps).
More Impact
While analyzing these restrictions on “Google Cloud Platform Console”, I noticed that this API keys could also be shared within all other Google Services including critical ones; such as BigQuery, Cloud, Compute Engine, and StackDriver. Because it is a new discovery for me, I am still analyzing the potential impacts of these ones at the wild and it could be a new blog posting once within enough data.
Different Scenarios
While I mentioned the client-id mechanism is secure enough, it can still be used maliciously if it is configured insecurely in some cases.
On one of the Synack’s private programs, application was making request to the back-end within google-signature.json with a parameter requestUrl including value /maps/api/streetview?size=400x400&location=40,40&client=<redacted>. On the response, it was returning a Google Maps API URL within signed signature parameter.
Since this feature is used within client side input, it could be used with maliciously as signing requests whatever the API & location wanted and used on the attackers own system. Report is accepted around $200 payouts.
How Much Earned Within/Different Bug Bounty Platform Reviews
Nowadays I notice that this vulnerability is being reported on several different platforms/programs, hence we can say that this is a publicly known one. When I check my oldest report for it, I see that it belongs to 2 years ago, which make me claim to being one of the first descrier of this one. Within that, I wanted to share my statistics depending on different platforms and how they behave out of it.
- Synack: 47 reported, 33 accepted, around 10k payouts in total. If not duplicated & can be exploitable via other application, Synack accepts this kind of maps vulnerabilities also, such as Bing, Baidu, Mapbox etc.
- HackerOne: 12 reported, 5 accepted, around 1k payouts in total. All accepted ones are managed by clients’ themselves and other 6 out of 7 was managed by HackerOne staff. I think they are lack of understanding this kind of vulnerabilities or they are just reviewing reports like a robots. Also experienced that they are not responding the messages after a vulnerability is marked as informative, which made me stopping look at their targets.
- Bugcrowd: 2 reported, 1 accepted & 1 duplicated, 500 payouts in total. Looks like they are also accepting this vuln types, however probably too late to check for public programs :)
- Detectify: Module already reported when I signed up for it and due to this date it has 333 hits. Congrats to the one who submitted it! Assuming he/she made at least 3k from that.
- Intigriti: Just looked into one of the their targets for a special occasion, 1 reported, 1 accepted. Looks like they are also accepting these.
Script
Since this is a publicly known one yet, I made a script which checks all Maps API endpoints within supplied API key to see whether it is vulnerable or not and also creates PoC codes for them. It is checking all Maps API’s except JavaScript one, which is impossible to check within a python script because the full requests are generated with the JavaScripts. Instructions also added to the script for checking it manually.
Also, when using the script, let me know if you encounter any bugs or false positives because it is still beta and not tested by a bigger community comparing within just a few guys.
Link: https://github.com/ozguralp/gmapsapiscanner/
TODO: Import all Google API’s in addition to Map ones to check whether other API’s are authorized for this key or not, for increasing to a greater impact.
More Recommendations
For remediating this kind of issues, below remediations can be conducted together or seperately.
- IP, Referrer or App restriction check controls should be applied.
- It can be considered using the client id authentication solution and signatures rather than API keys.
- For best practices, not used APIs sho be disabled for lowering the exploitable level.
Last Words
Since this is my first blog posting, please leave me some comments/feedbacks via here or Twitter. Would really appreciate it for future posts!
