Security Research & Defense

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

April, 2013

  • Defending Websites from XSS attacks with ModSecurity 2.7.3 and OWASP Core Rule Set 2.2.7

    Even though cross-site scripting vulnerabilities have a 15-year history, they remain a big problem in the web security space. According to our research, there are hundreds of new issues discovered each month, and at least a few of them are being used in high-severity attacks.

    The general problem of cross-site scripting has no easy solution. Yet, some of the existing mitigation techniques show high (over 95%) levels of efficiency in detection of real-life XSS attacks. One such solution is Internet Explorer’s XSS filter. As David Ross described in his blog posts, the core of the IE filter consist of a set of heuristics detecting common patterns of XSS attacks in URLs. Thanks to our collaboration with OWASP community, analogous set of rules is now available through OWASP ModSecurity Core Rule Set 2.2.7.

    The new rules are present at the end of the file: base_rules\modsecurity_crs_41_xss_attacks.conf. They are divided into non-volatile (15 rules) and volatile (11 rules) sets, marked accordingly:

    # non-volatile
    SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:<script.*?>)" "phase:2,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'8',accuracy:'8',id:'973315',capture,logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',t:none,t:htmlEntityDecode,t:compressWhiteSpace,block,msg:'IE XSS Filters - Attack Detected.',tag:'OWASP_CRS/WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{}-OWASP_CRS/WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

    In our practice, the non-volatile rules produce a very low number of false-positive hits, while the volatile ones tend to be susceptible to application-specific behavior. On most applications volatile rules also have a low false-positives ratio, but when a web application relies too much in its design on “suspicious” characters, selective disabling of specific volatile rules might be needed.

    Application of the XSS-catching heuristics on IIS server is very simple, since version 2.7.3 users can install ModSecurity IIS module using Web Platform Installer. Also, with the recent general-availability release, when using Windows Azure Virtual Machines one can easily automate installation of ModSecurity IIS over Remote PowerShell, for example, by extending the launching script from Michael Washam’s blog with this simple snippet:

    # Use native PowerShell Cmdlet to install ModSecurity IIS on the remote virtual machine
    Invoke-Command -ConnectionUri $uri.ToString() -Credential $credential -ScriptBlock {
    $msidir = $env:temp+"\modsecurityiis"
    md $msidir
    $file = $msidir+"\modsecurityiis.msi"
    $webclient = New-Object System.Net.WebClient
    msiexec /i $file /qb

    After installation, the default OWASP CRS IIS rules can be enabled for a selected website by adding to the web.config file, in system.webServer section:

    <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\owasp_crs\modsecurity_iis.conf" />

    This simple step should let web server administrators see a significant majority of XSS attempts and attacks launched on their websites.

    The releasing of ModSecurity IIS version was a major milestone for the ModSecurity web application firewall project. We also won some community awards and WAF comparison tests. It is good to look back on past accomplishments, but it is also important to look ahead. How can we make ModSecurity IIS better in the future?

    As part of this effort, the ModSecurity Team in SpiderLabs Research has developed a new user survey for 2013.

    Click here to take survey.

    If you are a user of ModSecurity IIS, I encourage you to take the survey as it will give us a better understanding of how ModSecurity IIS is being used, and also to get feedback on what we are doing well and what we need to improve.

    It is only 15 questions. As an added incentive, you can also enter your email address into a raffle to win a copy of Ryan Barnett’s new book: "The Web Application Defender's Cookbook: Battling Hackers and Protecting Users".

    Thanks for using ModSecurity IIS and for helping us to make it better!

    - Greg Wroblewski, SRD Blogger

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

  • Introducing EMET v4 Beta

    Great news!  Today we are proud to announce a beta release of the next version of the Enhanced Mitigation Experience Toolkit (EMET) – EMET 4.0.  Download it here:

    EMET is a free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution.  It does so by opt-ing in software to the latest security mitigation techniques.  The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an available update has not yet been applied.  We encourage you to test out the beta release by downloading and installing it, asking questions about the new features, and reporting any issues you find for us to address before the final release.  We plan to officially release EMET 4.0 on May 14, 2013.

    The feature set for this new version of the tool was inspired by our desire for EMET to be an effective mitigation layer for a wider variety of potential software exploit scenarios, to provide stronger protections against scenarios where EMET protection already exists, and to have a way to respond to 0day exploits as soon as possible.  Here are the highlights of the EMET 4.0 feature set:

    •        EMET 4.0 detects attacks leveraging suspicious SSL/TLS certificates
    •        EMET 4.0 strengthens existing mitigations and blocks known bypasses
    •        EMET 4.0 addresses known application compatibility issues with EMET 3.0
    •        EMET 4.0 enables an Early Warning Program for enterprise customers and for Microsoft
    •        EMET 4.0 allows customers to test mitigations with “Audit Mode”

    SSL/TLS Certificate Trust features

    EMET 4.0 allows users to configure a set of certificate pinning rules to validate digitally signed certificates (SSL/TLS certificates) while browsing with Internet Explorer. This option allows users to configure a set of rules able to match specific domains (through their SSL/TLS certificates) with the corresponding known Root Certificate Authority (RootCA) that issued the certificate. When EMET detects the variation of the issuing RootCA for a specific SSL certificate configured for a domain, it will report this anomaly as an indicator of a potential man-in-the-middle attack.

    Advanced users can also add exceptions for each pinning rule.  This will allow EMET to accept SSL/TLS certificates even if the pinning rule doesn’t match.  Exceptions are related to some properties of the RootCA certificate, such as key size, hashing algorithm, and issuer country.

    Strengthened mitigations, blocking bypasses

    We learned a great deal during the “Technical Preview” phase of EMET 3.5.  We saw researchers poking and presenting clever tricks to bypass EMET’s anti-ROP mitigations.  EMET 4.0 blocks these bypasses.  For example, instead of hooking and protecting only functions at the kernel32!VirtualAlloc layer of the call stack, EMET 4.0 will additional hook lower level functions such as kernelbase!VirtualAlloc and ntdll!NtAllocateVirtualMemory.  These “Deep Hooks” can be configured in EMET’s Advanced Configuration.  We have seen exploits attempt to evade EMET hooks by executing a copy of the hooked function prologue and then jumping to the function past the prologue.  With EMET 4.0’s “Anti detours” option enabled, common shellcode using this technique will be blocked.  Finally, EMET 4.0 also includes a mechanism to block calls to banned API’s.  For example, a recent presentation at CanSecWest 2013 presented a method of bypassing ASLR and DEP via ntdll!LdrHotPatchRoutine.  EMET 4.0’s “Banned API” feature blocks this technique.

    Application compatibility fixes

    Users of previous versions of EMET had encountered isolated compatibility issues when enabling mitigations on both Microsoft and third party software.  EMET 4.0 addresses all these known app-compat issues.  That list includes issues in the following areas:

    -          Internet Explorer 9 and the Snipping Tool

    -          Internet Explorer 8’s Managed Add-ons dialog

    -          Office software through SharePoint

    -          Access 2010 with certain mitigations enabled

    -          Internet Explorer 10 on Windows 8

    The EMET 4.0 installer also opts-in protection rules with certain mitigations disabled where we know a mitigation interacts poorly with certain software.  Examples include Photoshop, Office 2013’s Lync, GTalk, wmplayer, and Chrome.

    Early Warning Program for enterprise customers and for Microsoft

    When an exploitation attempt is detected and blocked by EMET, a set of information related to the attack is prepared with the Microsoft Error Reporting (MER) functionality.  For enterprise customers collecting error reports via tools like Microsoft Desktop Optimization Package or the Client Monitoring feature of System Center Operations Manager, these error reports can be triaged locally and used as an early warning program indicating possible attacks against the corporate network.  For organizations that typically send all error reports to Microsoft, this information will add to the set of indicators we use to hunt attacks in the wild, and will facilitate the remediation of issues with security updates before vulnerabilities become a large scale threat. The EMET Privacy Statement (available also via the main EMET window) includes more information about the type of data that will be sent in the error report via Microsoft Error Reporting.  The Early Warning Program is enabled by default for the EMET 4.0 Beta and can be disabled in the EMET UI or via the EMET command line component.  We are eager to hear customer feedback about this feature to help shape the Early Warning Program for the EMET 4.0 final release.

    Audit Mode

    When previous versions of EMET detected exploitation attempts, it would report the attack via the EMET agent and then terminate the program to block the attack.  For EMET 4.0, in response to customer feedback, we provided an option to configure EMET’s behavior when it detects an exploitation attempt.  The default option remains to terminate the application.  However, customers wanting to test EMET in a production environment can instead switch to “Audit Mode” to report the exploitation attempt but not terminate the process.  This setting is not applicable for all mitigations but we provide this option whenever possible.


    Other Improvements

    EMET 4.0 includes a bunch of other improvements.  The quantity of new features and volume of work put into this release is the reason we skipped the EMET 3.5 full release and jumped straight to EMET 4.0.  Please refer to the EMET 4.0 Beta Users Guide for the full set of features but here are several other highlights:

    -          EMET Notifier becomes EMET Agent, with new duties and functionalities

    -          More granular reporting options (tray icon, event log, both, or none)

    -          New default profiles for both mitigations and Certificate Trust

    -          Registry configuration to customize the EMET Agent’s messaging

    -          Optimized RopCheck for significantly better performance

    -          Numerous UI tweaks to make EMET easier to use

    -          Enable wildcard support when adding applications to be protected

    -          Allow processes to be protected even if they do not have .exe extension

    -          Switched to .NET Framework 4.0

    -          EMET is an officially supported Microsoft tool with support available for customers with Premier contract

    We are eager to hear feedback on this new version of EMET!  This beta period is a short four weeks – we learned our lesson from the long EMET 3.5 Technical Preview about crisp timelines and short beta periods.  We need to get customer feedback during this beta period, before the official release of EMET 4.0.  Some of the EMET 4.0 feature set came straight from customer feedback. We want to make EMET a tool that you feel great about deploying and configuring in your environment.  This beta period provides an option to get the feedback of early adopters before it goes live to everyone.  Please email us at with any feedback, questions, or suggestions.  And download EMET 4.0 Beta today and try it out. 


    The EMET Team

  • Assessing risk for the April 2013 security updates

    Today we released nine security bulletins addressing 13 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and seven have a maximum severity rating of Important. 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

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 2 Difficult to build reliable exploit code for these vulnerabilities. Fixes for Pwn2Own vulnerabilities coming in a future security update.

    (Remote Desktop Client ActiveX control)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. By default, Internet Explorer users must click through the “gold bar” before ActiveX controls are loaded. (click here to see example picture)

    Does not affect version 8 of the RDP client, distributed by default with Windows 8 and Windows Server 2012 and available for Windows 7 SP1 and Windows Server 2008 R2 SP1.


    (Windows Kernel)

    Attacker who is already running code on a machine uses one of these vulnerabilities to elevate from low-privileged account to SYSTEM. Important 2 Difficult to build reliable exploit code for these vulnerabilities.  

    (Windows drivers)

    Attacker who is already logged-in and able to run malicious code at a low privilege level plugs in a USB thumb drive while custom malicious code is running. These sequence of events leads to code execution at SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  

    (Active Directory DoS)

    Attacker able to authenticate to the Active Directory domain controller sends malicious LDAP requests causing a resource exhaustion condition. When attack stops, performance returns to normal. Important 3 Difficult to predict likelihood of denial of service code appearing in the wild. No potential for code execution. This is a post-auth denial of service condition only.

    (Windows Defender Anti-malware)

    Attacker having write access to the root of the system drive (C:\) places malicious file that is run as LocalSystem by the Anti-malware service. Important 1 Likely to see reliable exploits developed within next 30 days.

    Unlikely to see wide-spread infection as low privileged users do not have permission to write to root of system drive by default.

    To exploit this vulnerability, attacker must have permission to create a new file at the root of the system drive. (C:\malicious.exe)

    (SharePoint Server 2013)

    On a SharePoint Server that has been upgraded from SharePoint 2010 to SharePoint 2013, an attacker able to legitimately authenticate to the SharePoint service may be able to access content in another user’s “My Site”. Important 1 Likely to see reliable exploits developed within next 30 days.

    Unlikely to see wide-spread use of this vulnerability as it only affects SharePoint sites that were created in a non-default way.

    Affects only “My Sites” created using the legacy user interface mode on a SharePoint Server 2013 that has been upgraded from SharePoint Server 2010.

    Sites created on a clean/new installation of SharePoint Server 2013 or sites created using the default user interface after a SharePoint Server upgrade are not affected.



    Attacker who is already running code on a Windows Server 2003 system configured in non-default “basevideo” mode may be able to use this vulnerability to elevate from low-privileged account to SYSTEM. Other configurations vulnerable to denial of service (system bugcheck). Important 1 Likely to see reliable exploits developed within next 30 days.

    Unlikely to see wide-spread infection as only non-default scenario affected for potential code execution.

    As seen in the bulletin, several platforms are vulnerable to a local, post-auth denial of service condition. However, only Windows Server 2003 with /basevideo configured at boot is vulnerable to code execution vulnerability.


    Attacker submits malicious HTML to a server, bypassing SafeHTML’s sanitization code. The malicious HTML is subsequently displayed to a victim, resulting in potential elevation of privilege for the attacker. Important 3 Unlikely to see exploit for reliable code execution against products being updated in next 30 days. We have seen limited, targeted attacks attempting to leverage this vulnerability against Microsoft online services. No known attacks against the products being addressed by MS13-035.

    - Jonathan Ness, MSRC Engineering