ATTACK
Rabbit r1 Data Breach Again Shows The Dire Need for Improved Secrets Security
June 28, 2024
A community group called Rabbitude, dedicated to improving the Rabbit r1 experience through reverse engineering and jailbreaking the hardware device, gained access to the Rabbit code base and discovered several valid hardcoded API keys. The data exposure has raised concerns about the company’s security posture. These concerns have been exacerbated by the lack of urgency in Rabbit’s response to the breach.
At the forefront of the AI revolution currently underway has been the promise of AI virtual assistants which, presumably, would be able to support and assist you in your day-to-day flights like booking a flight or reminding you where you know someone from before a meeting. One of the hottest names driving this effort is Rabbit Inc., who is building their own AI-enabled device called r1 as well as the Large Action Model (LAM) that aims to revolutionize human-computer interaction by automating various tasks for its users.
The introduction of the r1 has come with much excitement, including multiple awards at the vaunted Consumer Electronics Show (CES) and garnering over 50,000 pre-orders. The device has been met with plenty of skepticism as well, including seemingly prescient concerns about the company’s approach to security.
On June 25th, 2024, a group called Rabbitude disclosed that on May 16th, they were able to gain access to Rabbit’s code base and discovered a number of hardcoded API keys with access to Eleven Labs, Azure, Yelp, and Google Maps. The Rabbitude group does not seem to have nefarious intentions. In fact, their stated purpose on their website is to “reverse, hack, and experiment with the r1 and report our findings publicly,” with the goal of “making the r1 experience better.”
While the exposure of hardcoded API keys is, in itself, a major concern for any organization, the breadth of permissions associated with the exposed keys further amplifies the severity of the exposure. According to Rabbitude, the exposed keys provide the ability to “read every response every r1 has ever given, brick all r1s, alter the responses of all r1s, replace every r1’s voice.”
As of the disclosure, Rabbitude claims that while they’ve been working with the Rabbit team, no action has been taken by the company to rotate the keys and they remain valid. Rabbitude gets a little chippy at the end of the disclosure stating that they felt compelled to publicize the company’s poor security practices and that while they were not planning to publish any details of the data, this was “out of respect for the users, not the company.”
As of Wednesday morning, June 25th, Rabbit had posted an update about their ongoing investigation on their website claiming they had rotated the relevant keys and updated processes to guard against the issue going forward. While company disclosures are positive steps toward keeping the community informed, it should be noted that Rabbit’s disclosure came only after the public disclosure from Rabbitude… which was over a month after Rabbitude contacted Rabbit about the breach in the first place. Not only that, Rabbitude published a second disclosure, after the announcement from Rabbit claiming that they still had access to the exposed SendGrid key.
Rabbit’s secret exposure illustrates just how critical it is that organizations systematically and completely eliminate hard coded secrets from their code as well as prevent new secrets from being added in the future. Furthermore, by regularly validating existing secrets, you can help prioritize active and known valid credentials.
Real-time secret detection is essential to prevent new secrets from being committed to code in the first place. This proactive approach stops the continuous addition of secrets, allowing your security and development teams to focus on addressing high-severity historical issues and reducing the backlog. Detecting secrets at every code change, not just at pull requests, is key to effective prevention.
It's likely that secrets exist in your source code. In fact… a staggering 96% of organizations are likely to have secrets where they should not be. Using effective tools to identify, prioritize, and facilitate mitigation of the most critical hard coded secrets is of the utmost importance, as illustrated by the Rabbit secret exposure. Scans for existing secrets in code should be conducted regularly so as to avoid flagging secrets that have already been rotated.
In the case of the Rabbit API key exposure, the value of secret validation is especially clear as well. Considering that as of the Rabbitude disclosure, these valid keys remain exposed in the code base, a tool that effectively validates secrets could have been helpful should the Rabbit team show any interest in fixing the exposed secrets.
Read our comprehensive guide on selecting a secret detection & mitigation!
Arnica is purpose built to avoid situations like the Rabbit exposure. We combine real-time and historical scanning with our extensive secret validation to help organizations stop the bleed and then effectively tackle their secrets backlog.
Book a demo with the Arnica team to see how Arnica empowers teams to build a “no new secrets policy” as part of an overarching Application Security strategy that include detection, prioritization, and mitigation across SAST, SCA, IaC, licensing, package reputation, developer permissions, and developer and code anomalies.
