Keylogger Found in Audio Driver of HP Laptops, Says Report (bleepingcomputer.com)

← Back to Stories (view on slashdot.org)

Keylogger Found in Audio Driver of HP Laptops, Says Report (bleepingcomputer.com)

Posted by msmash on Thursday May 11, 2017 @02:30AM from the security-woes dept.

An anonymous reader writes: The audio driver installed on some HP laptops includes a feature that could best be described as a keylogger, which records all the user's keystrokes and saves the information to a local file, accessible to anyone or any third-party software or malware that knows where to look. Swiss cyber-security firm modzero discovered the keylogger on April 28 and made its findings public today. According to researchers, the keylogger feature was discovered in the Conexant HD Audio Driver Package version 1.0.0.46 and earlier. This is an audio driver that is preinstalled on HP laptops. One of the files of this audio driver is MicTray64.exe (C:\windows\system32\mictray64.exe). This file is registered to start via a Scheduled Task every time the user logs into his computer. According to modzero researchers, the file "monitors all keystrokes made by the user to capture and react to functions such as microphone mute/unmute keys/hotkeys."

116 comments

Min score:

Reason:

Sort:

Never assume... by thegreatbob · 2017-05-11 03:29 · Score: 3, Insightful

Was this malice or stupidity? Perhaps both?

--
There is no XUL, only WebExtensions...
1. Re:Never assume... by Joce640k · 2017-05-11 03:30 · Score: 2
  
  Never attribute to one that which can adequately be explained by the other.
  
  --
  No sig today...
2. Re:Never assume... by Calydor · 2017-05-11 03:34 · Score: 3, Insightful
  
  Malice.
  It had NO REASON WHATSOEVER to keep a logfile for the keystrokes. Listen to the keyboard for a hotkey or combo? Sure thing, that's what these programs HAVE to do. But a logfile? WHY? Was it gonna check if it MISSED SOMETHING two hours ago?
  
  --
  -=This sig has nothing to do with my comment. Move along now=-
3. Re:Never assume... by MightyMartian · 2017-05-11 03:35 · Score: 3, Insightful
  
  I can't sort out how it would be an accident. Sometimes these things are due to debugging modes not being turned off on the production release, but what debugging mode in an audio driver would require logging keystrokes?
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
4. Re:Never assume... by Sperbels · 2017-05-11 03:37 · Score: 1
  
  How could this be stupidity? Who accidentally adds keylogging code to an audio driver?
5. Re: Never assume... by Anonymous Coward · 2017-05-11 03:38 · Score: 0
  
  Someone is gonna lose their job over this, especially if it blows up in the media with wide press coverage.
6. Re:Never assume... by Anonymous Coward · 2017-05-11 03:41 · Score: 5, Insightful
  
  Perhaps used originally for debug, but not removed for release builds. Which would be stupidity.
7. Re:Never assume... by K.+S.+Kyosuke · 2017-05-11 03:44 · Score: 2
  
  Not to mention that bugging is the polar opposite of debugging.
  
  --
  Ezekiel 23:20
8. Re:Never assume... by bws111 · 2017-05-11 03:45 · Score: 2
  
  Well it does say that the driver is looking for things like mute/unmute and other hotkeys, so I guess if you are debugging those functions you may want to log the keystrokes you see.
9. Re:Never assume... by Anonymous Coward · 2017-05-11 03:47 · Score: 0
  
  Due to the Fn keystrokes for audio control. It is just stupidity.
10. Re: Never assume... by Anonymous Coward · 2017-05-11 03:48 · Score: 1
  
  Yeah, criminals would love it if everyone thought they were stupid and not malicious. It gets them lesser charges.
11. Re:Never assume... by Anonymous Coward · 2017-05-11 03:49 · Score: 0
  
  It's not in the driver in the proper sense. It's in the hotkey listener that turns the mic on or off when a function key is pressed.
12. Re:Never assume... by Anonymous Coward · 2017-05-11 03:49 · Score: 0
  
  with espionage and counter espionage, ALWAYS assume the most deliberate and egregious application.
13. Re:Never assume... by Anonymous Coward · 2017-05-11 03:51 · Score: 1
  
  I don't quite agree with that advice. Perhaps a better rule of thumb would be:
  Be suspicious, but don't accuse without proof.
  The problem is that if you never "attribute to malice" (i.e. be suspicious) then you will be taken advantage of. That's the reality of human culture: the dishonest ones (of which there are many) can pick out the naive ones as easy as they can sort their laundry. They've been practicing it their entire lives. They know within seconds of meeting a person whether or not they will likely make a good target. You can't simply assume that everyone has good intentions until proven otherwise, or you WILL be taken to the cleaners.
  The reality is that human beings have a long way to go before reaching the pinnacle of evolution. When that time finally comes, human beings will then be able to assume good intentions by default. Until then, safety first.
14. Re:Never assume... by Anonymous Coward · 2017-05-11 03:52 · Score: 0
  
  I'm going to go with stupidity. Someone probably was debugging the hotkey functionality, logging events to check behavior.. And forgot to comment out the debug features in the shipped build.
