Security Research & Defense

MS13-037 addressing Pwn2own vulnerabilities

swiat — Tue, 14 May 2013 17:25:00 GMT

MS13-037 addresses a number of vulnerabilities in Internet Explorer, several of which were reported to us by the TippingPoint Zero Day Initiative (ZDI) program. We’ve gotten questions from customers about the specific vulnerabilities purchased by ZDI from the CanSecWest pwn2own contest. We’d like to use this blog post to provide more background on the set of vulnerabilities required for an attacker to exploit modern-day browsers and the state of fixes for those specific vulnerabilities.

Exploiting recent versions of Internet Explorer

Several years ago, a single memory corruption style vulnerability in the browser could be directly leveraged to compromise a system, could be used to run code in the context of the browsing user. Microsoft has invested heavily in platform-level mitigations for client-side applications such as browsers to the extent that today multiple different vulnerabilities must now be discovered and chained together in an exploit to compromise a system. A single memory corruption style vulnerability is just the start of an attacker’s discovery process. Typically, the attacker would need to also need to bypass ASLR and discover a way out of the IE Protected Mode limited code execution environment.

Pwn2own 2013

ZDI reported five separate vulnerabilities to Microsoft as a result of the contest:

VUPEN’s IE10 exploit

IE10 memory corruption style remote code execution vulnerability (CVE-2013-2551)
IE post-exploitation Low Integrity -> Medium Integrity escalation (CVE-2013-2552)

MWR Labs (Jon Butler and Nils) Chrome exploit

Windows kernel elevation of privilege to escape sandbox (CVE-2013-2553)

VUPEN's FireFox exploit

Windows LDRHotpatch ASLR/DEP bypass (CVE-2013-2554)

VUPEN's Adobe Flash exploit

IE9 broker issue used in the exploit for Adobe Flash (CVE-2013-2556)

Status of security updates

MS13-037 addresses the two Internet Explorer vulnerabilities used in the VUPEN exploit. The Windows vulnerabilities and the IE9 broker issue will be addressed in a future security update cycle. Here’s a chart that describes the state of fixes and level of exposure for these vulnerabilities provided to us by the ZDI.

	CVE-2013-2551	CVE-2013-2553	CVE-2013-2552	CVE-2013-2554	CVE-2013-2556
IE10	Fixed (MS13-037)	Not Affected	Fixed (MS13-037)	Not Affected	Not Affected
IE9	Fixed (MS13-037)	Not Affected	Fixed (MS13-037)	Not Affected	Update Pending
Windows 8	Not affected	Update Pending	Not Affected	Not Affected	Not Affected
Windows 7	Not affected	Update Pending	Not Affected	Update Pending	Not Affected

As you can see, MS13-037 addresses the primary or initial code execution vulnerabilities but we still are working on the updates to address other vulnerabilities used as part of the exploit chains to win pwn2own. Thankfully, ZDI reported those vulnerabilities directly to us and we don’t have any reason to believe that ZDI or the researchers who discovered these vulnerabilities have disclosed the vulnerability details to any third party. So we typically treat the pwn2own vulnerabilities as any other vulnerability report received as part of the coordinated vulnerability discovery process. It’s super interesting for us as security researchers ourselves to see the ingenuity displayed during the contest to exploit the hardest targets out there (!!) but its the severity of the vulnerabilities (not necessarily their debut as part of the contest) that guides our prioritization of fixes.

Each bulletin lists our “official” acknowledgement and thanks to the researchers and third parties involved in discovering and reporting these vulnerabilities to Microsoft. But today from everyone on the SRD team, we want to also pass along our thanks and a hat tip to the pwners out there – really impressive job on these vulns, guys. Thanks for helping us make the platform stronger.

- Jonathan Ness, MSRC Engineering and William Peteroy, MSRC

Assessing risk for the May 2013 security updates

swiat — Tue, 14 May 2013 17:14:00 GMT

