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.

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.

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:

1. Secure Socket Layer (SSL) or Transport Layer Security (TLS)
2. Secure E-mail (such as S/MIME)
3. 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:

1. Start the Certificates MMC snap-in
1. Click on the Start button and enter mmc.exe into the Start Search field
2. From the File menu, select Add / Remove Snap-in…
3. Select the Certificates snap-in on the left and click Add
4. Select Computer account, click Next, then click Finish to complete the wizard
5. Click OK to dismiss the dialog
2. Configure the snap-in to show Physical Certificate Stores
1. Select the Certificates (Local Computer) node
2. From the View menu, select Options…
3. Check the Physical certificate stores checkbox, then click OK
3. Select the public commercial root CA you want to configure to use with a custom OCSP responder
1. Select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Third Party -> Certificates node
2. Select the root CA
4. Move the root CA certificate to the Registry node
1. Right-click on the root CA certificate
2. Select Cut
3. Select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Third Party -> Certificates -> Registry -> Certificates node
4. From the Action menu, select Paste
5. Configure the custom OCSP responder location with the root CA certificate
1. Right-click on the root CA certificate
2. Select Properties
3. Select the OCSP tab
4. Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
5. Click OK

Steps to Configure Custom OCSP from Group Policy

1. Select the Group Policy Object where certificate configuration will be stored
2. From the Group Policy Editor, select the Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities node
3. 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
1. Right click on the Trusted Root Certification Authorities node and select Import… to add the root CA certificate
2. Click Next
3. Enter the file name of the root CA certificate, then click Next
4. Click Next, then Finish to complete the wizard
4. Configure the custom OCSP responder location with the root CA certificate
1. Right-click on the root CA certificate
2. Select Properties
3. Select the OCSP tab
4. Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
5. 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:

1. On the Tools menu, click Internet Options, and then click the Advanced tab.
2. 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.

1. Click on the lock icon in the address bar:
   
2. The below window will open up:
   
3. Click “View certificates”
4. The below window will open up: 
   
5. 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.

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.*

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:

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.*

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.

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

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.*

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.

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.*

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

• Additional Details and Background on Security Advisory 943521
• MS08-015: Protocol Handler and its Default Security Zone
• Enriching the Web Safely: How to Create Application Protocol Handlers

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.*

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.*