AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
![]() ![]() Since there were no long, gibberish-looking tokens in the /devices request, it was pesos to pizza that the KensingtonWorks server was not protected by any kind of password or key. First I confirmed that it really was only listening on lo0, the loopback interface:Īccept: application/json, text/plain, */* I downloaded and installed KensingtonWorks. As Sherlock Holmes might have said, once you eliminate all the good reasons for doing something, all that’s left are the questionable ones. Nonetheless, I couldn’t think of a good reason for KensingtonWorks to open up even a local network port. This at least meant that the application was only accessible to other programs running on the user’s machine, and not to other machines on their network. The 127.0 at the edge of the screenshot in my correspondent’s message suggested that KensingtonWorks was only listening on the local loopback interface. From a privacy perspective there’s nothing intrinsically problematic about listening on a network port but from a security point of view it increases the application’s attack surface area and gives the developers more ways in which they can make mistakes. My correspondent had messaged me in response to my request for suspected privacy abuses, but I reckoned that this was more likely to be a security problem than a privacy one. No user interaction with the page is required.īack to my DMs. These requests trick KensingtonWorks into physically opening the users terminal application, then pasting and executing the attacker’s payload commands. The attacker’s website uses JavaScript to send HTTP requests to an unsecured local web server run by KensingtonWorks. To exploit the bug, the attacker lures their victim to a malicious website. In this post I’ll describe how the vulnerability works and how I found it. Users should either upgrade to v2.1.17 or uninstall the product until the remaining, less severe flaw is fixed, depending on their risk tolerance. However, they haven’t patched the root cause, and an attacker can still use the same pattern to secretly mess with the user’s KensingtonWorks settings. They have not been in contact with me since, but they appear to have recently mitigated the most harmful effects of the vulnerability, preventing it from being used to execute arbitrary code. I disclosed this flaw to Kensington on, when I said that I would wait for 90 days before publishing details of the vulnerability to give them time to fix it. The result of said shovelwork was a vulnerability that allows an attacker to remotely execute arbitrary code on a victim’s computer. My dad owns several Kensington devices, and if you mess with my dad then, well, I’d prefer if you didn’t. It shouldn’t need to receive any network connections in order to manage its users’ mice. There’s nothing necessarily wrong with this, but it was still a strange thing for KensingtonWorks to do. In their message they noted that KensingtonWorks was listening on a TCP network port, allowing other programs on the user’s computer to connect to it. They had noticed some odd behavior by KensingtonWorks, a piece of software that allows its users to add power functionality to mice made by Kensington, a popular brand of peripherals. Back in February, a Twitter user who has asked to remain anonymous sent me a tipoff.
0 Comments
Read More
Leave a Reply. |