Today we released ten security bulletins addressing 33 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and eight 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	Likely first 30 days impact	Platform mitigations and key notes
MS13-038 (Internet Explorer 8)	Victim browses to a malicious webpage.	Critical	1	CVE-2013-1347 currently being exploited in active attacks.	Addresses the issue that was first discovered as an exploit on the US Department of Labor website. Includes the IE8 mshtml.dll from MS13-037 + one additional fix for CVE-2013-1347. Vulnerable code is also present in IE9 but not vulnerable in same way. Update for IE9 is included as defense-in-depth measure.
MS13-037 (Internet Explorer)	Victim browses to a malicious webpage.	Critical	1	Likely to see reliable exploits developed within next 30 days.
MS13-039 (HTTP.sys)	Attacker sends malicious HTTP request to victim IIS server, creating a resource exhaustion denial-of-service.	Important	1	Likely to see reliable exploits developed for denial-of-service within next 30 days.	Most likely target would be Windows Server 2012 web servers. Windows Server 2003, 2008, 2008 R2 not affected.
MS13-042 (Publisher)	Victim opens malicious .PUB file	Important	1	Likely to see reliable exploits developed for denial-of-service within next 30 days.	11 CVE’s affecting primarily Publisher 2003. One affects Publisher 2007 and Publisher 2010. None affect Publisher 2013.
MS13-046 (Kernel mode drivers, win32k.sys and dxgkrnl.sys)	Attacker who is already running code on a machine uses one of these vulnerabilities to elevate from low-privileged account to SYSTEM.	Important	1	Difficult to build reliable exploit code for this vulnerability.
MS13-043 (Word 2003)	Victim opens malicious .doc file	Important	2	Difficult to build reliable exploit code for this vulnerability.	Does not affect Word 2007, Word 2010, Word 2013, Word Web Apps, or Office for Mac.
MS13-041 (Lync)	Victim accepts an incoming Lync chat invitation and then agrees to view a shared program or shared content presented by the attacker.	Important	2	Difficult to build reliable exploit code for this vulnerability.	Cannot be exploited via regular Lync chat. Requires victim agreeing to view shared content.
MS13-044 (Visio)	Victim opens malicious SVG image on system where Visio is installed. Through a sequence of events, Visio can be tricked into automatically sending the contents of a local file to a remote server.	Important	3	No direct code execution. This is an information disclosure vulnerability only.
MS13-045 (Windows Writer)	Victim clicks on a malicious wlw:// URL, opening Windows Writer (blogging software) and causing it to potentially overwrite local files writable by the logged-in user.	Important	3	No direct code execution.	After clicking on the prompt, user prompted to open Windows Writer. Vulnerability can only be triggered after user agrees to open Windows Writer.
MS13-040 (.NET Framework)	.NET Framework’s process to verify digital signature of XML can potentially be tricked into accepting unsigned XML as signed when first presented with signed XML.	Important	3	No direct code execution. This is a spoofing threat.

- Jonathan Ness, MSRC Engineering

Microsoft "Fix it" available to mitigate Internet Explorer 8 vulnerability

swiat — Wed, 08 May 2013 23:13:00 GMT

Today, we are making available a “Microsoft Fix it” solution to block attacks leveraging the Internet Explorer 8 (IE8) vulnerability described in Security Advisory 2847140. This code-signed, easily downloadable and install-able Fix it package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time IE is loaded. Here are the links to both apply and uninstall the Fix it solution:

Apply Fix it	Uninstall Fix it
Microsoft Fix it 50992	Microsoft Fix it 50991

In this blog post, we’d like to describe the following:

More information about the progress toward a comprehensive security update
More information about workaround options to disrupt exploits leveraging this vulnerability
More information about how the Fix it solution works

Comprehensive update in testing now

We have built a comprehensive security update that addresses this vulnerability and it is currently being tested around-the-clock. We will release it as soon as testing confirms it is ready for broad release to all customers. Tomorrow, please visit our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle.

Workaround options

