This week, an Authy API was misused to verify the registered phone numbers of millions of users and recent injection attacks are prompting US security agencies to promote secure by design for software development. A research team demonstrates IoT hacking via API.
As this is a significant milestone for 42Crunch and APIsecurity.io, namely our 250th issue, we are starting a new initiative. We’re inviting readers to share articles you’ve read that you feel merit inclusion in the newsletter. You can submit suggestions via email here. This week we feature two interesting articles from our APISecurity.io readers.
Breach: Another unsecured API vulnerable to mass data scraping
In a report released earlier this month, Authy, a provider of two-factor authentication (2FA) solutions, confirmed how a threat actor used an unauthenticated API to verify millions of users’ phone numbers registered with Authy to generate one-time passwords.
This incident is similar to another recent case of mass data scraping via Trello’s API, which I covered in depth in a recent 42Crunch webinar. Both incidents have common characteristics to avoid in your own API development:
- An API that does not require authentication. This means a malicious user can easily abuse the API without first creating an account.
- An API that does not enforce authorization. So, a user can retrieve account information about other users.
- An API that accepts an identifier like a phone number or email address and, if found, returns the user’s account information. This allows a malicious user to verify the existence of a user account for a given identifier.
- An API that does not enforce rate limiting, or where rate-limits can be bypassed. This puts the mass into mass data scraping!
An API that returns user account information should apply authorization and rate-limiting controls, to limit the information to authorized users and use cases only.
Vulnerability: Injection attacks prompt calls for ‘secure by design’
In a recent alert, leading security agencies in the United States are urging teams to adopt the ‘secure by design’ principle for software development as a more effective way to prevent injection vulnerabilities. This follows a number of successful OS command injection attacks that have targeted and compromised network edge devices.
OS command injection is similar to other injection vulnerabilities, such as SQL injection, XPath injection and cross-site scripting, all of which involve the injection of malicious input causing unexpected or unauthorized behavior in the target. These vulnerabilities are also commonly found in APIs and are the cause of significant API breaches.
Recommended solutions to prevent injection attacks focus on limiting, sanitizing, and properly validating user input. The goal is to distinguish between good and bad input, and ensure only the good input gets through.
The benefit of a secure-by-design approach is that it enables teams to define in advance the type, format, structure and range of valid values that can be expected from user input. This early definition ensures that reliable security rules can be built into the code, verified by testing teams, and monitored for compliance by security and operations teams as the code is deployed to production.
Secure by design is the most effective way to protect software, including APIs, from injection vulnerabilities that constantly expose organizations to cybersecurity attacks. This also appears to be the conclusion of major US security agencies.
Vulnerability: API Security raising the “steaks” for IoT
A broken authorization vulnerability in the API of a Traeger Grill (yes, you can now cook your steak by API) allowed a malicious user to remotely control other users’ grills.
That’s the discovery of Bishop Fox’s Nick Cerne, who explained how his team managed to hack a grill registration API to remotely take control of a grill belonging to a colleague and then adjust the grill’s temperature to maximum setting.
In this case, ownership was identified only via a grill ID that could be retrieved from a sticker physically located on the grill. Additional security measures included a device-generated certificate, but this was not enforced by the API and so the ID alone was sufficient to control the device.
Using a grill ID as the sole means of authorization is comparable to using API keys for the same purpose. This assumes that the legitimate holder of the key (or grill sticker) has the motivation and means to keep it private from other users; despite a long history of API keys being hardcoded into apps, transmitted without encryption, or accidentally pushed to Github.
So, although the potential impact here was limited to burnt food and some frustrated grillers, this case highlights the importance of sufficient and effective authorization controls in APIs.
Hopefully the report will provide your API team with some food for thought.
Reader’s Share: API Security and the Circuit Breaker pattern
This informative blog post describes the circuit breaker pattern for APIs and the options for its implementation.
Circuit breaker is a design pattern for APIs that protects backend infrastructure from a flood of API requests when a component such as a database or remote service temporarily goes down. Essentially, this pattern prevents API requests from overloading the backend and allows the failing component the opportunity to recover and resume service.
When backend infrastructure fails, it can also expose vulnerabilities in an API’s error handling. If infrastructure details are unintentionally disclosed in the API’s response to the client, a malicious actor can launch more targeted attacks on a system. Again, the circuit breaker pattern could potentially prevent such leaks by temporarily separating the API and its response from the failing backend component.
Thank you to Nevatek’s Andrew Slivker for the share!
Reader’s Share: Deactivating an API, One Step at a Time
In this article, Bruno Pedro presents a process for decommissioning APIs, taking into account the impact of changes on API consumers.
Deactivating a public API can be a delicate balancing act between a product engineering team that wants to sunset an aging API, and a customer success team that needs to communicate and manage change with API consumers who may be reluctant to make the necessary changes.
Importantly, this type of governance process also has significant security benefits by preventing zombie APIs. The recent zombie API breach at Optus, reported in our previous issue of this newsletter, highlights the risk when teams fail to properly manage an end-of-life process for their APIs.
Thank you to 42Crunch’s Fyodor Loenko for the share!
Events: Black Hat Summit, Las Vegas
The 42Crunch senior leadership and technical teams will be at Black Hat Summit next month in Las Vegas. We will also be demoing our API security technology on the Microsoft Stand #1240 on Thursday on the main conference floor. If you’d like to schedule a meeting please reach out.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
