Security Research & Defense

More information about the new Excel vulnerability

swiblog — Tue, 24 Feb 2009 18:43:00 GMT

This morning, we posted Security Advisory 968272 notifying of a new Excel binary file format vulnerability being exploited in targeted attacks. We wanted to share more information about the vulnerability to help you assess risk and protect your environment.

Office 2007 being targeted

The current attacks we have seen target users of Office 2007 running an earlier version of Windows (Windows 2000, XP, 2003). The exploit technique used in these attacks would not work on Windows Vista or earlier versions of Microsoft Office without substantial improvements made by attackers.

We analyze a lot of Office content type exploits and this is the first time we have seen a working exploit in-the-wild that is able to run code on Office 2007. It is always interesting to analyze the first exploit for a new platform, especially one that has held up without being exploited for several years. Note that this is in the legacy binary file format, not the newer XML format. The nature of this vulnerability, unfortunately, lends itself to easier exploitation on Office 2007 compared to earlier versions of Office. The routines that handle object destruction were changed in Office 2007 in a way that makes exploitation for code execution easier. The same vulnerable code is present in earlier versions of Office but will more likely result only in an application crash on those versions. It appears attackers are targeting Office 2007 running on Windows XP.

How to protect yourself

The security advisory lists a couple different workaround options:

1 – Turn on MOICE. MOICE converts the XLS to XSLX before opening. Again, the new XML file format is not susceptible to this vulnerability.

2 – Turn on FileBlock. This option is a little more disruptive to most environments. With FileBlock enabled, Excel will only open the new XML-based file format that is safer. It will not open the legacy binary file format. If your organization has switched over to using the new file format exclusively, this might be a great option, even just long enough for us to get a security update out to address the vulnerability.

- Jonathan Ness and Bruce Dang, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP

swiblog — Mon, 02 Feb 2009 22:53:00 GMT

One of the responsibilities of Microsoft’s Security Engineering Center is to investigate defense in depth techniques that can be used to make it harder for attackers to successfully exploit a software vulnerability. These techniques are commonly referred to as exploit mitigations and have been delivered to users in the form of features like /GS, Data Execution Prevention (DEP), and Address Space Layout Randomization (ASLR). In Windows Server 2008 and Windows Vista SP1, Microsoft released support for a new platform mitigation known as Structured Exception Handler Overwrite Protection (SEHOP). The purpose of this article is to explain the problem this feature is attempting to solve, how it goes about solving it, and what you can do take advantage of it.

The exploitation technique: SEH overwrites

The purpose of the SEHOP mitigation is to prevent an attacker from being able to make use of the Structured Exception Handler (SEH) overwrite exploitation technique. This exploitation technique was publicly documented by David Litchfield of NGS Software in a research paper that he published in September, 2003[1]. Since this publication, the SEH overwrite technique has become a standard weapon in an attacker’s arsenal. Roughly 20% of the exploits included in the latest version of the Metasploit framework make use of the SEH overwrite technique. SEH overwrites are also commonly used by exploits that target the increasing number of browser-based vulnerabilities[4].

At a high-level, the SEH overwrite technique uses a software vulnerability to execute arbitrary code by abusing the 32-bit exception dispatching facilities provided by Windows. At a functional level, an SEH overwrite is generally accomplished by using a stack-based buffer overflow to overwrite an exception registration record that has been stored on a thread’s stack. To provide some context, an exception registration record is composed of two fields: a next pointer and an exception handler function pointer. The next pointer is used to link an exception registration record to the next record in the singly-linked list of registered exception handlers. The exception handler function pointer is called by the Windows exception dispatcher when an exception occurs. The definition for an exception registration record can be seen below:

typedef struct _EXCEPTION_REGISTRATION_RECORD
{
struct _EXCEPTION_REGISTRATION_RECORD *Next;
PEXCEPTION_ROUTINE Handler;
} EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD;

After an exception registration record has been overwritten, an exception must be raised so that the exception dispatcher will attempt to handle it. This can be accomplished in a number of ways, such as by overwriting a return address on the stack with a bogus address in order to cause an access violation exception to be raised. When an exception is raised, the exception dispatcher will attempt to enumerate the list of exception registration records for the thread and call the exception handler that is associated with each record. By corrupting the next pointer and exception handler function pointer of one of the exception registration records, the exception dispatcher can be made to execute code from an arbitrary address as specified by the corrupt exception handler function pointer.

In many cases, an attacker will choose to overwrite the exception handler function pointer with an address that contains instructions that are equivalent to a pop reg, pop reg, ret. This allows an attacker to reliably execute arbitrary code by transferring control to the EstablisherFrame that the exception dispatcher passes as the second parameter when calling an exception handler. This works because the EstablisherFrame parameter holds the address of the attacker-controlled exception registration record. Attackers have also used heap spraying in conjunction with an SEH overwrite to reliably execute arbitrary code. The following diagram illustrates what an SEH overwrite would typically look like from an exploitation perspective:

The mitigation technique: SEHOP

There are two general approaches that can be considered when attempting to mitigate the SEH overwrite exploitation technique. The first approach involves making changes to the compiled versions of code such that executable files are made to contain metadata that the platform would need to properly mitigate this technique. Microsoft pursued this approach and released a functional mitigation with Visual Studio 2003. This mitigation took the form of a new linker flag known as /SAFESEH. Unfortunately, the need to rebuild executables in combination with the inability to completely handle cases where an exception handler is pointed outside of an image file make the SafeSEH approach less attractive. The details relating to how SafeSEH works are beyond the scope of this article, but more information can be found on MSDN[2].

The second approach involves adding dynamic checks to the exception dispatcher that do not rely on having metadata derived from a binary. This is the approach taken by SEHOP. At a high-level, SEHOP prevents attackers from being able to use the SEH overwrite technique by verifying that a thread’s exception handler list is intact before allowing any of the registered exception handlers to be called. This mitigation technique is made possible because of an implicit side effect of an SEH overwrite. When the majority of stack-based buffer overflows occur, an attacker will implicitly overwrite the next pointer of an exception registration record prior to overwriting the record’s exception handler function pointer. Since the next pointer is corrupted, the integrity of the exception handler chain is broken. This insight, in combination with ASLR, is what allows SEHOP to effectively mitigate SEH overwrites.

From an implementation perspective, SEHOP achieves this functionality in two distinct steps. The first step involves the insertion of a symbolic exception registration record as the tail record in a thread’s exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record.

The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers. An illustration of this logic can be seen in the following diagram:

How you can use SEHOP

SEHOP is enabled by default on Windows Server 2008 and disabled by default on Windows Vista SP1. The primary reason this feature was disabled by default on Windows Vista SP1 was due to a lack of adequate application compatibility data. KB article 956607 documents how SEHOP can be enabled or disabled on a system-wide basis[3].

Wrapping up

We are continuing to investigate new and enhanced exploit mitigation techniques and feel that SEHOP is a valuable addition that can help protect users. We encourage users to enable this feature if it is not enabled by default in order to better protect themselves against the SEH overwrite exploitation technique. For more information about the origins of SEH overwrites and SEHOP, it may be helpful to refer to the cited work[1,5].

