This week, we have news of an API authentication bypass vulnerability in the Ivanti Sentry cybersecurity product and a report into Docker images that are exposing APIs and private keys. We also have articles on API security’s role in protecting retail apps, how APIs and generative AI interoperate, and how attackers bypass Web Application Firewalls. We conclude with Dana Epp showing how to use Postman Flows for exploiting APIs.
Vulnerability: API authentication bypass in Ivanti Sentry
First up this week is news of a vulnerability in the Ivanti Sentry cybersecurity product. The vulnerability (tracked as CVE-2023-38035) impacts versions 9.18 and earlier of the product.
The vulnerability allows an attacker to access an administration API endpoint (running on port 8443 by default) without any authentication at all. The API provides a number of high-privilege functions, including changing the configuration, running commands, and writing files to the system. Due to the impact of potential access, the vulnerability is rated critical and assigned a CVSS of 9.8. In their statement, Ivanti highlighted that the likelihood of real-world exploitation is relatively low since, in most cases, this administrative port will not be publicly accessible. As a precaution, they released a set of RPM scripts to patch the issue and advised customers to disable this administrative endpoint unless absolutely needed explicitly.
This is another example of API 02:2019 — Broken User authentication; in this case, it appears there was no authentication at all (never mind it being broken). Instead, the system designers relied on the port being disabled via configuration or being blocked by a firewall as a mitigation. Defense in depth is always the best strategy for a secure system.
Report: Docker images expose APIs and private keys
Next up is an interesting report featured in Security Boulevard, citing a report from Git Guardian on the prevalence of stored credentials within Docker images. The report cites previous research from Git Guardian into 10,000 Docker images and then more recent research from the RWTH University in Germany into over 300,000 Docker images on DockerHub.
The headline figure is the fact that 8.5% of the images contained stored secrets such as API keys and private keys. Breaking down the credentials by type revealed the following:
- 52,107 private keys
- 2,920 cloud keys
- 213 social media keys
- 25 keys for financial tools (Stripe, Square, PayPal, etc)
The researchers mention some caveats regarding the accuracy of their findings: firstly, not all keys could be tested and validated against their intended systems for validity (leading to false positives), and secondly, not all credentials were necessarily detected (leading to false negatives).
Whilst the adoption of containers has been a great boon to developers and IT teams, they do present an additional risk vector for security teams to consider. In my personal experience, I have encountered developers who have mistakenly assumed credentials embedded into a lower layer of a container image would not be accessible. An attacker can either use a tool to unpack the layers or just execute a shell within the running container to access any “secrets”. A container is not a secure storage medium.
This report shines a spotlight on an increasingly prevalent problem affecting API security, namely the leakage of keys and tokens. Remember to use a secure and robust credential storage mechanism, for example, a key vault, and do not rely on obfuscation, such as hiding credentials in a container image.
Article: API security’s role in protecting retail apps
The next article again comes from Security Boulevard and discusses API security’s role in protecting retail apps. The article highlights the growth of APIs, particularly within cloud platforms, where they form a vital part of the connecting fabric and the increasing attractiveness of APIs for attackers.
The article then makes a distinction between the control plane (which is largely the responsibility of the cloud provider) and the data layer, which is definitely the responsibility of the end user. Increasingly, this data layer is growing in complexity with both a north-south element (for external connectivity) and an east-west element (for internal connectivity between services). The report highlights the importance of data protection from a governance and compliance perspective and highlights many API data security risks that will be familiar to readers of this newsletter.
The most interesting part of the report is the discussion on cloud-native protection platforms, in particular, the protections that can be offered by modern so-called cloud application protection platforms (CNAPP). These offer end-to-end protection and complete lifecycle management of cloud-native applications, covering threats such as web application and API attacks and cloud, storage, and database attacks. As an example, a CNAPP typically encompasses the following:
- DevSecOps
- Cloud security posture management (CSPM)
- Infrastructure-as-code (IaC)
- Kubernetes security posture management (KSPM)
- Cloud infrastructure entitlement management (CIEM)
- Runtime cloud workload protection platform (CWPP)
This is another timely reminder that good API security requires a layered approach, including hardening and protecting your runtime environments using modern cloud-native protection platforms such as CNAPPs. It’s worth remembering, though, that regardless of how well the underpinning platform is secured, APIs will still be vulnerable if they are poorly designed or implemented or not tested sufficiently.
Article: How APIs and generative AI interoperate
The next article from Silicon Angle discusses the role APIs play in driving the adoption and integration of generative AI and how the two bring great opportunities but, with it, increased challenges for risk management. The democratization of generative AI (driven by the runaway success of ChatGPT) has enabled software engineers and developers to incorporate AI capabilities into the offerings, and APIs provide the vital connecting tissue between these integrations. The rise of so-called “citizen developers” using low-code platforms and API-connected AI services will be building the next generation of apps. Ironically, many of them will learn these skills using the very AI services they themselves are integrating.
More technically savvy users will continue to create complex software systems using multiple APIs and various AI and ML systems to solve some of the world’s hardest challenges. These solutions will then be offered back to the open market to be consumed via – you guessed it – APIs. This is a rose-tinted view of a future where we are locked into a spiral of continuous learning and technological advancement.
However, this leads to an increasingly complex web of connectivity between systems, which will begin sharing data with one another. This will lead to increasing complexity from a security and compliance viewpoint. Developers must be mindful of the various data privacy requirements associated with the systems they build and the risks exposed by simply connecting everything via an API.
Article: Common bypasses of Web Application Firewalls
The next article from The New Stack describes many of the techniques hackers use to attack and bypass Web Application Firewalls (WAFs). This is particularly interesting to API security practitioners since WAFs are commonly the only line of defense for APIs, and it is worth knowing their limitations.
The article first identifies some of the most common WAF attack types, including:
- Injection attacks: these may include SQL injection, command injection, and cross-site scripting attacks. Generally, these attacks seek to evade protections (in a WAF or in the backend API or application code) to allow attacks against the underlying systems, such as a database.
- Broken access control: these attacks either target missing authentication or insufficient authorization validation and are the most common attacks against APIs. WAFs in particular, are ineffective in protecting against this category.
- Vulnerable and outdated components: when a new vulnerability is discovered in a component, bot farms will scan the internet for publicly exposed instances to attack. WAFs are critical in protecting these types of attacks.
The article then describes the three types of WAFs, namely:
- Negative security model: this attempts to block so-called “known bad” via a “deny list”.
- Positive security model: this only allows so-called “known good” via an “allow list”.
- Hybrid security model: uses a combination of signatures (the deny list) and then checks if the request is allowed (the allow list). This improves efficiencies since block lists are easier to implement.
Now, how do attackers exploit WAFs in practice? Firstly, attackers know that analyzing traffic is computationally expensive and increases latency. To this end, they will exploit the limitations of WAFs by sending large packets (such as 8kB or more), which will not be scanned at all by many popular WAFs. Alternatively, attackers may pad their attack payloads by placing dummy data at the front of the payload and then placing the malicious payload at the end. The intent is to trick the WAF into allowing the packet once it has scanned a few kBs of innocuous data at the front of the payload.
Finally, the article concludes with three steps to improve your WAF security:
- Test your web applications with padded request data.
- Examine your web application logs to find request sizes greater than, say, 8kB to identify attacks.
- Determine if you can change your configuration to disable padded attacks (limit the request size, for example).
Web Application Firewalls are a useful tool in the armory of a defender, but it is worth being aware of some of their limitations and attack vectors.
Guide: Using Postman Flows for API exploits
Finally, this week, we finish with another of Dana Epp’s customarily awesome guides — this time, he shows us how to use the Workflows feature with Postman to exploit APIs. Dana describes the value of demonstrating an exploit in the real world rather than describing it at an abstract level. Certainly, from my experience, a developer is far more likely to implement a fix if they see their app being exploited with their own eyes.
Dana takes us through an introduction to Postman Flows (a GUI state-machine-like interface to automate API tasks), how to use it to implement some flows such as password reset and OTP enumeration, and how to use the Flow Query Language (FQL). He then uses it to crack the OWASP crAPI password reset function. As usual, it’s an excellent read, taking you through all the details and the many lessons learned in this example.
I’ve used Flows previously to do some very basic automation, but this gives a view of the advanced attacks that can be implemented using Flows. I am inclined to agree that the limitation in being able to export or share Flows is an unfortunate one; hopefully, the good people at Postman are planning updates on this one in the future.
Thanks again, Dana, for a great guide.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