As listed in Security Advisory 2847140 and confirmed externally, Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a good workaround option for the in-the-wild attacks and public pentest framework that we have seen. The exploit version in the pentest framework that target Windows Vista and Windows 7 leverages a DLL module installed by Java 6 to bypass ASLR. EMET’s Mandatory ASLR feature blocks this exploit by enforcing ASLR randomization for this DLL when it gets loaded by IE8. At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only. These exploits currently used by attackers are also blocked both by EMET’s EAF mitigation and by the EMET 3.5 TP and 4.0 Beta anti-ROP mitigations. The first ROP stage triggers EMET’s StackPointer, CallerCheck and SimExecFlow checks. Enterprises already using EMET can anlyze their machine logs to investigate possible exploitation events for this exploit reported by EMET mitigations.

For a stronger level of protection, we recommend installing the Fix it solution until the comprehensive security update is available. The Fix it applies changes to the mshtml loaded binary, similar to the changes applied by the IE team’s comprehensive security update. More information about the vulnerability, and how it is blocked by the Fix it, can be found in the next section.

How the Fix it “fixes” the vulnerable code

The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements. When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.

The appcompat shim-based “Fix it” protection tool does the exact same thing as the fix provided by the Internet Explorer team. This is still a workaround, but more surgical as compared to other workarounds because it blocks the root cause of the vulnerability. The shim modifies in memory the mshtml!CBlockContainerBlock::BuildBlockContainer function in order to force the code flow change that results in the layout structures being properly cleaned up before access:

      InjectLoopHere:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+103

match:74CC08DC 8B 45 08          mov     eax, [ebp+arg_0]     Inject code here!!
match:74CC08DF 8B 40 08          mov     eax, [eax+8]
patch:74CC08DC E9 ?? ?? ?? ??    jmp     WhilepNextExistingBlock2
patch:74CC08E1 90                nop

      ResumeExecution:
.text:74CC08E2 C1 E8 0A          shr     eax, 0Ah
.text:74CC08E5 A8 01             test    al, 1
.text:74CC08E7 0F 85 FB 8E FD FF jnz     loc_74C997E8


      WhilepNextExistingBlock:   CODE XREF: CBlockContainerBlock::BuildBlockContainer-6C6CE
.text:74CC094E 39 7D F4          cmp     [ebp+pNextExistingBlock], edi 
.text:74CC0951 0F 85 38 36 F9 FF jnz     LoopToRelocate


      LoopToRelocate:            CODE XREF: CBlockContainerBlock::BuildBlockContainer+2DF
.text:74C53F8F FF 75 F4          push    [ebp+pNextExistingBlock]
.text:74C53F92 8B 4D 0C          mov     ecx, [ebp+arg_4]
.text:74C53F95 FF 75 08          push    [ebp+arg_0]
.text:74C53F98 8D 55 F4          lea     edx, [ebp+pNextExistingBlock]
.text:74C53F9B E8 2B 64 0A 00    call    CLayoutBlock::RemoveChild ; layout structure cleanup
.text:74C53FA0 8B F0             mov     esi, eax
.text:74C53FA2 3B F7             cmp     esi, edi

match:74C53FA4 0F 8D A4 C9 06 00 jge     WhilepNextExistingBlock
patch:74C53FA4 E9 ?? ?? ?? ??    jmp     CLOBBER_NOPS_PATCH_BYTES
patch:74C53FA9 90                nop

.text:74C53FAA E9 25 58 04 00    jmp     CHK_FAIL
.text:74C53FAA                   END OF FUNCTION CHUNK CBlockContainerBlock::BuildBlockContainer


      CLOBBER_NOPS_PATCH_BYTES:
patch:???????? 7D 07             jge     WhilepNextExistingBlock3
patch:???????? E9 ?? ?? ?? ??    jmp     CHK_FAIL
      WhilepNextExistingBlock2:
patch:???????? 33 FF             xor     edi, edi
      WhilepNextExistingBlock3:
patch:???????? 39 7D F4          cmp     [ebp+pNextExistingBlock], edi  
patch:???????? 0F 85 ?? ?? ?? ?? jnz     LoopToRelocate
patch:???????? 8B 45 08          mov     eax, [ebp+arg_0]  
patch:???????? 8B 40 08          mov     eax, [eax+8]
patch:???????? E9 ?? ?? ?? ??    jmp     ResumeExecution