Matt Miller, MSEC Security Science

*Posting is provided "AS IS" with no warranties, and confers no rights.*

References

[1] Litchfield, David. Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server. Sep, 2003. http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf

[2] Microsoft Corporation. /SAFESEH (Image has Safe Exception Handlers). http://msdn.microsoft.com/en-us/library/9a89h429(VS.80).aspx

[3] Microsoft Corporation. SEHOP. http://support.microsoft.com/kb/956607

[4] Microsoft Corporation. Microsoft Security Intelligence Report volume 5. Nov, 2008. http://www.microsoft.com/downloads/details.aspx?FamilyId=B2984562-47A2-48FF-890C-EDBEB8A0764C&displaylang=en

[5] skape. Preventing the Exploitation of SEH Overwrites. Sep, 2006. http://uninformed.org/?v=5&a=2&t=sumry

Expanding Horizons

swiblog — Mon, 02 Feb 2009 22:51:00 GMT

The original Security Vulnerability Research & Defense (SVRD) blog was launched in 2007, with the intent of providing more information about vulnerabilities in Microsoft software, mitigations and workarounds and active attacks.

The blog is now expanding its focus a bit (and changing its name slightly), to include postings contributed by the Microsoft Security Engineering Center (MSEC) Security Science team. This team develops more effective and scalable ways to find vulnerabilities, researches and applies innovative exploit mitigation techniques to Microsoft products, and focuses on tracking and providing early warning of new exploits.

In the blog, you’ll still find all the juicy spill-over technical stuff from the MSRC bulletins: information that’s discovered during Microsoft’s technical investigation of security issues that the team feels will help customers protect themselves. With this change, you’ll also now hear about new security defenses and other applied research that the Security Science team is working on.

Generally the Security Science team’s postings will happen once per month, outside of the Security Update Tuesday cycle. Our hope is that this change will give customers an even better view of our efforts to harden future products and at the same time continue to provide helpful and timely information on vulnerabilities and threats.

Matt Thomlinson, Sr. Director of Security Engineering, TWC Security

*Posting is provided "AS IS" with no warranties, and confers no rights.*

XSS Filter Improvements in IE8 RC1

swiblog — Fri, 30 Jan 2009 20:44:00 GMT

On Monday IE8 RC1 was released. Here are some of the most interesting improvements and bug fixes to the XSS Filter feature:

Some byte sequences enabled the filter to be bypassed, depending on system locale
URLs containing certain byte sequences bypassed the Beta 2 filter implementation in some locales. For example, with a Chinese locale system, URLs of the following format would bypass the filter:

http://www.fabrikam.com?x=%A0<script>alert();</script>

The filter decodes the URLEncoding prior to passing the URL through our regular expression engine. The presence of a raw 0xA0 byte followed by a 0x3C byte (“<”) can cause MultiByteToWideChar to fail. This is because with Chinese and other locales, 0XA0 0x3C is not a valid multi-byte character. In this circumstance, the failure cascades so that the regular expression matching would fail to be case-insensitive. But even worse, at a later point in the regular expression code, the 0xA0 0x3C sequence would be interpreted as a single multi-byte character. Thus the < character would essentially be missing from input and the appropriate heuristic would not detect XSS.

The IE8 RC1 fix enables the regular expression code to treat all input as a stream of individual bytes, not characters in the default codepage (which could be multi-byte).

Yosuke Hasegawa and 80sec both discovered this bug in the IE8 Beta 2 release.
NULLs in HTTP responses caused filtering to drop chunks of HTTP response data
The relevant buffer class was rev’d in the code to fix this.
Added protection against attack scenarios involving PHP stripslashes
The stripslashes function in PHP removes backslashes from input. (It also replaces double-backslashes with a single backslash.) It’s common for PHP developers to call stripslashes before outputting a string. In these cases if the output enables a server-side XSS bug, that bug can still be abused despite the IE8 XSS Filter.

This is an example of a platform-specific artifact as discussed in the XSS Filter Architectural Overview:

The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.

This describes the new behavior well – the filter now generates additional signatures as necessary for an alternate interpretation of the input. These new signatures are designed to compensate for the behavior of the PHP stripslashes feature.

It does appear that the PHP “magic quotes” feature is now deprecated. If the use of stripslashes in PHP code is due to the magic quotes feature then it should be expected that stripslashes usage will decline on the web. Regardless, we made the call that this issue still seems to be pervasive enough, at least today, to be worth mitigating in IE8 RC1.

Ronald van den Heetkamp identified this issue.
Added protection against attack scenarios involving servers that still support overlong UTF-8
Similar to the PHP Stripslashes change described above, we now generate and process additional signatures if overlong UTF-8 sequences are identified on input.

While overlong UTF-8 appears to be specifically banned in RFC 3629, it still unfortunately seems to be common enough on web server platforms that it makes sense for us to address this attack vector in our code.

Amit Klein provided feedback which helped identify this issue.
Added protection against attack scenarios involving injection of FORM and ISINDEX elements
Though in general we do not block generic HTML injection, we make an exception for these two elements as they enable attack scenarios similar to those involving injection of script.

Gareth Heyes identified the ISINDEX element.
OBJECT tag’s CODETYPE attribute is now treated equally to the TYPE attribute
The OBJECT tag’s CODETYPE attribute provides the same functionality as the TYPE attribute. In IE8 RC1 both attributes are considered equal.

Gareth Heyes identified this issue.
General performance improvements
Ex: Pre-validation to avoid the performance hit of a regular expression in some cases.

I want to especially thank Dany Joly on the IE team for the extraordinary work he’s done perfecting the XSS Filter implementation in IE8.

Onward to RTM!

David Ross, MSRC Engineering - working on a Security Science project

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Update - 2/11/09: Change to blog signature

Stack overflow (stack exhaustion) not the same as stack buffer overflow

swiblog — Wed, 28 Jan 2009 23:20:00 GMT

Periodically we get reports into the MSRC of stack exhaustion in client-side applications such as Internet Explorer, Word, etc. These are valid stability bugs that, fortunately, do not lead to an exploitable condition by itself (no potential for elevation of privilege). We wanted to clarify the distinction between stack exhaustion and stack buffer overflow. Stack buffer overflows often lead to elevation of privilege. Unfortunately, the literature tends to use stack overflow to refer to both cases, hence the confusion. The error code STATUS_STACK_BUFFER_OVERRUN (0xc0000409) refers to a stack buffer overflow while the error code STATUS_STACK_OVERFLOW (0xc00000fd) refers to stack exhaustion.

On Bugtraq this morning, there was a public post of a stack exhaustion bug that, fortunately, does not lead to arbitrary code execution. Let's take a closer look at it and a few other examples. We'll start with today's Bugtraq posting:

<INPUT type="text" name="A" value="CCCCCCCCCCCCCCCCCCCC(many thousands)”>

When IE attempts to parse this HTML, it runs out of stack space. Hooking up Windbg, you will observe the following first-chance exception:

(f9c.5b8): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=0337304c ecx=09410040 edx=0007c3c0 esi=00000000 edi=0346b800
eip=77f66627 esp=03373000 ebp=03373000 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
77f66627 56              push    esi

