Hacker Fails for the Win

BLACK HAT EUROPE 2022 – London – Researcher Douglas McKee was having no luck extracting the passwords in a medical patient-monitor device he was probing for vulnerabilities. The GPU password-cracking tool he had run to lift the layers of credentials needed to dissect the device came up empty. It wasn’t until a few months later when he sat down to read the medical device’s documentation that he discovered that the passwords had been right there in print the whole time.

“I finally got around reading the documentation, which clearly had all the passwords in plaintext right in the documents,” McKee, director of vulnerability research at Trellix, recounted in a presentation here today. It turned out the passwords were hardcoded into the system as well, so his failed password-cracking process was massive overkill. He and his team later discovered bugs in the device that allowed them to falsify patient information on the monitor device.

Failing to pore over documentation is a common misstep by security researchers eager to dig into the hardware devices and software they are studying and reverse-engineering, according to McKee. He and his colleague Philippe Laulheret, senior security researcher at Trellix, in their “Fail Harder: Finding Critical 0-Days in Spite of Ourselves” presentation here, shared some of their war stories over mistakes or miscalculations they made in their hacking projects: mishaps that they say serve as useful lessons for researchers.

“At all conferences we go to [they] show the shiny results” and successes in security research like zero-days, Laulheret said. You don’t always get to hear about the strings of failures and setbacks along the way when sniffing out vulns, the researchers said. In their case, that’s been everything from hardware hacks that burned circuit boards to a crisp, to long-winded shellcode that failed to run.

In the latter case, McKee and his team had discovered a vulnerability in the Belkin Wemo Insight SmartPlug, a Wi-Fi-enabled consumer device for remotely powering on and off devices connected to it. “My shellcode was not getting through to the stack. If I had read the XML library, it was clear that XML filters out characters and there’s a limited character set allowed through the XML filter. This was another example of lost time if I had read through the code I was actually working with,” he says. “When we deconstructed it, we found a buffer overflow that allowed you to remotely control the device.”

Don’t ASSume: Schooled by Distance-Learning App ‘Security’

In another project, the researchers studied a distance-learning software tool by Netop called Vision Pro that, among other things, includes the ability for teachers to remote into students’ machines and exchange files with their students. The Remote Desktop Protocol-based feature seemed straightforward enough: “It allows teachers to log in using Microsoft credentials to get full access to a student’s machine,” McKee explained.

The researchers had assumed that the credentials were encrypted on the wire, which would have been the logical security best practice. But while monitoring their network captures from Wireshark, they were shocked to discover credentials traveling across the network unencrypted. “A lot of times assumptions can be the death of the way you do a research project,” McKee said.

Meantime, they recommend having in hand multiple versions of a product you’re researching in case one gets damaged. McKee admitted getting a bit overzealous in deconstructing the battery and internals of the B Bruan Infusomat infusion pump. He and his team took apart the battery after spotting a MAC address on a sticker affixed to it. They found a circuit board and flash chip inside, and they ended up physically damaging the chip while trying to get to the software on it.

“Try to do the least invasive process first,” McKee said, and don’t jump into breaking open the hardware from the start. “Breaking things is part of the hardware hacking process,” he said.