The “Fix it” solution will apply only for the x86 versions of Internet Explorer 8 that have applied MS13-028: Cumulative Security Update for Internet Explorer: April 9, 2013. Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.

Conclusion

We want to reiterate that only IE8 is vulnerable to this issue and we currently see only limited attacks. We are hard at work developing a comprehensive security update. Tomorrow, please review our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at switech@microsoft.com or secure@microsoft.com.

Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.

- Cristian Craioveanu and Jonathan Ness, MSRC Engineering

EMET 4.0's Certificate Trust Feature

swiat — Wed, 08 May 2013 16:18:00 GMT

Three weeks ago, we released a beta version of EMET 4.0 to get feedback on the new EMET features and to get more real-world testing before the official release. We have been amazed and so grateful for the thousands of downloads and hundreds of emails with feature suggestions, bug reports, questions about the new features, and kind words cheering us on. Thank you (!!) to those of you who are helping us make EMET 4.0 a great release. Seeing how much the community of defenders cares about this product drives and motivates us to make it awesome! With this blog post, we want to give you an update on the EMET schedule and walk through the steps to leverage EMET 4.0’s new Certificate Trust feature.

Official release delayed two weeks to May 28, 2013

We have acted on and addressed a number of bug reports and points of feedback already. One of the most important was a vulnerability first reported by TK of NSFocus where having EMET loaded made exploitation of system vulnerabilities easier – that is fixed. We also received the “Agent not running” bug report several times and that is addressed for the final release of EMET 4.0. We are fixing several application compatibility issues reported that we otherwise would be unlikely to have discovered on our own pre-release. Your feedback is making EMET 4.0 a better product – thank you!

We want to make product changes to address more of the feedback before we release EMET 4.0 to the world. So we decided to postpone the release of final version of EMET 4.0 by two weeks, to May 28th, 2013. We are sorry if this decision may interfere with your future plans of deploying EMET, but we prefer to take some extra time to work on all the feedback received and to release a product as reliable and safe as possible.

EMET and certificate pinning

As you may know EMET 4.0 implements a new protection feature known also as “certificate pinning” which in its simplest form could be described as a method of associating an X509 certificate (and its public key) to a specific Certification Authority (root or leaf).

Certificate pinning and certificate cross-validation became two very popular topic in recent years because of the major incidents and fault happened in the PKI space; in fact the current PKI and Certification Authorities model has demonstrated some limits and shown critical issues when scaled to a globalized and fully interconnected world where it’s not entirely safe to assume that every CA in the world is immune from breach, errors or poor practices as clearly showed by the table below which summarizes the most significant PKI issues seen so far. On the other hand the reason why users should care about certificate pinning is the fact that the numbers of CA across the world and located in multiple countries has grown significantly in recent years and the entire PKI model works with the assumption that all these CA will always operate with the same level of trust and confidence.

Date	SECURITY ADVISORY	SECURITY ADVISORY (LINK)	DETAILS
Mar 2011	KB2524375	http://technet.microsoft.com/en-us/security/advisory/2524375	nine fraudulent digital certificates issued by Comodo
Aug 2011	KB2607712	http://technet.microsoft.com/en-us/security/advisory/2607712	[…] at least one fraudulent digital certificate issued by DigiNotar
Nov 2011	KB2641690	http://technet.microsoft.com/en-us/security/advisory/2641690	DigiCert Sdn. Bhd, a Malaysian subordinate certification authority (CA) […] has issued 22 certificates with weak 512 bit keys
Jan 2013	KB2798897	http://technet.microsoft.com/en-us/security/advisory/2798897	one fraudulent digital certificate issued by TURKTRUST Inc.