The stack is simply exhausted and there is no possibility of running arbitrary code in this case. Let’s look at a few others.

The next issue was also reported in IE recently:

<SCRIPT> 
foo = new Array();
while(true) {foo = new Array(foo).sort();}
</SCRIPT>

Again, the HTML has requested an extra-ordinary amount of stack space. IE attempts to allocate space and it eventually runs out. Unable to process the HTML, it returns a stack overflow / exhaustion error (0xc00000fd).

One last example is from April 2008 and, again, it leads to a stack overflow/exhaustion error (0xc00000fd):

var str = "aaaaaaaaaaaaaaa(many thousands)”
document.myform.text.value = str
document.myform.submit()

<form name='myform'>
<input name='text' type='text' />
<input name='Submit' type='submit' />
</form>

As you can see, there are several ways of reaching a stack exhaustion condition. Fortunately, these are stability issues that by themselves cannot lead to remote code execution. This happens when a parsing client-side application cannot allocate enough stack space to complete an operation (as shown in the examples here where a web page was attempting to allocate as much stack as possible and eventually runs out of space).

We are always happy to triage bugs sent to secure@microsoft.com. Please send them in to us. We are definitely committed to engineering and security excellence. We evaluate every report and determine whether to service them as security issues or whether to hand them off to the product team to fix as reliability and stability issues. For each security issues, we will triage against the SDL bug bar (link to sample bug bar) and address via the MSRC security bulletin process. All issues (such as these stack exhaustion bugs) that are stability or reliability issues are triaged according to customer impact and addressed in future releases of the product.

Update Jan 29: Thanks to Mark Dowd for pointing out that stack exhaustion bugs might have a security impact if combined with a buffer overrun bug. You can read more about his research at https://www.blackhat.com/presentations/bh-usa-07/Dowd_McDonald_and_Mehta/Whitepaper/bh-usa-07-dowd_mcdonald_and_mehta.pdf

- Jonathan Ness, SVRD blogger

*Posting is provided "AS IS" with no warranties, and confers no rights.*

References:

STATUS_STACK_OVERFLOW (0xc00000fd ):

Debugging a Stack Overflow http://msdn.microsoft.com/en-us/library/cc267849.aspx
StackOverflowException Class http://msdn.microsoft.com/en-us/library/system.stackoverflowexception(VS.71).aspx

STATUS_STACK_BUFFER_OVERRUN (0xc0000409):

Analyze Crashes to Find Security Vulnerabilities in Your Apps http://msdn.microsoft.com/en-us/magazine/cc163311.aspx

MS09-001: Prioritizing the deployment of the SMB bulletin

swiblog — Fri, 09 Jan 2009 20:24:00 GMT

This month we released an update for SMB that addresses three vulnerabilities. This blog post provides additional information that might help prioritize the deployment of this update, and help explain the risk for code execution.

In the bulletin you will see that the cumulative severity rating is Critical for Windows 2000, XP and Server 2003 systems, while Vista and Server 2008 have cumulative severity ratings of Moderate.

Two of the three vulnerabilities pose the risk for Remote Code Execution (CVE-2008-4834 and CVE-2008-4835), and hence these are rated Critical. However, Vista and Server 2008 systems are not vulnerable to the first of these vulnerabilities, and the second vulnerability does not affect systems using default settings. As a result, we rated Vista and Server 2008 as Moderate for CVE-2008-4835. CVE-2008-4114 affects all Windows platforms and results in a system DoS without any risk of RCE, and hence is rated Moderate. The table below summarizes the exposure for each version of Windows.

	Exposure
Windows 2000	RCE
Windows XP	RCE
Windows Server 2003	RCE
Windows Vista	DoS
Windows Server 2008	DoS

