Top 10 API Breaches in 2024, Part III

Whew! Finally, the last part of the top 10 API breaches in 2024! Thanks for staying till the end—we owe you.

While the first and second parts included an abundance of technical details—and believe us, we restrained ourselves from throwing even more info at you—this third part differs.

The shortage of detailed technical incident reports, the idea to have at least one part where the popularity of the affected organizations takes tiny precedence over rich technical details (to see that no company is immune to API security breaches), and our wish to offer a lighter read at the end are the culprits for the slight change of course.

However, that doesn’t mean you have superficial descriptions in front of you. We still stick to our original plan of favoring API breaches that include technical information. Only, this time, the descriptions don’t go that much into detail. But you still learn what goes wrong and why things hit the skids when your APIs go wrong.

4. Twilio’s Authy Data Breach

Twilio is the company we all know and… love. The famous customer engagement platform is the preferred choice of more than 300K enterprises and 10M devs across the globe.

Twilio’s Authy is a free 2FA (two-factor authentication) mobile app available on both Google Play and App Store. It works similarly to Google Authenticator. The likes of Cloudflare and Pinterest use Authy to enable 2FA for their customers, which only shows how big Authy is.

In June 2024, we learned that Authy was, unfortunately for Twilio and many of us, hacked. Threat actors from the group ShinyHunters, responsible for many other data breaches, succeeded in leaking 33.4M phone numbers linked to Authy accounts. Now, that’s a bummer.

Phone numbers are private data—so private that many people hardly ever share them with others—and when associated with full names, they can pose phishing, smishing, and SIM swap risks. Hence, all the concerns around this security incident.

If anyone ever relied on APIs, that’s Twilio. This particular data breach was a result of an API endpoint allowing unauthenticated requests, which makes it fall within API2:2023 Broken Authentication on the OWASP Top 10 API Security Risks – 2023 list.

Twilio hasn’t revealed the specifics related to the breach, such as the name of the exploited API endpoint and why it didn’t include a proper authentication mechanism (for instance, was it a shadow API?). Nonetheless, we have sufficient information to get a picture of what happened.

The hackers carried out the cyberattack by entering a massive list of phone numbers into the unauthenticated API endpoint, presumably knowing that phone numbers are essential to Authy’s account identification system.

For each phone number associated with an Authy account, the API returned user-related information, such as ID, account status, and device count. Twilio claimed that the attackers didn’t leak private information other than phone numbers.

However, the incident is bad enough as it is, especially considering that the whole point of Authy’s existence (as a 2FA solution) is to help others achieve secure authentication. See the irony? But it happens even to the best of us.

3. The Siemens AMA Cloud API Incident

There’s no need to introduce Siemens. This company has become a household name over the years, mostly due to its now already ancient mobile phones.

Today, among other services, Siemens offers a cloud system called AMA (Asset Management Assurance) Cloud, which is essentially a web app built upon React. If you try to access this app, it’ll immediately redirect you to a Microsoft SSO (single sign-on) page.

The prominent ethical hacker Eathon Zveare and his colleagues from the Traceable ASPEN team didn’t have a Microsoft user account that existed in the Siemens database. To bypass the intended login process, they tried to disable the login redirect by changing the website’s client-side JavaScript code. And they succeeded.

Upon inspecting how the authentication mechanisms worked, the ethical hackers concluded that the website stored the login token, JWT (JSON Web Token), client-side, that is, in the browser’s Session storage.

The discovery and analysis of the unauthenticated API endpoint getUsers provided them with the data they needed to create a JWT with the correct information for a user who had admin access to the app. When we say correct, we mean the data necessary for the app to recognize the JWT as legitimate.

The ethical hackers put the counterfeit JWT into the Session storage and gained full access to the app. The JWT worked because the validation was done completely on the client side. The token was never sent to the backend for API server validation.

This vulnerability is another example of API2:2023 Broken Authentication. It only reemphasizes the insufficiency of client-side validation and the indispensability of server-side validation. It could lead to threat actors gaining control of legitimate user accounts, accessing sensitive user data, and carrying out actions on behalf of legitimate users.

The vulnerability was disclosed at the end of July 2024, even though it was discovered and reported to Siemens much earlier the same year.

2. The Digi Yatra Controversy

