Rabbit R1 Penetration Test

Preamble

Like many of you, we have been following the drama online about the Rabbit R1 device launch and the various “hacks” surrounding it. At Obscurity Labs we specialize in performing security & software engineering services, with a more recent focus in artificial intelligence & machine learning. We were excited to get the call to conduct the penetration testing for Rabbit Inc.

Penetration tests are a form of risk management where stakeholders attempt to understand the various weaknesses and risks of a given system and come up with mitigating strategies. In essence, a penetration test is not focused on whether a product or service can be compromised, as the answer is invariably: yes, with enough time and resources, it can be done. This penetration test was conducted in a progressive manner, beginning as a gray box test and ending as a white box test.

Throughout this post, we will talk through details of each attack path, while also explaining the likelihood and impact of each. This will provide better insight as to how much risk is involved for each.

Now we will start our journey at the beginning, which is prior to our commencement of the penetration test. As we progress through the timeline, I'll do a short review of the "hacks" that have occurred against Rabbit's R1 device & infrastructure along with our team’s opinions. Then we’ll explain our reproduction of those “hacks” during our penetration test, along with some insider knowledge as to whether or not you should care about the impacts of each.

The purpose of comparing previous hacker's results with ours isn't to discredit them, but to make sure the entire story is being told. While many of the feats accomplished were valid, a lot of assumptions were made by both the hackers and their fan base as to what took place beyond line-of-sight.

Act 0: The Leaky Minion

Part of the differentiator of the Rabbit R1 is how it interacts with the web. The Large Action Model (LAM) that powers the R1 uses a web browser and web semantics to intuitively navigate around as a real human would, rather than relying on application programming interfaces (APIs) or software development kits (SDKs) provided by individual services. However, this implementation comes with an additional challenge: handling user authentication outside of the LAM.

When you use an application for the first time you will navigate to the “rabbithole” to open a connection to what we will call the “Minion”. As many have pointed out, it is in fact (as of the time of this posting) a Virtual Network Computing (VNC) connection to a machine running in Rabbit Inc.'s data centers. This may look sketchy because it isn't something we are used to seeing unless you are a server administrator, but it isn't as bad as it seems.

Before we go further, we would like to point out some terminology here. A commonly used software architecture is that of the “client” and “server” where the client runs in an untrusted environment and sends commands back to a trusted server where the company owning the server has more control and can maintain confidentiality and integrity of the service and data. Typically, anything that runs in a browser is considered the client, and the system it connects back to is the server. However, in this case the "Minion" machine we are connecting to with VNC is also a client and treated by Rabbit Inc. as if it were running in an untrusted environment. In addition to the “Minion”, the Rabbit R1 device (hardware and software) along with anything you can reach by a browser are considered "clients" for the rest of this blog post, and everything else is considered a "server".

The fact that we are typing in our usernames and passwords into a machine through a VNC connection is unusual and poses a unique security risk to Rabbit Inc. in that we now have access to a machine inside of their network. One of the risks is that it is impossible to fully secure this “minion” from being attacked and compromised. To compensate for this risk the Rabbit development and security teams have opted to split their services into multiple components, and only store the source code required to make the minion function on the minion itself and isolate it from the rest of the network inside Rabbit Inc.'s infrastructure.

Our team replicated this attack path and was able to steal the source code running on the minion; however, it only contains Playwright scripts used to launch the browser into which credentials are entered. After further analysis of the source code running on the minion, it was determined that no source code for the LAM was exposed. It was also determined the service instances do not interact with anything sensitive or of value to an attacker. Our team provided additional hardening recommendations to further secure these resources from potential abuse. This type of an attack is more akin to hacking your own personal Android phone and claiming you successfully hacked Google. Thus, while this seems damning at first blush, it is only because it is difficult to know and understand all the moving parts at play here.

After reviewing the systems that power Rabbit Inc.’s services, we discovered that Playwright is used to provide a sandboxed browser for users to log into various services. The stored authentication tokens are then collected and sent to a secure secrets vault. Note, the actual username and password being typed in isn’t what is being collected and stored. It is the cookie sent by the service provider to prove you have logged in successfully, also known as a session token or sometimes a full JSON Web Token (JWT).

The storage of user credentials is a common security concern that requires thorough review. We have thoroughly explored this attack path, reviewed the source code and infrastructure, and deemed it a non-issue. Every user/service combo gets a fresh minion to use for login that is terminated after use or timeout.

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.

