Hacker News Reader

Comment by jchw | Hacker News Reader

So... This has ballooned from debug code with no evidence of ever being maliciously used to "loss of confidentiality" and now instead of being a keylogger it's a "hidden keylogger."

Dramatic tone change for no actual new news. Sure this is getting the person's blog attention, but now I'm certain I don't agree with the alarmist title of the original post.

View on HN

And the assertion that "an attacker with access to the computer could have enabled it to record what a user was typing" is somewhat silly.

If the attacker has access to the computer, why not install some other key logger that would send info to the attacker's site?

Or as Raymond Chen is fond of saying (citing from the Hitchhikers Guide), "It rather involved being on the other side of this airtight hatchway".

Claiming that an attacker would use this is nonsensical.

You need write access HKLM in order to change the registry key, if you have write access to HKLM you can inject your own driver (inc. keylogger) into the OS.

Plus the keypresses are context-less (i.e. you don't know what application, or window the keypress was sent to). A continuous stream of keypresses with no context is darn near useless, it doesn't even contain timestamps!

Any number of off-the-shelf keyloggers would do a far better job, all of which can be auto-loaded if you have HKLM write access. They'll even tell you the exact web page a keypress was sent to and manage the job of sending that information to you...

Those off the shelf keyloggers world be detected by security software, however, whereas something signed by the vendor is going to be whitelisted. I still wouldn’t say this is a huge sign of malice but it’s definitely open for creative misuse.

www.facebook.com<return> stephan<tab>123abc

doesn't seem useless to me.

A person that knows that you can use tab to jump between form fields probably uses a password manager anyway.

You only need a powered user to modify HKLM. It's a group between users and administrators, not often used or known.

I agree that the someone having access to run arbitrary code on a machine is a much bigger deal. In this case, the difference between this debugging feature and an installed keylogger is the use of trusted software to perform the keylogging. When the mictray issue came out earlier this year, I ran across a blog post you may find interesting [1]. To summarize, the author repurposed the HP executable to log keys to a remote server using webdav.

[1] https://diablohorn.com/2017/05/12/repurposing-the-hp-audio-k...

Thanks, Julian - that was interesting. The redirecting of the keylog to a webdav destination lets the key logging happen to a remote server, without installing any untrusted software, and with no user UI-level exposure.

>> why not install some other key logger that would send info to the attacker's site?

Because one would assume that this software/driver has been signed and would not be recognized as evil by any protection system, at least not one on the laptop.

and get their ssh keys while you're at it.

The previous one in the audio(!) drivers was as bad as it could have been:

https://www.bleepingcomputer.com/news/security/keylogger-fou...

"writes all keystrokes to a local file at:

C:\users\public\MicTray.log"

Note: Public folder! All keystrokes. Discovered May 2017, preinstalled on 28 HP laptop models. Other hardware that uses this driver may also be affected.

Edit, to the other commenters in other threads: please don't mix them, there are two "keyloggers." The one in the audio(!) driver was always on, recording by default to the publicly accessible file, as seen here.

The one in the new news is a code in the keyboard driver that can be turned on (and here it's important to know if the switch is publicly accessible) but isn't on by default. Depending on how that one is turned on and where the result is logged, it can be not worthy to worry too much. But these details also matter.

Unlike this one, it even looks like the audio driver exploit is on by default. Much stranger. Guess HP developers aren't very clean with their release process.

Okay so reading the comments here makes me feel a bit more at ease, but honestly after reading the article I was literally like, "why the hell would the AUDIO driver need to monitor key strokes.." It really sounded like a deliberate installation of a hidden keylogger. I am glad to read that perhaps it is not, but damn sloppy.

To test hotkeys during development.

Listening for function key presses, I would imagine.

Every laptop I've ever had allowed volume control with function keys.

Disclaimer: it's been over a decade since I've done applications development and I've never done driver development.

Ah yeah that makes sense... sort of. I would have expected specific volume commands to come through from another layer, not for the audio driver itself to be directly listening to the keyboard. But I guess that's why it's just debugging code.

We already lost control over HW and SW. There are often malicious functionalities in binary software and our 'hardware' can't be trusted either (Intel ME, AMD PSP, firmwares, bioses). Some time ago, firmware in a notebook used to install drivers into windows during boot without user knowing that. We are dependent on technology and we don't seem to care about security much, other than buying some magical binary blobs called Antivirus and Cleaners.

One can also argue that the comments in response to the different phrasings of the same news de-escalated from "this is very serious" to your comment's "this is actually not news."

There are always contrarians, and in this case the comment-section contrarians ended up amusingly contradicting themselves.

Reply on news.ycombinator.com