15. Re:Never assume... by Anonymous Coward · 2017-05-11 03:56 · Score: 0
  
  If you want to write an application that responds to key presses, you have to hookup an event handler to the key press and release buttons. Then you just filter for the key press that you need. That should be all that is required. But logging every keystroke to a file, and then sending that data to another API if the file can't be accessed for some reason? Looks like a jigsaw piece for some larger system.
16. Re:Never assume... by Wonda · 2017-05-11 03:57 · Score: 4, Insightful
  
  Could well have been for debugging, and they forgot to take it out again.
17. Re:Never assume... by ShanghaiBill · 2017-05-11 03:57 · Score: 4, Informative
  
  but what debugging mode in an audio driver would require logging keystrokes?
  One reason would be to replay a sequence of keystrokes to verify that a bug has been fixed.
  My company has an internal app that logs input (keystrokes, mouse movements). If the program crashes, the keylog is emailed along with the stack trace to the responsible programming team. This has been a wonderful help for debugging and is WAY more useful than user descriptions of what they were doing. We can see what caused the fault, and after fixing the problem we can replay the input to verify that it is fixed. However, it only records input when this app has the focus, and users are informed that their input is being recorded.
18. Re:Never assume... by AmiMoJo · 2017-05-11 04:01 · Score: 3, Insightful
  
  The developer needed some debug info, and maybe even figured it would be helpful for remote debugging of problems, so they threw in a log file. Probably meant to disable it in the release build, or maybe they were just incompetent and didn't realize what a problem it was.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
19. Re:Never assume... by Anonymous Coward · 2017-05-11 05:09 · Score: 0
  
  Actually, it may be a good idea that there is a small percentage of people who are assholes. It makes sure that the rest of the population stay vigilant.
  Say we finally meet those extra terrestrials, and they where up to no good, we better be protect our selves.
20. Re:Never assume... by Alumoi · 2017-05-11 05:24 · Score: 1
  
  These days? Everybody and his dog. Personal info is the new currency.
21. Re: Never assume... by Anonymous Coward · 2017-05-11 05:25 · Score: 1, Funny
  
  Just ask Hillary ....
22. Re:Never assume... by chuckugly · 2017-05-11 05:27 · Score: 1
  
  Well it has to capture keystrokes, so I guess if the developer was having trouble w/ that the log would be useful. Not appropriate for release of course.
23. Re:Never assume... by v1 · 2017-05-11 05:32 · Score: 1
  
  it looks like they intended to log the pressing of the volume and mute keys, probably to make sure they were being captured and responded to accurately and reliably. So when the beta tester tells you "the music was playing when I left for lunch but when I came back it was silent so I rebooted it", they can look at the logs and verify that no, right about the time you left for lunch you pressed the Mute button whilst trying to turn off the wifi.
  As a developer I can see where it would be a lot easier to simply log all the keys - possibly more helpful in the above example seeing mute and wifi buttons being hit at the same time. But forgetting to turn that off before GM'ing... d'oh!
  
  --
  I work for the Department of Redundancy Department.
24. Re:Never assume... by chuckugly · 2017-05-11 05:33 · Score: 1
  
  Yeah, a log file that only logs keystrokes has an air of incompetence about it anyway.
25. Re:Never assume... by rickb928 · 2017-05-11 05:41 · Score: 1
  
  This. Competence is not an absolute.
  
  --
  deleting the extra space after periods so i can stay relevant, yeah.
26. Re: Never assume... by Pascoea · 2017-05-11 05:41 · Score: 1
  
  especially if it blows up in the media with wide press coverage.
  So, what your saying is nobody is going to lose their job over this? To the unwashed masses, privacy is dead. People are paying for devices with cameras and microphones in them, that literally listen to every word spoken around them. Do you think the public cares that some obscure driver on a laptop is even going to be a blip on the radar? Half of the US population probably couldn't tell you who Conexant is, or what a driver even does. Quick, without looking, does your current device use a Conexant audio chipset?
27. Re:Never assume... by Anonymous Coward · 2017-05-11 05:46 · Score: 0
  
  It could be that their debug build was their release build. With CI/CD and SCRUM processes, there isn't really any difference, as the goal is to crank out code and ship it as soon as it compiles without errors, perhaps passing a unit test.
  Not surprising if it was an accidental debug issue. There is no cash earned by doing it right, just as security has no ROI.
28. Re:Never assume... by Anonymous Coward · 2017-05-11 06:09 · Score: 1
  
  That is true, not even up for debate in fact. However, given the current climate of computer security (more specifically that major "state actors," or "countries" to the rest of us, are doing everything they can to BREAK computer security), you can't really help but wonder. I mean considering the stuff that's been leaked from the CIA and NSA...a lot of it probably cost a lot of money and a lot of hours to develop, plus the right 0-day exploits bought at the right price...wouldn't it be easier for them, in theory, to pay off/threaten a manufacturer to include their software as standard on any laptop they sell? I'd be surprised if that WASN'T happening by one of these state-sponsored groups, if not all of them...save money on development costs by forcing a big name corporation to do their dirty work. If it comes back on the corporation, said state-actors have already set themselves up with plausible deniability. "Those companies weren't acting on our instructions or on our payroll. They wrote their own spyware in-house to monetize people's personal information and the CIA would NEVER do a dirty, dishonest thing like that."
  Maybe it's playing the devil's advocate, but I think realistically when a piece of software like this is uncovered, it's not the sort of thing you can simply write off as being an incompetent programmer who forgot about the debug mode any more. You need to properly investigate it in my opinion. That involves considering the possibility that malice does indeed exist.