For all affected versions of Windows, the two RCE vulnerabilities are unlikely to result in functioning exploit code as stated in the exploitability index (http://technet.microsoft.com/en-us/security/cc998259.aspx). There are a few reasons for this:

The vulnerabilities cause a fixed value (zero) to be written to kernel memory – not data that the attacker controls.
Controlling what data is overwritten is difficult. To exploit this type of kernel buffer overrun, an attacker typically needs to be able to predict the layout and contents of memory. The memory layout of the targeted machine will depend on various factors such as the physical characteristics (RAM, CPUs) of the system, system load, other SMB requests it is processing, etc.

In terms of prioritizing the deployment of this update, we recommend updating SMB servers and Domain Controllers immediately since a system DoS would have a high impact. Other configurations should be assessed based on the role of the machine. For example, non-critical workstations could be considered lower priority assuming a system DoS is an acceptable risk. Systems with SMB blocked at the host firewall could also be updated more slowly.

- Mark Wodrich, SVRD Blogger

Posting is provided "AS IS" with no warranties, and confers no rights.

Information regarding MD5 collisions problem

swiblog — Tue, 30 Dec 2008 18:36:00 GMT

Today Microsoft released a security advisory (961509) regarding collisions in MD5 hashes on certificates. This specific problem affects the entire industry and is not a Microsoft specific vulnerability. Serious weaknesses in MD5 have been known for many years now; it is because of these weaknesses that MD5 is banned in new code under the Microsoft Security Development Lifecycle (SDL). Software developers are urged to migrate away from using MD4, MD5 and even SHA1 and use SHA-256 and later instead for hashing, signatures and message authentication codes (see slide 22 for more information http://download.microsoft.com/download/8/4/7/8471a3cb-e4bf-442a-bba4-c0c907d598c5/Michael%20Howard%20SDL%20Development%20Practices.ppsx)

The most common type of certificates that Certificate Authorities (CAs) will issue are for three main purposes:

Secure Socket Layer (SSL) or Transport Layer Security (TLS)
Secure E-mail (such as S/MIME)
Code signing (such as Authenticode)

In this context, we believe that the most likely attack scenario will through SSL/TLS (though we have not seen any attacks at this time.) Thus, common web browsers are similarly exposed to this problem since HTTPS uses SSL/TLS to establish the secure connection.

Thus the purpose of this blog post is to explain this problem in more detail as well as highlight mitigations and workarounds when using Internet Explorer.

Lastly, we should note that certificates hashed with SHA1 are not affected by this problem.

Summary of the problem

An MD5 hash collision allows a malicious user to potentially generate a rogue certificate derived from a valid one. This user can then impersonate a valid site or person since both certificates look legitimate because the certificate hashes are the same. An attacker will have to lure a user to initiate an SSL/TLS connection, then the certificate will be validated by the client and it will seem valid. Thus, the user will think that it is establishing a safe connection with site or person when in fact it is connecting with the attacker.

Although any certificate hashed with MD5 and then signed can potentially be manipulated we have not seen any active attacks.

Mitigations & Workarounds

Green filled address bar (IE7 & IE8)

Extended Validation certificates (http://www.cabforum.org/EV_Certificate_Guidelines.pdf) are required to use SHA1 (instead of MD5) Thus, these certificates are not affected by this problem. Internet Explorer 7 and later take advantage of EV certificates by highlighting the address bar in green. See http://blogs.msdn.com/ie/archive/2006/11/07/improving-ssl-extended-validation-ev-ssl-certificates-coming-in-january.aspx for more information. Below is such an example:

In short, if Internet Explorer 7 address bar is highlighted in green then there is no risk against this attack.

Certificate revocation in IE7 & IE8 & OCSP configuration

Certificate revocation allows a Certificate Authority to revoke a specific certificate, after which it is no longer accepted as valid by the user’s browser. While it does not fully help prevent the attack, it improves the ability a certificate authority has to respond to them by allowing them to disable fraudulent certificates.

Certificate revocation is enabled by default for Internet Explorer 7 and later (running on Vista & above) since Online Certificate Status Protocol (OCSP) is used to confirm whether a certificate is valid or not. Thus, in the event that a malicious certificate is being actively used then a Certificate Authority can revoke it and Internet Explorer will automatically block the web-site visited.

Below are the steps needed to configure an OCSP.

Steps to Configure Custom OCSP Responder Location Locally on Vista SP1 and Windows Server 2008:

Start the Certificates MMC snap-in

Click on the Start button and enter mmc.exe into the Start Search field
From the File menu, select Add / Remove Snap-in…
Select the Certificates snap-in on the left and click Add
Select Computer account, click Next, then click Finish to complete the wizard
Click OK to dismiss the dialog

Configure the snap-in to show Physical Certificate Stores

Select the Certificates (Local Computer) node
From the View menu, select Options…
Check the Physical certificate stores checkbox, then click OK

Select the public commercial root CA you want to configure to use with a custom OCSP responder

Select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Third Party -> Certificates node
Select the root CA

Move the root CA certificate to the Registry node

Right-click on the root CA certificate
Select Cut
Select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Third Party -> Certificates -> Registry -> Certificates node
From the Action menu, select Paste

Configure the custom OCSP responder location with the root CA certificate

Right-click on the root CA certificate
Select Properties
Select the OCSP tab
Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
Click OK

Steps to Configure Custom OCSP from Group Policy

Select the Group Policy Object where certificate configuration will be stored
From the Group Policy Editor, select the Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities node
Add the Root CA certificate to Group Policy. Note: You must remove the root CA certificate from the Third Party Certification Authorities store from each computer manually prior to applying this policy

Right click on the Trusted Root Certification Authorities node and select Import… to add the root CA certificate
Click Next
Enter the file name of the root CA certificate, then click Next
Click Next, then Finish to complete the wizard

Configure the custom OCSP responder location with the root CA certificate

Right-click on the root CA certificate
Select Properties
Select the OCSP tab
Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
Click OK

Certificate revocation on IE6

Certificate revocation checking is disabled by default on Internet Explorer 6, as it requires the download of a Certificate Revocation List (CRL) to validate whether a certificate is still marked as valid. On low bandwidth connections, such as dial-up, this may increase latency.

Certificate revocation for Internet Explorer 6 can be enabled following the below steps:

On the Tools menu, click Internet Options, and then click the Advanced tab.
In the Security area, select the Check for publisher’s certificate revocation and Check for server certificate revocation check box.

See below link for more information:

http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c06ie6rk.mspx?mfr=true

Reviewing the certificate

Another alternative to verify whether the certificate is using MD5 is to look at the certificate details. It is important to note that the certificate itself and the entire chain (the Certification Path), excluding the root, needs to be reviewed to assess whether a certificate hashed with MD5 has been used. Below are the steps on how to do this in Internet Explorer 7.

Click on the lock icon in the address bar:
The below window will open up:
Click “View certificates”
The below window will open up:
If the signature algorithm is SHA1 using RSA (sha1RSA) then this certificate is safe from the vulnerability described in this document, if it is MD5 (such as md5RSA) then it could potentially be compromised.

Caveat: If the rogue certificate has misleading information about the CRL then web browsers might not be able to identify the certificate as revoked. In corporate PKI deployments, we recommend configuring a specific OCSP responder in the Windows OCSP configuration. This will allow organizations to revoke certificates that have been fraudulently signed and modified to no longer carry a correct validation location.

We would like to thank the engineers who helped build the above guidance:

Eric Lawrence from the Internet Explorer team
Kelvin Yiu and Tom Albertson from the Windows Cryptography team
Maarten Van Horenbeeck from the Microsoft Security Response Center team
Michael Howard from the Security Development Lifecycle team

Finally, the link to the Microsoft Security Response Center (MSRC) blog, which discusses this advisory is: http://blogs.technet.com/msrc/archive/2008/12/30/information-on-microsoft-security-advisory-961509.aspx

Update 12/31/08: "Reviewing the certificate" section updated in resposne to e-mail to switech AT microsoft.com.

Damian Hasse, MSRC Engineering Blogger

Posting is provided "AS IS" with no warranties, and confers no rights.

Windows Media Player crash not exploitable for code execution

swiblog — Mon, 29 Dec 2008 20:40:00 GMT

On Christmas Day, the MSRC opened a case tracking a Bugtraq-posted POC describing a “malformed WAV,SND,MID file which can lead to a remote integer overflow”. By Saturday evening, we saw reputable internet sources claiming this bug could lead to executing arbitrary code on the system.

We investigated right away and found that this bug cannot be leveraged for arbitrary code execution.

Let’s take a closer look to understand why.

The POC is a MIDI file handled by quartz.dll, a core component of the DirectShow framework. We have blogged previously about this component here. WAV,SND, and MID file extensions are all handled by quartz.dll which explains the finder’s statement about the exception being hit when parsing any of those 3 file types.

This particular crash is an unhandled CPU exception when executing a div instruction. When the processor executes a “div reg” instruction, it does this:

EAX = (EDX:EAX)/reg

If the result cannot fit on a 32 bit register it generates a CPU exception. This one is not handled by quartz.dll. There is no memory corruption here and the value does not appear to be used for any memory allocation. Rather, the operation is calculating a value related to the rate at which the media is to be played.

We found this already through our internal fuzzing efforts. It was correctly triaged at the time as a reliability issue with no security risk to customers. We do like to get these reliability issues fixed in a future service pack or a future version of the platform whenever possible. This particular bug, for example, has already been fixed in Windows Server 2003 Service Pack 2.

Christopher Budd has also posted to the MSRC blog about this issue.

Jonathan Ness and Fermin J. Serna, SVRD Bloggers

*Posting is provided "AS IS" with no warranties, and confers no rights.*

More information about the SQL stored procedure vulnerability

swiblog — Mon, 22 Dec 2008 18:13:00 GMT

Security Advisory 961040 provides mitigations and workarounds for a newly-public post-authentication heap buffer overrun in SQL Server, MSDE, and SQL Express. This blog post goes into more detail about the attack surface for each affected version and the overall risk from this vulnerability.

As listed in the advisory, the following products have the vulnerable code:

SQL Server 2000
SQL Server 2005 SP2
MSDE 2000 (Microsoft SQL Server 2000 Desktop Edition)
SQL Server 2005 Express Edition

Let’s look at the attack surface for this vulnerability for each platform:

Product	Requires Auth?	Listens on network? (default)	Runs as (default)	Result of successful exploitation
SQL Server 2000	Yes	Yes	SYSTEM	Any user who can connect to and authenticate to the SQL Server can run code as SYSTEM.
SQL Server 2005 SP2 (SP3 is not affected)	Yes	Yes	Service account specified during install	Any user who can connect to and authenticate to the SQL Server can run code as the account specified during installation.
MSDE 2000	Yes	No	SYSTEM	Any local user able to initiate a connection from the local machine running MSDE and authenticate to the SQL instance can run code as SYSTEM.
SQL Server 2005 Express	Yes, Builtin\Users granted logon rights by default	No	Network Service	Any local user able to initiate a connection from the local machine running SQL Express and authenticate to the SQL instance can run code as NetworkService. All accounts in Builtin\Users group can authenticate using integrated authentication by default.

So as the table above shows you have to be authenticated to exploit this vulnerability. Additionally, by default, MSDE 2000 and SQL Server Express 2005, which are redistributed and used by Microsoft and third party applications, can’t be exploited remotely. But it’s important you not ignore this vulnerability for a couple of reasons.

As we said, an unauthenticated attacker cannot exploit this vulnerability directly. However, if an attacker finds a SQL injection vulnerability in the web application connected to your database, he could combine the SQL injection vulnerability with this vulnerability and run code “without authenticating”. Technically, the attacker did authenticate – he just used your compromised web application to authenticate for him. Of course, if an attacker does compromise your web application using SQL injection, he can take a number of actions anyway.

Secondly, remember our October advisory and blog post about service isolation? That vulnerability allowed an attacker to escalate from code running as NetworkService to LocalSystem. Unfortunately, this SQL vulnerability allows any user logged on to a machine running SQL Express to escalate to SYSTEM by leveraging the SQL vulnerability to get to NetworkService and then the service isolation vulnerability to get to SYSTEM.

Thus, we highly encourage you to apply the workaround listed in the security advisory to block this attack and let us know if you have questions.

The affected stored procedure will have no impact for the majority of customers. It is called as a trigger for user modifications during transactional replication with updatable subscriptions. So if your SQL installation does not include replication, the workaround will have no effect other than to protect you from this vulnerability. The workaround will also have no impact on your database installation if you use transaction replication with read-only subscriptions, bi-directional, or peer-to-peer settings. It is only transactional replication with updatable subscriptions that is impacted.

One caveat about the stored procedure workaround: If an attacker connects to the database as sa (or a member of the sysadmin server role), denying execute permission to public will not be effective in stopping them from executing the stored procedure. Of course, if someone has sysadmin rights in SQL Server, they likely have other ways to gain administrator privileges on the server already.

If you don’t want to use the raw SQL in the advisory, you can apply the change using GUI tools. Here are screenshots for the SQL Server Enterprise Manager (SQL 2000) and SQL Server Management Studio (SQL 2005) changing the setting from GRANT to DENY.

Update 12/25/08: Added caveat about workaround being ineffective against attackers connecting as sa / sysadmin

Jonathan Ness and Bruce Dang, SVRD Bloggers

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Clarification on the various workarounds from the recent IE advisory

swiblog — Sat, 13 Dec 2008 02:00:00 GMT

Today Microsoft revised the Workarounds section of Security Advisory 961051. We wanted to share more detail about the vulnerability and explain the additional workarounds here to help you protect your computers.

Information about the vulnerability

The vulnerability is caused by memory corruption resulting from the way Internet Explorer handles DHTML Data Bindings. This affects all currently supported versions of Internet Explorer. Malicious HTML that targets this vulnerability causes IE to create an array of data binding objects, release one of them, and later reference it. This class of vulnerability is exploitable by preparing heap memory with attacker-controlled data (“heap spray”) before the invalid pointer dereference.

Which workarounds should you apply?

The advisory now lists nine different workaround options. We have been adding additional workarounds with each advisory revision to give you more surgical options to cut off the vulnerable code path. Only IE8 has an option to turn off data binding altogether. So unless you are using IE8, you’ll need to:

(A) block access to the vulnerable code in MSHTML.dll via OLEDB, protecting against current attacks
(B) apply the most secure configuration against this specific vulnerability.

Optionally, you may choose to (C) make it much harder to heap spray.

The table below lists what type of protection each advisory workaround provides.

Workaround	A	B	C
1. Set Internet and Local intranet security zone settings to "High" to prompt before running ActiveX Controls and Active Scripting in these zones		X	X
2. Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone		X	X
3. Disable XML Island Functionality	X
4. Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL	X
5. Disable Row Position functionality of OLEDB32.dll	X
6. Unregister OLEDB32.DLL	X
7. Use ACL to disable OLEDB32.DLL	X
8. Enable DEP for Internet Explorer 7 on Windows Vista and on Windows Server 2008			X
9. Disable Data Binding support in Internet Explorer 8	X	X

Applying a workaround from the (A) column will protect against current attacks but to comprehensively protect against the vulnerability, we recommend that you also apply a workaround from the (B) column.

Why list five different ways to protect against OLEDB data provider attack vector?

Let’s briefly touch on workarounds 3-7, each being a different way to protect against the OLEDB data provider attack vector.

6 & 7 –Unregister or Disable via ACL the OLEDB32.DLL

We listed these workarounds in yesterday’s advisory and they still remain viable options. However, these are two somewhat drastic options. All applications that rely on any part of this DLL will fail to function.

5 - Disable Row Position functionality of OLEDB32.dll

In our investigation, we discovered that disabling a single OLEDB32 COM object is enough to block access to the affected code path. We continue to list workaround options #6 and #7 in the advisory but #5 is actually far preferable because it is as good as either #6 or #7 and less invasive.

4 - Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL

This workaround option is another way to block access to the OLEDB data provider. The great thing about this option is that it blocks access for Internet Explorer only. It will not disrupt stand-alone data access applications. However, it only exists when UAC and IE Protected Mode are both enabled (default configuration) on Windows Vista and Windows Server 2008. We will go into more detail for this option below because it is pretty cool. :)

3 - Disable XML Island functionality

Exploits targeting the OLEDB data provider require msxml3.dll as well as OLEDB32.dll. We initially considered suggesting customers unregister or ACL msxml3.dll to block attempts to exploit the vulnerability. Blocking msxml3.dll system-wide turned out to break lots of stuff. However, disabling only the XML Data Island CLSID is enough to prevent msxml3.dll from loading only for IE for known attacks. Also, from our testing, it appears that not very many websites use the XML Data Island functionality so this is our least intrusive workaround from column A and it works on all supported platforms.

Further information about the Integrity Level ACL workaround

To provide this type of selective protection, the new workaround relies on the fact that, by default, Internet Explorer runs with Protected Mode turned on. This means that the iexplore.exe process runs at a low integrity level. For more information on what this means and how this works, refer to http://msdn.microsoft.com/en-us/library/bb250462.aspx. As mentioned in the article, the integrity mechanism makes it possible to block processes from being able to write to securable objects (such as files) that have a higher integrity level. One thing that the article does not mention, however, is that it is also possible to block a process from being able to read or execute securable objects at a higher integrity level. This is done by applying a special integrity level entry to the Access Control List (ACL) for an object. Later on in this post, we will walk you through how to do this for OLEDB32.DLL such that Internet Explorer cannot read or execute it.

One thing that should be noted about this workaround is that Internet Explorer must be running with Protected Mode turned on. This requires that both Protected Mode and User Account Control (UAC) are enabled (the default setting). You can determine whether or not Protected Mode is enabled by examining the Internet Explorer status bar as is illustrated in the following screenshot:

Enabling the Workaround (only applies to Windows Vista and later operating systems)

To use this workaround you must first create a temporary directory and then copy an inf file from the attached zip file to it. Use the BlockAccess_x86.inf file if the underlying operating system is 32 bit and the BlockAccess_x64.inf file if the underlying operating system is 64 bit. If you are unsure which operating system you are using, you can figure it out by opening the Control Panel and selecting System. Look for the following output in the resulting window.

Once you have the appropriate file copied over, start an elevated Administrator command prompt, navigate the prompt to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.

    SecEdit /configure /db BlockAccess.sdb /cfg <inf>

After running the command, you should see the following output.

    The task has completed successfully.
    See log %windir%\security\logs\scesrv.log for detail info.

SecEdit will also create a file called BlockAccess.sdb in the directory it was run from. You can safely delete it and the inf file.

Validating the Workaround

It is possible to use the icacls command to quickly determine whether or not the workaround has been applied. If you are using a 32 bit operating system, you just need to run the following command:

    icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

On the other hand if you are using a 64 bit operating system, you will need to run icacls twice; once for the 32 bit version of OLEDB32.DLL and once for the 64 bit version. The two commands are as follows:

    icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
    icacls "%ProgramFiles(x86)%\Common Files\System\Ole DB\oledb32.dll"

Each time you run icacls, search through the output for the following line.

    Mandatory Label\Medium Mandatory Level:(NW,NR,NX)

If the line is present and includes both the NR and NX values, the workaround has successfully been applied. However, if either the line is missing, or one of the NR or NX values is missing, the workaround has NOT been successfully applied.

Undoing the Workaround

To undo the workaround, you will once again need to create a temporary directory and copy an inf file from the zip into it. This time you will need to copy UnblockAccess_x86.inf if you are using a 32 bit operating system and UnblockAccess_x64.inf if you are using a 64 bit one. After copying the file, start an elevated Administrator command prompt, navigate to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.

    SecEdit /configure /db UnblockAccess.sdb /cfg <inf>

You should see the same output as before and similar to last time, you can safely delete the UnblockAccess.sdb and UnblockAccess.inf files.

Let us know if you have any questions.

Update Dec 13, 2008: Added "Disable XML Island Functionality" workaround.

- Andrew Roths, Jonathan Ness, Chengyun (SVRD Bloggers)

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-076: Windows Media Components: Part 1 of 2

swiblog — Tue, 09 Dec 2008 18:07:00 GMT

Today we released MS08-076, which addresses two flaws in the Windows Media components: Windows Media Player, Windows Media Format Runtime, and Windows Media Services. Viewed separately, the issues are not that severe and the aggregate severity rating is Important at most. However, if the two issues are combined the impact can be quite severe, with the potential for Remote Code Execution. Read on to understand how these issues can be combined by an attacker and how they are related to the SMB Reflection bulletin we released last month. The information should be useful to help prioritize the deployment of this update.

The SPN Vulnerability

The first vulnerability, CVE-2008-3009, relates to the Windows Media components' use of the NTLM authentication protocol, specifically regarding SPNs (Server Principal Names). Media players which use the Windows Media components (such as Windows Media Player) could be prompted by the server to authenticate before accessing the media. In response, the client will send the current user’s credentials, possibly using NTLM if this is the protocol that is negotiated by the client and server.

If the server is malicious it can use the NTLM credentials it receives to perform a reflection attack against the client. This type of attack is discussed in more detail in last month’s bulletin MS08-068 and the related SVRD blog post. That bulletin updated SMB clients to protect them from attacks. This bulletin does the same thing, but for Windows Media components clients. In order to be protected against NTLM reflection attacks, a client must pass a valid SPN into the InitializeSecurityContext API while performing an authentication. InitializeSecurityContext for NTLM is covered on MSDN here, and SPNs are covered here. While the SPN documentation focuses on Kerberos authentication, NTLM also supports the use of SPNs.

In this case, since the Windows Media Components passed in an incomplete SPN, NTLM reflection protections would not be enabled for this authentication request. An attacker could try to exploit this by targeting SMB on the client machine using the reflected credentials.

It is important to note that the Windows Media components are zone-aware, in the same way Internet Explorer is. This means that when media is retrieved from a server, the code determines whether the server is on the local intranet (and hence in the Intranet zone), or else in the Internet zone. (There are also the Trusted Sites and Restricted Sites zones which can be configured by the user.)

Servers in the Internet zone are inherently un-trusted, and Windows Media components will not send NTLM credentials to these servers without prompting the user. Hence, for the SPN vulnerability to be exploited, the attacker must either be on the local intranet (e.g. the same subnet as the victim), or the attacker must somehow trick the system into performing NTLM authentication with a machine on the Internet. That’s where the second vulnerability comes into play…

The ISATAP Vulnerability

First off, you might be wondering what ISATAP is. As the bulletin says, ISATAP is a technology to enable IPv6 traffic to be sent within an IPv4 network – it’s one of the “transition technologies” that can be used as the network is migrated from an older IPv4-only network to an IPv6 network. Since ISATAP provides IPv6 connectivity, only systems with IPv6 enabled (such as Windows Vista) are affected by this issue.

The ISATAP vulnerability, CVE-2008-3010, is due to the way Windows Media components treat ISATAP addresses when making the zone determination. Instead of treating an ISATAP server address as an Internet zone address, it is treated as classified as being in the Intranet zone. As explained above, this leads to an information disclosure vulnerability, since NTLM authentication data could be sent to un-trusted destinations on the Internet.

It should be noted that a properly-configured edge firewall will block the IP protocol used by ISATAP, and so an attacker on the Internet will not be able to have victims contact their malicious server. (See the “IPv6 Security Considerations and Recommendations” paper on Technet.)

Combined severity

Given the above information, it should be clear how combining these two vulnerabilities could lead to an attacker being able to gain access to the victim’s machine. However, when determining bulletin severity we do not consider combined attacks for different vulnerabilities, hence the overall severity of Important for this bulletin.

Possible attack scenarios

Due to the way ISATAP is blocked on most routers and edge firewalls, an attacker would need to be on the same network as the victim (not on the Internet).

Typically an attack that leverages these two vulnerabilities would be combined with an SMB reflection attack (creating something known as a “cross-protocol reflection attack”). The exact impact depends on the operating system targeted and the permissions of the user account that the Windows Media components client is running under. It is important to note that even with the update for MS08-068 applied, systems are vulnerable to attack under the above scenario, since SMB is not the one generating the NTLM authentication request.

In part two of this blog post, we will discuss additional workaround steps that can be applied on client machines, and also expand on the ISATAP vulnerability applies to Windows Media Servers.

Mark Wodrich, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-076: Windows Media Components: Part 2 of 2

swiblog — Tue, 09 Dec 2008 18:07:00 GMT

In this part, we would like to talk more about CVE-2008-3010: ISATAP vulnerability in Windows Media components. As described in the bulletin MS08-076, Windows Media components (Windows Media Player, Windows Media Format Runtime, and Windows Media Services) treat an ISATAP server address as an intranet zone address, and thus may leak NTLM credentials.

There are two different scenarios: the client side and the server side.

The client side scenario is simple. It relates to Windows Media Player (WMP) or any client applications that build upon the Windows Media Foundation SDK or Windows Media Format SDK. For example, when a user uses WMP to open ISATAP URLs addresses, WMP might leak NTLM credentials to internet. Please note here the term client side scenario does not mean that the OS needs to be a client OS. For example, a user could still use WMP in Windows Server 2008 and hit this issue.

It should be noted that there is a workaround for the client side scenario: modifying the Access Control List (ACL) for WMNetMgr.dll. This was not listed in the bulletin as it only applies to the client side scenario and not the server side scenario. The details are as follow:

For Windows XP, run the following command from an administrator command prompt:

for /F "tokens=*" %G IN ('dir /b /s %windir%\WMNetMgr.dll') DO cacls %G /E /R everyone

For Windows Vista and Windows Server 2008, run the following commands from an elevated administrator command prompt:

for /F "tokens=*" %G IN ('dir /b /s %windir%\WMNetMgr.dll') DO takeown /F %G && icacls %G /deny everyone:(F)

WMNetMgr.dll handles network connections. Thus the impact of this workaround is that WMP or other client applications may not be able to connect to any servers. Local media playback would still be fine.

The server side scenario is more complex and it relates to Windows Media Services (WMS). Even though servers don't typically send out NTLM credentials, there are scenarios where a Windows Media server is vulnerable. For example, suppose a user buys a streaming service and has an ISP’s WMS pull contents from his/her WMS for distribution on the content distribution network. In this situation, the ISP's server can perform an NTLM authentication to the user's server. To see how this works, consider the following diagram:

In the above diagram, the “edge” server acts as a client to the “origin” server. Therefore, the “edge” server’s credential may be leaked by WMS to the “origin” server, which could be controlled by an attacker. While the above setup may not be the common scenario, a possibility exists for this to occur thus we fixed WMS to make sure it classifies ISATAP address in the right zone.

Chengyun, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-075: Reducing attack surface by turning off protocol handlers

swiblog — Tue, 09 Dec 2008 18:06:00 GMT

Today Microsoft released a security update, MS08-075, that fixes a vulnerability in Windows Explorer in Vista and Server 2008 that was exposed through the search-ms protocol handler. This is a remote unauthenticated vulnerability that requires user interaction, so we wanted to give you a bit more information about protocol handlers and how you can reduce your attack surface by turning off any protocol handlers you don’t intend to use.

Quick introduction to protocol handlers

A protocol handler is a way to extend the functionality of your web browser. The well known mailto:// protocol is a great example. Instead of the familiar http:// or https:// protocols, mailto:// links start your e-mail application and tell it to create a new e-mail message to a particular e-mail address, and optionally with a particular subject.

You can see how the mailto:// protocol handler is associated to your e-mail application on your computer by examining the registry key HKEY_CLASSES_ROOT\mailto\shell\open\command. In the default value of that registry key you will see the command line that is executed when you click on a mailto:// link, or when a web page references mailto:// in a URL that is automatically retrieved, like in the src value of an <iframe>. The %1 value in the registry key is replaced with the rest of the URL that follows the ://.

If the application that is associated with a protocol contains a vulnerability that can be triggered by the data passed to it on the command line, this can be a serious attack vector. A malicious web page could pass specially crafted data to that application as soon as you visit the web page, by putting a URL containing the vulnerable protocol in something like the src value of an <iframe>.

If you use Vista or Server 2008, and you have User Account Control and Protected Mode Internet Explorer turned on (the default) , then Internet Explorer 7 provides protection against this attack by warning the user before processing a protocol handler by displaying a dialog like this one:

There are two different ways to add a protocol handler to Internet Explorer. One is by associating a protocol (e.g. search-ms://) with an application, where the remaining portion of the URL is passed as a command line argument. That is the method we discuss in this post. There is another method for registering a CLSID with a protocol which involves writing code that implements specific interfaces. We are not covering these handlers in this blog post, but you can read more about them here: http://msdn.microsoft.com/en-us/library/aa767916(VS.85).aspx

A quick note about PowerShell

Since protocol handlers are configured in the registry, PowerShell is a great choice for working with them. In this post we provide several PowerShell scripts to help you work with protocol handlers. It’s important to note that by default, PowerShell won’t let you run scripts. For more information on this policy and for information how to change it refer to: http://technet.microsoft.com/en-us/library/cc764242.aspx.

Warning: If you do modify your execution policy, it may be easier to unintentionally execute a malicious PowerShell script. If you alter your execution policy to run these scripts, the safest option is to restore the execution policy to the default “Restricted” value once they have completed.

How to enumerate all of the protocol handlers on your system

To do this, look for all of the subkeys of HKEY_CLASSES_ROOT that have an empty string value named “URL Protocol” and a subkey structure of “shell\open\command”. Here is our script to do just that, and return the results to you in a hash table (name, value pairs):

$Results = @{}

foreach ($Key in Get-ChildItem Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT)

{

$Path = $Key.PSPath + '\shell\open\command'

$HasURLProtocol = $Key.Property -contains 'URL Protocol'

if (($HasURLProtocol) -and (Test-Path $Path))

{

$CommandKey = Get-Item $Path

$Results.Add($Key.Name.SubString($Key.Name.IndexOf('\') + 1), $CommandKey.GetValue(''))

}

$Results

How to enable or disable a protocol handler

To disable a protocol handler, our PowerShell script (attached at the end of this post) removes the “URL Protocol” string from the registry key and puts a “Disabled URL Protocol” string in its place, so we know that we purposefully disabled it. We have also included a script to reverse the process, re-enabling the protocol handler again.

Related Posts

Conclusion

If you want to reduce your attack surface (your exposure to possible future vulnerabilities), you can use this information and these scripts to disable protocol handlers that you don’t need to use. We hope that you found this post helpful in defending your systems!

Kevin Brown, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

MS08-068: SMB credential reflection defense

swiblog — Tue, 11 Nov 2008 18:40:00 GMT

Today Microsoft released a security update, MS08-068, which addresses an NTLM reflection vulnerability in the SMB protocol. The vulnerability is rated Important on most operating systems, except Vista and Windows Server 2008 where it has a rating of Moderate. This blog post is intended to explain why the issue is less severe on Vista and Windows Server 2008, and provide some additional details to help people determine the risk they face in their environment.

This vulnerability allows an attacker to redirect an incoming SMB connection back to the machine it came from and then access the victim machine using the victim’s own credentials. (Hence the term “credential reflection”). In typical Windows XP configurations where SMB sharing is enabled and the user is a member of the Administrators group, this allows the attacker to easily take over the machine. Public tools, including a Metasploit module, are available to perform this attack.

Typical attack vectors for this vulnerability will leverage HTML either via a web browser or e-mail. Resources within the HTML document (such as IMG tags) can be used to reference a file on the attacker’s machine, and these file are then retrieved using the SMB protocol. The attacker’s machine prompts the victim for credentials and then reflects these credentials to the victim’s machine, gaining access. In cases where the attacker is on the same network as the victim, even “trusted” websites can be leveraged to perform this attack – since network data can be modified before the victim receives it.

What happens when this attack is performed against a Vista or Windows Server 2008 machine? While both Vista and WS08 are vulnerable to this attack, and the credential reflection can succeed, several other factors mitigate the impact of this attack:

The first big difference between Vista and Windows Server 2008 and earlier versions of Windows is that File and Print Sharing is not enabled by default. A user must first enable File and Print sharing (which also enables an exception in the Windows Firewall) in order to be vulnerable to this attack.
In non-domain environments, the default system shares (admin$, c$) are not accessible remotely by admin users, even if File and Print Sharing is enabled and the Windows Firewall allows inbound connections. (See KB 951016 for more details).

Here is an example of connecting to a Vista machine, authenticating as a user that is a member of the Administrators group, and still not being able to access admin$ and c$:
```
C:\> net use \\10.10.10.1\ipc$
The password or user name is invalid for \\10.10.10.1\ipc$.

Enter the user name for '10.10.10.1': swi
Enter the password for 10.10.10.1:
The command completed successfully.


C:\> dir \\10.10.10.1\admin$
Access is denied.

C:\> dir \\10.10.10.1\c$
Access is denied.
```
In domain environments, if a user is logged on using a domain account which is a member of the local machine’s Administrator account, then the default system shares (admin$ and c$) will be accessible to them. (See KB 951016 again for details).

In the context of this vulnerability, a domain account with local Administrator permissions can successfully be used in a reflection attack, and the attacker will be able to connect back to the victim and access the admin$ and c$ shares. However, due to UAC and integrity levels, the attacker will connect back with the same integrity level as the victim. In most cases this will be Low or Medium integrity level (for non-elevated programs). Under Low and Medium integrity, the attacker would have read permissions (at most) to the admin$ folder. This means they would not be able to add new binaries or overwrite files in the system folder. They would also not be able to perform RPC operations that require High integrity (such as adding a service).

However, an attacker would be able to write to locations under the victim’s user folder, such as the Startup folder or Desktop. (Any other folder that the user has write permissions would also be vulnerable under a reflection attack). The Startup folder is a valuable target for an attacker. Although for non-admin users, the files placed here will run with non-admin rights.
The Windows firewall will protect against this attack when the network profile is “Public”. Only the “Private” network profile will allow incoming SMB connections by default. People using public networks such as WiFi hot-spots will most likely be using the “Public” profile and therefore be protected.
Customers behind NATs and edge firewalls are not vulnerable to attack from machines outside the firewall, since inbound SMB is not enabled in default configurations.

It should be noted that while the second point above is a real mitigation, there could still be non-default shares that are available on the machine that could be leveraged by an attacker and result in the target being compromised. If a user has made any shares available on their machine, then they are at increased risk.

In terms of general mitigations, the bulletin mentions several options. In almost all cases the greatest risk comes from machines on the internal network. It is still a good idea to block outbound SMB traffic, but if an attacker is already within the perimeter (or the user is on an untrusted network such as a public WiFi hot-spot), there are mitigations which fall into these categories:

Disable File and Print sharing (assuming it is not needed on user’s machines).
Block inbound SMB connections using the Windows Firewall
Enable IPSec and require it on inbound SMB connections.
Enable SMB message signing. This can be enabled on select “high value” servers, or on all machines. (Note that there may be a substantial performance impact)

- Mark Wodrich, SVRD Blogger

*Postings are provided "AS IS" with no warranties, and confers no rights.*

Most common questions that we've been asked regarding MS08-067

swiblog — Sat, 25 Oct 2008 19:27:00 GMT

Since the release we have received several great questions regarding MS08-067 (http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx), thus we decided to compile answers for them. We still want to encourage everyone to apply the update.

Can the vulnerability be reached through RPC over HTTP?

No, the vulnerability cannot be reached through RPC over HTTP. RPC over HTTP is an end-to-end protocol that has three roles: client, proxy and server. To be clear, this is different from standard RPC, and the two protocols do not interoperate. Moreover, the only way to hit the vulnerable code is through named pipes, so the Interface security callback will drop the connection when connecting through TCP/IP.

Using Outlook to connect to an Exchange server to access e-mail is a common scenario that uses RPC over HTTP; since the RPC over HTTP proxy is used the Exchange server is not exposed to external attacks.

Further information about RPC over HTTP:

http://msdn.microsoft.com/en-us/library/aa375384.aspx

Further information about using Exchange with RPC over HTTP:

http://technet.microsoft.com/en-us/library/aa996072(EXCHG.65).aspx

What type of protections does ISA provide against this vulnerability?

The ISA and TMG RPC filter only recognizes RPC traffic that begins on the RPC End-Point Mapper (TCP:135). Since MS08-067 attacks are carried within CIFS (TCP:445) or NetBIOS (TCP:139) connections, they are not visible to the ISA or TMG RPC filter.
By default, ISA Server and TMG do not allow RPC, NetBIOS or SMB traffic from the external network.
By default, ISA 2000 allows all traffic unfiltered from the LAT (internal network) to the local host. The update should be applied to any ISA 2000 deployment immediately.
By default, ISA 2004, 2006 and TMG do not allow SMB, NetBIOS Session or RPC to the local machine except from remote management hosts, array members and Content Storage Servers (CSS). Since compromised CSS and remote management hosts may pose a threat to the ISA or TMG server, they should have the update applied immediately.
If you have changed ISA or TMG policies to allow SMB or NetBIOS traffic to the local host (such as for a Branch Office scenario), you should apply the update to your ISA or TMG server immediately.

Can an anonymous user reach the vulnerable code if the “restrict anonymous named pipes” group policy setting is used?

There are two different behaviors depending on the platform version.

Unfortunately the Windows XP SP2 and Windows Server 2003 group policy setting “Network Access: Named pipes that can be accessed anonymously” (see http://technet.microsoft.com/en-us/library/cc785123.aspx for more information) will not block anonymous connections to the browser named pipe. The vulnerable code can still be reached since by default, connections to this named pipe will be allowed regardless of the setting. In short, even if “browser” is removed from this list, the named pipe can still be reached anonymously.

In Windows Vista and Windows Server 2008 this behavior was changed and the setting takes effect when the browser named pipe is removed and the system is restarted.

Would sharing files and/or printers via Terminal Server or Remote Desktop Connection expose the vulnerability?

No, Terminal Server and Remote Desktop Connection do redirection using virtual channels embedded inside the RDP protocol. Moreover, Terminal Server does not open ports 139 or 445.

We would like to thank the engineers who helped provide definitive answers to these technical questions:

- Bruce Dang, Fermin J. Serna, Damian Hasse, Andrew Roths and Jonathan Ness from the SVRD team

- Tassaduq Basu, Kamen Moutafov from the Windows Networking Team

- Scott Field from the Windows Security Architecture Team

- Jim Harrison from the ISA Team

- Costin Hagiu from the RDP Team

- David Kruse from the Core File System Team

Posting is provided "AS IS" with no warranties, and confers no rights.