Avoid Detection with Shadow Keys

July 23, 2018 arikkublanov

CyberArk Labs has discovered a vulnerability using Google APIs. This blog post introduces the vulnerability, which we call “shadow keys.”

The vulnerability was reported to Google by CyberArk Labs in January 2018 through the responsible disclosure process, and subsequently fixed by Google. A detailed timeline is below.

Introduction

Google automatically creates API keys that are associated with a user’s project. Shadow keys are essentially illegitimate “copies” of these keys. Because valid API keys are created unbeknownst to users, they would also be unaware of any shadow keys.

This was a significant vulnerability because if an attacker were to obtain a Google API key through nefarious actions, they could then create a shadow key to access applications as if it was the original user key. The attacker could also bypass the detection/billing system of some Google API services.

The shadow key technique described in this blog post enables an attacker or a malicious user to find, enumerate and create a list of such shadow keys using Google services.

Google APIs Explained

The API key allows you to monitor your application’s API usage in the Google API console. For a standard plan customer, the API key gives access to a generous free daily quota, as well as the option to pay to increase the daily quota. For a premium plan customer, a user must use an API key to access all the custom features and benefits of the premium plan.

Registering for an API key ensures that Google can contact the user about the application, if necessary. In the Google API console, the user can also look up an existing key or view a list of enabled APIs. By using an API key to authenticate applications, users can manage all of their APIs in the Google API console, access real-time usage data and 30 days of historical usage data for their application in the console, and view usage reports with more than 30 days of data in the Google Cloud Support Portal.

The API key has two major roles:

Project identification — Identify the app or the project that’s making a call to this API.
Project authorization — Check whether the calling app has been granted access to call the API and has enabled the API in its project.

By identifying the calling project, API keys enable usage information to be associated with that project, and allow the Google Extensible Service Proxy (ESP) to reject calls from projects that haven’t been granted access or enabled by the API (see Figure 1).

Figure 1- Google API key Identification and Authorization.

Shadow Key Discovery
Google API loader allows you to easily import APIs and specify additional settings (such as language, location, API version and so on). In addition to the basic loader functionality, savvy developers can also use dynamic loading or auto-loading to enhance the performance of their application.

Prior to Google’s fix of the shadow key vulnerability, CyberArk Labs found the following API service located in Google’s script loader. According to Google at the time, “Google Loader no longer requires keys. You don’t need to make any changes if you’re already using one, but if you choose you may simply remove the key parameter from your requests. Note that some APIs use other keys (e.g., from the Google APIs Console) which are unaffected by this change.”

The API that enumerates the valid API keys was meant to be used for old Google API keys, which are very different in structure. The API sent back information on the validity of new Google API keys that were generated at the console.developers.google.com site.

For a valid Google console API key, it returned google.loader.KeyVerified = true:

And for an invalid API key, it returned google.loader.KeyVerified = false:

Using this service, we were able to enumerate valid and invalid API keys.

According to Google, “Enumerating API keys is infeasible by design. A 64-alphanumeric key would have 36^64 combinations, a brute force attack is not even feasible given the time constraints to discover valid keys.”

However, we found it possible to forge a shadow key when the original key was malformed. We used a vector that we called “Malform,” which allowed us to rotate one valid key from left to right from index=6 until the end of the key index=39, and each time we could change one character to be from the following characters: abcdefghijklmnopqrstuvwyxzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.

The algorithm is best demonstrated in the following screen shot.

As a result, we received three more keys – the shadow keys. Only the character in the index of 39 was changed, and all three were valid keys that could be used to access the user’s application data.

For proof of concept, we created a real Google API key. To start, we had only one key on our project as the image below indicates.

We rotated it, and then got our three shadow keys (see image below).

We used the following services to get information regarding the API keys, such as project number, project name and configuration settings on that key.

https://www.googleapis.com/youtube/v3/videos?part=id&key= API_KEY

https://translation.googleapis.com/language/translate/v2/detect?key=

All of the shadow keys were associated with our project ID 131071927382, and not presented on the project credentials as shown above.

Shadow Key Usage

We created a Google web application hosting our simple Google map script, which displayed the location from where any user browses using the original key generated to us by Google API services. We used the original API key on our code:

Any user who browsed to this web page was able to receive its location on the browser.

The server responded to the user and we were able to see the responses using the “response code” filter on the owner project dashboard.

Based on the “by credential” filter used, you can see that it’s the same graph and that requests from the Google JavaScript maps API services were used with the original key.

Next we used one of the shadow keys that we discovered earlier – AIzaSyBYgdZ_Q8Rgi1XT1cR5PLn7Jh94xD6CbAF – in our application code.

We were able to browse to the site because the shadow key is valid. It worked.

On the owner dashboard you can see that the server responded to the user requests using the shadow key.

But when using the credential filter, there was no detection of the shadow key and it wasn’t logged.

We made more requests with the shadow key and with our original API key.

We gained access to the API with the shadow key without being detected. All the blank spots were made with the shadow key.

In the following screen shots, you’ll notice that we were limited in the “Quotes” tab by the Map loads as users can only use up to 20 loads per day.

When using the original key within our code, the system detected that the user made and exceeded all of their permitted daily loads.

A red line was displayed on the owner UI, indicating that they exceeded the daily limit.

