This week, the main news is coverage of the huge data breach affecting the Australian telecommunications company Optus, with APIs as a likely root cause. We also have articles on API security, authentication and authorization vulnerabilities, and how Docker REST API exposure can present risks.
Breach: APIs at the root of Optus data breach?
The big news over the last two weeks has been the data breach at the Australian telco Optus. At least 2.1m Optus account holders had at least one form of ID exposed, with at least 150,000 passports and 50,000 Medicare numbers stolen. Although full details are unknown at the time of writing, initial reports indicate that unauthenticated API endpoints may have been at the root of the breach.
As is often the case, the breach was not an act of super sophisticated attackers using advanced methods โ anyone with the ability to exercise an API would have been able to execute an attack.
The article highlights some of the key findings known thus far:
- The API had no rate-limiting, allowing the attacker to exfiltrate huge amounts of data.
- The API had apparently never been pen tested before it was deployed.
- Most surprisingly, the API appeared to be unauthenticated โ a rather severe case of API2:2019 โ Broken authentication.
- Optus did not appear to classify their data according to sensitivity, nor did they implement any reasonable data retention policy.
- Optus did also not use any form of data masking with confidential information.
- The Optus network and endpoints were not actively monitored to detect malicious activity.
The author makes several excellent recommendations. Firstly, similar to payment gateways for sensitive payment information, a personal information gateway should be used to protect PII. Secondly, data handling, classification, and retention policies should be specified and mandated for all organizations.
From an API perspective, I would also suggest that following even the most basic API security best practices would have entirely eliminated the API-related issues in this breach.
Article: API security guide
API security guides and best practices are always popular with readers of the newsletter, and this week we have a great one from Ben Eaton.
Eaton gives a great discussion on why API security differs from web application security, and thus why your tools and methods may not be suited to API security. The key differences are:
- The traditional network perimeter is being eroded primarily by APIs and network controls no longer offer the same levels of protection.
- For web applications, a client uses a web browser that a WAF can validate. However, with APIs, there is no standard client, meaning that client enforcement is difficult โ this makes it more difficult to distinguish between expected behavior and bot attacks or DDoS attacks.
- Attacks cannot easily be detected by examining incoming requests payloads.
- Frequently changing incoming request formats present challenges to creating WAF rules.
A useful guide and one worth bookmarking.
Article: Authentication and authorization vulnerabilities
Another popular topic with our readers is authentication and authorization best practices. An interesting article from SC Magazine covers some of the common reasons for authentication and authorization vulnerabilities.
The article takes a broad view of the types of vulnerabilities, starting with basic coding errors, such as insecure value comparisons (like equality testing) and path-based authorization vulnerabilities. Another common pitfall is the lack of a trusted authorization source: developers need to make an authorization decision when clearly this decision should be made elsewhere, by a central enforcement point. To continue the list of usual suspects, there are also API5:2019 โ Broken function level authorization and token mismanagement.
The article provides excellent guidance on how to eliminate many of these vulnerabilities, such as:
- Incorporate access control into the API lifecycle as early as possible.
- Implement access control at the application level, rather than at the server level.
- Review the code of critical code paths in access control logic.
- Use specialized libraries for access control rather than implementing your own bespoke logic.
- Check any an all access control on third-party infrastructure.
Some interesting takes on a familiar topic.
Article: Docker REST API exposure presents risks
AS our last piece this week, we have coverage of the risk that exposed Docker REST API endpoints can present, courtesy of Dark Reading.
Researchers at TrendMicro placed a Docker “honeypot” on the internet, leaving an exposed REST API endpoint. Among their findings were the activities of a well-known hacker collective TeamTNT who performed three different types of exploits. The researchers found that attackers hosted a malicious container image that contained rootkits, kits for Docker container escape, the XMRig Monero coin miner, credential stealers, and Kubernetes exploit kits.
As the result of their experiment, the authors recommend restricting Docker REST API endpoints to only local networks or trusted sources. They also recommend employing Docker hardening guidelines and ensuring that passwords are not stored in cleartext.
Docker is a powerful developer tool but presents a new attack surface. As the report concludes:
“Developer-centric tools like Docker have been known to be abused extensively. Itโs important to educate [developers] at large by creating policies for access and credential use, as well as generate threat models of their environments”
Event: 42Crunch at API World 2022
API World is the world’s largest vendor-neutral API-specific conference, and this year it takes place in San Jose from the 25th to the 27th of October. Join Isabelle Mauny (co-founder and Field CTO of 42Crunch) at the conference where she will be presenting on:
- API Security 101: Top API Vulnerabilities and How to Address Them
- How a Combined Shift-Left and Shield-Right Approach Delivers End-To-End API Security
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
