The internet has tons of services we love to use every day, whether it’s posting a picture on Instagram, shopping on Amazon or playing an online game with your friends. These apps and services work by interacting with servers using something called “application programming interfaces”, or “APIs” for short.
Writing good APIs is a time-consuming affair that requires quite a bit of labor. A well-written service with low downtime often involves APIs that are optimized for high usage with testing being an integral part of the development process. API testing is the process of confirming that a single endpoint returns the correct response to a given request. This process was quite tedious in the past when testers had to write test cases and commands using different methods.
In 2012, Indian software developer Abhinav Astana created “Postman” to solve this issue. It proved to be immensely popular, and Postman is arguably the hottest service for API testing right now. It began as a simple API client and debugging tool, which quickly grew into a very adaptable API testing solution with 20 million users.
The Problem at Hand
Applications and services often have more than one APIs for different functions and features called as collections. Users on Postman can upload their “collections” and “workspaces” in a public manner. This is done with the aim of collaboration, in a manner similar to GitHub. Public collections enable easy sharing of API requests and environments, facilitating collaborative development and testing across different team members or even different organisations, for example, to demonstrate things like service level agreement implementations in a practical sense. Other developers can then use these collections as a starting point, reducing the amount of work needed to set up their own requests.
Since these collections are public, users sometimes accidentally share things that are sensitive and high-risk. This typically happens due to simple human error, but can end up costing organisations massively if they end up in an attacker’s hands!
Leaked Secrets
The obvious problem is leaked secrets. API keys, Passwords, Tokens, etc. Leaked secrets such as API keys, passwords, and tokens represent a critical vulnerability. In February 2024, GitHub detected 1 million confirmed secret key leaks in just four weeks alone! (source: https://github.blog/2024-02-29-keeping-secrets-out-of-public-repositories/). These secrets are essential for the security of web services and are used to authenticate and authorise access to software applications and IT services. If these secrets are exposed, malicious actors can gain unauthorised access to systems, impersonate legitimate users, and potentially access sensitive data. The leakage of such information can lead to widespread security breaches, resulting in substantial operational and reputational damage to an organisation.
Broken API Access Authorization
Another major reason APIs are affected is when access to them isn’t as restricted as it should be. BOLA (Broken Object-level authorization) and BFLA (Broken Function-level authorization) attacks occur when an API does not have sufficient authorization controls in place. For example, an exposed GET request endpoint during testing may give exposure to details such as customer PII, which can be used for social engineering attacks. An infamous BOLA incident occurred on the Apple Store website’s internal API, where a user’s package order status could be tracked via the “/api/Home/GetOrderStatus” (https://www.resecurity.com/blog/article/vulnerabilities-in-e-commerce-solutions-hunting-on-big-apples) endpoint by simply providing an email address. Email addresses can be found quite easily on websites like GitHub and Twitter, giving malicious parties such as criminals and stalkers an insight into where a victim might be living or working, their buying habits, and canceling or placing orders on their behalf via the customer care helpline.
How an attacker may destroy all of your company’s hard work (source: OWASP)
When used in combination, these flaws can be quite severe. A broken object-level authorization or a leaked API key with full permissions can allow an attacker to make a simple GET request to access a user’s primary identifier, such as their UUID, email ID, or account name. Broken or improper function authorization would allow an attacker to use this leaked API key or email ID to run a “DELETE” operation to simply delete their account and any information associated with it. Sometimes, an entire database may be deleted this way, causing huge financial loss! This occurred in 2022, when the Russian Federal Agency for Air Transport (Rosaviatsiya) had around 65 terabytes, or 70% of its data deleted, causing a million-dollar loss after a password was leaked online. It remains unrecovered to this day. (source: https://www.aerotime.aero/articles/30871-70p-of-data-deleted-in-rosaviatsiya-cyberattack-reports)
Leaked logs and Business logic
If your API setup is exposed to these attacks, a malicious user can do anything ranging from changing naming conventions, modifying database schemas, and even deleting data effortlessly, therefore crippling business operations.
(source: OWASP)
One passive issue is leaked API logs and transactions. Since one API key is all an attacker may need to sweep data out of your databases, logging environment conditions such as server resource usage (CPU, storage throughput, etc.) can help you understand if you are being attacked through a Distributed Denial of Service (DDoS) setup. Handling API requests necessitates various resources including network bandwidth, CPU, memory, and storage. Service providers offer additional resources like emails, SMS, and phone calls through API integrations, which incur costs per request. Restricting the volume of requests to a specific service conserves computational resources and helps flag unusual activity.
Environment Exposure
API logs may also leak infrastructure metadata such as details about an organisation’s environment and server configuration, such as subdomains, endpoints, IP addresses, ports, and details about cloud services and many other attack vectors. If such information is leaked, key vulnerabilities could be exposed to an attacker, from which they can develop an entire attack roadmap to target specific systems, potentially facilitating attacks such as Distributed Denial of Service (DDoS) and phishing-based ransomware attacks. Last year, Indian startup HCL Technologies was affected by a ransomware attack when phishing was used to gain access to an isolated cloud environment that was leaked in API logs. This caused the company’s shares to plummet 3.24% in a single day and led to reputational loss (source: https://therecord.media/hcl-india-ransomware-attack)
Our Research
We at the RedHunt Labs Research team have several tools that help us continuously monitor sensitive organisation data such as leaked secrets, API keys, and much more. So we decided to embark on a research project, scanning as many Postman collections, environments, and requests as we could – with the intention of assessing the severity of this problem and raising awareness of the attack surfaces that could be exposed in these situations. We expected to discover a few user credentials for small-scale applications, but we later found several organisations across different industries that were quite vulnerable in this area.
Methodology
Using the Postman API and our in-house tools, we were able to perform a scan of around 200,000 Postman environments from the past year (2023-2024) that included workspaces, collections, and global variables. Within these environments were more than 530,000 requests that users configured to communicate with various public API endpoints. Thankfully, not all of them had leaked secrets. We captured around 84,260 from a years’ worth of public postman collections and workspaces, which consisted of folders, globals, and requests that the API returned to us.
Our secret monitoring setup uses a mix of regular expressions for popular secret types (such as usernames and passwords, Bearer Tokens, etc.), as well as custom definitions we developed as a part of our attack surface management platform. These are run over several hundred thousand files at a time and take mere milliseconds to complete one scan!
Findings – tens of thousands of tokens, secrets, keys, and more!
| Top secret types | Count |
| JSON Web Token (JWT) | 70,875 |
| Bearer Token | 5,500 |
| Postman API Key | 2,037 |
| Base64 Authentication Credentials | 1,506 |
| Docusign API Key | 738 |
| Firebase Cloud Messaging API Key | 585 |
| Github Access Token | 555 |
| Azure Subscription Key | 521 |
| MailGun API Key | 317 |
| AWS Access Key | 228 |
| Google Cloud API Key | 223 |
| Google Cloud OAuth Secret | 200 |
| OpenAI API Secret Key | 130 |
| Private Key | 80 |
We were able to find tens of thousands of generic credentials, including 70,000 JSON Web Tokens (JWTs), more than 5,500 Bearer Tokens, over 1,500 Base64 Authentication Credentials, and much more. We also found hundreds of cloud service credentials, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), the official Postman API, Docusign, Firebase, GitHub, GitLab, and so on. The map below sums up the top secret types we were able to collect, with the quantity of each secret type.
Approximately 86% of our findings were hardcoded JWT tokens. These tokens are used to authenticate data between a backend (or server) and a client. When used appropriately, they secure systems by sharing a temporary secret between parties.
Most tokens of this nature are majorly used for authentication. A bearer token is another form of authentication. The client just needs to show it to a server to gain access without having to prove who you are every time, by “bearing” or holding the pass. This type of secret is more susceptible to exploitation, due to its simplistic nature.
Shared secrets such as JWTs, Bearer tokens, and base64 encoded credentials are used across multiple deployments and platforms and are thus a bit vague to explain and test, since no two implementations are the same. The overwhelming quantity of these tokens that we caught also makes it a bit difficult to inspect on a per-result basis and shadows other secret types.
To overcome this, we will simply trim our results to eliminate generic secret types and target leaked secrets that more specifically affect popular cloud services.
Thankfully, we captured several other interesting secret types as well. These included online services such as GitLab, GitHub, Microsoft Azure, the Postman API itself, and many more! There are several tools available online to test these credentials to check if they are false positives or actual credentials.
Sample Case
Here is a sample secret that we found in a leak. Upon inspection, the user here seems to have manually pasted a key to an Amazon service, which appears to integrate with their machine learning platform SageMaker.
Amazon uses two types of keys for identity access management – Access keys and Secret keys. The Access key ID is an account identifier, while the secret key is like a private key for the user that is only shown once (for security reasons). Gaining access to both these keys gives us access to whatever AWS services and products this account is configured to use.
Since we have both the secret key and the access key, we can now pass it through a simple tool like ScoutSuite. A tool like this can help us audit cloud services quickly and easily using these credentials. This gave us the following list of services this organisation’s account uses.
In the spirit of responsible disclosure and business ethics, we refrain from directly accessing sensitive information and performing operations like create, read, update and delete (CRUD). However, from an attacker’s point-of-view, running a simple command like “aws logs describe-log-groups” can give tons of valuable information like CloudWatch logs. These logs can expose the entire backend of projects and may contain sensitive information like environment details and what API endpoints exist. It may also contain debug logging statements, that may contain more program logs, testing secret keys, usernames, emails, and much more.
Upon inspecting the logs, we found that the keys belong to a UK-based tech startup. We then proceeded to take the appropriate steps to notify them of this situation. And this is just a single example of such an occurrence. Last year, we discovered a leaked API key from Mercedes-Benz on our GitHub monitoring setup that exposed all their internal repositories, trade secrets, and business intelligence. You can read more about this here: https://redhuntlabs.com/blog/mercedes-benz-source-code-at-risk-github-token-mishap-sparks-major-security-concerns/
Preventing Exposure
1. Keep your Postman workspaces private and regulate user access
In an obvious step, if your organisation uses Postman.com, make sure all your collections are private, and that only your trusted developers and testers have full access. When deploying API keys and credentials, make sure there is proper access control to them. Never deploy credentials with full or “super user” style access and make sure your production API keys are not committed to an online service like GitHub.
2. Monitor public-facing code repos and Postman instances for API secret leaks and credential leaks.
Postman.com has an inbuilt feature where you can be notified if you accidentally commit a credential within a POST request. However, this feature works only in collections you create and write to, and does not give you total insight across Postman workspaces and collections.
At RedHunt Labs, we have several tools and technologies available to detect leaked API keys, passwords, and credentials across multiple cloud services, from Postman to DockerHub and Bitbucket – all in near real-time.
Click here to request a demo and check if your organisation has an exposed attack surface.
3. Dilute, regulate, and restrict API and data access
Poorly implemented authentication mechanisms that cause BOLA and BFLA, such as an exposed endpoint, unauthenticated access, lack of data encryption, etc., may allow attackers to compromise authentication tokens, exploit logical and implementation flaws, or even simply read plaintext data. For example, organisations may neglect to conduct method-level authorization checks to validate that the object being accessed or modified falls within the user’s authorization scope. This is typically fixed by setting and using least-privileged access (restricting access) as much as possible. Using end-to-end encryption via TLS also prevents data from being further analysed in the event an unexpected endpoint exposure-based leak does happen.
Common developer misconfigurations, such as not sanitising requests to APIs are also common reasons data breaches and SQL injection attacks occur. Validating inputs and sanitization ensures and verifies that data sent to input data is stripped of harmful characters and mitigates the risk of attacks such as SQL injection attacks, cross-site scripting, and command injections.
4. Log and monitor your API, database, and server operations
Recording all access and actions such as data modification and deletion in databases, when an API call was triggered, the time of the request, and the outcome can help you pinpoint specific vulnerabilities within your organisation and patch them up within time to prevent additional loss. It is important to make sure access to this is restricted as well, to prevent environment variables exposure as discussed above.
Wrapping It Up
We at RedHunt Labs help organisations continuously discover their Attack Surface across Postman collections and workspaces, subdomains, containers, git repos, etc., and help identify security risks on External Attack Surface before attackers do.
Our Agentless Attack Surface Management Platform NVADR has capabilities to continuously monitor your publicly exposed Postman workspaces and collections from across the internet and has been able to identify data leaks for many of our customers.
If you would like to check out your organisation’s Attack Surface, we also offer a Free Scan. Request a Free Scan here.
.
Want to check out your organisation’s Attack Surface for FREE?
Book Your Scan with us today!
.