Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

September, 2010

  • The Enhanced Mitigation Experience Toolkit 2.0 is Now Available

    Today we are pleased to announce the availability of the Enhanced Mitigation Experience Toolkit (EMET) version 2.0.  Users can click here to download the tool free of charge. 

      

    For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications.  This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited.  By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products.  In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.

     

    Below is a screenshot of the tool, which features a brand new interface as part of this release.

     

     

    The installation package for EMET v2.0 includes a detailed user guide.  A copy can also be found at the bottom of this post.  It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of.  Please be sure to read the guide before using the tool.

     

    Additionally, the BlueHat team has helped us put together a training video on EMET v2.0.  The video gives an even more in-depth look at some of the security mitigations offered by the tool.  You can watch the video online here.

     

    To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release.  That post also gives a rundown of all the changes that are new with the 2.0 version.

     

    As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

     

    - Andrew Roths and Fermin J. Serna

  • Use EMET 2.0 to block Adobe Reader and Acrobat 0-day exploit

    Background on the exploit

    As you probably know there is a new exploit in the wild for Adobe Reader and Acrobat. This particular exploit is using the Return Oriented Programming (ROP) exploit technique in order to bypass Data Execution Prevention (DEP).

     

    Normally Address Space Layout Randomization (ASLR) would help prevent successful exploitation.  However, this product ships with a DLL (icucnv36.dll) that doesn’t have ASLR turned on.  Without ASLR, this DLL is always going to be loaded at a predictable address and can be leverage by an exploit.  In the below screenshot we use Process Explorer to show what this looks like.

     

      

     

    Find more information on the importance of enabling ASLR in your products at http://msdn.microsoft.com/en-us/library/bb430720.aspx.

     

    How EMET 2.0 blocks the exploit

    The good news is that if you have the Enhanced Mitigation Experience Toolkit 2.0 (EMET) enabled for AcroRd32.exe, it blocks this exploit.  This is happens thanks to two different mitigations:

     

    Mandatory ASLR: On Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 this mitigation will force the relocation of non ASLR-aware DLLs. The exploit will then fail to use ROP successfully since it is expecting the DLL to be at a predictable location.  Take a look at the below screenshot from Process Explorer to see what this looks like.

     

     

     

    Export Address Table Access Filtering (EAF): The exploit is also blocked by the EAF mitigation.  This is important for Windows XP and Windows Server 2003 because they do not support mandatory ASLR. With this mitigation in place EMET will detect the shellcode accessing the EAT of Kernel32.dll trying to resolve some APIs (e.g. LoadLibraryA). EMET will then raise a STATUS_STACK_BUFFER_OVERRUN unhandled exception and the program will be terminated before the shellcode does anything bad.

     

    How to enable EMET for Adobe Reader

    In order to enable EMET for Adobe Reader and Acrobat you have to install EMET and run the following simple command line as an Administrator. Please note the path to the Adobe Reader and Acrobat could be different in your system (especially if you are not using a 64 bit system).

     

    C:\Program Files (x86)\EMET>emet_conf.exe --add "c:\program files (x86)\Adobe\Reader 9.0\Reader\acrord32.exe"

     

    The changes you have made may require restarting one or more applications

     

    We have been working closely with the Adobe Secure Software Engineering Team (ASSET) on recommending EMET as a mitigation option. Due to the time-sensitive nature of this issue, we have only been able to perform a cursory look at the functional compatibility of this mitigation. Keep in mind, Adobe Reader and Acrobat support broad feature sets, which require extensive testing to fully cover all functionality. Therefore, we recommend that you also test the mitigation in your environment to minimize any impact on your workflows.  Please refer to Adobe's guidance regarding EMET under the Mitigations section of their Security Advisory.

     

    New updates to EMET 2.0

    Also, last week we made available version 2.0 of EMET on this blog post. We would like to thank all the people that gave it a try it and sent us feedback. Today we are releasing an updated version of EMET (2.0.0.1) with some bug fixes.  The download for the old version has been replaced with the new version and can be obtained here.

    The following are the changes you can find in the new version:

    • The DEP mitigation is now enabled with the ATL thunk emulation for better compatibility.
    • The GUI does a better job of handling situations where a process tries to block it from determining if DEP enabled or disabled for that process. Previously, the GUI crashed in certain scenarios with programs such as Antivirus and Intrusion Prevention Systems.
    • EMET now correctly protects applications launched with 8.3 filenames.
    • Enhancements have been made to EMET running on Windows XP to support more 3rd party applications. Previously, there where situations where the protections could fail to protect certain applications.

     

    As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

     

    - Fermin J. Serna and Andrew Roths

      

    Updated September 14, 2010 - In certain Windows XP configurations, users have encountered problems where several applications configured for use with EMET do not get protected by EMET.  When this happens you will see that the process does not have a check mark under the "Running EMET" column of the main application.  If you have encountered this issue, please download the latest version of the tool which addresses this problem.

  • Assessing the risk of the September security updates

    Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five having a maximum severity rating of Important. Furthermore, six of the nine bulletins either do not affect the latest version of our products or affect them with reduced severity. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Index Likely first 30 days impact Platform mitigations and key notes
    MS10-061
    (Spooler)
    Windows XP systems sharing a printer compromised via over-the-network print request. Critical 1 Currently being exploited by Stuxnet malware. Windows Vista and later platforms not vulnerable by default, even if sharing a printer. For more information on risk-by-platform, see the SRD blog post.
    MS10-062
    (MPEG-4)
    Victim browses to a malicious webpage or opens a malicious AVI movie with Media Player. Critical 1 Likely to see an exploit released able to exploit the vulnerability in MPEG-4 codec. Code execution less likely on Windows Vista and Windows 7 due to additional heap mitigations.
    MS10-064
    (Outlook)
    Victim opens or previews a malicious RTF email if using Outlook in “Online Mode” Critical 2 Will be difficult to build a reliable exploit. Unlikely to see widespread exploitation due to mitigating factors. Office 2003 and Office 2007 not vulnerable in default “Cached Exchange” mode.
    MS10-063
    (OpenType font engine)
    Victim browses to a malicious webpage or opens a malicious Office document. Critical 2 Difficult to build a reliable exploit for this vulnerability, may or may not see exploit developed in first 30 days.  
    MS10-065
    (IIS)
    IIS servers using the FastCGI handler targeted with malicious HTTP requests. Important 1 Likely to see proof-of-concept code developed for FastCGI vulnerability. Less likely to result in reliable code execution. See SRD blog post for more about exploitability.

    Only IIS 5.1 running on Windows XP is vulnerable to remote code execution in a default configuration.

    However, administrators of internet-facing IIS servers with FastCGI enabled strongly encouraged to apply the update as soon as possible.

    MS10-068
    (LSASS)
    Authenticated attacker sends an LDAP request over the network to an Active Directory server. Important 1 Likely to see exploit code developed.  
    MS10-066
    (RPC)
    Victim makes an RPC connection to a malicious RPC server. Server sends a malicious response that causes memory corruption on victim client. Important 1 Likely to see proof-of-concept code developed for this vulnerability. Attacker in most cases will need to be on same network as victim.
    MS10-067
    (Wordpad)
    Victim opens a malicious .doc file with Wordpad. Important 1 Likely to see exploit code developed. Less likely to see wide-spread exploitation as many systems open .doc files with Microsoft Word which is not vulnerable.  
    MS10-069
    (CSRSS)
    Attacker logged-on to a system with Far East locale exploits this vulnerability locally to elevate privileges. Important 1 Likely to see exploit code developed. Only Japanese, Korean, and Chinese locales affected.

    Thanks to the whole MSRC Engineering for their work on this month’s cases.

    - Jonathan Ness, MSRC Engineering

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

  • MS10-061: Printer Spooler Vulnerability

    This morning we released security bulletin MS10-061 to address an issue in the Windows print spooler. In this blog post, we’d like to provide additional detail about the specific configurations of Windows that are vulnerable to this issue and more background on its connection to the Stuxnet malware.

    Vulnerable configurations

    Depending on the configuration, the vulnerability allows a local or remote user to write arbitrary files to %SYSTEM%. This is happens because the spooler does not properly impersonate the user under certain conditions. Fortunately, only a subset of Windows machines are remotely vulnerable, as demonstrated in the chart below.

    The list of these older printers can be found in KB 2347290.

    Password-based sharing is enabled by default on Windows 7, Vista, Windows Server 2008 R2 and Windows Server 2008 and later platforms, making the default scenario not vulnerable on those platforms. The “Users” group is also not a member of the local “Guests” group by default on these platforms.

    A local user can also exploit this vulnerability to gain SYSTEM privilege. In order to do this, the user would need to be able to add a printer; on Vista+, normal users can add printers by default.

    In the wild?

    This particular vulnerability is one of several used by the Stuxnet malware to escalate privilege and/or propagate across the network. When Stuxnet starts up, it enumerates all printer shares on the network and tries to connect to them using the “Guest” account; if it is successful, it will call various APIs to copy itself to the remote systems and execute it.

    - Mark Wodrich and Bruce Dang, MSRC Engineering

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

  • MS10-065: Exploitability of the IIS FastCGI request header vulnerability

    This month, Microsoft released an update for IIS that addresses three vulnerabilities. The blog post focuses on one of these: the Request Header Buffer Overflow Vulnerability (CVE-2010-2730), which affects IIS version 7.5 and has a maximum security impact of Remote Code Execution (RCE). Below we provide more details on the vulnerability and the potential for reliable remote code execution, to assist with assessing risk and prioritizing deployment of the update. We also aim to allay fears of malware utilizing this vulnerability to spread across networks.

    Vulnerability details

    CVE-2010-2730 affects Windows servers running IIS with a non-default configuration. If the FastCGI handler is enabled (e.g. to support 3rd-party server-side scripting languages), the system could be vulnerable to a heap buffer overrun when handling HTTP request headers.

    A successful exploit would allow a remote attacker to execute code in the context of the IIS worker process.

    For more details, refer to Security Bulletin MS10-065.

    Exploitability details

    While a successful exploit leading to RCE is possible in theory, there are some technical factors that make it less likely. In practice it is more likely that attacks will lead to a crash of the IIS worker process and a denial-of-service (DoS) condition when the service reaches its restart limit. Let’s look into the factors that hamper exploitation:

    The vulnerable code processes HTTP request headers from the client - these are under the attacker’s full control. An initial buffer is allocated on the heap and used to store the request header names and values, and is re-sized as needed, until all the client’s headers have been processed.

    At this point, no buffer overrun has occurred. The code then proceeds to copy pre-defined parameters to the buffer, assuming that enough space has been reserved by the earlier code. In some cases this will lead to a buffer overrun. The data written to the buffer is of the following format:

    Name : string pointer
    NameLen : integer
    Value : string pointer
    ValueLen : integer
    

    At the point the buffer overrun occurs, only the Name and NameLen fields are populated (non-zero) – the code will retrieve values for each of these parameters once they have been appended to the buffer.

    The important thing to note is that none of the data that is written beyond the end of the buffer is under the attacker’s control. The Name fields will point to string data in the IIS worker process. The pointer values will be unpredictable due to ASLR. The NameLen fields will be predictable low-value integers, but will not be of much use to an attacker.

    Once the values for these parameters have been filled in, the Value field will point to string data and ValueLen will also be a low-value integer. (The contents of the strings may be attacker-controlled).

    Conclusion

    In order to obtain a reliable RCE exploit, the attacker would need to be able to predict or control the values outlined above, and also control the layout of the heap buffers to some extent. Due to the lack of control or predictability of the data written beyond the end of the buffer, this vulnerability will be tricky to impossible to exploit reliably.

    For this reason, attempts to exploit this vulnerability are more likely to result in a DoS than RCE.

    I would like to thank Nazim Lala, Bruce Dang and Charles Weidner for their work on this issue.

    - Mark Wodrich, MSRC Engineering

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

  • Understanding the ASP.NET Vulnerability

    Our recent advisory describes an ASP.NET vulnerability which was recently publicly disclosed. This blog post will give you more information about the vulnerability and the workaround. It will also provide a script which will help you detect ASP.NET applications on your server that are in a vulnerable configuration.

    The Impact of the Vulnerability

    ASP.Net uses encryption to hide sensitive data and protect it from tampering by the client. However, a vulnerability in the ASP.Net encryption implementation can allow an attacker to decrypt and tamper with this data.

    But what can the attacker do with this capability? Part of the answer depends on the ASP.Net application being attacked. For example, if the ASP.Net application stores sensitive information, such as passwords or database connection strings, in the ViewState object this data could be compromised. The ViewState object is encrypted and sent to the client in a hidden form variable, so it is a possible target of this attack.

    If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file in the ASP.Net application which the worker process has access to will be returned to the attacker.

    How the Vulnerability Works

    To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.Net which acts as a padding oracle. This allows an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server.

    By making many requests the attacker can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.

    The Workaround - Silencing the Oracle

    The workaround for this vulnerability is to use the customErrors feature of ASP.NET to configure applications to return the same error page regardless of the error encountered on the server.

    By following the steps in the advisory to map all error messages to a single error page, you make it difficult for the attacker to distinguish between the different types of errors, effectively limiting access to the oracle.

    How to Detect Vulnerable ASP.Net Applications

    Some ASP.Net applications may already be configured to return the same error page for all server errors. To detect ASP.Net applications that are not configured this way and need to have the workaround applied to them, use the following script:

    Note: After installing the MS10-070 security update, the workaround is no longer necessary and there is no need to run this script.

    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    '  DetectCustomErrorsDisabled.vbs Script
    '  Version 3.1
    '  
    '  This script will help detect vulnerable configuration for the Padding Oracle 
    '  ASP.Net vulnerability documented in MS advisory 2416728.
    '  
    '  http://www.microsoft.com/technet/security/advisory/2416728.mspx
    '  
    '  Usage: 
    '      cscript DetectCustomErrorsDisabled.vbs [RemoteServerName] 
    '
    '  NOTE: THIS SCRIPT USES THE FILESYSTEM AND SHELL OBJECT AND SHOULD BE
    '       RUN AS AN ADMINISTRATOR
    '
    '  The script works by enumerating all web.config and assessing if the 
    '  side-channel leak for the padding oracle vulnerability is mitigated by the 
    '  use of homogenizing custom error responses from ASP.Net applications. 
    '  
    '  Note: On IIS 7 servers, this script requires IIS6 compatibility mode to be
    '  installed.
    '  
    '  More information on: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
    '  
    '  Version History:
    '  1.0 - Initial version
    '  2.0 - Added additional checks for app/site root config
    '  3.0 - Added error validation for XML parsing and path checks
    '  3.1 - Added check for missing root web.config
    ' 
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    OPTION EXPLICIT
    ON ERROR RESUME NEXT
    DIM strServer
    DIM objWebService, objWebServer, objDir, objFileSys
    DIM physicalPath, dir, xmlDoc, nodeList, node, ret
    DIM configFile, configFilePath, configLine
    DIM childNodes, ErrPage500, ErrPage404, errFound
    DIM index, errCount
    
    strServer = "localhost"
    
    
    ' Parse command line input
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    IF WScript.Arguments.Length=1 THEN
        strServer = WScript.Arguments( 0 )
    END IF
    
    IF WScript.Arguments.Length>1 THEN
        WScript.Echo "Illegal number of arguments"
        WScript.Echo "Usage: cscript.exe DetectCustomErrorsDisabled.vbs [RemoteServerName]"
        WScript.Quit( 1 )
    END IF
    
    ' Initializations
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SET objFileSys = CreateObject("Scripting.FileSystemObject")
    SET objWebService = GetObject( "IIS://" & strServer & "/W3SVC" )
    IF Err <> 0 THEN
        WScript.Echo "Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed."
        WScript.Quit (1)
    END IF
    SET xmlDoc = CreateObject("Microsoft.XMLDOM")
    
    IF IsNull(objFileSys) THEN
        WScript.Echo "Failed to create FileSystemObject. Please run script as Admin."
        WScript.Quit (1)
    END IF
    
    IF IsNull(objWebService) THEN
        WScript.Echo "Failed to connect to IIS ADSI provider. Make sure you have IIS6 "_
        + "management compatibility role service installed."
        WScript.Quit (1)
    END IF
    
    WScript.Echo("Enumerating possible paths with ASP.Net configuration that have" _
        +" custom errors turned off.")    
    WScript.Echo ("")    
    
    
    ' Search web server for unsafe configuration
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    FindASPNetConfig(objWebService)
    
    
    ' Search all paths on web server for possible web.config  files.
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SUB FindASPNetConfig(WebService)
    
        FOR EACH objWebServer IN WebService
            IF objWebserver.Class = "IIsWebServer" THEN
                EnumDirectories(objWebServer)
            END IF
        NEXT
        
    END SUB
    
    ' Recursively go through vdirs and webdirs
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SUB EnumDirectories(objDir)
        
        DIM objSubDir
        ' The first call to this is from IIsWebServer, so we can skip that
        FOR EACH objSubDir IN objDir
            IF (objSubDir.Class = "IIsWebVirtualDir") THEN
                GetPhysicalPaths(objSubDir)            
                EnumDirectories(objSubDir)          
            END IF
        NEXT	
        
    END SUB
    
    
    ' Get physical paths for web and virtual directories
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SUB GetPhysicalPaths(objDir)
        
        physicalPath = objDir.Path
        CALL EnumWebConfig(physicalPath,1)
    
    END SUB
    
    
    ' Recursively search for web.config files.
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SUB EnumWebConfig(Path,IsRoot)
    
        IF NOT objFileSys.FolderExists(Path) THEN 
            IF IsRoot THEN
                ' WScript.Echo Path & ": Site's disk path is incorrect and root web.config does not exist"
                WScript.Echo Path & ": ** Vulnerable configuration found **"
            END IF
            EXIT SUB
        END IF
    
        configFilePath = Path & "\web.config"
        IF objFileSys.FileExists(configFilePath) THEN 
            CALL ProcessWebConfig(configFilePath,IsRoot)
        ELSEIF IsRoot = 1 THEN
            ' WScript.Echo Path & ": Site or app root web.config does not exist"
             WScript.Echo Path & ": ** Vulnerable configuration found **"
        END IF
        
        FOR EACH dir IN objFileSys.GetFolder(Path).SubFolders
            CALL EnumWebConfig(dir.Path,0)
        NEXT
    
    END SUB
    
    ' Skip known identities that will have Write access by default
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    SUB ProcessWebConfig(Path,IsRoot)
        xmlDoc.async="false"
        xmlDoc.load(Path)
        errFound = 0
        SET nodeList = xmlDoc.getElementsByTagName("customErrors")
    
        IF IsRoot = 1 AND nodeList.length = 0 THEN
            ' Root web.config does not set defaultRedirect, so this config should 
            ' have a customErrors section present with customErrors turned on and a 
            ' defaultRedirect present. Else this is a vulnerable configuration.
    	
            ' WScript.Echo path & ": Root web.config must have customErrors with defaultRedirect defined"
    
            errFound = errFound + 1
    
        ELSEIF IsRoot = 1 THEN
            ret = CheckRootCustomErrorsSection(nodeList, Path)
            errFound = errFound + ret
        END IF
    
        DIM count
    
        FOR count=0 TO nodeList.length-1
            ret = CheckCustomErrorsDisabled(nodeList.Item(count), Path)
    	    errFound = errFound + ret
            ret = CheckCustomErrorsAreHomogenous(nodeList.Item(count), Path)
    	    errFound = errFound + ret
        NEXT
                
        IF errFound > 0 THEN
            WScript.Echo Path & ": ** Vulnerable configuration found **"
        ELSE
            WScript.Echo Path & ": ok"
        END IF
    END SUB
    
    
    FUNCTION CheckRootCustomErrorsSection(xmlnodelist, path)
    
        errCount = 0
        FOR index=0 TO xmlnodeList.length-1
            ret = CheckRootCustomErrorsDisabled(nodeList.Item(index), Path)
    	    errCount = errCount + ret
        NEXT
    
        CheckRootCustomErrorsSection = errCount
    END FUNCTION
    
    
    FUNCTION CheckRootCustomErrorsDisabled(xmlnode, path)
        
        IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN
            ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml
            CheckRootCustomErrorsDisabled = 1
            EXIT FUNCTION
        ELSEIF IsNull(xmlnode.getAttribute("defaultRedirect")) THEN
            ' WScript.Echo path & ": defaultRedirect not set: " & xmlnode.xml
            CheckRootCustomErrorsDisabled = 1
            EXIT FUNCTION
        ELSE
            CheckRootCustomErrorsDisabled = 0
        END IF
        
    END FUNCTION
    
    
    FUNCTION CheckCustomErrorsDisabled(xmlnode, path)
        IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN
            ' Unsafe config
            ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml
            CheckCustomErrorsDisabled = 1
        ELSE
            CheckCustomErrorsDisabled = 0
        END IF
        
    END FUNCTION
    
    FUNCTION CheckCustomErrorsAreHomogenous(xmlnode, path)
        IF xmlnode.childNodes.length=0 AND len(xmlNode.getAttribute("defaultRedirect"))>0 THEN
    	    CheckCustomErrorsAreHomogenous = 0
            EXIT FUNCTION
        END IF
    
        SET childNodes = xmlnode.childNodes
    
        ErrPage404 = ""
        ErrPage500 = ""
    
        DIM count
        FOR count=0 TO childNodes.length-1
            CALL GetErrorPage(childNodes.Item(count))
        NEXT
    
        IF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") = 0 AND IsNull(xmlNode.getAttribute("defaultRedirect")) THEN
            ' Missing defaultRedirect in this case will cause config to be vulnerable
            'WScript.Echo path & ": missing defaulRedirect URL: " & xmlnode.xml
            CheckCustomErrorsAreHomogenous = 1
            EXIT FUNCTION
        ELSEIF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") <> 0 AND StrComp(ErrPage500, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN
            'WScript.Echo path & ": 500 and default error pages differ: " & xmlnode.xml
            CheckCustomErrorsAreHomogenous = 1
            EXIT FUNCTION
        ELSEIF StrComp(ErrPage500,"") = 0 AND StrComp(ErrPage404,"") <> 0 AND StrComp(ErrPage404, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN
            'WScript.Echo path & ": 404 and default error pages differ: " & xmlnode.xml
            CheckCustomErrorsAreHomogenous = 1
            EXIT FUNCTION
        ELSEIF StrComp(ErrPage404, ErrPage500) <> 0 THEN
            'WScript.Echo path & ": 404 and 500 error pages differ: " & xmlnode.xml
            CheckCustomErrorsAreHomogenous = 1
            EXIT FUNCTION
        ELSE 
            CheckCustomErrorsAreHomogenous = 0 
        END IF
    
    END FUNCTION
    
    SUB GetErrorPage(xmlnode)
        IF xmlnode.nodeType <> 1 THEN
            EXIT SUB
        ELSEIF IsNull(xmlnode.getAttribute("statusCode")) THEN
            'Do nothing.
        ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "500") = 0 THEN
            ErrPage500 = xmlnode.getAttribute("redirect")
        ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "404") = 0 THEN
            ErrPage404 = xmlnode.getAttribute("redirect")
        END IF
    
    END SUB
    
    

    Acknowledgements

    Many thanks to Levi Broderick, Nazim Lala, and Stefan Schackow for their contributions to this post.

    -Kevin Brown, MSRC Engineering

     

    Updated September 18, 2010

    Made several improvements to the included script to catch additional corner cases and provide additional error handling. Clarified that an attacker can only retrieve files from within the ASP.Net application.

    Updated September 21, 2010

    Updated the script to add a check for missing root web.config files, and attached a zip of the script to the post so it can be downloaded directly.

    Updated September 29, 2010

    Added a note clarifying that the workaround and the detection script are no longer necessary once the security update has been installed. The security update is now available - please see MS10-070 for more information.

  • Additional Information about the ASP.NET Vulnerability

    Over the past couple of days we’ve received some additional questions regarding the ASP.NET vulnerability. In this post we will answer some of the most common ones.

    Is My ASP.NET Site Affected By This Issue?

    Yes, all sites that use ASP.NET are affected by this vulnerability. You should follow the recommendations outlined in the advisory. The advisory includes a workaround that can help harden a server against attack. In our previous blog post we provided a script that can help you identify ASP.NET sites that could benefit from this hardening.

    Has My Site Been Attacked?

    The publicly disclosed exploit would cause the web server to generate thousands (or tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client. You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block potential attackers. The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks.

    Additionally, if your site has been attacked, you should see warnings in the application event log similar to:

    Event code: 3005
    Event message: An unhandled exception has occurred.
    Event time: 11/11/1111 11:11:11 AM
    Event time (UTC): 11/11/1111 11:11:11 AM
    Event ID: 28e71767f3484d1faa90026f0947e945
    Event sequence: 133482
    Event occurrence: 44273
    Event detail code: 0

    Application information:
    Application domain: c1db5830-1-129291000036654651
    Trust level: Full
    Application Virtual Path: /
    Application Path: C:\foo\TargetWebApplication\
    Machine name: FOO

    Process information:
    Process ID: 3784
    Process name: WebDev.WebServer40.exe
    Account name: foo

    Exception information:
    Exception type: CryptographicException
    Exception message: Padding is invalid and cannot be removed.

    The highlighted exception detail is the most important piece of information in the event log entry to look for. It is possible to hit this error while developing new ASP.NET website code, and it can happen in certain production environments. However, if it did not appear on your production servers until recently, it is possible that it indicates an attack. Verifying that the time of these exceptions corresponds to the large number of requests described above would increase the confidence that this entry was caused by an attack.

    -Kevin Brown, MSRC Engineering