Keylogger Found in HP Laptop Audio Drivers

This is a weird story: researchers have discovered that an audio driver installed in some HP laptops includes a keylogger, which records all keystrokes to a local file. There seems to be nothing malicious about this, but it’s a vivid illustration of how hard it is to secure a modern computer. The operating system, drivers, processes, application software, and everything else is so complicated that it’s pretty much impossible to lock down every aspect of it. So many things are eavesdropping on different aspects of the computer’s operation, collecting personal data as they do so. If an attacker can get to the computer when the drive is unencrypted, he gets access to all sorts of information streams—and there’s often nothing the computer’s owner can do.

Tags: , ,

Posted on May 17, 2017 at 6:32 AM • 34 Comments

Comments

Sok Puppette • May 17, 2017 7:09 AM

In a halfway well designed system, the audio driver doesn’t have access to the keyboard OR the disk.

Unfortunately people have been shoveling garbage out the door for 30+ years now, so we don’t have many well designed systems.

Kai • May 17, 2017 8:01 AM

I’m guessing the reason the audio driver has access to the keyboard is so you can use hotkeys to adjust the volume or mute the audio output. Why they’re writing this out to a file is anyone’s guess.

Private Joe Bauers • May 17, 2017 8:13 AM

A keylogger, nothing malicious about it, nope. Installed by the corporate successor of defense and intelligence contractor Rockwell. Records every keystroke for perpetual backup on the cloud, but, ah, so what? Just goes to show, one little brain fart and you can accidentally implement documented state surveillance policy.

Classic case of It is difficult to get a man to understand something, when he’s paid to be comically obtuse.

keiner • May 17, 2017 8:30 AM

@Kai
If it was for hotkeys and debuggin, why not log hotkeys ONLY?

This whole story makes no sense at all…

Andrew G • May 17, 2017 8:36 AM

To me the most interesting part of the story is that the keylogger was detected, and HP was quickly shamed into patching it.

tx • May 17, 2017 8:53 AM

In a halfway well designed system, the audio driver doesn’t have access to the keyboard
I’m guessing the reason the audio driver has access to the keyboard is so you can use hotkeys to adjust the volume or mute the audio output.

The OS should be doing that, not the audio driver.

Agggie • May 17, 2017 9:05 AM

The pattern here exactly fits NSA’s documented tampering with Cisco and Debian: an unnecessary change pokes a gaping hole in security. It sits for months and months and then some little typo weaponizes it. With Debian the entire process was recorded in the public domain, traceable to an individual cutout. When sabotaging commercial products, the colluding corporation can conceal the details that establish intent. Watch HP tie itself in knots feigning full disclosure. Their computer business is languishing anyway, they clearly put it out of its misery. Now NSA and CIA owe them one. MIPRs and SAPs will make up for the reputation hit.

From here on in, only an idiot would buy an HP box.

albert • May 17, 2017 9:09 AM

@Sok Puppette,
“…In a halfway well designed system, the audio driver doesn’t have access to the keyboard OR the disk….”

True.

“…Unfortunately people have been shoveling garbage out the door for 30+ years now, so we don’t have many well designed systems…”

Garbage? True, but this has nothing to do with being well designed. It’s deliberately installed spyware. It may be that HP was unaware of it, and Conexant is to blame. BTW, their site is unavailable (Error 502)

It appears that the Conexant HD Audio Driver is used in a lot of Windows systems, not just HP.