For this reason EMET 4.0 decided to take a little step far from the traditional exploit mitigation area and introduces a new feature called Certificate Trust to allow anyone to create pinning rules for any SSL/TLS website certificate, giving the ability to detect Man-In-The-Middle attacks leveraging untrusted certificates. EMET 4.0 comes with Certificate Trust enabled by default, including a set of pre-configured websites for the most common domains used by Microsoft online services; nevertheless, since we believe that certificate pinning is a useful tool to detect MITM attacks targeting any domain and not just Microsoft services, we designed Certificate Trust totally configurable, in order to allow any user to configure custom pinning rules that will be enforced when browsing the web with Internet Explorer.

Since we received a lot of feedback about this new feature and a lot of users sent inquiries on how to properly use it, we are publishing this blog to explain how to configure and test Certificate Trust.

Introducing the Certificate Trust feature

EMET 4.0 has a main switch button in the system mitigation panel that can be used to activate or de-activate Certificate Trust. Once enabled, users have to specify which certificates and Root Certificate Authorities to trust. Users can verify that the Certificate Trust feature is activated from the EMET GUI by checking that the system status of this mitigation is “Enabled” and that Internet Explorer process (iexplore.exe) is in the list of configured apps (with or without memory mitigations enabled). This configuration allows EMET to inject into the protected process a new small module (EMET_CE.DLL) that will operate only within Internet Explorer to enforce the certificate pinning protection.

EMET pinning model is based on two simple types of metadata: Pinning Rules and Protected Websites. Users can define custom “pin” relationships between subject name(s) seen in SSL certificates and a set of trusted Root Certification Authorities. EMET supports the creation of “one-to-one” pinning rules (one domain pinned to one specific RootCA) or “one-to-many” (one domain pinned to a set of specific RootCAs), and gives the ability to define minor exceptions for each rule.

For example, let’s consider the domain “login.live.com”, which is configured and protected by default by EMET 4.0 Beta. EMET has a specific pin rule for the subject name of “login.live.com” which is linked to two RootCAs. One of these RootCAs is VeriSign RootCA, which is visible when manually inspecting the certificate for that domain. Any certificate seen by Internet Explorer for “login.live.com” and originated from a RootCA different than the two configured in EMET will be detected and reported as suspicious.

Configuring Certificate Trust: an example

In order to understand the exact steps required to create a custom pinning rule, we are providing a step-by-step configuration guide for Twitter. This guide can be used as reference to configure any other online service (e.g. webmail, social networks, file sharing, online banking, etc.) or any corporate portal that uses SSL/TLS connections (e.g. webmail.mycompany.com, fileshare.mycompany.com, etc.), and take advantage of EMET’s Certificate Trust feature.

