Hacking A KVM: Teach A Keyboard Switch To Spy

When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.


DSC_0418KVM’s started off really simple but they haven’t stayed that way. In the early 1990’s you could get a 4-port KVM which was little more than an AV-style switch. The transition of keyboards to USB brought with it a big upgrade to the KVM hardware. In 2000 switches with 16-ports and a full USB stack came onto the scene. Ten years later you could find Matrix KVM’s that support 1024 machines or more. These are far from the early switches, they’re full blown computers built to make access to server racks full of machines simple.

Finding the Firmware

DSC_0422The key is the firmware, own it and you own the device. The undisclosed manufacturer of the device presented in this talk was nice enough to include a CD in the box that contains the firmware update utility, as well as the firmware.bin file. The firmware utility unpacks this binary and stores it in memory which makes it easily accessible.

Unfortunately running the dumped blob through Binwalk did nothing for the researchers. The 64 kilobytes of data contains not a single string and zero usable results, it’s obviously obfuscated. The next test was sniffing the data transmitted through the update cable which comes with the unit. Other than your normal serial overhead and error correction, what is going through the cable is byte-for-byte identical to the blob. They needed to figure out a way to crack that code.

Decoding the Firmware

The real key to decoding the firmware blob came when looking at the circuit board of the KVM. There are two big chips with the device manufacturer’s name branded on them; likely ASICs. In addition to that there is an 8052 processor and an external RAM chip. Looking at the firmware through the lens of 8051 Assembly (yes, this is an 8052 but assembly is the same as the ’51 variant) is what did it for them.

It didn’t immediately turn up any clues, but looking at the last eight bytes of the firmware, a pattern started to emerge. Matching the frequently used values found across several variants of the firmware, the researches started to associate this as an identifier of the firmware version. These were basic numeric values, but the four bits representing each number were hidden in each byte, occupying positions [6..3]. By rotating the bytes to the right by three, each byte becomes the ASCII value for a number, and these lined up with the rev number of the firmware.

They were almost there. Looking at the strings they found an alphabet but in the wrong order. Closer study showed that the letters were grouped into 3 sets and each set was shuffled in the same way. This string was the key to un-shuffling the rest of the binary. Eureka, obsfucated code! Shifting all bytes of the firmware allowed Binwalk to parse the file and that resulted in strings, functions, and everything you need to read the program.

Demonstrating the Vulnerability

Of course reading the firmware is only the first step, you need to show that something useful (insidious) can be done with it. During the talk the pair demonstrated their custom firmware switching to a different system, “typing” in the password (which would have been logged earlier when a human typed it in), and echoing out a binary file which was then executed to load malware onto the system.

Yes, you need physical access to perform this attack with the KVM used during the talk. But some KVMs allow firmware updates over IP, and many of them have web interfaces for configuration. There are many vectors available here and knowing that, the discussion turns to prevention. Keystroke statistics are one way to prevent this kind of attack. By logging how fast characters are being typed, how tight the cadence is, and other human traits like use of backspace, the effectiveness of this type of attack can be greatly reduced.

11 thoughts on “Hacking A KVM: Teach A Keyboard Switch To Spy

  1. Hmmm, seems to me these days you get your SSH access through putty for as many systems you need. No need for a KVM. I have a 16 port on the shelf i have not used in many years. If it has a known ip address and has SSH its as easy as pie.

      1. In servers with management cards you often can. I’m quite suspicious of the security of these cards though. They often run a full Linux/VXWorks install which is never updated.

  2. > Keystroke statistics are one way to prevent this kind of attack. By logging how fast characters are being typed, how tight the cadence is, and other human traits like use of backspace, the effectiveness of this type of attack can be greatly reduced.

    WAT? you have a hardware keylogger logging ALL OF THIS DATA, and can replay password input with precision up to 8ms, how is tracking this going to help you?

  3. Personally, this just looks like an issue of limiting control access to the switching firmware itself by design and physically isolating the path to control this to an input port only; internally there should be no reverse connection to allow the existence of an internal loopback between two machines keyboard inputs. That would be a different switch, a router. Protocols already exist for that. What Charlie Underwood suggested with data diodes should already be built into a ‘smart’ KVM though design, not as an afterthought. Obfuscating code is a poor way to protect something, and if it exists in every device manufactured, obviously anyone can take as much time as they like decoding it. I see no problem in designing and physically isolating circuits which control, from the circuits which use. Then I think, this would work just like the older systems with only a few outputs, and a button to switch between them. Protecting access to the machine setting the configuration of the switching paths would always be of paramount importance. The only purpose to do it the way shown in this article would be to allow access from any machine, to any machine, Who needs a router then? A switch like that would be dangerous, I say scrap them, and re-design, or find someone with better smarts and buy their product instead.

    I applaud these guys for pointing out the absurdity and lackadaisical attitude found in development nowadays. Either that, or the developers have a built in mismanagement of security for ulterior purposes. A “Design by Intent” attitude clouded in obfuscation. This is why open source works best. Publish your codes, and let the white hats do what a white hat does best, protect the world from the black and gray hats.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.