But with our shadow key, the system didn’t detect that we exceeded our Map loads per day.

No red line was displayed on the owner UI.

We were able to access the application, bypass detection and avoid payment – even after we had exceeded our daily request limit – because the shadow API key didn’t belong to the owner’s application according to the credentials tab of the owner’s dashboard.

Conclusion

Using only a single valid Google API key, it was possible to create shadow keys that went undetected and could avoid payments to Google.

With only a valid key, an attacker could create shadow keys and sell them to other malicious actors, giving them the ability to access the same applications and data as the original valid key, but go undetected by Google.

As stated above, CyberArk Labs followed the rules of responsible disclosure and alerted Google to the vulnerability, which it has since fixed. It’s now no longer possible to enumerate keys on Google’s script loader. CyberArk Labs also recently tested several shadow keys that were created prior to Google’s fix, and they no longer work.

Disclosure Timeline

January 28, 2018: Shadow keys concept reported to Google
March 9, 2018: Google responded that a bug was filed with the API team
March 20, 2018: Google confirmed that shadow keys is an issue and rewarded the CyberArk researcher with a bug bounty as part of Google’s Vulnerability Reward Program
April 3, 2018: Google indicates this issue will be addressed in a few weeks
May 23, 2018: CyberArk researcher noticed that the vulnerability was fixed
May 24, 2018: Google stated that they issued a fix for shadow keys

REFERENCES

Configuring and Securing Credentials in Jenkins

Enterprise DevOps teams today have the ability to deliver high-quality products and services to market fast...

Cryptocurrency Evolution: The Rise of Monero and Its Impact on Cyber Security

This article is part of a series of blog posts on cryptomining from the CyberArk Red Team. It explores the ...

Up Your Security I.Q. by Checking Out Our Collection of Curated Resources.

Avoid Detection with Shadow Keys

Previous Article

Next Article

STAY IN TOUCH

Avoid Detection with Shadow Keys

Previous Article

Next Article

Recommended for You

Over the past few years, we’ve seen a huge increase in the adoption of identity security solutions. Since these types of solutions help protect against a whole range of password-guessing and...

Introduction Welcome, fellow travelers of the Cosmos! While we may not be traversing the stars on a spaceship, we are all interconnected through the powerful network of blockchains. Unfortunately,...

Introduction This is the final installment of the blog series “A Deep Dive into Penetration Testing of macOS Applications.” Previously, we discussed the structure of macOS applications and their...

Abstract The Play ransomware group is one of the most successful ransomware syndicates today. All it takes is a quick peek with a disassembler to know why this group has become infamous. This is...

TL;DR Whether working at home or in the office, when conducting cybersecurity research, investigating the dark web forums or engaging with any dangerous part of the internet, staying safe is...

TL;DR An overview of a fuzzing project targeting the Hyper-V VSPs using Intel Processor Trace (IPT) for code coverage guided fuzzing, built upon WinAFL, winipt, HAFL1, and Microsoft’s IPT.sys....

As vulnerability researchers, our primary mission is to find as many vulnerabilities as possible with the highest severity as possible. Finding vulnerabilities is usually challenging. But could...

Introduction In this blog, we will discuss innovative rootkit techniques on a non-traditional architecture, Windows 11 on ARM64. In the prior posts, we covered rootkit techniques applied to a...

Introduction This is the second part of the “A Deep Dive into Penetration Testing of macOS Application” blog series. In the first part, we learned about macOS applications and their structure and...

Introduction As many of us know, there are a lot of guides and information on penetration testing applications on Windows and Linux. Unfortunately, a step-by-step guide doesn’t exist in the macOS...

TL;DR In this post, we’re going to learn how Foundry can be used to write a proof of concept (PoC) for uninitialized smart contract vulnerabilities. We will take a look at and exploit a simple...

Recently, a new trend has emerged in the world of ransomware: intermittent encryption, the partial encryption of targeted files. Many ransomware groups, such as BlackCat and Play, have adopted...

Know Your Enemy In the previous post (Part 1), we covered several rootkit technique implementations. Now we will focus on kernel rootkit analysis, looking at two case studies of rootkits found in...

In the previous blog post, we described how the Docker research started and showed how we could gain a full privilege escalation through a vulnerability in Docker Desktop. In this follow-up blog...

CyberArk Malware Research Team Abstract CyberArk Labs discovered a new malware called Vare that is distributed over the popular chatting service, Discord. Vare has been used to target new malware...

Abstract Once threat actors gain a foothold on a system, they must implement techniques to maintain that access, even in the event of restarts, updates in credentials or any other type of change...

Introduction Everyone knows what phishing is. It has been around for more than two decades. Now it seems that phishing is more accessible than before. This blog covers how malicious actors can...

Introduction NTFS is a filesystem developed by Microsoft that was introduced in 1993. Since then, it has become the primary filesystem for Windows. In recent years, the need for an NTFS...

Everything started when I was researching Windows containers. It required installing Docker Desktop for Windows, and I couldn’t help but notice that there were many Docker processes. Since some of...

TL;DR I discovered multiple bugs in OEM vendors for peripheral devices, which affected many users of these OEM vendors (Razer, EVGA, MSI, AMI). Many of the vulnerabilities originated in a...