This week, we have two vulnerabilities: an API vulnerability in the Delinea platform and a remote command execution (RCE) affecting Palo Alto PAN-OS devices. We also have articles on how to fix API design, seven ways to better manage supply chain risk, and whether OpenBanking will transform the future of finance. Finally, we have Dana Epp on how to use “naughty strings” to break APIs.
Vulnerability: Delinea patches API vulnerability
This week’s first vulnerability comes courtesy of SC Media, who report that Delinea, privileged access management (PAM) provider, confirmed a critical vulnerability in its Delinea Platform and Secret Server Cloud products on April 15, 2024. The vulnerability, identified as a flaw in the SOAP API, could allow attackers to bypass authentication, gain administrative access, and extract sensitive information if left unpatched.
Delinea has addressed the issue by patching the vulnerability in its cloud-based service and providing a remediation guide for its on-premises customers. They stated that they found no evidence of compromised customer data or attempts to exploit the vulnerability.
Security professionals emphasize the importance of immediately updating on-premises installations of Delinea Secret Server Cloud to mitigate the risk of potential network compromises and data breaches. If exploited, the vulnerability could grant attackers significant control over the network, enabling them to move laterally, escalate privileges, deploy malware, and launch ransomware attacks.
The article also highlights API security’s importance, as attackers know that most organizations lack adequate protection for their internal API assets:
“Attackers are well aware that most organizations do not have API security solutions protecting their internal API assets”
Vulnerability: API vulnerability in Palo Alto devices
This week’s second API vulnerability comes courtesy of Security Boulevard, covering a remote code execution (RCE) vulnerability in the Palo Alto PAN-OS devices. The vulnerability potentially allowed attackers to execute commands on the devices, which ultimately could have led to device takeover. The vulnerability (tracked as CVE-2024-3400) has already been addressed by Palo Alto, which recommends that customers immediately update their devices to a version of firmware greater than 10.2. There are no indications that this vulnerability was exploited in the wild.
The exploit itself was surprisingly simple, involving the injection of code into an XML RPC request as shown:
<cmd code="ping">OS command exploit is there</cmd>
This type of attack can be prevented by using well-tuned WAFs, while dedicated API protection solutions offer excellent defenses against injection attacks of this type.
An interesting side note about this vulnerability was that GitHub responded quickly to remove copies of proof-of-concept and exploit code from their repositories. Despite their efforts, the code spread rapidly in the cybersecurity community. Fortunately, in this case, Palo Alto rapidly released a patch.
Article: How to fix API design
The next article comes via The New Stack and covers API design, why they consider it to be in a poor state, and how this impacts, among other things, API security. The fundamental issue with API design concerns the long lifetime of APIs, which means that poor decisions often exist longer than ideal to maintain backward compatibility and legacy systems.
Some of the impacts of poor API design include the following:
- Limited scalability: Poorly designed APIs can hinder a business’s ability to scale effectively, leading to performance issues, slower response times, and downtime during high-traffic periods. Backward compatibility is also a concern, as older clients using outdated API versions can negatively impact overall system performance.
- Increased costs: Maintaining and managing poorly designed APIs can consume significant resources, leading to increased operational costs. If an API is not designed to scale, it may require substantial resources to fix as the business grows, further impacting the organization’s bottom line.
- Security risks: Developers often overlook security when designing APIs, focusing more on functionality. This can lead to vulnerabilities, such as buffer overflow attacks, which can be exploited by attackers. If API security vulnerabilities are exploited, it can result in significant financial and reputational damage to the business.
The author then describes five steps in which API design can be improved, namely:
- Prioritize API design from the start: Focus on designing the API correctly, considering scalability, security, and long-term maintenance. A well-designed API can minimize future costs, reduce security risks, and ensure the API can help the business scale its digital operations.
- Adopt API design best practices: Use RESTful principles, consistent naming conventions, and API description languages like OpenAPI or RAML. Adhering to the OpenAPI Specification can provide a framework for planning, designing, building, testing, and documenting APIs, reducing the likelihood of design errors and improving overall API quality.
- Understand and prepare for security risks: Design APIs to handle potential security threats, such as buffer overflow attacks and SQL injection. Validate and sanitize input data, implement rate limiting, and use secure protocols like HTTPS. Implement API security tools to monitor and protect against automated and zero-day attacks.
- Regularly audit and update APIs: Conduct regular reviews and updates to identify and rectify design issues before they become major problems. Test APIs for performance and security vulnerabilities, gather user feedback, and create new API versions when necessary, following a proper versioning strategy.
- Plan for API evolution: Design APIs to accommodate future changes and additions without breaking existing functionality. Plan for deprecating old versions, communicating changes to users, providing clear migration paths, and supporting old versions for a reasonable period. Establish a clear deprecation policy and communicate API changes well in advance.
From my perspective, security should be a first-class class citizen in the design process. Too often in this newsletter, there is evidence of vulnerable APIs due to poor design decisions, such as a lack of rate limiting or information leakage. By considering these issues at design time, the API can be designed to be secure at the outset.
Article: Seven ways to better manage risk
In the last two quarters, we have seen a steady increase in the number of leaked API keys and tokens. I would be inclined to say that this is most likely the top threat vector-facing API currently. The team at ReversingLabs has put together a helpful guide on better ways to manage your supply chain risk in the event of credential leakage. The report highlights the magnitude of the problem — GitHub reported a 28% increase in 2023 over the preceding year and also reported a 22% increase in the number of repositories.
The report lists seven ways to manage risk resulting in leakage, as follows:
- Swift mitigation is crucial after an exposed secret is discovered.
- Developers need guidance, not just alerts, to rectify their mistakes effectively.
- Certain file types, such as .env files, are more likely to leak secrets.
- Automated detection is necessary but insufficient on its own.
- DMCA notices can be used to stop leaks but have limitations and risks.
- AI tools like ChatGPT cannot be relied upon to block leaks effectively.
- Compromised secrets must always be revoked, as merely hiding the leak is ineffective.
From my own perspective, prevention is always better than cure when it comes to secret leakage. Easy wins can be achieved by using a good secrets manager or vault and by preventing inadvertent long-term storage of credentials (for instance, by preventing them from being committed to GitHub). The other key piece of the puzzle is to detect a leak as early as possible and then have a robust process to revoke and re-issue credentials.
This is a hard problem to solve, but one I’m optimistic we as an industry will crack.
Article: Will OpenBanking transform the future of finance?
I have recently written about addressing API security regulations in financial services, and our next article discusses how OpenBanking will transform the future of finance. The report focuses on recent growth figures relating to OpenBanking in the UK, where over 11.4 million payments were processed in July. This reflects a 102% year-on-year growth, suggesting an increasingly rapid adoption. The article rightly highlights the concern around the exposure to risk that may result from this growth via the proliferation of open APIs. As the sector shifts to an API-first approach, scaling without a clear security strategy can harm the entire UK financial sector’s progress toward API growth. Many organizations lack full visibility into their existing APIs, which are proliferating faster than DevOps teams can release patches or keep up with their API inventory.
The article recommends that financial institutions implement a proactive API security and governance strategy to ensure the success of open banking. This strategy should be centered around three fundamental building blocks:
- API governance for visibility.
- Improving cross-team collaboration between development and security teams.
- Taking a multi-layered approach to protect against both external and internal threats.
The authors conclude along similar lines to my own views, namely the need for a multi-layered approach to API security, as a perimeter-only approach is insufficient. This approach should include measures such as multi-factor authentication, enhanced monitoring, privilege management, and application-level controls to identify threats beyond the perimeter.
Guide: Breaking APIs with “naughty strings”
Finally, this week, we conclude in the time-honored manner by featuring Dana Epp’s guide to breaking APIs with “naughty strings.” The article describes an attack technique that uses a large list of strings, which are problematic for APIs with poor input validation. Using such strings can elicit unexpected behaviors from APIs, often resulting in information leakage or injection attacks through access control bypasses.
Dana covers the following topics in the guide:
- Obtaining a suitably large list of “naughty strings.”
- Using the strings in Postman
- Using the strings to crack a login form in the crAPI application
Thanks to Dana for another top article.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
