• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

War Room

Shells from above

RSM logo

  • Home
  • About
  • Blog
  • Talks/Whitepapers
  • Tools
  • Recreation
Home > R&D > Research > Chromoting For Access

Chromoting For Access

December 15, 2014 By Spencer

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.

Chromoting Message Sample

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.

Share this...
  • Reddit
  • Email
  • Facebook
  • Twitter
  • Linkedin

Spencer

Primary Sidebar

Categories

  • Defense
  • Forensics
  • Offense
  • Physical
  • R&D

Most Viewed Posts

  • DLL Injection Part 1: SetWindowsHookEx 10.8k views
  • Sophos UTM Home Edition – 3 – The Setup 10.8k views
  • Leveraging MS16-032 with PowerShell Empire 10k views
  • Bypassing Gmail’s Malicious Macro Signatures 9.8k views
  • How to Bypass SEP with Admin Access 8.9k views

Footer

  • RSS
  • Twitter
  • Tools
  • About
  • RSM US LLP

+1 800 903 6264

1 S Wacker Dr Suite 800
Chicago, IL 60606

Copyright © 2023 RSM US LLP. All rights reserved. RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit for more information regarding RSM US LLP and RSM International.