29. Re:Never assume... by Anonymous Coward · 2017-05-11 06:20 · Score: 0
  
  A fool of a saying. It's that type of shit that led to people believing the world was flat.
30. Re:Never assume... by Immerman · 2017-05-11 06:26 · Score: 1
  
  I agree it's suspicious in light of modern surveillance interests. In fact the best argument I can think of for it being incompetence rather than maliciousness, is the sheer degree of incompetence demonstrated. If it were malicious it would make far more sense to at least mildly encrypt the logfile so that its nature wouldn't be immediately obvious to anyone who stumbled over it. I mean how many obscure binary data files are used in the world? I doubt even security researchers regularly go to the trouble of reverse-engineering the formats so that they can see what they hold.
  Of course, that would also pretty much eradicate any attempt at plausible deniability if they were caught anyway...
  
  --
  --- Most topics have many sides worth arguing, allow me to take one opposite you.
31. Re:Never assume... by dgatwood · 2017-05-11 06:41 · Score: 2
  
  For this type of product, storing that data might actually make sense to keep. The problem is not that the data is being stored, but rather that it is being stored on disk where anybody with the right access privileges can trivially get to it.
  Debug logging is the perfect use case for an in-memory ring buffer. That approach ensures that the data is relatively hard to access (i.e. that it can be accessed only by your debugging tool that knows the magic handshake or whatever). It also ensures that the data is transient enough that using that data maliciously would be fairly impractical.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
32. Re:Never assume... by thegarbz · 2017-05-11 07:22 · Score: 1
  
  It had NO REASON WHATSOEVER to keep a logfile
  I see you've never had to fault find something before.
  It had no reason what so ever to keep a log file in production release. There are plenty of reasons to do so in non production releases, and the transition between production and internal releases can be attributed to incompetence.
33. Re:Never assume... by ColdWetDog · 2017-05-11 07:23 · Score: 1
  
  Along with the open Telnet and FTP servers.
  Right.
  
  --
  Faster! Faster! Faster would be better!
34. Re:Never assume... by HiThere · 2017-05-11 07:26 · Score: 2
  
  Malice seems a reasonable assumption, but I think at this point the verdict has to be "not proven". It is, however, a good reason to avoid HP in either case.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
35. Re:Never assume... by HiThere · 2017-05-11 07:33 · Score: 1
  
  I would actually say that it makes sense to accuse, but to be careful in ones wording so that one did not assert. Something like:
  "I find this highly suspicious, and to me it seems the most probable explanation is malice, of course it could be incompetence."
  Were the revealed actions of the powerful different, I'd be less apt to estimate probability in this way, and more willing to accept incompetence as the explanation. Of course, in either case one should hesitate to do any further business with them.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
36. Re:Never assume... by gweihir · 2017-05-11 08:20 · Score: 1
  
  Stupidity. It is far too obvious (if anybody bothers to look) for anything else. Basically, you type a random number in and then search for it on disk. The only protection against detection it has is that most people do not assume developers are quite this extremely stupid. After Intel last week, I think we can safely assume that even software from big names can contain utterly demented mistakes that are a catastrophe for security.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
37. Re: Never assume... by Anonymous Coward · 2017-05-11 10:12 · Score: 0
  
  God this is so tired. Just... just... stop.
  Captcha: Mileage.
38. Re:Never assume... by Aighearach · 2017-05-11 11:40 · Score: 1
  
  So how are you supposed to debug your bug without bugging it? And if you do bug the bug with a debug log don't you risk bugging it anyway?
  At least some of the bugs are before you even get to the keyboard, and I know those ones are bugged about being bugged because the bug leaked.
39. Re:Never assume... by SnarkSide · 2017-05-11 12:32 · Score: 1
  
  Stupid is, as stupid does.
40. Re: Never assume... by Anonymous Coward · 2017-05-12 00:21 · Score: 0
  
  It makes me feel "mildly nauseous."
41. Re: Never assume... by Anonymous Coward · 2017-05-12 02:56 · Score: 0
  
  Yup I bet that is exactly what happened. Its exactly the sort of thibg that would not be noticed by standard testing practices. In needs a security audit process as well.
42. Re:Never assume... by peawormsworth · 2017-05-12 18:33 · Score: 1
  
  Well, HP should be able to answer that quite easily. I assume that they at least use version control. That should reveal the exact employee who create the logging code. And every person who signed off on the code reviews. And all the chat messages between employees and managers.
  It should not be hard for the company to find out what happened... unless the thing was approved by management in some sort of espionage agreement.
43. Re: Never assume... by Anonymous Coward · 2017-05-14 11:09 · Score: 0
  
  What about **killer road**?