Although the use of VNC in this context appears unconventional, we commend the Rabbit Inc. security team for recognizing the associated risks and implementing multiple layers of security and isolation to mitigate them. While the likelihood of an attacker reaching this point is high, the potential impact remains low.

Act 1: Doom and Gloom

This next attack path builds upon the previous one, but raises the stakes a bit. After escaping the sandboxed browser created by Playwright, it is possible to get shell access and arbitrary code execution on the minion. With this shell access comes keys to the kingdom, but a kingdom of nothing. It turns out the Minion itself is just a pod running in Kubernetes that is both unprivileged and isolated from the other workloads.

Building on the kudos from the Act 0 attack path, it appears more impressive but offers even fewer results to the attacker. The team extensively enumerated this pod using the same methodologies posed by the original attack to fully understand the attack surface. During the analysis of the pod, various degrees of access were obtained, allowing the team to enumerate common targets such as security misconfigurations, vulnerabilities, service account tokens, etc. While code execution is often sought after by attackers, in this instance, the team was unable to achieve lateral movement, gain privileged access to Kubernetes, or compromise the Confidentiality, Integrity, Availability of Rabbit Inc.’s additional services.

Act 2: The Virtual Rabbit

One of our high-level objectives was to attempt to dump the Android package (APK) of RabbitOS from the R1 device. This would enable the team to run the package on alternative platforms such as Android Studio and disassemble/analyze the source code to manipulate communications. This level of access is crucial for inspecting secrets, network traffic, and potential vulnerabilities on the device.

The assessment team successfully accessed the Android Debug Bridge (ADB), which was left enabled on the initial batch of units. However, it has since been disabled through software updates, which our team verified during the testing window. This initial access would allow an attacker to pull the APK off the device. During this phase of the engagement, our team successfully ran the APK locally.

Our team carefully reviewed the disassembled source code for any hard-coded secrets. The analysis of the APK yielded a few results, with the only noteworthy finding being an API key for read-only access to Google Maps. While this key should be loaded dynamically rather than hard-coded, it holds no real value to an attacker.

A major area of interest for our team was the analysis, interception, and manipulation of the API logic on the various endpoints used for communication between the Rabbit R1 and its service endpoints. This testing also included the Rabbit R1 management console. Although we managed to communicate with the secure web socket server from the command line, it provided no additional benefits. We were only able to send legitimate commands and receive legitimate responses.

While this level of access to the device is of interest to the team, the risk here is low since it does not grant more access and control over communications than just using a proxy. It may offer some convenience by reducing the number of devices needed, but this novelty will likely diminish as the capabilities relying on the Rabbit R1 hardware increase.

Act 3: The Playwright in the Room

Lastly, we used the previously leaked information about the minions to see if we could exploit our understanding of how the Rabbit Inc. servers worked using Playwright. To provide the sandboxed experience for the minion while also allowing the Rabbit Inc. servers to retrieve the cookies, the minion must leave the chrome debugger port open.

While the code for the LAM isn’t included in the previous Playwright code leaks, it does provide a pathway into potentially attacking the LAM. Prior to performing any actions against a service that requires authentication, the LAM requests a copy of the stored cookies for that service from the secure secrets provider and loads them into the virtual browser the LAM uses to interact with the web. Initially, we assumed that we could manipulate the contents of those cookies to change how the LAM behaves. However, the cookies do not go directly to the LAM, but to the virtual browser instead. As a result, the worst we were able to do was cause confusion and crash that specific service.

After examining the full source code for how the LAM interacts with these cookies, it became apparent that there wasn’t much of an attack path here, at least not one that would provide any benefit other than the amusement that comes from the harassment of artificial intelligence systems (no, I do not accept our new AI overlords).

This attack path has the most promise, but cannot be used to hack Rabbit Inc. directly. Instead, it could potentially affect the services Rabbit Inc. uses, such as Uber Eats, which would require a zero-day exploit for that specific service. The likelihood of this being successful is very low, and the direct risk to Rabbit Inc. is also very low. However, the risk would be higher for the individual service provider, depending on what access it allows.

Conclusion

During our penetration test of Rabbit Inc. from April 29, 2024, to May 10, 2024, we found and reported on many interesting findings, with a few of our favorites listed here. Overall, nothing too concerning was found that would lead us to believe that Rabbit Inc. and the R1 device are insecure or mishandling customer or query data. Consistent with that conclusion, we note that while previous hacks against Rabbit Inc. have drawn skepticism about the company’s security practices, they have had little to no impact on its user base outside of that.