Guest Accounts Gain Full Access on Chrome RDP

Research By: Ofer Caspi, Benjamin Berger

Chrome Remote Desktop is an extension to the Chrome browser that allows users to remotely access another computer through Chrome browser or a Chromebook. It is fully cross-platform, and supports macOS versions from OS X 10.6 (2009) and above, all from the Chrome browser on virtually any device.

However, one of our security analysts recently noticed an unexpected behavior in Google Chrome Remote Desktop Application on macOS. The strange behaviour allows, in some cases, a ‘Guest user’ to login as Guest and yet receive an active session of another user (such as administrator) without entering a password.

Check Point Research reported this bug to Google on 15th February 2018. Google responded that from a CRD (Chrome Remote Desktop) perspective, the login screen is not a security boundary.

As we see it this is a security issue and believe users should be alert to the risk of letting a guest remotely access their machine.

In the case described below we will see how the discovered bug works.

How the ‘Bug’ Works

On macOS it is possible to let other people use your Mac temporarily as guest users without adding them as individual users. Indeed, you can use parental controls to set restrictions so that guests can only access items that you are willing to share with them.

The ‘Guest account’ option though is not enabled by default, and does not need a password to log in to. When someone logs in as a ‘Guest user’, the files created by the ‘Guest’ are stored in a temporary folder, acting similarly to a sandbox, and its content are deleted once the Guest has logged out.

To exploit this bug, once a Guest user connects to a remote desktop machine, the machine should have at least one active user in session (such as someone logged in and locked the screen / screen saver after x time). The RDP will show a login screen of available users as show in the screen below:

Figure 1: The RDP Login screen of available users.

First let’s look at the normal behavior of the RDP.

If we select on the login screen the main account (“victim”) we will be asked for a password, and after successful login we will see the identical screens of both the local chrome RDP extension and the remote machine that we are connecting to:

Figure 2: The screens of both the local chrome RDP extension and the remote machine being connected to.

Now let’s look at the problematic scenario. Note that the RDP should be a reflection of the actual screen on the remote machine.

In the login screen, a user then clicks on the ‘Guest’ icon and, since a guest does not require a password, the system will proceed:

Figure 3: The system proceeds without requiring a password.

What is expected to happen is that the local user that connects remotely to a macOS machine will receive the desktop of a ‘Guest’. But while this is what appears in the remote machine, the local machine (the Chrome extension) receives the desktop of the other active user session, which in this case is an admin on the system, without ever entering the password:

Figure 4: The local machine receives the desktop of the other active user session.