Stolen Nvidia Certificates Used To Hide Malware in Driver Downloads (pcworld.com) 32
Last week Nvidia confirmed that it had been the victim of an internal hack, though it claimed no customer information was compromised. Now we're seeing one of the first effects of the hack on end-users: Nvidia GPU driver packages with malware hidden inside. PCWorld: While it was always possible for malefactors to host links pretending to be drivers in the hopes of installing viruses, trojans, and other nasty stuff on a user's PC, this situation is more concerning. The hackers appear to have leaked Nvidia's official code signing certificates, a means by which users (and Microsoft) can verify that a downloaded program comes from the publisher it says it's from. That's allowing files containing a host of popular malware suites to be posted and downloaded, bypassing Windows Defender's built-in executable verification and slipping past anti-virus software. BleepingComputer reports that two now-expired (but still usable) verification codes have been compromised and used to deliver remote access trojans. Another example, using the Nvidia verification to sign a fake Windows driver, was also spotted.
Re: (Score:1)
Re:Not usable (Score:4, Informative)
Idiots. (Score:2)
Re: (Score:3)
If you download your drivers from some random email, you get what you deserve. Only install drivers from your OS' repository or direct download from the maker of your device.
I'd caution direct download from the maker of your device when said maker has been compromised. How long has Nvidia been compromised before they noticed? Did code silent slept-in with backdoors? Were the silicion chips compromised at fab level?
Re: (Score:3)
Another reason to never have auto updates on.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Certificates are public, they can't be 'leaked'. What could be leaked, if you have poor security processes, are the private keys. And if you manage to leak not only the private key for your signing server, but also the private key to your web server, you have some really poor security.
Re: (Score:2)
No, there is no such thing as a 'private' certificate, and certificates are not 'keys'. The purpose of a certificate is to identify to origin of the public key contained within it. The recipient of the certificate can then decide whether or not to trust that origin (by making sure the certificate is signed by someone trusted). A 'private certificate' makes zero sense - who would be the recipient of such a certificate and what would its purpose be? A compromised certificate means that either the private
Re: (Score:2)
Rather than argue with you: Congratulations on your new career at McDonalds...
Re: (Score:2)
Re: (Score:2)
Instead of just being an obnoxious ass, why don't you provide any citations to any sources that show anything I said was wrong?
Re: (Score:2)
Olde News (Score:3)
Re: (Score:2)
Hides or hid, or both? (i.e. is it just you or do you have a sibling on the way?)
How was a signing key leaked? (Score:2)
Re: (Score:3)
Let me correct your post, it was out of order...:
How bad was Nvidia's security?
These should never have been on a network connected computer in the clear. You always air gap or use a dedicated hardware signing device to store your signing keys. That's why most of the time you have to schedule signing of your driver/cert/code so that the people who have access to your keys can get together and authorize the signing.
Re: (Score:2)
"Air gap" machines cannot serve web traffic, nor can they sign and publish software. Storing the private keys only on an airgapped repository makes the keys of no practical use to the owner.
Re: (Score:2)
Re: (Score:2)
In decades of work, I've never seen a commercial or open source company require that kind of air gap for build services. Dev groups aren't generally willing to put up with that, and try to fire the person who insists they go through that kind of extra work.
Re: (Score:3)
Here is what our process is:
1) Dev does a build, and generates hashes of all things to be signed
2) QC does testing, verifying that the hashes of what they are testing match the build
3) After sign-off, two security officers take the files to be signed to the air-gapped signing server
4) Both security officers verify the hashes
5) Both security officers insert their smart cards into the signing server (log on to HSM)
6) HSM generates signatures
7) Signatures are applied to files
I guess in your 'decades of work' y
Yawn (Score:1)
These hackers are boring and lame. They never got control of NVidia's servers that send out updates via GeForce Experience, so most of their efforts are absolutely moot. They're just a bunch of amateur losers.
Re: (Score:2)
That you know of.
EV Code Signing certificate revoked in 3...2...1.. (Score:5, Informative)
All of the EV code signing certificate providers out there *require* the use of a cryptographic USB key/dongle or a HSM whereby accessing the private key for a certificate is impossible. Looks like Nvidia violated the terms of use of their EV code signing certs and thus breached their contract. Whoever manages their certificate issuance program (DigiCert?) should immediately revoke every one of Nvidia's code signing certs and then double down on not reissuing them until they pass an expensive and strict audit annually from here on out and also all certificate providers should blacklist Nvidia globally.
Re: (Score:2)
What are certificate revocation lists for? (Score:2)
If a certificate is known to be comprised, isn't that why they are added to a revocation list, so they can no longer be used?