Debugging code left in production software is often a security problem waiting to happen.
That’s because debugging code is typically put in when you need an “insider view” of what’s going on.
Debugging features often puncture deliberate security holes to allow troubleshooting data to escape – something that’s OK in an in-house test environment, but unacceptable in an official product release.
So, you should not only remove debugging code when it’s no longer needed (code that isn’t there can’t get included by mistake!), but also arrange your production builds so that any debugging code that’s left behind by mistake gets discarded or disabled automatically when the software is compiled for release.
Many a slip
But there’s many a slip, as they say, twixt the cup and the lip.
The infamous Internet Worm of 1988 had three propagation tricks; the easiest and most effective of these was to connect to your email server in the hope that your system administrator had left debugging turned on in the Sendmail product.
If Sendmail debugging was on, the server would take an incoming email and run it directly as a series of system commands – clearly the sort of debugging bodge that makes no sense outside a controlled lab environment.
Dlink did something equally dangerous in some of its recent routers: if you told your browser to announce itself under the weird name of
xmlset_roodkcableoj28840ybtide instead of, say, Firefox or Safari, then you could run any sysadmin command on the router without knowing the password.
Reading that peculiar “roodk cable oj” incantation backwards makes the blunder obvious: the text string is
Edit by 04882 Joel: Backdoor in reverse.
And HP blundered with a number of its LaserJet printers a few years ago, accidentally leaving a telnet command shell open for debugging…
…in the production code running on shipping printers.
An open telnet shell meant that anyone could simply connect to the device login and get a command prompt to allow them to mess with the printer at will, without needing any special software or a password.
According to security researcher Michael Myng, HP made another debug-code-in-real-build mistake this year, leaving a deliberately-created keylogger built into the keyboard drivers on a number of HP laptop models.
Myng says he started disassembling HP’s keyboard driver to help a friend, who wanted to figure out how to take control of the keyboard backlight.
While reverse engineering the code, he noticed a bunch of text strings including intriguing messages like this:
ulScanCode=0x%02X, kKeyFlags=%X CPalmDetect::KeyboardHookCallback
Don’t worry if you aren’t a C programmer: all you need to know is that these messages imply that there’s some sort of keyboard hook (the fancy name for a keylogger function) in the code, and that the program might keep a record of scancodes (the identifying numeric codes of individual keypresses based on their keyboard positions) as you type.
It didn’t take Myng much more digging to realise that by setting a special registry entry called
Mask, he could trigger the driver into recording every keypress via an official Windows logging system called WPP.
WPP is short for Windows Software Trace Preprocessor, and Microsoft officially advises that:
WPP software tracing is primarily intended for debugging code during development.
In other words, that
CPalmDetect::KeyboardHookCallback we saw above should not have survived release.
Fortunately, Myng reports that:
I messaged HP about the finding. They replied terrifically fast, confirmed the presence of the keylogger (which actually was a debug trace) and released an update that removes the trace.
Well done to HP for a straight-talking answer followed by rapid action – we’ll call that a good result.
Note that you’d have needed administrator power to authorise the registry tweak needed to start this “keylogger” in the first place, so the risk can be considered low.
Nevertheless, for a hacker who already has a foothold inside your network, setting a registry entry to start capturing keystrokes via an official, digital signed keyboard driver…
…is a lot easier than fiddling with the driver software itself, or trying to install a new driver to do the job.
What to do?
- If you have an affected HP computer, get and install the update now. (Warning: there are well over 450 different models on HP’s official list, all the way from HP 240 G2 to the Star Wars Special Edition 15-an000 Notebook.)
- If you’re a programmer, don’t leave debug code behind.
- If you’re a quality assurance tester, don’t believe the programmers when they assure you “that debug code is harmless and can stay”.
6 comments on “HP leaves accidental keylogger in laptop keyboard driver”
registry tweak needed to start this “keylogger” in the firt place -> first place
Thanks, now fixed 🙂
Is this problem exclusive to Windows or is there a similar problem on Linux?
By installing Lubuntu do you sidestep the problem?
Fix hard to find… but finally got it.
I hear that HP disabled this keylogger by default and a hacker will need physical access to your system in order to enable it. However, it is still risky as it can compromise a lot of user’s private data. I just installed the update. Thanks for the info.