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.
KVM’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
The 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.