Digi Yatra is an innovative initiative of the Indian government whose purpose is to enable paperless and contactless airport boarding through facial recognition technology.

Behind this project stands the DigiYatra Foundation—a private, not-for-profit organization owned by the statutory body Airports Authority of India. In short, Digi Yatra is a pretty big deal.

One of the key results of the initiative is the Digi Yatra app, which allows both iOS and Android device users to use facial recognition for air travel.

However, in March 2024, it became clear that something was off with the app:

• DigiEvolve, the company that developed it, was completely dropped from the Digi Yatra ecosystem.
• DigiYatra Foundation required users to uninstall the app, install a new Digi Yatra app, and re-register a user account.

Despite officials claiming they had everything under control and that the app supported privacy by design, it turned out that the software might have jeopardized the privacy of 3.3M passengers’ data.

Passengers’ data was supposed to be stored locally in a secure wallet on user devices. Not storing it in central storage was the logical choice, considering that the app owners guaranteed absolute privacy and presumably wanted to minimize the probability of PII (personally identifiable information) abuse.

Instead, it seemed that the API endpoints api-ssi.dataevolve.in and d-zxstcsa9j9.execute-api.ap-south-1.amazonaws.com leaked passengers’ information, such as travel history and biometric data, to AWS servers managed by DigiEvolve. That basically meant DigiEvolve itself.

This data could’ve been misused (and abused) in various ways. One example is selling it to third parties for, say, ad targeting. Needless to say, that was in stark contrast to how the app was supposed to work.

Truth be told, the Digi Yatra incident hasn’t been officially confirmed—at least, not to our knowledge—and apart from Indian media and websites, none other than Wallarm has reported it. In that sense, the topic remains highly controversial and open to debate.

Nonetheless, the lack of transparency and the way officials have handled the whole situation—a new app overnight and dropping the app development company without explanation—speaks a ton in the minds of many privacy-concerned people in India.

This API-related incident is unique in that it wasn’t an external factor that threatened sensitive user data. Conversely, it was the app development company itself that… well, breached the data. Whether it was knowingly or unknowingly—the latter due to an overlooked security flaw in the API—we can’t tell.

In any case, this API-related incident is an example of how not to handle security and privacy issues, even if they exist only in the realm of suspicions and rumors.

1. The Rabbit R1 Stolen Hardcoded API Keys

Rabbit R1 is a personal AI assistant gadget developed by the tech startup Rabbit Inc. Even though it’s a new product by a relatively new company, it gained enormous popularity at the beginning of 2024.

In June 2024, Rabbitude group of ethical hackers and developers that seems dedicated to reverse engineering, hacking, and experimenting with R1—disclosed that it accessed the Rabbit R1 codebase and discovered crucial hardcoded API keys.

The leaked API keys were used for the following services:

• ElevenLabs
• Azure
• Yelp
• Google Maps
• SendGrid

They allowed the ethical hackers to:

• Read every Rabbit R1 response in the (short) history of this AI assistant, even those containing sensitive personal information.
• Brick R1 devices.
• Modify R1 responses.
• Change R1’s voices.
• Access the full history of emails sent on the subdomain r1.rabbit.tech, including user information.
• Send emails from rabbit.tech email addresses.

Moreover, the API key for ElevenLabs gave Rabbitude full privileges so the group could:

• Obtain a full history of text-to-speech messages.
• Change and delete voices.
• Insert custom text replacements in the R1 responses.

Rabbit claimed that it was an insider who leaked the code containing the hardcoded API keys. But the key word here is “hardcoded.”

Hardcoding secrets, including API keys, is widely considered a bad security practice. Leaked/stolen API keys enable hackers to gain unauthorized access to sensitive data and services, circumvent security mechanisms, and cause financial losses.

Conclusion

This is the end, my friend. Authentication issues dominated in this last part, but overall, we’ve seen that authorization vulnerabilities are prevalent in the API realm.

After you’ve seen how so many things can go wrong, we won’t leave you in the lurch. To see how you can secure your APIs by avoiding vulnerabilities in development and discovering security risks in production, check out how a purpose-built API security platform can support your efforts and make your life easier.

You may regret buying that extra pair of sports shoes you never wear, but you’d hardly regret this. If not else, you’ll discover what you don’t want.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.