From a clean computer using a trusted internet connection download and inspect the SSL/TLS certificate for the domain that has to be protected with EMET (e.g. https://twitter.com) and find the correct subject name that will be used in the “Protected Websites” tab (e.g. “twitter.com”)

Lookup the RootCA for “twitter.com” in the “Certification Path” and make note of some significant details related to this RootCA certificate (name, thumbprint, validity, serial number, etc.). For example the current RootCA of “twitter.com” has a VeriSign certificate with the following details:

CN = VeriSign Class 3 Public Primary Certification Authority - G5
Thumbprint = 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5
Validity = From: November ‎7, ‎2006; To: ‎July ‎16, ‎2036

Open EMET_GUI and click on “Configure”->”Certificate Trust”. In the “Pinning Rules” tab add a new rule (e.g. TwitterCAs) which will be used to import the specific VeriSign RootCA acquired earlier for twitter.com (double check you’re importing the correct VeriSign CA). This pinning rule will be used to create a “one-to-one” pinning, but anytime it is possible to add more RootCA certificates into this rule to create “one-to-many” pinning.

Go to the “Protected Websites” tab and add a pin that links “twitter.com” to the just created rule “TwitterCAs”.

Click “OK” to save the settings and restart the browser if needed.

The Certificate Trust configuration can be exported as XML file and later imported on a different machine or distributed to a corporate environment to be imported using the EMET_conf command line utility. For the Twitter example used in this blog, the exported XML configuration file is shown below:

  
<EMET Version="4.0.4854.22469">
  <Pinning>
    <PinRules>
      <PinRule>
        <ID>{67626c91-5591-4acd-a87f-864593250fff}</ID>
        <Name>TwitterCAs</Name>
        <ReferencedCertificates>
          <UniqueCertificateIdentifier>
            <Issuer>CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US</Issuer>
            <SerialNumber>18DAD19E267DE8BB4A2158CDCC6B3B4A</SerialNumber>
          </UniqueCertificateIdentifier>
        </ReferencedCertificates>
        <Expiration>5/10/2014 4:00:00 PM</Expiration>
      </PinRule>
    </PinRules>
    <PinnedSites>
      <PinnedSite>
        <Domain>twitter.com</Domain>
        <PinRuleMember>{67626c91-5591-4acd-a87f-864593250fff}</PinRuleMember>
        <Active>True</Active>
      </PinnedSite>
    </PinnedSites>
  </Pinning>
</EMET>

Notes about Certificate Trust configuration

After evaluating the initial feedback received and some questions from users regarding the Certificate Trust feature, we think it’s also important to share some additional notes and guidelines for users dealing for the first time with certificates and pinning rules:

Some websites may use different portal as entry-point for authentication; it’s always good to carefully check the correct domain name to add into the “Protected Websites” tab (e.g. “outlook.com” service is accessed via the “login.live.com” authentication service);
Each pinning rule has an expiration date that delimits for how long a rule is effective; after the specified date, the rule will no longer be used to check certificates; expiration date can be usually aligned with the expiration date of the certificate included in a pinning configuration;
Domains cannot be added in the “Protected Websites” tab by using wildcard characters (e.g. *.live.com is not allowed); also, the domain name added into this tab is not the domain name in the URL bar of the browser, but it’s one subject name of the SSL certificate;
To avoid false positives and to configure less restrictive rules, it is possible to add exceptions on each pinning rule based on three properties of the RootCA certificate: key size, country, and signature hashing algorithm; when a RootCA is not present in the defined trusted set for a specific domain, EMET may allow an exception of the pinning rule if explicitly configured (for example: allows an exception if the RootCA certificate does not use MD5, has a minimum key size of 4096 bits, and is located in USA);
When EMET detects a suspicious certificate it will be reported with a visible message from EMET Agent, while the important details of the certificates are logged into the Window Events Log; a warning message is a good pointer to examine carefully what’s happening for a SSL/TLS certificate but doesn’t necessary mean that the detected certificate is malicious, few times changes of RootCAs happen also for legitimate reasons;
The quickest way to test that the Certificate Trust feature is working is to configure a wrong pinning rule that will fail for a test domain; for example, if for twitter.com we configure a different RootCA than the specific VeriSign CA identified earlier, EMET will display the following warning message when browsing with Internet Explorer on “twitter.com”:

Conclusion

We hope you are as excited about using the final release of EMET 4.0 as we are about releasing it. If you have any questions about EMET 4.0, specifically about the Certificate Trust feature detailed in this blog post, please email us at emet_feedback@microsoft.com. And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!

- Elia Florio, MSRC Engineering

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

swiat — Mon, 29 Apr 2013 06:07:00 GMT

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.%{rule.id}-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
$webclient.DownloadFile("http://www.modsecurity.org/tarball/2.7.3/ModSecurityIIS_2.7.3.msi",$file)
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:

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

swiat — Thu, 18 Apr 2013 17:18:00 GMT

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:

http://www.microsoft.com/en-us/download/details.aspx?id=38761

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 emet_feedback@microsoft.com with any feedback, questions, or suggestions. And download EMET 4.0 Beta today and try it out.

Thanks,

The EMET Team

Assessing risk for the April 2013 security updates

swiat — Tue, 09 Apr 2013 16:53:00 GMT

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
MS13-028 (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.
MS13-029 (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.
MS13-031 (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.
MS13-036 (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.
MS13-032 (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.
MS13-034 (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)
MS13-030 (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.
MS13-033 (CSRSS)	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.
MS13-035 (SafeHTML)	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

Assessing risk for the March 2013 security updates

swiat — Tue, 12 Mar 2013 17:07:00 GMT

Today we released seven security bulletins addressing 20 CVE’s. Four of the bulletins have a maximum severity rating of Critical, and three 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
MS13-021 (Internet Explorer)	Victim browses to a malicious webpage.	Critical	1	Exploit code for CVE-2013-1288, an issue affecting IE8, is publicly available. Likely to see reliable exploits developed within next 30 days for other vulnerabilities addressed by this update as well.	IE 10 on Windows 7 is not affected.
MS13-022 (Silverlight)	Victim browses to a malicious webpage.	Critical	1	Likely to see reliable exploits developed within next 30 days.	Affects Silverlight 5.
MS13-027 (Windows USB driver)	Attacker physically inserts malicious USB device into victim’s workstation or server, resulting in code execution at SYSTEM.	Important	1	Likely to see reliable exploits developed within next 30 days.	Pre-auth code execution only possible for attacker able to physically insert malicious hardware device into victim computer. See this blog post for more background on this vulnerability.
MS13-024 (SharePoint 2010)	Attacker issues a search query on the SharePoint site with malicious script in the query string. In certain circumstances, a SharePoint admin may view search queries in such a way that the script from the attacker’s search query is run in the context of the SharePoint administrator’s session.	Critical	1	Likely to see reliable exploits developed within next 30 days.	Affects only SharePoint Server 2010 Service Pack 1, no earlier or later versions of SharePoint.
MS13-023 (Visio Viewer 2010)	Victim uses Visio Viewer 2010 to opens malicious Visio .DXF file.	Critical	2	Less likely to see reliable exploit developed for this vulnerability. Visio Viewer exploits not often seen in the wild and this one looks more difficult than usual to exploit for reliable code execution.	Visio itself not affected by this vulnerability directly. Only Visio Viewer 2010 affected.
MS13-025 (OneNote 2010)	Attacker lures victim to open OneNote file from a malicious or attacker-controlled directory. Attacker uses this vulnerability to cause process memory from the victim’s OneNote process to be written back to the file in the attacker’s directory, potentially leaking information to the attacker.	Important	n/a	Not possible to leverage this vulnerability for code execution directly. Information disclosure only.	Affects only OneNote 2010 Service Pack 1, no earlier or later versions of OneNote. Attacker must lure victim to opening file from a server or location they control. Only information in the OneNote process at the time of user opening the malicious file could become accessible to the attacker.
MS13-026 (Office Outlook for Mac)	Attacker sends victim an email with links to external content. Content is loaded without prompting user.	Important	n/a	Not possible to leverage this vulnerability for code execution directly. Information disclosure only.

- Jonathan Ness, MSRC Engineering

MS13-027: Addressing an issue in the USB driver requiring physical access

swiat — Tue, 12 Mar 2013 16:59:00 GMT

Today we are addressing a vulnerability in the way that the Windows USB drivers handle USB descriptors when enumerating devices. (KB 2807986). This update represents an expansion of our risk assessment methodology to recognize vulnerabilities that may require physical access, but do not require a valid logon session. Windows typically discovers USB devices when they are inserted or when they change power sources (if they switch from plugged-in power to being powered off of the USB connection itself). To exploit the vulnerability addressed by MS13-027, an attacker could add a maliciously formatted USB device to the system. When the Windows USB device drivers enumerate the device, parsing a specially crafted descriptor, the attacker could cause the system to execute malicious code in the context of the Windows kernel.

Because the vulnerability is triggered during device enumeration, no user intervention is required. In fact, the vulnerability can be triggered when the workstation is locked or when no user is logged in, making this an un-authenticated elevation of privilege for an attacker with casual physical access to the machine. Other software that enables low-level pass-through of USB device enumeration may open additional avenues of exploitation that do not require direct physical access to the system.

- Josh Carlson and William Peteroy, MSRC

Assessing risk for the February 2013 security updates

swiat — Tue, 12 Feb 2013 18:08:00 GMT

Today we released twelve security bulletins addressing 57 CVE’s. Five 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 rating	Likely first 30 days impact	Platform mitigations and key notes
MS13-010 (VML)	Victim browses to a malicious webpage.	Critical	1	Has been leveraged as an address leak vulnerability in targeted attacks. Likely to see additional usage in next 30 days either as an info leak or potentially as a code execution vulnerability.	VGX.dll only recently included in Internet Explorer cumulative updates. DLL originally shipped as an Office component. Depending on platform, MS13-009 may also include the fix. To be sure fix is available for all platforms, WU detection logic targets MS13-010 for all platforms, even those where MS13-009 is already installed.
MS13-009 (Internet Explorer)	Victim browses to a malicious webpage.	Critical	1	Likely to see reliable exploits developed within next 30 days.
MS13-020 (OLEAUT32)	Victim opens a malicious RTF file with an embedded ActiveX control in either Word or Wordpad, resulting in potential code execution in the context of the logged-on user.	Critical	1	Likely to see reliable exploits developed within next 30 days.	Document-style attacks typically rated ‘Important’. However, this vulnerability in OLEAUT32.dll’s core memory management functions likely to be used by third party ActiveX controls. While we have not identified any Microsoft browser-based attack vector, third party ActiveX controls likely to expose this vulnerability within the browser.
MS13-011 (Windows Media)	Victim with a third party codec installed browses to a malicious webpage.	Critical	1	Likely to see reliable exploits developed within next 30 days. Less likely to see wide-spread attacks due to third party codec requirement.	Vulnerability cannot be triggered without third party codec installed.
MS13-012 (Oracle Outside In for Exchange)	Attacker sends email with malicious attachment and lures victim to view the attachment as a webpage within Outlook Web Access. The attacker could potentially compromise the server-side process generating the web page.	Critical	2	Difficult to build reliable exploit code for these vulnerabilities.	Oracle Outside In process runs at a lower privilege level, LocalService. For more background information, please see this SRD blog post.
MS13-015 (.NET Framework)	Victim browses to a malicious intranet webpage that offers an XBAP or ClickOnce application.	Important	1	Vulnerability itself is exploitable (hence the “1” rating). However, XBAP is disabled on IE9 and also in the Internet Zone on earlier versions of Internet Explorer. Therefore, less likely to see wide-spread exploitation.
MS13-016 (Windows drivers [win32k.sys])	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.	Same vulnerability present in 30 different win32k.sys functions, leading to high (30) CVE count.
MS13-017 (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	1	Likely to see reliable exploit code developed within next 30 days.
MS13-019 (CSRSS)	Attacker who is already running code on a machine uses one of these vulnerabilities to elevate from low-privileged account to SYSTEM.	Important	1	Difficult to build reliable exploit code for this vulnerability.
MS13-013 (FAST Search Server for Sharepoint)	Attacker having permission to upload malicious content to a Sharepoint server does so, which is indexed by FAST Search Server, resulting in potential code execution in context of the restricted token used by the indexing service.	Important	1	Likely to see reliable exploits developed within next 30 days.	The SharePoint Advanced Filter Pack that leverages Oracle Outside In technology for indexing is not enabled by default. The process that SharePoint uses for indexing when it is enabled runs with a restricted token similar to the Office 2010 Protected View sandbox. For more information, please see this SRD blog post.
MS13-018 (TCP/IP)	Attacker creates millions of TCP/IP connections to victim server in such a way that victim initiates connection teardown for each by sending FIN to attacker. Over time, victim’s non-paged pool is exhausted and victim is unable to create new network connections.	Important	n/a	Denial of Service only.	Denial of service only – no chance for code execution. For more background on this issue, please see this SRD blog post.
MS13-014 (NFS server role)	Attacker triggers denial of service condition on Windows server on which NFS server role has been activated.	Important	n/a	Denial of Service only.	Does not affect servers without NFS server role.

- Jonathan Ness, MSRC Engineering