Chromoting Background
Google Chrome offers a service dubbed “Chromoting” which allows users to opt into allowing remote access to their systems for either personal reasons or technical support. To use this service a user must download Chrome, be logged into their Google account, and enable Chromoting via the Chrome Remote Desktop application. The remote desktop application, when run on a supported OS (currently Windows, OSX and Ubuntu) offers the option to “Share” the computer that Chrome is currently running on. After this system is shared it can be accessed from other instances of the Chrome Remote Desktop Application where the same user is logged in with their Google account.
When a system is “Shared” on a Windows system, Chrome installs a system service which starts on boot and adds a configuration file. This configuration file is by default located in “C:\ProgramData\Google\Chrome Remote Desktop\host.json” and stores information necessary for the service to alert Google that the host is online. When the user enables sharing a system they are prompted to create a PIN which is used as a password when logging into the system. This PIN is required in addition to the authentication already provided by the users Google account. The data for confirming this PIN is stored within the aforementioned host.json file. The host.json file contains two keys which are used to authenticate the PIN specified by the user. The “host_id” is used along with the PIN specified by the user to calculate the “host_secret_hash” using HMAC-SHA256. The host.json file also contains an RSA 2048 bit private key, the public key of which is sent to the Chromoting servers. The following Python snippet demonstrates how the host_secret_hash can be calculated given the host_id.
Post Exploitation Usage
Chromoting can be manually installed silently over a meterpreter session given that a legitimate host.json configuration file has already been created. In this scenario an attacker can create a Windows virtual machine, install Chrome and configure it for Chromoting shared access. From here the attacker can take the remoting_core.dll and remoting_host.exe binaries that are installed along with the configured host.json file. By turning off this VM and uploading these two binaries and the configuration file to a compromised host, the attacker can configure the compromised machine to assume the identity of the test VM and enable Chromoting access for the attacker.
This technique requires administrative privileges as the files need to be written to the “Program Files” or “Program Files (x86)” and not a users directory. In addition the user manually installing the Chromoting service needs to be able to modify the registry and create a service. After uploading the binary files, the registry keys “HKLM\Software\Google\Chrome Remote Desktop\paired-clients\clients” and “HKLM\Software\Google\Chrome Remote Desktop\paired-clients\secrets” need to be created with no values. Note that on 64-bit versions of Windows these keys exist under “HKLM\Software\Win6432Node” and not “HKLM\Software”. Once these keys exist, a temporary service must be created and started from the command line to execute the following command:
"C:\Program Files\AttackersTempDir\remoting_host.exe" --type=daemon --host-config="C:\Program Files\AttackersTempDir\host.json"
After the service has been started it and the registry keys can be immediately deleted, even before the attacker has connected to the host. The binaries however, must remain on the system as another instance of remoting_host.exe is started when the attacker logs in.
After the service has been started the victim system will come online within about a minute. At which point the attacker can login and have an interactive desktop session with the compromised host. Chromoting acts similarly to VNC in the sense that if a user is already logged on they will not be disrupted as they would be with traditional remote desktop. Chromoting does however display a message that the desktop is currently being shared. This message can be moved to the edge of the screen which would make it nearly invisible to users that are not looking for it.
One of the benefits to this attack is that the compromised host communicates directly with the Chromoting servers and not with the attacker. Furthermore the remoting_host.exe and remoting_core.dll binaries are both signed by “Google Inc” making them less suspicious than binaries that the attacker may compile themselves.
The code powering the Chromoting service is open source and is available as part of the Chrome project.
