API Keys, API Keys, wherefore art thou always leaking?

Yes, we just realized that wherefore means why, not where. Don’t judge. :)

The rabbit r1 API key leak is the latest in a series of leaks that show that API security is still in its infancy. It is also one of the newer forms of credential theft and Account Takeover (ATO). When used in an attack, an API key provides access to troves of data that are easily consumed in large quantities. This type of attack is a high-impact security event.

What is the rabbit r1?

The rabbit r1, also called the ‘r1’, is meant to be a virtual assistant that requires minimal input to get the desired result. This pocket-sized artificial intelligence (AI) gadget is like a smartphone, but there are no apps for you to open and navigate.  If you’d like to order an Uber or play music, just tell the r1. The device interacts with your accounts and services in the background, but you won’t see any of that action on your r1 device. Once you’ve configured the rabbit r1 backend to access your accounts, you can just talk to the device to access those services.

The device gets mixed reviews on performance, but CEO Jesse Lyu claims to have sold 130,000 of these devices as of June 2024. If every device is configured to access Uber, Spotify, DoorDash, and other supported services, every device will have access to multiple user accounts.

So, what happened?

On May 16, 2024, a group of researchers/hacktivists called ‘rabbitude’ discovered hardcoded API keys in the rabbit r1 codebase. In simple terms, an application programming interface, or API, facilitates interaction between two applications. APIs allow rabbit r1 to communicate with the supported apps that the user configures. API keys are unique identifiers used to authenticate the user or application trying to access the API. When the hacktivists found the hardcoded API keys, they were able to gain access to these third-party platforms:

• ElevenLabs (for text-to-speech)
• Azure (for an old speech-to-text system)
• Yelp (for review lookups)
• Google Maps (for location lookups)

The access provided by the API keys varied, but at least one gave full privileges to ElevenLabs. This key would allow threat actors to get histories of all past text-to-speech messages, add custom text replacements, and more.  It could even be exploited to crash the rabbit OS backend and make all r1 devices unusable.

What is the big problem?

While all devices, applications, and companies are susceptible to vulnerabilities and exploits, the use of hardcoded keys has been a known bad practice for decades. It is a major security issue to an extent that it has been published as Common Weakness Enumeration (CWE) 321. This is not an unknown security issue. Hardcoded keys or credentials have been responsible for the compromise of everything from routers to switches to massive software platforms:

• Twitter API keys were leaked through thousands of mobile apps, allowing attackers to access various categories of sensitive information.
• Toyota inadvertently leaked keys in source code uploaded to GitHub, which exposed over 296,000 customer records with email addresses.
• Uber’s systems contained a hardcoded admin account that gave an attacker access to the company’s infrastructure and network. (CWE-798 addresses hardcoded credentials)

As an industry, IT seems to be bent on repeating the mistakes from the past.

Security standards for IT development and security warn against this practice for good reasons. If a hardcoded key is found, it may be difficult to remove without breaking the API. More importantly, if the key falls into the wrong hands, as it did with rabbit r1 it can be used for nefarious ends.

APIs are the highways of IT, allowing us to exchange large amounts of information at the push of a button. They are a strict necessity for proper automation, and as an industry, we would not be able to move forward without them. Their sensitivity and the impact of security issues force us to take a step back and analyze how we build them and how we interact with them.

What's the solution?

There are no one-size-fits-all solutions in cases such as these, but there are some best practices:

• Do not ever use hardcoded credentials in software.
• Have a comprehensive application security strategy effective both during build and run.
• Review code and security practices at a regular pace.
• Learn from the past. Many security mistakes have already been made ad-nauseum.

Barracuda can help

Barracuda Application Protection is an integrated platform that combines a comprehensive set of interoperable capabilities together to ensure complete application security, including protection for the OWASP Top 10 Web and API threats. Visit our website for details.