It's 2020 so not only is your mouse config tool a Node.JS Electron app, it's also pwnable by an evil webpage

Malicious JavaScript can inject commands to execute

27 Reg comments Got Tips?

Earlier this year, peripheral maker Kensington patched its desktop software to close a vulnerability that could have been exploited by malicious websites to quietly hijack victims' computers.

Now the programmer who found this remote-code-execution hole, and reported it to the manufacturer, has identified a similarly serious flaw that's yet to be addressed.

In a blog post on Tuesday, Robert Heaton, a software engineer at Stripe, recounted his discovery of a vulnerability back in February, since patched, and his subsequent discovery of a second problem, which remains unfixed.

He suggested these flaws would be fairly easy to exploit. To do so, an attacker would have to lure a victim to visit a webpage containing malicious JavaScript that attacks the KensingtonWorks software installed on the mark's Windows PC or Mac. The result would be the execution of code on the computer, allowing the miscreant to siphon off files, meddle with data, and so on.

But he downplayed the likelihood of this scenario because it's likely a miscreant will have more success tricking people into downloading and running malware disguised as a Flash Player update than exploiting a fairly uncommon piece of software.

KensingtonWorks, which debuted in January, is an app for customizing the functions of peripherals like Kensington trackballs and mice. It’s based on the Electron framework, which allows developers to create cross-platform desktop apps using JavaScript, Node.js, and other web technologies. It’s relatively easy for software developers to use and it’s rather difficult to secure.

The problem is running a local web server and not securing it

It’s possible to write reasonably secure Electron apps, particularly with improvements that have been added in recent releases to address the various issues identified by infosec investigators. But it’s not obvious how to secure applications built on the framework, and software created using early versions of Electron probably haven’t been rewritten to implement less vulnerable patterns.

Not only is web technology notoriously difficult to secure, depending on your experience and skill level, but it becomes more so when integrated with Node.js, which has access to the local file system. Many of the recent security improvements in Electron involve new APIs (e.g. contextBridge) and best practices (e.g. using a preload.js script) to keep Electron’s main process and its access to the Node.js APIs isolated from Electron’s rendering process, which runs web code. But there are still fairly few examples of how to write secure Electron code.

For Heaton, though, the issue is the architecture of the KensingtonWorks app – such as its use of a local, poorly secured web server to receive user-interface clicks – rather than the use of the Electron framework.

“I don’t think the root cause is anything to do with Electron,” he told The Register. “The problem is running a local web server and not securing it – the fact that the app has an Electron frontend doesn’t affect this. The second vulnerability does exploit the fact that Electron apps can potentially be XSS-ed if you don’t sanitize your data, but so can browsers and no one grumbles about that too much.”

These shoddy design choices make KensingtonWorks an easy target, he argued in his post.

“The application consists of two components: a UI that users click on in order to configure their mouse; and a web server running on the user’s local machine,” he explained. “The UI sends HTTP requests to the web server, which updates the user’s mouse configuration accordingly.”

Felix Rieseberg at Covalence 2020

Electron devs bond at Covalence conference: We speak to those mastering the cross-platform tech behind Slack, Visual Code Studio, etc


Heaton argues it’s an unnecessary risk to run a local web server and leave it laying around on a machine with an open port. He concedes it’s possible to run a local web server securely but contends doing so increases the attack surface of the application and adds more opportunities for Kensington’s developers to make code mistakes.

Most desktop applications, he said, don’t rely on a local web server to handle user clicks on the app interface. Instead, they just trigger backend commands directly, without HTTP requests. But he suggests Kensington’s developers took this approach because they wanted to use Electron. This would allow them to create and maintain one app, for both macOS and Windows, rather than separate native apps for each operating system.

The problem with Kensington’s approach, he said, is that the app’s local web server has almost no authentication.

“This means that an attacker can easily spoof the requests that the UI sends to the server, without needing to know a long, random API key or anything like it,” said Heaton. “Presumably Kensington didn’t add authentication because they didn’t expect anything to try to talk to the server other than their own, trusted UI.”

With the first flaw, disclosed in June, a maliciously crafted webpage could use JavaScript to send background HTTP requests to the web server installed by KensingtonWorks, running on http://localhost:9090, and wind up executing arbitrary code on the victim’s machine. Because the only form of authentication was the five-digit device identifier, the JavaScript could try every possible number in a matter of five minutes.

Kensington patched the issue by removing from KensingtonWorks the emulatebuttonclick endpoint, which could be exploited to run malicious code. But it didn’t fix the app’s overall security model.

Clean your inputs

The unpatched bug involves a cross-site scripting vulnerability (XSS). Heaton said websites and Electron apps can defend against XSS by sanitizing their user inputs, which means, for instance, replacing characters that can be interpreted as functional code with encoded forms that get read as harmless text. “However, KensingtonWorks does not do this,” he said.

Heaton described how an attacker could create a webpage with malicious JavaScript that sends an HTTP request to /config/apps?device=$DEVICE_ID, a KensingtonWorks endpoint for creating app-specific device configurations and accessible via the built-in web server. When the user next opens the KensingtonWorks app, it will try to display these configurations and will interpret the configuration as JavaScript code and execute it. Said code could be the following, which creates an empty file /tmp/oh-dear:

<script>require(‘child_process’).spawn(‘touch’, [‘/tmp/oh-dear’]);</script>

“The spawn NodeJS function in the payload allows the attacker to run a shell command of their choice, giving them direct remote code execution,” Heaton said. He adds that he told Kensington about this second vulnerability on July 6, 2020, but the company neither responded nor fixed the flaw.

“Kensington fixed the first vulnerability within a week or so of me reporting it, but it’s unfortunate that they haven’t fixed the second yet,” he said in his message. “I’ve been emailing their general support email address, but I’d have found it easier if they had a dedicated security email address. That way I would know that my emails had been received and could try to follow up if I didn’t hear anything back.”

The peripheral maker says it’s investigating Heaton’s findings. “Kensington has been made aware of this and their software team is looking into it,” a company spokesperson said. ®

Biting the hand that feeds IT © 1998–2020