This week, we look at the recent data breach at the Internet Archive and the critical role of API token management. We have a report from Trend Micro detailing security issues with API Gateway deployments, and we look at recently discovered OWASP API vulnerabilities in popular enterprise and open source platforms. Also a quick look at the new GNAP protocol and what it offers over OAuth 2.0.
Vulnerability: Key Lessons at the Internet Archive
Since early October, the Internet Archive, home of the popular Wayback Machine web archive, has suffered a number of high-profile attacks by groups credibly claiming to have breached Internet Archive’s systems and platforms.
According to one report, the attacker initially gained unauthorized access after discovering an exposed Gitlab authentication token on an Internet Archive development server. The token was reportedly exposed for over two years, yet it still allowed the hacker to access Internet Archive’s source code on Gitlab. From this source code, additional tokens were discovered, including an API token for the company’s Zendesk support system.
The Zendesk API token allowed the hacker to access over 800,000 support tickets. Many of the tickets were submitted privately by users and included identifying information. It’s worth noting that two weeks after the issue was reported to Internet Archive, the Zendesk API token could still be used to access their admin account.
Both the original Gitlab token and the Zendesk API token appear to be long-lived tokens or to have no expiration date. A thread on Zendesk support also indicates that Zendesk API tokens (really API keys) do not limit the scope of access by role or resource.
This type of token management isn’t the root cause of the breach, but it can certainly increase the likelihood of persistent attacks and compound the damage by granting all-or-nothing access to systems and resources.
API keys are particularly prone to this type of abuse when used for purposes other than identifying an API client. You can read more about best practices for API token management in this (still very relevant) 2018 article.
Industry Report: Is your API Gateway Secure by Default
Secure by default is a product development approach that shifts the burden of security from the user to the product manufacturer. According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA):
“Secure-by-Default” means products are resilient against prevalent exploitation techniques out of the box without additional charge. These products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them.
In contrast, a recent report from Trend Micro examines the default settings of two popular API gateway solutions, APISIX and Kong, and identifies a number of critical vulnerabilities that could be exploited to compromise the API gateway platform, including:
- Use of default admin passwords
- Passwords stored on the platform in clear text
- Security tokens exposed in log files
- Platform administration access exposed on all network interfaces
In addition to the insecure defaults, some API gateways support community plugins to extend the functionality of the platform. Installing a community plugin can introduce new vulnerabilities into the API gateway and compromise the protections it’s designed to provide for your APIs.
For example, API gateways typically implement authorization protocols such as OAuth and OpenID Connect. API teams can offload the burden of implementing these protocols to an API gateway, allowing the team to simply configure authorization flows for their APIs instead of coding from scratch.
However, if the API gateway itself is vulnerable to an attack due to insecure default settings or from installing a vulnerable plugin, the authorization controls protecting your APIs may be affected.
The report examines these and other security issues with the APISIX and Kong gateways in particular, though it can serve as a useful guide for reviewing your own API gateway deployments, which may suffer from similar vulnerabilities.
Industry News: An RFC for GNAP
Speaking of OAuth, have you heard of GNAP?
GNAP (the Grant Negotiation and Authorization Protocol) was recently published by the IEFT as RFC9635. According to one of its authors, Justin Richer, GNAP is the result of an investigation into the shortcomings of the popular OAuth protocol for delegated authorization, and is already used in scenarios such as online payments and key management.
Reading some of the documentation, it looks really promising. Appendix A provides the TL;DR you’re looking for to understand the use cases where GNAP can be better suited than OAuth.
The section on ‘consent and authorization flexibility’ caught my attention.
“OAuth 2.0 generally assumes the user has access to a web browser. The type of interaction available is fixed by the grant type, and the most common interactive grant types start in the browser… GNAP allows a client instance to list different ways that it can start and finish an interaction, and these can be mixed together as needed for different use cases. GNAP interactions can use a browser, but they don’t have to”
I recently worked on building a set of APIs for a demo application, and wanted to add an OAuth delegated authorization flow. Figuring out which grant type to use quickly became a challenge. In the end, nothing really fitted neatly (among other things I wanted to avoid using a browser).
The kind of flexibility that GNAP claims to offer could be a great benefit to API developers, and simplify the building of bespoke authorization solutions.
Vulnerability: Injection attacks on Palo Alto Expedition platform
Palo Alto Networks Expedition is a tool that allows users to migrate firewall configurations from other vendors, such as Checkpoint or Cisco, to a Palo Alto Networks PAN-OS firewall.
Two critical vulnerabilities were recently discovered in the platform API that allow both command injection and SQL injection attacks.
A detailed report from Horizon3.ai includes an account of their research as well as a proof of concept demonstrating how to manipulate API input parameters to gain unauthorized database access or execute malicious commands on the Expedition system.
Injection attacks are a common way for threat actors to find and exploit API vulnerabilities, by sending malformed data in parameters or headers that are not properly validated by the API.
SQL injection, command injection, and path traversal are all examples of injection attacks.
Palo Alto Expedition users are advised to update to v1.2.96 or later. Also, all firewall usernames, passwords, and API keys processed by Expedition should be rotated after updating.
Vulnerability: API Incident on Trend Micro’s Cloud Edge
Cloud Edge is a unified threat management solution from Trend Micro. According to a report from Cyber Security News, a vulnerability was discovered in a Cloud Edge REST API that exposed the appliance to command injection attacks. A successful attack allows a hacker to execute malicious code on the appliance in the context of root.
Similar to the Palo Alto vulnerability mentioned earlier, the vulnerable Cloud Edge REST API accepts user-supplied input without proper validation and uses the input to execute a system call. The lack of input validation creates a vulnerability through which the attacker can control the commands executed on the appliance.
Cybersecurity agencies such as CISA and the FBI in the United States are urging software development teams to adopt secure-by-design principles to prevent common vulnerabilities such as command injection during the design and development phases.
Trend Micro strongly encourages users to update to the latest version of the product.
Vulnerability: How to identify SSRF vulnerabilities
I recently noticed two incidents of server-side request forgery (SSRF) that are worth looking at to illustrate how the vulnerability can occur in your API code and how to avoid it.
An API can be vulnerable to SSRF if it retrieves resources from a remote location based on a user-provided location (e.g., a URL, hostname, or subdomain). The API should carefully inspect and validate user input to ensure that it does not point to an unexpected location.
PostHog
PostHog is an open source product analytics platform used by product development teams. A security advisory reported a Server Side Request Forgery vulnerability discovered in the PostHog platform API, which was quickly patched by the team.
The root cause and subsequent fix can be seen from the associated code changes. The ‘subdomain’ property is set by user-supplied data in an API request. A malicious user could set an invalid subdomain value and cause the API to access resources in an unexpected location.
The fix, as demonstrated by the code change, was to set constraints on the input value, thereby blocking invalid or malicious input with a HTTP 400 response.
Plane
Plane is an open source project management tool for running development cycles and managing product roadmaps. An SSRF vulnerability was recently reported on an image retrieval service on the platform. A POC demonstrates how an overly permissive wildcard pattern (“**”) on a ‘hostname’ input property was the root cause of the vulnerability. This allowed a user to set any value for the hostname.
This SSRF vulnerability was fixed by removing the permissive pattern and preventing resource retrieval from arbitrary remote sources.
Watch out for similar SSRF issues in your own APIs.
Webinar: Mitigate OWASP API Risks through Security by Design
The OWASP Top 10 API Security Risk list provides a clear roadmap of the most common and dangerous vulnerabilities that can compromise your APIs. I’ll be demonstrating in this webinar how to incorporate the OWASP guidelines into your security initiative to help build secure, resilient APIs by design.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