Oblivious-ware by Anonymous Coward · 2017-05-11 03:30 · Score: 0

See title
Other vendors by Anonymous Coward · 2017-05-11 03:30 · Score: 0

That Conexant audio driver is installed on other laptops. I remember seeing it on some Dells, but can't be sure since I don't have the machine anymore. Can anyone check this?
My PC is safe it seems by hcs_$reboot · 2017-05-11 03:35 · Score: 4, Funny

# ls -l C:\windows\system32\mictray64.exe ls: cannot access 'C:windowssystem32mictray64.exe': No such file or directory

--
Slashdot, fix the reply notifications... You won't get away with it...
1. Re:My PC is safe it seems by AnthonywC · 2017-05-11 03:43 · Score: 3, Funny
  
  You can running windows; you are not safe.
2. Re:My PC is safe it seems by Anonymous Coward · 2017-05-11 03:47 · Score: 1
  
  woosh
3. Re:My PC is safe it seems by DontBeAMoran · 2017-05-11 03:52 · Score: 1
  
  ls -l C:\windows\system32\mictray64.exe
  ls: C:windowssystem32mictray64.exe: No such file or directory
  Funny how Unix, Linux and Mac users are alike these days. The only odd one is Windows.
  
  --
  #DeleteFacebook
4. Re:My PC is safe it seems by Kardos · 2017-05-11 04:30 · Score: 1
  
  You're doing it wrong, you need to quote the path there:
  $ ls -l "C:\windows\system32\mictray64.exe"
  ls: cannot access C:\windows\system32\mictray64.exe: No such file or directory
5. Re:My PC is safe it seems by Anonymous Coward · 2017-05-11 04:34 · Score: 0
  
  Isn't Apple's slogan "Think different."
  OSX is a derivative copy of BSD. BSD and Linux are copies of Unix. Of course they are the same. Nothing funny about saying rain comes from the sky.
6. Re: My PC is safe it seems by Anonymous Coward · 2017-05-11 04:54 · Score: 0
  
  Leave it to a Mac user to forget the quotes.
7. Re:My PC is safe it seems by Anonymous Coward · 2017-05-11 05:18 · Score: 0
  
  Weird, I run windows and that command worked just fine...
  c:\>ls -l C:\windows\system32\mictray64.exe
  ls: C:\windows\system32\mictray64.exe: No such file or directory
  Funny how none of the operating systems are really that different these days.
8. Re: My PC is safe it seems by Anonymous Coward · 2017-05-11 05:44 · Score: 0
  
  WhooooooooooosherZ
9. Re: My PC is safe it seems by DontBeAMoran · 2017-05-11 06:53 · Score: 1
  
  "Radishes are a fascinating example of how something can be both tasteless and burn your tongue at the same time." - unknown
  Are you happy now?
  
  --
  #DeleteFacebook
10. Re:My PC is safe it seems by Anonymous Coward · 2017-05-11 10:03 · Score: 0
  
  Wow...you are SO fucking witty.
11. Re:My PC is safe it seems by Anonymous Coward · 2017-05-12 02:07 · Score: 0
  
  Don't you know a thing about the shell? The backslash is a special character and needs to be escaped.
  ls -l 'C:\windows\system32\mictray64.exe'
Not a problem! by Joce640k · 2017-05-11 03:36 · Score: 3, Insightful

Anything capable of reading this is capable of installing its own key logger, so.... non-story.
Still, it shows the stupidity of some programmers. I get you need to debug things but have an on/off setting and disable it by default.

--
No sig today...
1. Re:Not a problem! by Anonymous Coward · 2017-05-11 03:49 · Score: 0
  
  By your logic no viruses are a problem...
  Anything capable of installing is capable of installing its own key logger, so... non-story.
  This is a story. Both because people should be warned about possibly being infected with the rogue driver, and also because people should be wary of certain brands.
2. Re:Not a problem! by Anonymous Coward · 2017-05-11 03:53 · Score: 0
  
  By your logic no viruses are a problem...
  Anything capable of installing *virus_name* is capable of installing its own key logger, so... non-story.
  This is a story. Both because people should be warned about possibly being infected with the rogue driver, and also because people should be wary of certain brands.
