The Problem:

SSL Certificate processing on WinOSes has been compromised.

To identify if servers are effected

Open Regedit on the server and go to:

HKLM\Software\Microsoft\SystemCertificates\AuthRoot\Certificates

If there are hundreds of Certificates in there then you have a problem, it breaks Certificate processing. If combined with a ZDE… The problem also becomes one of too much trust (too many Certificates). IF Server Admins use IE on the Server with too much trust then we have another problem... IE should not be run on a server.





Event IDs (EIDs) that are indicative of this issue (not complete):

EID #36885 - Event Source: SChannel

EID #36887 - Event Source: SChannel

EID #36855 - Event Source: SChannel

EID #2 - - Event Source: IAS

EID #39 - Event Source: NapAgent

EID #20225 - Event Source: RemoteAccess

EID #20271 - Event Source: RemoteAccess

Possible Exploits ?

After exporting the SystemCertificates registry key I applied the reverse engineered KB code and Dec. 2012 KB 931125 .SSTs to it. I again exported the SystemCertificates. Using Beyond Compare I went to the last CERT in the list that was removed from the system and took it's registry key (the SHA1 of the CERT) and searched the Interweb.

The last CERT key removed was "CE1A3553BA6155DA5160097B4B1EA1FF4CBA7195".

In searching for that key it seems that several Virus'/Trojans are leveraging it:

June 28th, 2013

http://home.mcafee.com/virusinfo/virusprofile.aspx?key=3354154#none

Sept. 1st, 2013

http://home.mcafee.com/virusinfo/virusprofile.aspx?key=3868943#none

Even so, if our ability to properly handle CERTs is compromised our ability to use PKI is compromised. After the DigiNotar / Staat der Nederlanden <place w:st="on"><city w:st="on">Root</city> <state w:st="on">CA</state></place> compromise in June 2011 and VeriSign's CA compromise in 2001 we NEED to be able to properly process CAs.









MS’s Approach to the Cleanup



http://support.microsoft.com/kb/933430

http://social.technet.microsoft.com/Forums/windowsserver/en-US/7b5e6cb7-a4f3-4466-afea-0c32da5d3167/updated-root-certificates-windows-update-for-windows-2008-r2-server-kb931125

The basic issue is that MS's only solution seems to be one of four (non-viable) manual options. Although they could have created a new KB to fix this they didn’t. It also seems they are keeping it quiet.

None of the MS solutions seem to completely address the issue (WinXP Root Certs being loaded into Servers and no clean, clear, or easy way to remove).

MS Solutions:

Run Fix-It on every system

NO. This will delete the registry key including your own certificates which will lead to broken services.

Deleting the Registry Key manually (or via GPO or 'package')

NO. Again, as with the solution above, you will be deleting your own certificates which will lead to broken services.

Deleting expired certs, small certs, certs you know and here a cert, there a cert

NO. It is too hard to tell what certificates you are using for what when you are presented with hundreds of certificates.

Reconfigure SChannel to not send the list

NO. This doesn’t fix the problem. It merely only stops the OS from telling you about it.

Another Solution:

Remove JUST the Certificates that were added by MS in Dec 2012.

Obtain a copy of KB 931125 from Dec 2012 from MS

Use WinRAR to export the KB contents to a directory

Use the UpdRoots.EXE and the .SSTs to remove the CERTs added by KB 931125



"UpdRoots.EXE -d AuthRoots.sst" – for the Root CERTs

"UpdRoots.EXE -d UpdRoots.sst" - for the updated CERTs

"UpdRoots.EXE -d Roots.sst" - for the Local Machine CERTs





