This article is more than 1 year old
It's 2020 so not only is your mouse config tool a Node.JS Electron app, it's also pwnable by an evil webpage
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.
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.
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.”
Electron devs bond at Covalence conference: We speak to those mastering the cross-platform tech behind Slack, Visual Code Studio, etcREAD MORE
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.”
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.
“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. ®