According to this site;(http://www.processchecker.com/file/Conexant%20Audio%20sp40762.exe.html), HP designed the driver.

. .. . .. — ….

keiner • May 17, 2017 9:27 AM

Nice little detail not really in line with the “debug” story told:

“If the logfile does not exist or the setting is not yet available in Windows registry, all keystrokes are passed to the OutputDebugString API, which enables any process in the current user-context to capture keystrokes without exposing malicious behavior. Any framework and process with access to the MapViewOfFile API should be able to silently capture sensitive data by capturing the user’s keystrokes.”

https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt

Me • May 17, 2017 9:52 AM

@keiner

Actually, that could just be that the debug keylogger was set to map debug data to the file. If that mapping failed (file didn’t exist) then the debug data goes to its default location OutputDebugString. That would be my guess, not being familiar with the actual system, but having seen plenty of programs that write to files by redirecting stdout.

Clive Robinson • May 17, 2017 10:59 AM

I’ve had a little time to think on this and it’s one of those things that I find deeply suspicious because of the level of deniability that comes from it.

Firstly, yes due to the way PC’s are manufactured, nearly all buttons go through the key board (including the power button and wifi on/off switch etc).

Thus adding the volume control and mute buttons was a natural progression for manufacturers as was going to flash ROM and removing the wrote protect tab etc. Thus “efficiency -v- security” yet again.

Writing the key strokes to a file, is kind of what you expect from a test harness, and also something of use to technical support people. We saw this idea splat the news headlines big time several years ago with various US phone companies installing the CarrierIQ software that sent all the key strokes in plain text across the Internet for “Customer Support” reasons.

We should also know that the audio side of PC’s is probably the part least subject to change after all howmany of you still have AC97 compatable chips and drivers in your system? Realtek still holds the majority market place for OEM aidio and network chips thus you are quite likely to have a Taiwanese “Crab Inside” your laptop. Some of you may remember back in 2011 it was found that some one had “black bagged” their driver signing certificate.

Thus it’s clear that the backwater that many think the “audio” side of PC’s is anything but when it comes to opportunities for spyware, and that the opportunity to use it as such is not just there but very wide spread and importantly very stable/long lived for such backdoor code…

As for the log file it’s self, due to the way it changes and where it is, it’s a prime candidate for getting “backedup to cloud” across the Internet. Thus even if you have taken security steps like FDE you are thwarted in your attempts.

Avoiding cloud backup for most average users of Win10 etc is next to impossible, it’s the way Microsoft want it to be, along with telemetry and forced OS upgrades. The fact that such a file becomes in effect a business record of a third party supplier means that it only takes a letter or less for this data to be aquired by various LEO or IC agencies in quite a few jurisdictions.

So all the steps of an exfiltrating keyboard logger are there, and they all appear to have deniability, which in of it’s self is odd. You would expect atleast one step not to have deniability if it was all accidental…

So whilst I can not say it’s a deliberate keylogger it’s got more smoking guns than the OK Corral…

And that’s before you look into the backgrounds of the companies involved, and their relationships to the US IC etc.

Andrew • May 17, 2017 11:13 AM

I said it before, keystrokes represents basically the interaction of a user with the machine, maximum amount of information with minimal storage. Until smartphones provided location, sound and images, keystrokes were the most valuable user data.

So easy to store and hide several bytes all along the input chain…. keyboard : keys, controller, cable, usb plug – hardware keyloggers exist for all of them, see link … then the computer .. drivers, controller, firmare, OS, installed software etc…

http://cheap-spy-equipment.blogspot.ro/#6164786723664546145

Ross Snider • May 17, 2017 12:19 PM

This is exactly why I’ve been saying default full disk cloud backup is a bad idea.

This is the golden age of surveillance. Why on earth would you think uploading the real time monitoring of your system processes, their data, and all the data on your disk to a company that’s known to provide backdoor access to intelligence agencies?

The problem here isn’t that there’s a keylogger running with SYSTEM privileges on machines out of the factory floor. The problem here isn’t that the keylog is dumping the information so that it is readable by everyone on the machine. The problem is a combination of two: one old and one new.

Old problem: Your computer isn’t yours, as its behavior is controlled by other people and you are prevented from both understanding how it behaves and from changing how it behaves.

New problem: Your data isn’t yours, its considered the joint property of you and the infrastructure provider that supports your data. You are prevented from both understanding what is done with your data and from changing what is done with your data.

Chelloveck • May 17, 2017 4:39 PM

@Andrew: In this case, it’s a maximal amount of information in a maximal amount of storage. Every key-up and key-down event takes over 100 characters in the log file:

MicTray64.exe(tid 1040)   71388:[    J_STATE] - Mic target 0x1 scancode 0x1e flags 0x0 extra 0x0 vk 0x41

To be sure, it’s highly compressible, but it’s not exactly the format I’d choose for deliberate exfiltration of data.

I’ll give the developer the benefit of the doubt here. I’ve written similar temporary debugging code myself, and have even forgotten to remove it. Fortunately I’ve never had it escape to production. After one or two close calls I’ve taken to giving my debug flags such elegant names as:

#ifdef CHELLOVECK_IS_AN_IDIOT_AND_FORGOT_TO_DISABLE_THIS_DEBUG_CODE

to pretty much guarantee that leftovers get caught in code review.

This keylogger could be really clever malicious code masquerading as really stupid debug code, but until I see evidence to the contrary I’m more inclined to believe it’s just plain old stupid debug code.

Impossibly Stupid • May 17, 2017 4:40 PM

@Clive
“deeply suspicious because of the level of deniability”

This. Bruce can say “seems to be nothing malicious about this” all he likes, but the way it opens up new attack vectors is fishy as hell. It’s exactly the kind of thing you’d expect to see in a sophisticated attack, where no one component is that harmful, but taken collectively they all result in a wide-scale security breach. It should just be a set tenet of security that all keylogging like this is inherently malicious.

TM • May 17, 2017 4:58 PM

Bruce can say “seems to be nothing malicious about this”…

That’s because he couldn’t find a way this time to link russians to the story. LOL

due to the way PC’s are manufactured, nearly all buttons go through the key board

Sound drivers don’t interact with the keyboard normally, the special kb keys are processed via some user-land app that normally appears in the tray. That app then communicates with the driver if needed, but most of the time volume level change or silence doesn’t require talking to the sound driver, these are the standard WinAPI functions and the OS normally manages everything by itself. So there’s really absolutely no need for a sound driver to scan keycodes.

Douglas Almquist • May 17, 2017 7:11 PM

I have filed a formal complain with the Washington State Attorney General regarding this issue.

Jesse Thompson • May 17, 2017 7:54 PM

Any speculation that this is not malicious — against the background of our current surveillance state being such old news that everyone is bored of even exploring the matter any more — is precisely as useless as speculation that there might actually be a wolf this time after the five billionth time that Timmy Trollhard claims to have seen one.

Namely: whether we believe Timmy or not, we should behave as though we don’t and just allow it to gobble him up.

Andrew • May 17, 2017 8:25 PM

@chelloveck
Interesting observation, not sure in this case but the rule of thumb for intelligence released backdoors was that they should masquerade as bugs.

Willie B. Good • May 17, 2017 9:04 PM

Hum… Would this apply to Linux & BSD systems after I have cleaned the hard drives with DBan? I have encryption on some machines and not on others. For vacation this year I’m setting up a system as secure as I can in OpenBSD including a BIOS/UEFI password, whole disc encryption & OpenVPN; not perfect but I’m doing the best I can…

Blessings,

Willie.

BTW. I’ve dealt with MS beginning in ’84 , ’85? I still can’t stand them…

John Smith • May 17, 2017 9:20 PM

@Chelloveck:
“This keylogger could be really clever malicious code masquerading as really stupid debug code, but until I see evidence to the contrary I’m more inclined to believe it’s just plain old stupid debug code”

I am inclined to believe the exact opposite. Disguising malware as coding errors is a core competency of NSA.

Peter A. • May 18, 2017 2:54 AM

@Chelloveck, @John Smith and others:

Writing stupid insecure debugging code out of ignorance and forgetting to remove it is indistinguishable from writing stupid insecure debugging code on purpose and deliberately leaving it there. We only see the effect, never the intent. So it is all matter of your personal opinion.

Drone • May 18, 2017 4:58 AM

Yeah, the foreign guy with the H-1B Visa they hired to replace me just scraped some key logger code off a script-kiddy’s site and dropped it into the driver pretty-much as is. Now the Mute & Vol+/- Fn-keys work OK. Key logging is just an added bonus.

Andrew • May 18, 2017 5:17 AM

@drone
Also you don’t know if the visa story is true and who is he really working for or what compromises he had to do for that visa.

Ollie Jones • May 18, 2017 6:41 AM

Have you bought any new HP products lately? A printer? A laptop?

They are larded with crapware. The household-grade printer driver comes with all sorts of ridiculous extra stuff that you have to work around if you just want to print a couple of pages of text. No, I don’t want to buy paper. Yes, I have enough ink in the cartridges. No, it hasn’t dried up (yet). Just print my kid’s homework already kthksbai.

It’s an 80meg download for what should be, at the largest, a 200k hunk of well-debugged driver code that makes and passes PostScript or PCL6 to a USB port.

The laptops have buttons that are supposed to help you do useful stuff like rig projectors, but display ads for other products.

Their marketing people have totally seized control of the software content of device drivers. HP engineers are legendary for keeping it simple, but that legend is getting lost in the mists of time. It smells like a business death spiral to me: they upsell and cross-sell to monetize every little corner of the product line to stay in business. It’s a shame. They could charge a little more for a stripped-down functional product that had been through security review.

Marc Espie • May 18, 2017 8:27 AM

With all that’s happened recently (that keylogger, wcry, amt’s disaster), I don’t understand why we don’t clamor for more openness.

It’s exactly like cryptography: a lot of the problems come from the fact that a lot of steps of the engineering process are opaque, and 100% closed to scrutiny. In HP’s case, you don’t have a manifest of everything that was put on the machine. In Intel’s case, they purposely hide things from the user. In Wcry’s case, well even Microsoft slammed the NSA for hoarding exploits instead of helping them publish advisories.

I’m not saying opensource is perfect, but opening all that… junk (to be polite) to public scrutiny is the thing to do. When you do that stuff in public, you’re less tempted to do horrible hacks (if you have a little bit of self-respect), and you’ve got a chance at a peer-review process.

I suspect this (and the internet of shit^Wthings) is going to push us, sooner or later, to a more transparent way for engineering. Either that, or we let the governments close things really hard, and we won’t like it.

Jimbo Blogins • May 18, 2017 8:36 AM

Hardware vendor employees may still offer to give out their passwords for FTP via a polite email. Occasionally their is a hot Ethernet or audio driver, or other. It is used to be far worse, well no it probably hasn’t improved. Some employees would be better if they were always sick or did nothing at all, and also touched nothing.

Jiv4 • May 18, 2017 2:00 PM

This brings to light a recent attempt by government agencies to have Congress approve Carte Blanche access to any PC attempting to conceal its browsing activity (like using Tor). They wanted authority to enter those PCs without having to get a FISA approval or notify the party of their intrusion. Once in keylogging would be the least of one’s worries. They could use a utility like heapmemdump to capture and record the memory of a process actively encrypting a file. Potentially (I say potentially because I have not yet tried to do it) they could capture your key code. Then all files that you ever have and ever will (using that key code) would be open to them. What does that do to the strength of open source encryption? Since they were asking, the possibility of this happening has been around for some time and may have already been done. Any hacker, sanctioned as well as unsanctioned can enter your PC whenever they like and place a thread there to monitor processes running on your PC, looking for key strings and recording them to a file for transfer to a URL on the Net. Tell me it is not so.

John Smith • May 18, 2017 5:17 PM

@ Ollie Jones:
“HP engineers are legendary for keeping it simple”

HP engineers were legendary for excellence. They designed and made the best test equipment available. Used but well-maintained HP test equipment, even decades old, still costs a lot. There is still a thriving market for that gear, for good reason. There are ex-factory techs who repair that gear for a living, again because there is a thriving market for that service.

HP never really understood PCs, IMHO, but their mid- to high-end printers were great. I have a mid-range HP b/w laser printer, ten years old at least. It’s been trouble-free all that time.

Like someone else said above, keep your old gear, if its high-quality and working (or repairable). Not just for security reasons – for the build quality as well.

Impossibly Stupid • May 18, 2017 6:25 PM

@Peter
“We only see the effect, never the intent. So it is all matter of your personal opinion.”

That’s a false narrative. The software developer(s) of this driver is quite able to tell us their intent. It would have to be a pretty detailed in order to be believable, because it makes zero sense to have something at a low level like an audio driver interacting with something like the keyboard. The fact they they seem to be unable or unwilling to disclose their intent is what makes this effectively malicious. That is a simple matter of good security practices, not opinion.

65535 • May 19, 2017 12:09 AM

Well, so much for HP’s reputation. Sure HP fixed it but that is most likely because they were caught.

I think we have lost control of our manufacturing base which build basic motherboards, screens, BIOS/UEFI and micro controllers. Any number of actors could have slipped into the manufacturing chain and planted this style of key logger. Worse, is that HP would not care as long as their sales stay high.

I assume we will be see more of key logger spy stuff in when future consumer are actual tested. Maybe, some new security body should be created similar to UL [tm] for It devices – especially overseas manufactured devices. I will not hold my breath for this new IT security body to appear.

Kathleen Sefzek • May 12, 2021 1:31 PM

Hey howdy,

Anyone happen to know the name of the driver and of the file it outputs the data to?

I’ve had a little voyeur problem with a 2nd hand HP, and I am hoping maybe it can help with documentation of this hack. (Or at least rule out one possible method)

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.