This week, we examine a World Poker Tour website hack and also the exposure of Nagios Log Server API credentials, we explore an article on the causes of API drift, review common injection attacks targeting APIs, and highlight how DDoS campaigns are increasingly focusing on API endpoints.
Vulnerability: Security Pros Go All In on Poker Website
Security researchers Sam Curry and Shubs Shah uncovered a series of vulnerabilities that granted unauthorized access to the administrator panel of the online poker platform ClubWPT Gold.
Early in their investigations, the researchers discovered the full source code for the admin application exposed online. Using information from an exposed configuration file, hardcoded credentials, and easily guessed passwords, they were able to log in to a staging environment of the admin app.
Unfortunately, the same credentials were reused in the production site. Then the only remaining barrier to gaining full admin access to the production site was two-factor authentication (2FA).
That didn’t hold up for long. The researchers identified a vulnerable admin endpoint that failed to enforce authentication, allowing them to reset 2FA secrets for any admin user account as long as they could guess a valid user ID (uid).
Image from the report at samcurry.net
With this flaw, the team gained access to sensitive data on real poker players, including personal details, deposits, and account information.
While several weaknesses contributed to the compromise, the failure to enforce authentication on the admin endpoint proved crucial, since it allowed the researchers to effectively bypass 2FA protections in the production environment. Read the report.
Vulnerability: Credentials Exposed in Nagios Log Server API
In a previous issue, we covered an incident at OneLogin where sensitive client secrets were leaked in plaintext through a vulnerable API response. Researchers Seth Kraft and Alex Tisdale have identified similar flaws in the Nagios Log Server platform.
This issue was originally reported a few months ago, but it again highlights how common it is for APIs to expose highly sensitive data. In this case, a non-privileged user could send a simple GET request to a vulnerable endpoint and receive a list of user records, including usernames and API keys belonging to administrator accounts.
Researcher Seth Kraft also shared a short demonstration video of the exploit on LinkedIn.
Sample from exploit-db.com
This type of excessive data exposure vulnerability falls under OWASP API3:2023, and often occurs when an API is implemented to return entire database objects without proper filtering or authorization checks.
This is where defining and maintaining an OpenAPI definition for APIs can help, by forcing teams to explicitly document which response properties should be exposed, and by enabling automated checks to detect drift between the intended design and runtime behavior of the API. Read the article.
Article: Staying Ahead of API Drift
Continuing on the subject of API drift, Kin Lane of API Evangelist recently shared insights from his experience working on an API governance program at Bloomberg.
He points out how API drift often stems from gaps in communication and vocabulary between engineering and business teams. It’s an interesting perspective, because discussions of API drift typically focus on unsanctioned code changes, misconfigurations, or even malicious API tampering.
For those unfamiliar, API drift occurs when an API’s production behavior deviates from its documented specification. Distinct from the traditional monolithic applications, APIs are updated frequently to meet rapidly changing business demands, whether that means new services, integrations, or hooking up the latest AI tool to some product or service.
As Kin points out, minimizing API drift requires maintaining alignment between product intent, usually captured in text-based documentation, and development intent, expressed through schemas and API definitions. Bridging these silos is a key factor to keeping APIs predictable and avoiding drift. Read the article.
Article: Risks of API Injection Attacks
An article by Nordic APIs sets out some of the more dangerous or novel injection attacks that often target APIs.
The article includes examples of various attacks delivered through API properties and headers, as well as specific injection cases involving template values or URLs provided as user input, both of which we’ve covered in previous issues of this newsletter.
As an aside, it’s curious that injection vulnerabilities aren’t called out in the OWASP API Top 10 list. Admittedly it’s already a separate category in OWASP Top 10 2021, A03: Injection, but then so is Security Misconfiguration (A05), which is also included in the API Top 10 (API8). Given the prevalence and risk of injection attacks on APIs, it might be worth emphasizing in the OWASP API vulnerability list.
Automation tools like DAST (Dynamic Application Security Testing) are often used to simulate traditional injection attacks against websites and web applications using wordlists of common attack patterns. The challenge with APIs is that each one is unique, supporting a different set of input properties and processing logic. You have to get really lucky with DAST to hit on the particular injection pattern that can exploit a flaw in any given API. Knowing something about the context of the service behind the API helps to generate more relevant and targeted injection tests. There isn’t much benefit in running hundreds of SQL injection attacks against an API that uses a NoSQL database!
A great article on API vulnerabilities and well worth a read.Read the article.
Article: APIs in the Crosshairs of DDoS Attacks
In the previous issue of the newsletter, we covered a case of an accidental denial-of-service incident on one of Cloudflare’s API endpoints caused by a frontend coding error. A recent article on EM360Tech, “The API Blind Spot: How DDoS Attacks Are Bypassing Defences”, is a timely reminder of how API-targeted DDoS attacks are evolving, and why they’re often overlooked.
The article highlights the growing complexity of DDoS threats against APIs, pointing to both poor development practices and the emergence of AI-driven attack automation. It also outlines several attack types now common in the industry, from familiar flood and credential-stuffing attacks to more subtle Slowloris and Amplification attacks that can exhaust API resources while appearing as legitimate API traffic.
The key takeaway: mitigating API-level DDoS requires building secure APIs from the earliest stages of development, and implementing strong authentication and authorization ensures that only legitimate API users can access resources. Combined with measures like rate limiting and enforcing constraints on payload size, these practices help reduce the risk of API abuse and make DDoS attacks harder to execute. Read the article.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