3. Re:Not a problem! by AmiMoJo · 2017-05-11 03:58 · Score: 4, Informative
  
  Anything capable of reading this is capable of installing its own key logger, so.... non-story.
  No, that's not been true since Vista.
  Anything wanting to start with Windows and log keystrokes will need to be installed with administrator level permissions, which means a UAC prompt to the user (screen goes dark, everything except the warning message vanishes, if configured the user's password is required).
  By pre-installing it HP have provided a handy way for non-privileged malware to perform keylogger functions, without the need for a privilege escalation exploit.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
4. Re:Not a problem! by ledow · 2017-05-11 04:02 · Score: 2
  
  Er... no.
  C:\users\public\MicTray.log
  Public has *read and write* permission for anybody in the CREATOR OWNER and INTERACTIVE groups. The latter includes any logged-in user account. So anyone can potentially read the keystrokes of the admin who sat on the machine before them ten years ago while setting up the machine, even if they don't have - and never have had - permission to even install software on a machine.
  That's not "non-story".
  Installing software that can read the keyboard even when not focused requires a bit more than that. And even a keylogger device on the hardware wouldn't capture HISTORICAL keylogs of the users before you plugged it in.
5. Re:Not a problem! by Anonymous Coward · 2017-05-11 04:05 · Score: 0
  
  This is actually partially false, the file is deleted on logon. The long history only comes into play via backups (but if there are then what you say is true)
6. Re:Not a problem! by ledow · 2017-05-11 04:08 · Score: 1
  
  Shadow Copies.
7. Re:Not a problem! by Anonymous Coward · 2017-05-11 04:19 · Score: 0
  
  That's the sort of detail that gets overlooked when your programmer is swinging a hatchet as fast as humanly possible writing low value driver code for a constellation of rapidly changing, poorly documented devices. You get just enough time to make the led blink before you're off to the next thing and the oem(s) takes your half-baked crapwork and ships it. You learn what device is to be used 72 hours before your expected to make it work, so you grab whatever proof-of-concept demoware the device manufacturer provides, knock the larger pieces of shit off of it, instrument it with 'printf' to troubleshoot whatever problems it has, get it working once in a row and that's it. You're done. That's what is installed on your laptops, phones, etc.
  Odds are the keylogger exists because the audio guy was trying to figure out what sort of codes the keyboard hardware/driver was emitting and align it with the audio driver functions. Yeah sure, look it up in the documentation, the only copy of which is 8 timezones away in the wrong language and the guys that have it won't give it to you without an act of Congress because they don't know who the hell you are. By the time he got the other 15 problems ironed out during the 50 hour death march somewhere in China he completely forgot about having created the logger. Peer review amounted "make work yet?" and off it went.
8. Re:Not a problem! by Anonymous Coward · 2017-05-11 04:40 · Score: 0
  
  Shadow Copies and all of that timeline backup crap. Uses up drive space and time, never saves anyone from anything because the ransomware purges it, as does any kind of malware. Meanwhile it sits there as a vulnerability for any bad actor that picks up your machine ever.
9. Re:Not a problem! by omnichad · 2017-05-11 04:40 · Score: 1
  
  This also means that ALL malware has permission to access this file.
10. Re:Not a problem! by LordWabbit2 · 2017-05-12 02:17 · Score: 1
  
  Who ever wrote the driver is an idiot, you don't have to record every bloody keystroke for hot keys, it's built into the windows api.
  More specifically in user32.dll there is a method called RegisterHotKey, I've used it plenty times, works like a charm, there was/is no need to monitor every keystroke, and definitely no reason to write it all out to disk.
  
  --
  There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
What Is Being Done About This?? by Anonymous Coward · 2017-05-11 03:41 · Score: 0

And what is being done about this??
1. Re:What Is Being Done About This?? by Green+Salad · 2017-05-11 09:18 · Score: 2
  
  I'm doing something about it. I made a bunch of snarky comments at lunch and online.
Thanks America by Anonymous Coward · 2017-05-11 03:47 · Score: 0

another reason to stay away from American brand computers or hardware manufacturers if you can. It's funny how some in these comment sections say it was "stupidity", as if someone accidentaly started recording and logging all keypresses to a file on the harddrive, in an audiodriver... Typical mistake, right?
If you buy American, you get compromised stuff.
I have one of these laptops (HP 430 G3). by waspleg · 2017-05-11 04:04 · Score: 2

I'm at work right now typing on it. It doesn't have this executable, it doesn't have the Conextant audio driver either.
This does make me curious, though, since I recently tested some newer HP laptops/convertibles which had a noticeable cpu eating process called Flow which is also tied to the Conextant audio driver.
We gave them back so I can't check them but it's an interesting coincidence ...
1. Re:I have one of these laptops (HP 430 G3). by E-Rock · 2017-05-11 04:27 · Score: 1
  
  It's best practice to wipe a machine as soon as it comes in and to only put back what's absolutely necessary. If the audio works with the windows driver, they wouldn't have put this HP junk back on.
2. Re:I have one of these laptops (HP 430 G3). by Killall+-9+Bash · 2017-05-11 05:41 · Score: 1
  
  It's best practice to wipe a machine as soon as it comes in and to only put back what's absolutely necessary. If the audio works with the windows driver, they wouldn't have put this HP junk back on.
  I used to do this.... until I started purchasing Windows 7 'downgrade' computers with a windows 10 license... and no COA or media for either. Windows 10 licensing works great, until you actually have to do something with it. Try re-installing either OS on one of those PCs. I dare you.
  
  --
  "Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
Oh but they do. by waspleg · 2017-05-11 04:10 · Score: 2

They call it "telemetry" these days, because it sounds better than "spying" and "data exfiltration (theft)".
Maybe we should be trying to find the EULA for the audio driver? I bet it says they can do whatever the fuck they want =)
But is "they" Conexant or HP or Microsoft or everyone?
1. Re:Oh but they do. by Anonymous Coward · 2017-05-11 05:12 · Score: 1
  
  Also known as beacons. Check this out...
  My HP laptop (now linux) boots normally with no network connected. It also boots normally with a network connected. But if it has Internet-enabled DNS service but no traffic can get through because firewall, it takes an extra minute or more to boot. This is at the BIOS level, before the OS begins loading.
