According to a recent report by Symantec, over three-quarters of the mobile apps they analyzed contained valid tokens that allowed access to private cloud services. This exposes mobile apps to interesting supply chain vulnerabilities that could endanger sensitive business information.
Of course, as an API hacker, I see this as an opportunity.
Let me explain.
The mobile app supply chain problem
When developers hardcode API keys and other sensitive data into their apps it becomes trivial to gain unauthorized access to API endpoints and other cloud services. In Symantec’s research of over 1,800 apps, they found that:
- Over three-quarters (77%) of the apps contained valid AWS keys allowing access to private AWS cloud services
- Close to half (47%) of those apps contained valid AWS tokens that also gave full access to numerous, often millions, of private files via the Amazon Simple Storage Service (Amazon S3)
These insecure default configurations put confidential data in danger and expose application programming interfaces to attack.
So while Symantec goes into more detail about things like open cloud storage and the risks of data breaches, I look at the vast opportunity to take advantage of this security misconfiguration to focus on API attacks and abuse.
How API key misuse endangers the supply chain
One of the interesting findings in the research is the fact that over half (53%) of the apps were using the same tokens found in other apps. More interesting was the fact these apps came from different developers and different companies.
In other words, this clearly points to potential supply chain vulnerabilities.
But how?
The access tokens could be traced down to shared libraries, 3rd party modules, and other shared components used in developing apps.
Think about it for a moment. How many times do we see and hear about developers reusing code directly from StackOverflow? Or following API integration documentation and pasting an example directly from the API publisher?
Proper and updated documentation is useless when developers blindly copy and paste code.
It happens.
The point is when an API publisher makes it so easy for a developer to consume their endpoints it is extremely important that they consider restrictions in the use of potentially shared authentication artifacts like API keys.
When they don’t, this is an opportunity for you as the attacker.
How security misconfiguration of API keys helps us as hackers
Combining misuse of API keys with ad hoc configurations and insufficient logging, API security is at huge risk when session tokens become trivial to capture or steal.
It’s not uncommon to find leaked keys or other forms of authentication tokens right in configuration files that might get checked into source control like GitHub.
We all know how easy it is to search through GitHub for API keys.
And this is where we as API security testers can really win big.
By taking advantage of these security misconfigurations, we can easily gain access to API endpoints, cloud storage, and other services that should be protected.
We can also launch simulated attacks that are very difficult to detect and mitigate. It’s hard to assign attribution when the authentication keys are shared and aren’t in misconfigured HTTP headers. Or when there is a lack of verbose error messages to alert DevOps/CloudOps personnel to the abuse.
Shared libraries in APIs and the exposure to sensitive data
An interesting finding in Symantec’s research included the fact that personally identifiable information like biometric digital fingerprints was leaked for over 300,000 banking users, thanks to a popular third-party digital identity SDK.
This just goes to show the important role that a developer has in thinking about the resources that expose sensitive information and taking dependencies on third-party libraries. And the role we have as attackers is to closely look at those same third-party dependencies offensively when we plan an API attack.
A healthcare app case study
Consider this. Imagine you are a bug bounty hunter looking at mobile healthcare apps. Think about all the users private health information that web applications may expose through their APIs. Now consider how many healthcare providers hire the same dev shops or reuse the same mobile base apps, to deliver their services.
This is a huge opportunity.
This was proven by one API hacker who determined when auditing over 30 healthcare apps that they found 77% of the apps had hardcoded API keys. So discovering a single flaw in a reusable core application or third-party library may offer you the ability to report the same vulnerability to several companies.
Maximize the effort spent I always say.
The ideal types of supply chain API attacks
Let me give you a few examples of ideal attacks on API security to look for, thanks to these mobile apps, and how they can impact the supply chain.
Resource exhaustion and denial-of-service
Consider an API endpoint that does more than transfer sensitive data. Maybe it’s specific APIs that do heavy processing on the backend server. Remember, most mobile apps push all the heavy workload to the cloud for this very reason.
Now, look closer at the traffic. Are the requests able to be modified to trigger more processing? As an example, can you brute force the server to generate just-in-time reports that may affect usage before returning the data? Think distributed denial-of-service here.
At the very least, you might be able to prove resource exhaustion. So APIs that aren’t careful to identify authentication key usage may be exposing the website to unnecessary resource usage.
A resource exhaustion case study
A great example of this abuse was about a decade back with the Google Maps API attack thanks to an Improper Assets Management vulnerability. There was a rogue API exposed on the Internet that called into an old Google mapping API using a privately known API key that was leaked. It allowed developers to send requests from their own websites to gain access to mapping data without having to have an account with Google.
I guess Google wasn’t monitoring the deprecated endpoints much.
Eventually, the original customer who leaked their API key got locked out of the API when they maxed their request allocation for the service, preventing secure access for their users. This is the ultimate form of resource exhaustion and denial-of-service.
Cloud overspending & lack of cloud cost management
So consider that last API attack about resource exhaustion. That isn’t the only impact that can be demonstrated from hardcoded creds found in apps.
The original customer of the leaked API key was getting charged for every request. An attacker was able to build their own API client and consume the data for their users on their website, which allowed them to enable a reusable API endpoint.
This is an opportunity. You can showcase a lack of API security around the requests being made and the abuse of traffic to the third-party service. You can probably also demonstrate the inability of the customer to identify client access to cloud resources they are paying for, and the inability to monitor cloud spend before it gets out of hand.
Things like testing for governance around cloud cost management typically aren’t in the API Hackers’ playbook. I argue this is an IDEAL thing to add to it, especially if you are engaged in penetration testing.
Conclusion
I expect in the coming years we will continue to see more endpoints exposed in this way.
Developers will continue to bake cloud credentials into their apps and expose APIs because of a lack of understanding when it comes to access control within the libraries they trust.
We will continue to see traditional web applications impacted by these security misconfigurations and ultimately expose the brittle nature of vulnerabilities in the supply chain of APIs.
So leverage it. Expose these broken user authentication vulnerabilities and show how the access control needs to be improved to secure the APIs you are testing.
Not sure how? There are lots of resources in my Ultimate Guide to API Hacking Resources that can help. I’d suggest you check it out.
Happy hacking!
