Microsoft Windows Unauthorized Digital Certificates

ivansanders — Thu, 07 Jun 2012 05:00:00 GMT

Original release date: June 04, 2012 Source: US-CERT Alert TA12-156A

Systems Affected

All supported versions of Microsoft Windows, including:
* Windows XP and Server 2003
* Windows Vista and Server 2008
* Windows 7 and Server 2008 R2
* Windows 8 Consumer Preview
* Windows Mobile and Phone
Overview
X.509 digital certificates issued by the Microsoft Terminal Services licensing certificate authority (CA) can be illegitimately used to sign code. This problem was discovered in the Flame malware. Microsoft has released updates to revoke trust in the affected certificates.

Description

Microsoft Security Advisory (2718704) warns of active attacks using illegitimate certificates issued by the the Microsoft Terminal Services licensing certificate authority (CA). There appear to be problems with some combination of weak cryptography and certificate usage configuration. From an MSRC blog post:

We identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft. Specifically, our Terminal Server Licensing Service, which allowed customers to authorize Remote Desktop services in their enterprise, used that older algorithm and provided certificates with the ability to sign code, thus permitting code to be signed as if it came from Microsoft.

Security Advisory 2718704: Update to Phased Mitigation Strategy What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft's internal PKI infrastructure.

The following details about the affected certificates were provided in Microsoft Security Advisory (2718704):

Certificate: Microsoft Enforced Licensing Intermediate PCA

Issued by: Microsoft Root Authority
Thumbprint: 2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70

Certificate: Microsoft Enforced Licensing Intermediate PCA

Issued by: Microsoft Root Authority
Thumbprint: 3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08

Certificate: Microsoft Enforced Licensing Registration Authority CA (SHA1)

Issued by: Microsoft Root Certificate Authority
Thumbprint: fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97

Impact

An attacker could obtain a certificate that could be used to illegitimately sign code as Microsoft. The signed code could then be used in a variety of attacks in which the code would appear to be trusted by Windows. An attacker could offer software that appeared to be signed by a valid and trusted Microsoft certificate chain. As noted in an MSRC blog post, "...some components of the [Flame] malware have been signed by certificates that allow software to appear as if it was produced by Microsoft."

Solution

It is important to act quickly to revoke trust in the affected certificates. Any certificates issued by the Microsoft Terminal Services licensing certificate authority (CA) could be used for illegitimate purposes and should not be trusted.

Apply updates

Apply the appropriate versions of KB2718704 to add the affected certificates to the Untrusted Certificate Store. Updates will reach most users via automatic updates and Windows Server Update Services (WSUS).

Revoke trust in affected certificates Manually add the affected certificates to the Untrusted Certificate Store. The Certificates MMC snap-in and Certutil command can be used on Windows systems.

References

* US-CERT Current Activity: Unauthorized Microsoft Digital
Certificates - https://www.us-cert.gov/current/#microsoft_unauthorized_digital_certificates
* Microsoft Security Advisory (2718704) - https://technet.microsoft.com/en-us/security/advisory/2718704
* Unauthorized digital certificates could allow spoofing - http://support.microsoft.com/kb/2718704
* Microsoft certification authority signing certificates added to the Untrusted Certificate Store - https://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx
* Microsoft releases Security Advisory 2718704 - https://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx
* Windows Server Update Services - http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx
* Certutil - http://technet.microsoft.com/en-us/library/cc732443%28v=ws.10%29.aspx
* How to: View Certificates with the MMC Snap-in - http://msdn.microsoft.com/en-us/library/ms788967.aspx

-Ivan

Fix for DCOM 10009 Errors in Exchange 2010 SP1

Anonymous — Thu, 07 Jul 2011 05:00:00 GMT

You may notice DistributedCOM 10009 errors in the Windows Server 2008 R2 System Event Log whenever you run any of the following Exchange 2010 SP1 cmdlets:

Get-OWAVirtualDirectory
Get-WebServicesDirectory
Get-ActiveSyncVirtualDirectory

The DCOM 10009 error reads as follows:

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          7/1/2011 10:16:11 AM
Event ID:      10009
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CAS01.domain.com
Description:
DCOM was unable to communicate with the computer CAS02.domain.com using any of the configured protocols.
This happens because of an security context error when invoking an RPC call to the remote CAS server. The fix is to direct the RPC Runtime to ignore delegation failures. This can be done by configuring the registry on both the source and target machines, but is more easily done using Group Policy.

To configure Ignore Delegation Failures manually:

Run REGEDIT on the source computer
Navigate to HKLM\Software\Policies\Microsoft\Windows NT\Rpc
Create a new DWORD value called IgnoreDelegationFailure with the value of 1
Restart the computer
Repeat for each Exchange 2010 SP1 Client Access Server

To configure this setting using Group Policy:

Open the Group Policy Management Console
Edit the Group Policy Object (GPO) that applies to the Exchange 2010 SP1 servers. I usually use the Default Domain Policy.
Navigate to Computer Configuration > Policies > Administrative Templates > System > Remote Procedure Call
Double-click Ignore Delegation Failure.
Enable the policy and set the Ignoring Delegation Failure setting to ON.
Restart the Exchange 2010 SP1 Client Access Servers

This DCOM 10009 error does not seem to affect Windows Server 2008 servers, only Windows Server 2008 R2.

Search results for 'app:weblogs' matching tags 'Windows Server 2008 R2' and 'Security'

Microsoft Windows Unauthorized Digital Certificates

Fix for DCOM 10009 Errors in Exchange 2010 SP1