2. Re:Oh but they do. by mikael · 2017-05-11 05:49 · Score: 1
  
  You could use Wireshark to find out where the data was going. I Couldn't understand why my PC was sending 32K/minute over to one of Microsoft's servers. Turned out this was an executable called nvcontainer.exe as part of the Geforce Experience. From other forums, it seems to scan games downloaded from Steam. Perhaps it does static code analysis on DirectX or OpenGL calls. But it seems a funny way of doing this.
  
  --
  Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
3. Re:Oh but they do. by Aighearach · 2017-05-11 11:36 · Score: 1
  
  Online game cheating prevention is one of the things that Intel is including in their marketing information for chipset security features. It isn't clear if this is going to be popular or unpopular with the masses.
Consequences? by Anonymous Coward · 2017-05-11 04:31 · Score: 0

Post this story again when someone at HP goes to prison.
Intent by OhSoLaMeow · 2017-05-11 04:33 · Score: 4, Funny

"Although we did not find clear evidence that HPs intended to violate laws governing the handling of the keylogged information, there is evidence that they were extremely creless in their handling of very sensitive information."

-- James Comey

--
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
1. Re:Intent by crtreece · 2017-05-11 05:50 · Score: 1
  
  extremely creless
  I see what you did there.
  
  --
  file: .signature not found
2. Re:Intent by Anonymous Coward · 2017-05-11 06:51 · Score: 0
  
  Maybe not. Whoosh?
3. Re:Intent by HiThere · 2017-05-11 07:47 · Score: 1
  
  That seems to be a quote, possibly about something else, but I haven't been able to trace it down.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
Jail time by AndyKron · 2017-05-11 04:57 · Score: 1

If I put a tape recorder in a device and sold it to someone I'd go to jail. Audio drivers don't need keyloggers. Someone needs to go to jail.
1. Re:Jail time by gweihir · 2017-05-11 08:54 · Score: 1
  
  Not yet, but we will need this if software is ever to be secure. And in particular, we need somebody higher up to go to jail for this, because that is what "responsibility" means. The actual engineers likely saw their prototype declared "ready for production" (has happened to me, but I was forewarned, so it actually was production quality) and that was the end of what they could do.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
lol by Anonymous Coward · 2017-05-11 05:01 · Score: 0

lol
seriously why do manufacturers keep putting dog shit software on their machines? I would NEVER trust a laptop out of the box with the exception of a Mac. All Windows machines get wiped/imaged. but if the bug IS the driver? Hory Shet. I cant imagine the number of enterprise customers that will never ever patch this nor even realize its a thing. Here's hoping HP patches this immediately and it somehow makes its way onto those laptops at some point.
Also, HP is shit. if you need to buy a PC, buy a Dell. At least their support is decent. HP....what a croc of shit.
1. Re: lol by Anonymous Coward · 2017-05-11 12:04 · Score: 0
  
  Because they get a kickback.
Linux and GPL forces driver open sourcing by simpz · 2017-05-11 05:05 · Score: 1

The Linux model of having an unstable kernel ABI, to encourage HW vendors to upstream their drivers suddenly looks the best.
Stuff your Intellectual Property, I'd like safe drivers. I'll even grant you the use of firmware binary blobs. So a very limited release of company secrets.
And people blame (in a corporate shilling way) Android for being unable to upgrade the kernel due to HW vendors not open sourcing their drivers. Google and phone vendors should pressurize them.
Kid heartbroken by surveillance. by dweller_below · 2017-05-11 05:11 · Score: 4, Insightful

Recently we had a career fair for high school kids. Everybody was there. The kids loved it.
For one of our displays, we displayed the traffic of a wireless network using a network visualization tool: https://www.youtube.com/watch?... When the kids connected to the wifi, they could see their traffic. They loved doing different things and seeing what happened.
Somebody had surreptitiously placed a surveillance tracker on a kid's phone. Every thing he did caused a burst of traffic to a remote IP. When he scrolled a screen there was a burst of traffic to that IP, When he typed a character there was a burst of traffic to that IP.. He was absolutely heartbroken when he realized what was going on. His wonderful toy instantly became a treacherous enemy. His friends all took a step back and stared at him like he had become contagious.
I didn't know how to make it better. The best I could say was: "If he is being monitored by a government, they didn't really care what he was doing." Nobody seemed reassured..
1. Re:Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-11 07:29 · Score: 0
  
  I didn't know how to make it better. The best I could say was: "If he is being monitored by a government, they didn't really care what he was doing." Nobody seemed reassured..
  Tell him about this: https://lineageos.org/
  Wipe his phone and reinstall if possible.
2. Re:Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-11 07:31 · Score: 0
  
  The best I could say was: "If he is being monitored by a government, they didn't really care what he was doing." Nobody seemed reassured..
  This, by the way, was a mistake to say. If someone cared enough to break the law to monitor him, then that person was probably a serious threat to him.
