Remote Hardware Takeover via Vulnerable Admin Software

This article focuses on new research into potential remote hardware takeover vulnerabilities in admin software. These vulnerabilities occur due to a lack of control mechanisms, which enables potential WebSocket Hijacking attacks. The article explains how these attacks work, how to prevent them, and the importance of a content security policy header.

Remote Hardware Takeover via Vulnerable Admin Software

Increased digitization means that web browsers are integral to our daily lives. For example, I’m writing this article on a cloud-based word processing application, whereas a few years ago, I may only have had the option of using an executable desktop application. This growing capability means that the web will be a part of a broader attack scope in upcoming years. It’s safe to say that web security is no longer confined to web applications.

Taking Remote Control of Computer Hardware

A few weeks ago, we published a blog post about the study of researchers from Princeton and UC Berkeley on web based attacks, Discovering and Hacking IoT Devices Using Web-Based Attacks. This article focuses instead on new research on the potential vulnerabilities in web-based device configuration interfaces.

Taking Remote Control of Computer Hardware

This week, we explore a study conducted by Tavis Ormandy from Google Project Zero on taking control of users’ mice remotely through a websocket. In his research, Ormandy discovered that he had to download a 144MB program called Logitech Options in order to add a new function to his Logitech mouse. He realized that the program was copying itself to the Windows Registry directory HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and was set to run automatically when the computer started.

The program not only behaved as an electron application, but it also initiated a server. Since the Origin wasn’t checked during the handshake, connection to the websocket was possible from any website that the user visited.

x = new WebSocket("ws://localhost:10134");
x.onmessage = function(event) {console.log("message",; };
x.onopen = function(event) { console.log("open", event); };

Discovering the Lack of a Control Mechanism

On further analysis of the program, Ormandy discovered that the program expected JSON data, yet there was no enforcing rule or control mechanism set for the data to be sent in JSON format. When an unexpected data point was received, the app crashed. Here’s an example of an unexpected string input:

socket.send(JSON.stringify({message_type: "tool_update", session_id: "00cd8431-8e8b-a7e0-8122-9aaf4d7c2a9b", tool_id: "hello", tool_options: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" }))

Ormandy realized that tool_options expected an array value. He also found, in the Github repo of Logitech, that there was a communications protocol used by the program.

The only user authentication that the program used was a process id (pid) belonging to the user. At first sight, this might seem like a good precaution to take in order to slow down the attackers. However, Ormandy used a brute-force attack to bypass this precaution and obtained a valid pid to continue the process. After this authorization bypass, an attacker could configure anything and send commands.

WebSocket is one of the most important features of HTML5. Any website can make a WebSocket request to another resource. This request may include values stored in the browser, such as HTTP cookies. WebSocket Hijacking attacks abuse this feature in order to send and receive messages on behalf of the victim.

How to Prevent the Remote Control Attack

The most important part in all of this is that during the handshake – before a connection is established – the Origin value in the request isn’t taken into consideration. Tavis Ormandy suggests that Logitech could have whitelisted the origins and enforced the necessity of those Origin values in the WebSocket request.

Although HTTP and WebSocket are different protocols, the exact same necessity for control applies for HTTP too. Here’s an example of a request that initiates a websocket connection:

GET / HTTP/1.1
Host: localhost:10134
Connection: Upgrade
Sec-WebSocket-Version: 13

By checking the origin in this request, the websocket server can easily decide whether it should block the connection attempt or grant it.

Importance of the Content Security Policy Header

A way to make sure that your website isn’t abused to carry out such an attack, is to implement a proper Content Security policy (CSP). First and foremost, it will block Cross-site Scripting (XSS), if implemented correctly. However, it also lets you define to which websockets a connection can be established from your website as seen below.

Content-Security-Policy: connect-src 'self';

However, please keep in mind that this will only prevent your own website from being abused for such an attack. An attacker could use any website for that matter, including his own. So fixing the vulnerability on the affected device is the only effective way to prevent the attack.

What’s the Upshot?

The vulnerability reported by Ormandy on September 12 wasn’t given a proper response within Project Zero’s default 90 days, by which they expect vendors to respond and fix the reported vulnerability. This is why he shared the vulnerability with the public. Soon after he did this, Logitech employees responded. Meanwhile, he suggests that you disable Logitech Options until this vulnerability is fixed.

For further information, see “Options” Craft WebSocket server has no authentication.