5

First Lenovo was caught shipping Superfish with new PCs, which included a universal self-signed certificate authority, and now Dell has been caught shipping PCs with a similar root certificate.

What steps can I take when I get a new PC to make sure that there are no bad certificate authorities or root certificates?

  • Are there any programs that can automatically check this?
  • Are there any guides that can be followed to make sure there are only standard certificate authorities and certificates installed?
JonnyWizz
  • 1,971
  • 1
  • 14
  • 34
  • Evil CAs aren't the only risk, you can very well have a rootkit that intercepts TLS without actually being visible from the system itself. THe only way to be sure (at least for software-based attacks) is to reinstall the system from a known good image like an official Microsoft ISO. – André Borie Nov 24 '15 at 08:58
  • 1
    That's often not an option if you buy a new PC - you would get an OEM recovery image/disk. To get an official Microsoft ISO, you would have to buy a new copy of Windows. – JonnyWizz Nov 24 '15 at 09:00
  • 1
    Related question: [*How can I protect myself against software installing insecure root certificates?*](https://security.stackexchange.com/questions/106343/how-can-i-protect-myself-against-software-installing-insecure-root-certificates) – StackzOfZtuff Nov 24 '15 at 09:51
  • Related question: 2014-10-22: [*Reset Windows trusted certificates store to its default*](https://security.stackexchange.com/questions/71313/reset-windows-trusted-certificates-store-to-its-default) – StackzOfZtuff Nov 24 '15 at 09:59
  • @AndréBorie, you also need to make sure that you do not run some software from the manufacturer later. For example Dell installs a trusted root cert when Dell System Detect is run (see e.g. here: https://www.youtube.com/watch?v=DYLYG76o55c) – x457812 Nov 24 '15 at 15:49
  • @x457812 that's why I recommend getting the drivers from the internal device's manufacturers directly (Nvidia, etc) rather than from the OEM. – André Borie Nov 24 '15 at 16:51
  • @AndréBorie, understood. However some folks may want to run software such as Dell System Detect if they have a Dell PC because it's used for troubleshooting system defects. – x457812 Nov 24 '15 at 16:54
  • @x457812 I would be really cautious about software claiming to be able to troubleshoot system issues, as they're snakeoil. Even if I trusted Dell I wouldn't run such software just because it's a waste of time, and manual debugging works much better. – André Borie Nov 24 '15 at 16:58
  • @AndréBorie, some of the steps that software does is that it checks things like RAM, display, sound card, and other hardware for defects. Some of this testing cannot be done manually. – x457812 Nov 24 '15 at 18:15
  • Related question: Here "RCC.exe" ("Rogue certificate checker") is used: [*How did Symantec get a certificate on my laptop?*](https://superuser.com/questions/1005226/how-did-symantec-get-a-certificate-on-my-laptop) – StackzOfZtuff Nov 25 '15 at 13:09
  • Considering this question is not [just for Windows](https://security.stackexchange.com/q/71313/147346) would be great an answer [for Debian/Ubuntu Linux](https://askubuntu.com/q/1129300/349837) ([here](https://access.redhat.com/solutions/1549003) for it is Red Hat). Or I should start another question? – Pablo A Mar 28 '19 at 17:24

1 Answers1

6

Edit 2015-11-25

"PowerShell-PKI" project looks promising

Bryan Lockwood has put a a nice project on GitHub:

And here's his blog post that introduced it

You can run the script like so:

  1. Copy Nov2015-WindowsRootCAList.txt to Nov2015-WindowsRootCAList.NOSPACES.txt

  2. Work around a bug: Manually remove the trailing space characters in Nov2015-WindowsRootCAList.NOSPACES.txt.
    (Otherwise the script will report EVERYTHING as untrusted.)
    (I suggest you use your favorite text editor's search-and-replace-feature and just nuke all spaces.)

  3. Dot-source the script:
    PS C:\Powershell-PKI-master> . .\Audit-TrustedRootCA.ps1 3>&1 | out-null

  4. Run the function:
    PS C:\Powershell-PKI-master> Audit-Roots -FilePath .\Nov2015-WindowsRootCAList.NOSPACES.txt -OutputPath .\

The script the Windows trust store (stores?) against a list of known-good hashes.

Hashes-list is same as from certutil.

The origin of this hash-list is not entirely clear to me.

So I decided to generate the hashes myself with a bit of Cygwin-Bash-Scripting:

$ certutil.exe -generateSSTFromWU wuroots.sst
$ certutil.exe -dumpPFX wuroots.sst  | grep 'Hash' | tr -d ' ' | tr 'a-z' 'A-Z' | cut -d ':' -f2 | sed 's/$/ /' | sort > wuroots-hashes-pspkiformat.txt

And it turns out: the hashes from certutil and hashes from GitHub are in fact identical:

$ diff --report-identical-files -- wuroots-hashes-pspkiformat.txt Nov2015-WindowsRootCAList.txt
Files wuroots-hashes-pspkiformat.txt and Nov2015-WindowsRootCAList.txt are identical

Related Twitter Thread

This Twitter thread started by German security researcher Hanno Böck led me to the PowerShell project.

Maybe CertUtil and MMC to reset?

There was a great blog article last month:

Mike outlines a procedure to generate an .sst certificate container with just the default certificates retrieved from Windows Update and then uses MMC to pick and choose from them.

certutil -generateSSTFromWU rootcas.sst
invoke-item rootcas.sst

I haven't tried this, but I'm guessing that throwing out every CA and then simple importing all the default CAs from the SST file should do part of the trick.

Note: I don't know how Windows handles self-signed-CAs in the "Intermediate" store or elsewhere. I think that store is a cache anyway and can be nuked because it will be automatically rebuilt anyway -- but I'm not certain.

Prior art

EDIT. I just noticed that Tom Leek gave essentially the same answer to a similar question last year:

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86