This week, we have news of three vulnerabilities. First up is a supply chain vulnerability in the IBM Cloud platform, which is reported to be the first of its kind to affect a cloud provider. The second is another case of hardcoded API keys, this time in the Algolia AI search portal, and the third is a fantastic piece of research into a JSON-based SQL attack on WAFs. Finally, we have coverage of a report on the increase in attacks on shadow APIs.
Vulnerability: Supply chain vulnerability in IBM Cloud
The first vulnerability this week is, according to security researchers at Wix, the first of its kind affecting the public cloud. With some dramatic flair, the researchers coined the name “Hell’s Keychain” to describe their attack technique which is meticulously described in their blog. The researchers released their findings to the IBM Cloud team, who responded promptly to close the issues. No public exploits of this vulnerability are suspected.
The vulnerability comprises a chain of three exposed secrets which can be combined, together with a poorly segregated network, to perform access to an underlying PostgreSQL database. The three exposed secrets were:
- Kubernetes service account token: the researchers used an SQL Injection attack on the PostgreSQL database to obtain access to a command shell on the host from where they were able to inspect environments and discover Kubernetes tokens allowing access to a Kubernetes cluster.
- Container registry password: the researchers then discovered a secrets file containing various access credentials for a private container registry. Although not core to this vulnerability, this flaw could have enabled an attacker to access and modify the private container registry, possibly with rogue or malicious images.
- CI/CD server credentials: the researchers then discovered that they could scan container images for secrets which included the root credentials to the CI/CD systems, including FTP credentials and internal artifact repository credentials.
In order to utilize these obtained credentials, the researchers attempted to access the internal resources and – to their surprise – discovered that this internal network was accessible from the PostgreSQL host. They determined this to result from poor network design, specifically not isolating subnets.
The researchers concluded with the following advice on how to prevent such vulnerabilities:
- Implement continuous monitoring of your environments for secrets โ be sure to scan code and container repositories, CI/CD pipelines, documentation, and script files.
- Use the network controls provided to isolate your production environment โ despite access to all the credentials, this exploit could have been thwarted by using well-designed network segmentation.
- Lock down your container registry โ limit access to your container registry to prevent container corruption.
This research shows how easily a talented attacker can pivot between multiple systems, harvesting secrets along the way which can be used to devastating effect. I would definitely recommend reading the full reported from Wiz.
Vulnerability: Hardcoded API keys in Algolia portal
Almost every other week features news of a supply chain vulnerability related to leaked API credentials. This week is no exception โ it’s the turn of the Algolia AI search portal covered recently by PortSwigger. The security research team at CloudSEK revealed that over 1550 applications were found to be leaking API keys and application IDs for the popular AI search platform. Even worse, the researchers discovered that some applications (57 at last count) had hardcoded highly critical Algolia Admin API keys. Obviously this type of leakage is particularly serious as it allows an attacker to gain full access to the tenant, including the ability to read private user information and usage and search histories.
The researchers made the following suggestions for dealing with leaked API credentials:
- Ensure that the credentials are revoked as soon as possible.
- Ensure that clients are designed and implemented with security in mind โ API credentials are highly sensitive and should be stored securely.
- When communicating with a sensitive API, use a proxy pattern to prevent direct access to the sensitive API, instead, allow the exposed API to do this communication on your behalf to prevent the leakage of high-sensitivity credentials.
Vulnerability: JSON-based SQL allows WAF bypass
We are still in January, and we have a contender for the top security write-up of 2023 โ Noam Moshe of the Claroty Research team on {JS-ON: Security-OFF}: Abusing JSON-Based SQL to Bypass WAF. I’d recommend reading the article in detail; in essence, the bypass works as follows: WAFs can protect against SQL Injection by doing a simple pattern match in the incoming payloads. The researcher discovered that he could exploit the built-in support for JSON in most SQL engines to bypass the most popular WAFs, which did not anticipate SQL Injection payloads within the JSON body. This highlights the perils of the negative security model and the folly of using block lists.
The researcher discovered that whilst the majority of SQL database providers (PostgreSQL, MySQL, SQLite, and MS-SQL) have supported embedded JSON within queries for over a decade, the majority of popular WAFs do not parse JSON payloads in queries. The researcher tested against Palo Alto Networks, Amazon Web Services, Cloudflare, F5, and Imperva and found that whilst they defend adequately against SQL Injection in the raw query, but were blind to it when wrapped within a JSON object. All five vendors have been notified and are reported to have released updates that address the issues identified.
For me, this report illustrates two important considerations:
- Security tooling will always be on the back foot in addressing new attack vectors enabled by new features โ in this case, over a decade had passed before being addressed.
- The negative security model will always lack precision and be prone to missing attacks. Where possible, consider using the positive security model working against a precise allow list.
Thanks to Noam Moshe for this excellent research and accompanying write-up.
Article: Attacks on shadow APIs on the increase
Finally, this week, we have a quick read on the rise of attacks against shadow APIs. The topic of shadow APIs is a rising concern to security teams as the volume of APIs continues to increase. Due to the relative ease of creating and deploying APIs, zealous product developers are opting to release APIs outside of the standard, governed processes driving a rise in the number of these shadow APIs. Unfortunately, attackers have become wise to this fact and are focusing their efforts on these APIs which may be less rigorously designed, secured, and monitored.
The report indicated that an analysis of 20 billion transactions in the first two quarters of 2022 found that 16.7 billion of these were malicious and that up to 5 billion targeted shadow APIs. Although the report concludes that this is a rising problem, it concedes that this is one of the hardest problems facing API security today.
My recommendation is a combined strategy of governance (to prevent new shadow APIs) and API discovery (to identify existing shadow APIs).
Webinar: Protect Your APIs with Microsoft Azure Sentinel and 42Crunch Platforms
In the first of two events this week, I will present a webinar on how to use the recently released 42Crunch marketplace integration with Microsoft Sentinel to provide comprehensive monitoring, detection, and prevention of your API endpoints. The webinar will feature some walkthroughs of practical attacks and how to detect them โ be sure to reserve your place for next week January 31, 2023ย (8am PST / 4pm GMT).
This full agenda includes the following:
- Showcasing features of the new 42Crunch Microsoft Sentinel marketplace plugin.
- Creating alerts on common API threat conditions.
- Enrichment of API logs with threat intelligence data
- Detecting attack patterns for common adversarial tools.
- Using threat hunting to detect API attacks.
- Understanding of common bot behaviors and detection techniques.
- Generating notifications to 3rd party alerting services.
Event: 42Crunch and GitHub at CloudNativeSecurityCon North America
Attending #CloudNativeSecurityCon next week? Then join GitHub and 42Crunch for a networking reception of crafted cocktails and fine food and maybe a little chat about your API security options! Places are limited, so register now.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