3. Re:Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-11 07:42 · Score: 0
  
  I'm not aware that LineageOS has been declared safe and surveillance-free by anyone.
4. Re:Kid heartbroken by surveillance. by dweller_below · 2017-05-11 07:57 · Score: 2
  
  The best I could say was: "If he is being monitored by a government, they didn't really care what he was doing." Nobody seemed reassured..
  This, by the way, was a mistake to say. If someone cared enough to break the law to monitor him, then that person was probably a serious threat to him.
  I realized my mistake later. I was babbling on and on about types of RAT (Remote Access Tools) and the rise of the surveillance state. Eventually I stuttered to a stop when I saw the intense look of horror and betrayal on the kids face. You could not have hurt him more by stabbing him in the back with a knife. No amount of glib "Et tu Brute?" was going to make it better. His world had just become a dark, treacherous place. Somebody that he trusted, did not trust him. And, by placing the tracker on him in secret, they demonstrated that they were not worthy of trust.
  I still have no idea what I could have said to restore the possibility of love and trust to that kid.
5. Re:Kid heartbroken by surveillance. by gweihir · 2017-05-11 08:56 · Score: 1
  
  More likely some real creeps installed that and, oh, look, it is his parents! (Just remember the /. story from a few days back.)
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
6. Re:Kid heartbroken by surveillance. by Swave+An+deBwoner · 2017-05-11 10:00 · Score: 1
  
  I still have no idea what I could have said to restore the possibility of love and trust to that kid.
  
  Hey Kid, there's a newer model of this phone available for free if you want one.
7. Re: Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-11 12:06 · Score: 1
  
  Break the law? His parents probably bought that phone and if that's the case they can monitor all they want.
8. Re:Kid heartbroken by surveillance. by brewthatistrue · 2017-05-11 15:09 · Score: 1
  
  I would've assumed he installed one of the many "free" apps that ask for a million permissions they don't need and then phone home with everything.
9. Re:Kid heartbroken by surveillance. by rhazz · 2017-05-12 01:28 · Score: 1
  
  The best I could say was: "If he is being monitored by a government, they didn't really care what he was doing." Nobody seemed reassured..
  Far, far more likely a parental monitoring tool.
10. Re:Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-12 03:04 · Score: 0
  
  He's a teenager, right? And, yeah, it's heartbreaking to see that look of innocence betrayed. But do you really want him to remain the same naive victim? You could yadda-yadda forever about security and it will go in one ear and out the other. This got his attention, and that of the 'friends' backing away from him. They are no doubt all having nightmares about who's reading their sexts. A teachable moment, I'd say.
11. Re:Kid heartbroken by surveillance. by Anonymous Coward · 2017-05-12 08:44 · Score: 0
  
  Somebody had surreptitiously placed a surveillance tracker on a kid's phone. Every thing he did caused a burst of traffic to a remote IP. When he scrolled a screen there was a burst of traffic to that IP, When he typed a character there was a burst of traffic to that IP.. He was absolutely heartbroken when he realized what was going on. His wonderful toy instantly became a treacherous enemy. His friends all took a step back and stared at him like he had become contagious.
  
  It is sad. I see this all the time as a security researcher people go on saying "I have nothing to hide. I don't care." and laugh at my paranoia until they are the victim. Yet here we are in a world where nothing can be trusted.
  BTW cool network tool!
When does logging get invoked? by Anonymous Coward · 2017-05-11 05:13 · Score: 0

When does this log file actually get used? Mine shows 0KB and hasn't been modified since I got my computer.
Complete list on Bleeping Computer by entropy01 · 2017-05-11 05:30 · Score: 1

The write up on Bleeping Computer lists all of the suspect HP models: https://www.bleepingcomputer.c... Sure enough, I found MicTray running on one of our 640 models.
So who wrote this driver? by evolutionary · 2017-05-11 05:52 · Score: 1

This is getting scary. Even the 3rd party components in M$ Window$ is tainted. What's next? keystroke loggers in our browsers. This is why I use open source on my desktop and my phone. If something is there, it's at least easier to find anyone doing nonsense.

--
"Imagination is more important than knowledge" - Einstein
Spyware Apologist. by Anonymous Coward · 2017-05-11 06:00 · Score: 1

Spyware Apologist.
By now you goddamn know a full key logger in an AUDIO driver is unacceptable, full stop. "Oh darn, shouldn't have done that."
All malice can hide behind incompetence.
1. Re:Spyware Apologist. by OrangeTide · 2017-05-11 06:12 · Score: 1
  
  But how will I debug issues when QA reports that the volume control hotkeys are not working? I need ALL the key events to see what keys QA was pressing and devise a way to resolve the issue. Usually by closing the bug saying that they misconfigured their keyboard driver as it's not sending the proper multimedia keycodes.
  
  --
  “Common sense is not so common.” — Voltaire
