Hackers and malware can inject fake trusted root Certification Authority (CA) certificates into victim computers. This can trick victim computers and users into trusting bad code signatures, bad SSL web sites, bad e-mail signatures, and anything else which depends on certificates or PKI. (This was also the technique used by SuperFish on Lenovo computers.)
A similar problem occurs when a legitimate CA certificate is legally issued to someone that you just don't trust, perhaps because you're concerned they will create SSL certificates for man-in-the-middle attacks. What can we do about it?
The following describes two free PowerShell scripts: one for auditing the trusted root CAs on a computer and another for removing unwanted CA certificates. The ability to add root CA certificates is already built into Group Policy.
We must begin somewhere with a list of root CA certificates to trust, and then this list can be edited. One possibility is to begin with Microsoft's list. The following URL is where Microsoft periodically publishes the hashes of their own root CA certificates and the certificates of third-party companies that participate in Microsoft's Root Certification Program:
Unfortunately, you'll have to extract the hashes from the HTML yourself, e.g., save as a text file, pull out the hashes, and remove the space characters. The SEC505 zip file contains a text file of these hashes in the \Day3-PKI\AuditRootCAs folder, but please note that the list will eventually be out of date. Why Microsoft doesn't just post an XLS, XML or CSV file with the complete list is a mystery (if enough of us ask, maybe someone at Microsoft could do a Save As...).
Once you have Microsoft's latest list of trustworthy root CA hashes, add to this list the SHA1 hashes of any other root CAs you choose to trust, such as your own CA, third-party companies, the US Department of Defense, etc. The list is just a simple text file of SHA1 hashes. Feel free to remove the hashes of any CAs you do not want to trust.
Keep this text file in a protected shared folder on the network which grants Authenticated Users read-only access. Take care to prevent hackers from modifying the file. Periodically update the file with any new hashes, remove hashes for root CA certificates which have been compromised, and confirm that the file has not been maliciously altered. Use NTFS auditing to track attempted changes and consider alerting on attempted changes as well with a HIDS.
In the Securing Windows and PowerShell Automation (SEC505) course at SANS we have an entire day on PKI. In the course we use a PowerShell script (Audit-TrustedRootCA.ps1) to compare the list of CA hashes in the above reference file against the list of currently-trusted root CA certificates for the user and computer running the script. The Audit-TrustedRootCA.ps1 script is in the SEC505 zip file in the \Day3-PKI\AuditRootCAs folder. All the other scripts in the zip file are also in the public domain.
The output of the script is a CSV text file, which can be saved to a shared folder, whose file name indicates the name of the computer, the name of the user, and a timestamp, e.g., LAPTOP47.Administrator.634890196060064770.csv. The CSV file contains the hashes and names of any root CA certificates trusted by the user and/or computer which are NOT in the list of reference certificates. The script also writes to the Application event log (Event ID = 9017, Source = RootCertificateAudit).
The script can be distributed through Group Policy or executed through PowerShell remoting. Don't forget to change the default execution policy for PowerShell too. The user account under which the script runs will also need read access to the file of reference hashes and also write access to the folder where the output CSV file will be created. The -OutputPath parameter should take a UNC network path to a shared folder to consolidate the readings from many machines. A Distributed File System (DFS) share can be used for scalability.
The script is more-or-less a skeleton script to help you get started. It's pretty simple when you examine the code. Feel free to add error handling, logging, security, etc. If you do not wish to begin with a list of SHA1 hashes from Microsoft, feel free to construct this list yourself; the script only requires a file with a list of hashes, the list does not have to come from Microsoft.
Once you've gathered the CSV output files from your desired computers, review any files whose size indicates the presence of root CA certificates which are not on your reference list, i.e., those files will be larger than the rest.
If you discover unwanted root CA certificates, they can be deleted with the Remove-TrustedRootCA.ps1 script, which is also in the SEC505 zip file (Day3-PKI folder). Edit one variable near the top of the script ($BadCerts) which will contain the SHA1 hashes of the certificates to delete. Run the script with administrative or system privileges, perhaps as a Group Policy startup script or through PowerShell remoting. When it deletes an unwanted certificate, it writes to the local Application event log (Event ID = 9019).
Threats & Recommendations
Attackers may try to delete or corrupt the existing CSV files to prevent access. It's best to store the files in a shared folder whose NTFS permissions only allow the following permissions:
Principal: Authenticated Users
Apply to: This folder, subfolders and files
Allow: Full Control
Deny: Delete subfolders and files
Deny: Change permissions
Deny: Take ownership
Deny: Create folders/append data
Principal: Authenticated Users
Apply to: Files only
Deny: Create files/write data
The trusted administrator(s) can be granted Full Control to the archive files, certificates, and scripts as needed of course.
As discussed above, also take care to protect and audit the reference list of trustworthy root CA certificate hashes.
Caveats & Legal Disclaimers
The script is free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said...
THIS SCRIPT IS PROVIDED "AS IS" WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPT. NO TECHNICAL SUPPORT WILL BE PROVIDED.