AI personal assistant device company Rabbit said this week that a June hack of its systems was an “isolated incident [that] was not caused by a breach of our security systems,” but was caused, it said, by an employee who leaked source code to people outside the company who then compromised several of Rabbit’s systems. Rabbit added that a penetration test of its company after the incident has shown that its security systems are “working as intended, despite statements made by some external critics.”
“Last month [in June], an employee (who has since been terminated) leaked API keys to a self-proclaimed ‘hacktivist’ group, which wrote an article claiming they had access to our internal source code and some API keys. We immediately revoked and rotated those API keys and moved additional secrets into AWS Secrets Manager,” Rabbit wrote in a blog post. “It’s important to note that this isolated incident was not caused by a breach of our security systems—those API keys were obtained and shared illegally, and we are in communication with authorities for further investigation.”
It is good that Rabbit has fixed what was a shockingly bad security design—as we reported at the time, it is not a good security practice to hard code API keys—which are essentially master login tokens to critical services—directly into source code.
But the fact that a Rabbit employee leaked this vulnerable source code, which was then exploited, means the exact opposite of what Rabbit says it means: An insider intentionally or unintentionally leaking info to outside parties who then exploit that info is one of the many ways that a company can be hacked, and insider threats or poor personal security from individual employees is an attack vector that we have seen used time and time again to hack companies. For example, Twitter insiders have allegedly collected user data and spied for Saudi Arabia, a former Cash App employee stole records on more than 8 million customers, and a series of social media employees have been caught snooping on users. Poor employee security more broadly has led to recent breaches via a third party cloud provider called Snowflake at Ticketmaster, AT&T, Bausch Health, Nieman Marcus, and many others.
In this case, several critical Rabbit API keys were included in the leaked source code, and were used by researchers at the Rabbit jailbreaking collective Rabbitude to send emails from internal Rabbit email addresses used by the AI device to prove that they had access. The researchers told 404 Media at the time that they did not cause more widespread havoc because they were simply trying to expose the flaw, not cause harm.
“While yes we didn't steal user data, so the statement that no ‘customer data being leaked’ is, by its most pedantic definition, true, the compromise of us having access to the key happened and had we been malicious we very much could have accessed things we shouldn't have been able to,” Emily, one of Rabbitude's researchers, told 404 Media in June. “The fact that we were responsible in not doing anything with it in no way negates that they were irresponsible in both how they stored their keys in the codebase in the first place and how they (didn't) react to the knowledge that we had had access to the codebase in the second place.”
In response to Rabbit’s most recent statements, Emily said “Rabbit's focus on where the leak came from is a misdirect, and serves to miss the main problem here: those keys quite simply shouldn't have been hardcoded into Rabbit's code base to begin with.”
“You can't always limit the actions of staff within the company, but as Rabbit themselves acknowledge: that's why segregation and separation of concerns is so important. Separation of keys from the codebase is a basic practice of modern security, and the fact they failed to do this left them open to a whole host of attacks, including employee leaks, that they would otherwise have been far less exposed to,” she added. “These aren't insignificant keys, and this isn't [a] small indie pet project. This is a multi person team, funded with over $60 million in VC funding, and a further $20 million in sales. They have over 100k customers. This type of blatant mishandling of important keys is absolutely inappropriate.”
What happened in June is, by any definition, a security breach. But in its investigation into the breach, Rabbit minimized its own mistakes and the potential impact of a breach like this, and said that it had planned on eventually fixing the issues at some point, so it was not that big of a deal, anyway.
“We were already in the process of migrating secrets out of code and into AWS Secrets Manager (a tool for storing secrets, like API keys, securely). We prioritized this process for all keys with access to customer personal information and continued to migrate additional keys over time.” Rabbit wrote in its investigation. “We have reviewed our logs and believe the only abuse of those keys was to send defamatory emails to rabbit employees, a small number of journalists who encourage the work of hacktivists, and other members of the hacktivist group.”
Rabbit did not refer to 404 Media by name in its investigation, but to be clear, we do not directly “encourage” anyone to break into companies. A source came to us with evidence about a hack that potentially impact Rabbit's entire user base, we verified it, and wrote the news, which is our job and in the public interest. Emily told 404 Media that Rabbitude does not consider itself to be made up of “hacktivists.”
“To my knowledge none of the members of rabbitude have ever self-proclaimed rabbitude to be a ‘hacktavist’ group,” she said. “The first use of that term I saw was in Rabbit's own statement, and it appears to be an attempt to discredit the accurate reportings we have provided … The use of the same tactic to put down established journalists is wildly inappropriate.”
In its most recent post, Rabbit also said that it had hired a cybersecurity company called Obscurity Labs to perform a penetration test on its systems after the June incident. Rabbit said that “In contrast to what some have suggested, Obscurity Labs’ findings show that, among other findings, no source code for our AI agent was exposed, no sensitive or valuable information was available to an attacker, and authentication tokens that are collected when you log in do not contain the actual username and password being typed.”
Doing a penetration test after a security breach is laudable, and a step toward potentially restoring trust with customers. But a penetration test after a breach does not change the fact that a breach happened, and it does not mean Rabbit’s systems were always secure. The Obscurity Labs pentest is worth reading in full; jailbreakers are already noting points where they feel the report is lacking.
For example, Obscurity Labs wrote: “Another common security concern we hear is how Rabbit Inc. is storing our session tokens. Rabbit Inc. isn’t directly storing them. Instead, they are using a dedicated secret storage vault designed for this purpose, the testing of which was out of scope for this penetration test. However, our team conducted testing for the potential interaction between the minion and the secrets vault and discovered no attack path to access session tokens.”
The jailbreaking community has seized on this language, noting that nothing is ever “out of scope” for a potential hacker. Obscurity Labs has put an update on the post to note “The phrase ‘out of scope’ refers to testing the 3rd-party secret vault used to store session tokens. While Rabbit Inc. authorized us to perform a penetration test on the systems and services they own, they don't have the authority to authorize the testing of 3rd party systems and/or applications. However, the 3rd-party provider is responsible for conducting their own 3PA which is traditionally supplied to their customers when requested.”
We don’t know how good Rabbit’s current security is. But its response to this breach, where it denied there was a breach, then admitted there was a breach but blamed it on an employee, suggested incorrectly that journalists “encourage the work of hacktivists,” then later published a statement saying that this incident was not caused by a breach of its security systems when that is what it obviously was does not inspire confidence.