2. Re:Spyware Apologist. by sodul · 2017-05-11 11:12 · Score: 1
  
  I wrote a driver for multimedia, including volume keys, over 10 years ago and yes, I did include a key logger functionality in the debug build. That said the only keys I logged were the 'special', non ascii keys. I might have logged all keys on the very early stages of the driver development but I had absolutely no need to capture any of the 'writing' keys and if I wanted to record activity on these I would probably have recorded the event but not the actual character pressed.
  Having worked in the software industry for my entire career and for several years at Software Security companies, a lot of developers just do not care about security at all. I've even seen a lead developer complaining that he had to fix a XSS exploit that was only accessible to logged in users. His argument is that we should trust our customers so a fix was not required.
3. Re:Spyware Apologist. by OrangeTide · 2017-05-11 11:29 · Score: 1
  
  The virtual keycodes in Windows are a little funny. Some ASCII ranges are the letters/numbers on your keyboard. Other values that are ASCII values map to extra keys. 'A' is your A key, but 'a' is the 1 key on the numpad. Lots of funny stuff like that, I suppose you could have some reasonable (islower(c) || isdigit(c)) logic that skips logging at least most of the alphanumeric keys. or you can do if (c >= 0x80) and that will leave out all the alphanumeric keys, a few of the symbols, the numpad, and a few others. but get all the F-keys and multimedia keys, which is most likely the bug that people run into with Volume and multimedia controls. Did you press Fn+F11 to go to the next track, or Alt+F11, if it was Alt and QA filed a bug well shame on them, close as a PEBKAC.
  My guess is someone got lazy at the audio chipset vendor and didn't filter out with one of the one-liners I suggested, and consequently the log is filled with raw key events. And on top of that, nobody put a release process in place or added to QA's test plan to check if debug file(s) are present on the system. This is one of the big issues I have with purely ad hoc testing. Many software development shops have QA just monkeying around and not following any kind of process, and really you need both monkey testing and specification driven testing to catch important details.
  At my current position they only do ad hoc testing when they've run through the test plan, and the developers contribute line items to the test plan which are reviewed and assigned a priority. (lowest priority items are omitted) . I realize this is a bit of hindsight being 20/20, but I think at my company we would have caught something like this. Also debug files are documented in our ISS (internal software specification), and there is a preference to keep debugs for all project under the same top-level folder or have a memory-based logging that can be queried, and a release test that checks that it is disabled. (but such tests can be buggy too)
  
  --
  “Common sense is not so common.” — Voltaire
GoBack by Anonymous Coward · 2017-05-11 06:04 · Score: 1

I really miss GoBack. It was really easy to see things like this when running it. Scan through the log of file changes and note files that shouldn't be changing while you're simply editing a text file. Excellent for removing all forms of viruses except rootkits too, assuming you catch them early enough.
See the summary. by Anonymous Coward · 2017-05-11 06:08 · Score: 0

OP needs to debug their reading comprehension program.
Remember when HP rooted a reporter's laptop? by sandbagger · 2017-05-11 07:59 · Score: 1

All because they were unhappy with their press coverage? Why is anyone surprised that they stooped to this?

--
---- The above post was generated by the Turing Institute. Maybe.
Software freedom yields practical gains. by jbn-o · 2017-05-11 10:42 · Score: 1

It's the freedom of software that's crucial, not a development methodology of an unstable ABI. Binary firmware blobs are a source of problems; firmware is remarkably powerful and capable and there's no way to have good security with non-free firmware. Firmware for the system persists and provides spying powers that span OSes (install whatever OS, the firmware that acts as a keylogger keeps working). Proprietors including Google make considerable money from spying, but I suspect the real competition for them is in being a monopoly for the spying data they can provide—don't let others provide data proprietor X can provide or else the value of proprietor X's data goes down.

--
Digital Citizen
Article sparse in detail by Anonymous Coward · 2017-05-11 21:26 · Score: 0

Is it a specific version of the exe or if it is there at all?
I have 110,000 workstations to deal with, if I had a version I could write a simple query and know which machines in 5 minutes need to be fixed.
I do something like it (central errtrap) by Anonymous Coward · 2017-05-12 04:07 · Score: 0

See subject: In APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ I override std. structured errhandling in my code & pipe abends into a log (but I don't send it anywhere NOR does it record keystrokes (only errors/abends/crashes), it remains on user's disk) via a central TryTryCatchExcept routine that keeps all error handling std. (makes the program uncrashable for all intents & purposes too as a bonus).
APK
P.S.=> It's also uninfectable by traditional jump table attaching viruses & checks its size in every single routine, inline for speed (vs. calling a single centrally pointed to function that is a single point of fail to take out to override & undo) & IF it changes by even 1 byte? It warns the user it may be compromised & to reinstall it from a fresh pristine copy... apk
And people laughed at me... by Anonymous Coward · 2017-05-12 09:57 · Score: 0

for not installing vendor specific audio driver and just using the built-in (Microsoft) HD Audio driver. Ha!
You did them all a huge favor. by waspleg · 2017-05-13 02:55 · Score: 1

Stop feeling bad for teaching an exceedingly important lesson about real life.
Your next step should have been to show them how to disable/avoid/mitigate as much as possible and show them why their privacy/freedom/security matter not some kind of purposeless guilt.
Also, it's quite likely the spy was their parents not their gov't in that case but I digress.