Shadows, zombies, and Twilio's wide-open API

I don’t envy the authors of the various OWASP Top 10 lists. There are so many vulnerabilities in web apps and APIs, and only 10 make it to each list (CWEs for each item notwithstanding). For instance, the OWASP TOP 10 API 2023 list is now “missing” Insufficient Logging and Monitoring.

Onwards to our history-repeats-itself stories.

We'll start with the Trello “data breach” in early 2024. A Trello API endpoint allowed unauthenticated queries using email addresses and responded with usernames, full names, and other account information. The threat actor appears to have scraped the data for around 15 million users by validating email addresses leaked in other breaches against the Trello API.

It is only a matter of time before password reuse tests enable people to hijack Trello accounts, similar to what happened with Disney+ when it launched in 2019.

What annoyed me the most about this was that the breach was first discovered – or so it seems to me – when the threat actor released the data for sale. This means a few things, but there are two consistent configuration errors in this type of breach:

• Lack of effective rate-limiting
• Lack of logging and alerting (which would have alerted the Trello team about the breach in progress!)

These conditions were also seen in the recent Dell breach – and now, with the new Twilio breach. 

The Twilio breach is a bit more painful to me than the Dell breach because it happened through an unprotected Authy endpoint. Authy is a Two-Factor authentication app. That it had an unauthenticated API endpoint without any other protections is a massive problem, given that this is primarily a security product. Even bigger is – and from what I’ve read so far, this is true – the fact that this breach was not noticed until the threat actors released the data.

The data that has leaked so far includes phone numbers, accounts, and device details - no usernames or passwords. The threat actors have suggested validating these phone numbers against the Gemini and Nexo cryptocurrency breach databases. Further comparisons against other breach databases will probably yield reused passwords and used in combination with Smishing this will likely lead to some theft of crypto or Account Takeovers (ATOs).

API security

The number of breaches due to unsecured APIs is much too high. Security has not kept pace as we’ve transitioned to primarily API-based apps.  I’d estimate that API security is where web app security was in 2004. The OWASP list for API security is in its second iteration. Security teams are now starting to work on building API governance frameworks and building the frameworks to secure their APIs. However, if you expose that test API for something without any protection, you end up with another data breach.

Why does this happen? The number of motivated threat actors taking notes from each breach and having access to automation is much greater than in 2004. There are forums, telegram channels, and other online platforms where threat actors can share malware, exploits, and information on how to make money from these attacks. With automation and artificial intelligence in the mix, even low-skilled hackers can conduct advanced API attacks.

So, what could Twilio have done to prevent this breach?

• API governance policies that ensured that all these endpoints were known and secured
• Access control for all endpoints
• Effective rate-limiting that can identify and slow down/block low and slow automated attacks
• Improved alerting to notify them about abnormal activity

When it comes to API security, I love using the following image to show the problem –

You have your known APIs represented by the visible part of the iceberg, which is more likely to be secured. But then you have the unknown APIs:

• Shadow APIs that are expected to work but are unknown to the security team and unsecured.
• Legacy/Zombie APIs that shouldn’t be working, like an older version of an API endpoint, but are still open and responding and unsecured.

Barracuda can help

Today’s article is sponsored by…. Barracuda Application Protection! Barracuda Application Protection is a comprehensive Web Application and API Protection platform that is easy to use and manage. In this case, it provides the following relevant protections –

• Machine learning-powered API Discovery uses live traffic data to identify API endpoints (Shadow or otherwise) and then automatically turns on protection for the discovered API endpoints.
• Advanced Rate Limiting and Tarpits that can work on both a per-IP and a per-device setting. The per-device setting is very useful when your clients sit behind a NAT and use multiple devices.
• Authorization enforcement down to the parameter level, with integrations with JWT and Client certificates. This includes the ability to enforce VBAAC and ABAC.
• Machine Learning powered Account Takeover Protection with multiple layers of protection, including Credential Stuffing protection (for known breached accounts) and Privileged Account Protection (for accounts that are newly taken over.)
• Machine Learning powered Advanced Bot Protection that identifies and blocks the most advanced bots, including scrapers.
• Detailed Logging and Alerting, including integrations with SIEM/SOAR/XDR solutions like Azure Sentinel, Splunk, SumoLogic, Barracuda XDR, and more.

Barracuda offers complete application protection and the industry’s most comprehensive cybersecurity platform that defends all attack vectors with real-time threat intelligence and incident response. Visit our website to see how we defend email, networks, applications, and data.