ClassLink OneClick Browser Extension / Agent Universal XSS / Remote Code Execution

The ClassLink OneClick browser extension and the ClassLink Agent are vulnerable to universal cross site scripting and remote code execution.

MD5 | e8835af6f7679093a0b4696ac326601b

The ClassLink OneClick Browser Extension and the ClassLink Agent are vulnerable to Universal XSS and Remote Code Execution. Vendor has released software updates to fix both vulnerabilities on 3 June 2018.

=== Vendor ===

=== Vulnerability #1: Universal XSS through the OneClick Extension ===

To log users into websites, the ClassLink OneClick Extension injects JavaScript into the target webpage to perform the login. To begin this flow, a user visits a page that contains metadata about the target and the JavaScript to be injected. This page is not authenticated, which means it can be trivially forged by an attacker.

The extension only looks for URLs that contain the string "browsersso/". If that is found, it looks in the "head" tag for a login_url and scripts, such as pre_auth_script. None of these fields or the page itself are authenticated in any way.

An attacker could create a page that contains the correct string in the URL and include a script that goes to any website, and execute JavaScript to steal information such as cookies, API keys, saved credentials or any private information. This could then be posted to the attacker's server. A user simply visiting the page would trigger the attack.

Here is a simple proof of concept:

<script type="text">
appResponse: var x = {}; x.selectors = []; x.userauth = []; x.login_url = ""; x.pre_auth_script = "alert('XSS running on Google. document.cookie = ' + document.cookie)"; x,
gwstokenMd5: x,

If this page is hosted at any URL that contains "browsersso/" and is visited by a user the ClassLink OneClick Extension installed, it will automatically navigate to Google and show an alert box with your current cookie on, with no user interaction. A malicious script could, instead, post this or any other private information on the page to a remote server.

=== Vulnerability #2: Remote Code Execution Using classlink:// URL Protocol ===

The classlink:// URL protocol allows links to launch executables or open files on the system. This protocol is enabled by installing the ClassLink Agent.

The links contain a JSON-encoded payload encrypted using DES in ECB mode using a static symmetric key hardcoded into the executable of "234hyg32". The payload is not authenticated.

Because the payload is not authenticated in any way (the encryption does not function as authentication in this context), it can be arbitrarily modified. Since these URLs can launch executables with arbitrary parameters, it's trivial to leverage this into a remote code execution attack through the use of things like PowerShell or other local scripting environments included in Windows. For example in the following payload:

"LocalAppLaunchType": "localapp",
"path": [
"param": "-exec\" bypass -windowstyle hidden -c \"[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('This is an code execution proof on concept. The current logged in user is ' + [System.Security.Principal.WindowsIdentity]::GetCurrent().Name)",
"ignorepath": 0

This shows a proof of concept that runs a PowerShell command that will show the currently logged in user in a message box. This example payload can be encoded into the following URL, which will execute if clicked:


Alternatively, this link can be clicked automatically with JavaScript, so that visiting a web page is all that is required to trigger it. This example be modified to run any command, like downloading another executable from a remote source and executing it, allowing for the silent installation of malware just by visiting an attacker controlled webpage.

Additionally, the encryption used in the payload is not sufficient for modern use. Single DES is a deprecated standard and was withdrawn from recommended use in October 1999. The use of ECB Mode allows for a large number of attacks against the encrypted data itself. Also, the key size and character set do not have enough entropy to be sufficiently strong. A simple brute force on a modest machine could guess the key in approximately 24 hours.

=== Timeline ===

April 14th, 2018 - Reached out to vendor
May 7th, 2018 - Reply from vendor, sent disclosure
May 8th, 2018 - Vendor verified the issue and begun working on a fix
June 3rd, 2018 - Vendor confirmed fixes have been released

Related Posts