We introduce the inception attack, where an attacker controls and manipulates a user’s interaction with their VR environment and ap- plications, by trapping them inside a malicious VR application that masquerades as the full VR system. Once trapped in an “inception VR layer”, all of the user’s interactions with remote servers, net- work applications, and other VR users can be recorded or modified without their knowledge. This enables traditional attacks (record- ing passwords and modifying user actions in flight), as well as VR interaction attacks, where (with generative AI tools) two VR users interacting can experience two dramatically different conversations.
In this paper, we introduce inception attacks and their design, and describe our implementation that works on all Meta Quest VR headsets. Our implementation of inception attacks includes a cloned version of the Meta Quest browser that can modify data as it’s displayed to the user, and alter user input en route to the server (e.g. modify amount of $ transferred in a banking session). Our implementation also includes a cloned VRChat app, where an attacker can eavesdrop and modify live audio between two VR users. We then conduct a study on users with a range of VR experiences, execute the inception attack during their session, and debrief them about their experiences. Only 37% of users noticed the momentary visual “glitch” when the inception attack began, and all but 1 user attributed it to imperfections in the VR platform. Finally, we consider and discuss efficacy and tradeoffs for a wide range of potential inception defenses.
Quite some technical detail on the attack in the paper.
Using tools like Nmap [41 ], the attacker scans the wireless network to find Meta Quest headsets with open TCP ports and then requests access. By default, the Meta Quest’s wireless ADB listens to TCP port 5555 and requires no credential-based authentication.
I don’t think wireless ADB is enabled by default (nor does it listen to a specific port). At least, it doesn’t seem to be active on my Quest 3, even though I have Debug mode enabled through the Meta iOS app:
melis@blackbox 20:29:~$ nmap 192.168.178.38
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-04 20:30 CEST
Nmap scan report for 192.168.178.38
Host is up (0.0035s latency).
All 1000 scanned ports on 192.168.178.38 are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)
Nmap done: 1 IP address (1 host up) scanned in 7.43 seconds
Wireless ADB needs to be enabled explicitly, even providing the port:
# Plug in Quest 3 through USB, then ...
melis@blackbox 20:30:~$ adb tcpip 5555
restarting in TCP mode port: 5555
melis@blackbox 20:31:~$ nmap 192.168.178.38
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-04 20:31 CEST
Nmap scan report for 192.168.178.38
Host is up (0.0032s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT STATE SERVICE
5555/tcp open freeciv
Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds
Turning wireless ADB off again:
melis@blackbox 20:31:~$ adb usb
restarting in USB mode
melis@blackbox 20:31:~$ nmap 192.168.178.38
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-04 20:31 CEST
Nmap scan report for 192.168.178.38
Host is up (0.0032s latency).
All 1000 scanned ports on 192.168.178.38 are in ignored states.
Not shown: 1000 closed tcp ports (conn-refused)
Nmap done: 1 IP address (1 host up) scanned in 0.67 seconds
The wireless access requires the machine to be on the same wireless network as the Meta Quest headset. Beyond these two methods, Meta Quest also supports ADB proxy over SSH, another useful tool to enable remote access to Android devices (including Meta Quest headsets) without the need to be on the same wireless network [ 11].
“Meta Quest supports ADB proxy over SSH” is a weird statement. ADB Proxy simply seems to leverage wireless ADB access by using a proxy server in the same wifi network as the Quest, there’s nothing specific that the Quest has to do or support.