Security Research & Defense

EMET 4.0 now available for download

swiat — Mon, 17 Jun 2013 17:01:00 GMT

We are pleased to announce that the final release of version 4.0 of the Enhanced Mitigation Experience Toolkit, best known as EMET, is now finally available for download. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=39273.

We already mentioned some of the new features introduced in EMET 4: Certificate Trust, mitigations improvement hardening, and the Early Warning Program. During our beta period we added new features and solved application compatibility issues that have been reported both externally and internally. Below is a summary of the changes and enhancements:

Redesigned User Interface: We realized that with the addition of the new features introduced in EMET 4.0 Beta, the old graphical user interface was not as effective and easy to use. For this reason, we decided to re-design EMET’s GUI to facilitate and streamline the configuration operations. We also added the possibility to select the look-and-feel of EMET from a set of skins that we included. Finally, the new user interface is accessible and will change automatically according to your system settings:

Configuration Wizard: We know that configuration can be challenging when installing EMET for the first time. In EMET 3.0 we added the Protection Profiles, which were used to facilitate the initial configuration for applications. With EMET 4.0 we are introducing a Configuration Wizard that will automatically configure EMET with a standard set of SSL certificate pinning rules as well as a list of applications to protect. It also can preserve existing EMET 3.0 settings, and gives the possibility to add standard configuration for the new features. The Configuration Wizard will start automatically during EMET’s installation and can also be accessed, at any time, from EMET GUI. Advanced users can choose to apply a standard configuration through the Configuration Wizard and then customize EMET’s configuration afterwards according to their needs.

Changes in Certificate Trust: We made a few changes to the Certificate Trust feature, based on users’ feedback, further internal investigation, and partnership with third party online services. We added a new exception to the SSL certificate pinning rules that if enabled will make EMET verify just the Public Key component of the Root CAs present in the rule without matching subject name and serial number. Additionally, we made the Certificate Trust feature available on 64-bit versions of Internet Explorer. Finally, we added to the previous default rules for Microsoft online services new rules also for Twitter, Facebook, and Yahoo!.

Updated Group Policy profiles: Enterprise customers will notice that we updated our Group Policy profiles to include not only the ability to configure system and application mitigations, but also the reporting mechanisms, the advanced mitigation configurations, and the exploit action.

If you have EMET 4.0 Beta or EMET 3.5 Technical Preview installed on the system, you will need to uninstall them before installing EMET 4.0, and you will need to remove EMET’s configuration from the registry, by deleting the registry hives HKLM\Software\Microsoft\EMET and, if existing, HKLM\Software\Policies\Microsoft\EMET. If you have EMET 3.0 installed on the system, you don’t need to uninstall it before installing EMET 4.0. The previous version will be uninstalled and at the end of the installation you’ll have the opportunity to migrate the existing settings or to reset EMET configuration with the new default settings.

We want to thank those of you that downloaded EMET 4.0 Beta in the past two months and that provided valuable feedback that greatly helped us finalize EMET 4.0. In particular, we want to thank the Yang Yu from NSFocus security team that reported a technique that allowed to bypass EMET’s protections, and Adam Langley and Cem Paya from Google for feedback on the Certificate Trust feature. As said, we received many, many emails, and it would be impossible to name all the people that provided feedback for EMET 4.0 Beta. You know who you are, and we really appreciated your effort in testing EMET and reaching out to us to provide feedback. Again, thank you!

We truly hope that you enjoy all the new features that we introduced in EMET 4.0. We will continue working on improving EMET to provide better and better protections against internet attacks for customers and to make it even more user friendly and easy to use.

- The EMET Team: Ali Rahbar, Chengyun Chu, Cristian Craioveanu, Dan Beenfeldt, Elia Florio, Elias Bachaalany, Gerardo Di Giacomo, Jonathan Ness, Matt Miller, Neil Sikka, Nitin Kumar Goel, Ken Johnson

MS13-051: Get Out of My Office!

swiat — Tue, 11 Jun 2013 17:27:00 GMT

MS13-051 addresses a security vulnerability in Microsoft Office 2003 and Office for Mac. Newer versions of Microsoft Office for Windows are not affected by this vulnerability, but the newest version of Office for Mac (2011) is affected. We have seen this vulnerability exploited in targeted 0day attacks in the wild. In this blog we’ll cover the following aspects:

Technical Details
Attack Pattern
Advice for Detection

Technical Details

In the Office PNG file parsing code, there is a vulnerability where the length field of a chunk is not correctly checked. The PNG specification (http://www.w3.org/TR/PNG/#5Chunk-layout) says “Although encoders and decoders should treat the length as unsigned, its value shall not exceed 2^31-1 bytes.” However, in the malicious PNG files, we found the length field of a chunk equal to 0xFFFFFFFF. The PNG parsing code correctly treated this field as unsigned (as specified in the PNG spec), but was not catching the case when the value was 0xFFFFFFFF, which if interpreted as an unsigned value, exceeds 2^31-1. Below is what the malicious chunk size looks like (highlighted in yellow):

Shellcode analysis shows that the exploit for this vulnerability was a classic stack based buffer overflow, which wrote far past the end of a buffer on the stack, thereby overwriting control data on the program’s stack, eventually leading to high-jacking the program’s execution. Older versions of Office/Windows don’t have mitigations for these types of exploits, but newer versions of Office/Windows do. This is an example of how running current software can increase an organization’s security. We verified also that EMET 3.0 (and above) is able to stop the exploits observed so far, providing an additional mitigation against this specific attack.

Attack Pattern

The attacks we observed were extremely targeted in nature and were designed to avoid being investigated by security researchers. The malicious samples observed are Office documents (Office 2003 binary format) which do not include the malicious PNG file embedded directly in the document. Rather, the documents reference a malicious PNG file loaded from Internet and hosted on a remote server.

Attackers also equipped their servers with scripts which avoid serving the PNG exploit multiple times, in an effort to keep this 0day more concealed. We believe that the limited attacks observed were geographically located mostly in Indonesia and Malaysia.

Advice for Detection

The common pattern for all these documents is the filename “space.gif” used by each malicious file to fetch the remote PNG file containing the exploit. In order to help security vendors and enterprises look for potential indicators and to deliver an effective protection, we are providing some of the URLs used to load the remote PNG exploit and hashes of the malicious Office binary format documents observed in these limited targeted attacks.

hXXp://intent.nofrillspace.com/users/web11_focus/4307/space.gif
hXXp://intent.nofrillspace.com/users/web11_focus/3807/space.gif
hXXp://mister.nofrillspace.com/users/web8_dice/3791/space.gif
hXXp://mister.nofrillspace.com/users/web8_dice/4226/space.gif
hXXp://www.bridginglinks.com/somebody/4698/space.gif
hXXp://www.police28122011.0fees.net/pages/013/space.gif
hXXp://zhongguoren.hostoi.com/news/space.gif

MD5	SHA1
fde37e60cc4be73dada0fb1ad3d5f273	1bdc1a0bc995c1beb363b11b71c14324be8577c9
2f1ab543b38a7ad61d5dbd72eb0524c4	2a33542038a85db4911d7b846573f6b251e16b2d
7eb17991ed13960d57ed75c01f6f7fd5	d6a795e839f51c1a5aeabf5c10664936ebbef8ea
70511e6e75aa38a4d92cd134caba16ef	f362feedc046899a78c4480c32dda4ea82a3e8c0
28e81ca00146165385c8916bf0a61046	f751cdfaef99c6184f45a563f3d81ff1ada25565
35a6bbc6dda6a1b3a1679f166be11154	f7f1c39b42453f0b27b601f32c0af3cce99f79db

Thanks to Andrew Lyons and Neel Mehta of Google Inc for the report, and to Elia Florio and Cristian Craioveanu for helping with this case.

- Neil Sikka, MSRC Engineering
@neilsikka

Assessing risk for the June 2013 security updates

swiat — Tue, 11 Jun 2013 15:59:00 GMT

Today we released five security bulletins addressing 23 CVE’s. One bulletin has a maximum severity rating of Critical, and four 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-047 (Internet Explorer)	Victim browses to a malicious webpage.	Critical	1	Likely to see reliable exploits developed within next 30 days.	19 CVE’s being addressed.
MS13-051 (Office 2003)	Victim opens malicious Office document.	Important	1	Limited, targeted attacks seen exploiting single CVE addressed by this update.	Affects Office 2003 and Office for Mac 2011. See this SRD blog post for more information about the attacks.
MS13-049 (Windows networking)	Attacker establishes thousands of connections of a certain type to victim listening on a TCP/IP port, exhausting non-paged pool memory. This causes a denial of service condition where networking stack (or entire system) must be restarted.	Important	3	No chance for direct code execution. Denial of service only.	Can only be triggered from the local machine on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. Rated Moderate on those platforms.
MS13-050 (Print spooler)	Attacker who is already running code on a machine uses this vulnerability to elevate from low-privileged account to SYSTEM.	Important	1	Likely to see reliable exploits developed for denial-of-service within next 30 days.
MS13-048 (Windows kernel)	Attacker who is already running code on a machine uses this vulnerability to bugcheck machine or leak kernel memory addresses.	Important	3	No chance for direct code execution. Denial of service or information disclosure only.

- Jonathan Ness, MSRC Engineering

Java: A Fix it for when you cannot let go

swiat — Wed, 29 May 2013 14:30:00 GMT

There is much to say about the use of Java in both consumer and enterprise environments. Like any other platforms, it has both devoted supporters and fervent critics. But for most, Java is a requirement, a means to an end.

In the past few years, Java as a platform has been the target of numerous malware attacks, which exploit a number of Java runtime vulnerabilities on the target machines. The rise in Java exploitation has been attributed largely to unpatched software, although 0-day issues do creep in occasionally.

Fortunately, there are steps that can be taken to mitigate some of these issues. Oracle is providing a series of measures to prevent unauthorized Java Applets and Web Start Applications from running by requiring them to be signed with a trusted certificate. This is a great start. However, not everybody runs an up-to-date version of Java runtime. For a long time, Java updates used to install side-by-side with older versions. That’s no longer the case, but the problem of unpatched software persists. In addition, there are legacy apps that require an older platform to run.

What can be done about this? If you need to run Java inside a browser, not much -- keep your software up to date and visit only trusted websites. If you only care about running Java desktop apps, there are a few mitigation steps that allow the customer to disable Java support inside your browser, leaving desktop functionality intact. These steps will remove a prevalent remote exploit vector, but at the same time keep Java installed for local applications. This subject has been covered elsewhere; for instance, here.

Our customers tell us that the most effective mitigation tactics are both complete (covering all software versions, past and current) and friendly to enterprises, which face complex deployment issues. In order to address these concerns, we have issued an update to KB2751647 – How to disable Java web plugin in Internet Explorer. We are making available a “Microsoft Fix it” solution to block all Java web-attack vectors through Internet Explorer. The solution will work for all versions of Java (tested 5 and above) and all supported versions of Internet Explorer (32-bit or 64-bit):

Apply Fix it	Uninstall Fix it
Microsoft Fix it 50994	Microsoft Fix it 50995

The Fix it solution consists of two parts. The first makes use of Windows Application Compatibility Toolkit, changing the behavior of Internet Explorer at runtime so that it will prevent the load of Oracle’s Java Web plugins. This is achieved by hooking all LoadLibrary* functions so that they return NULL (last error ERROR_FILE_NOT_FOUND) when attempting to load all Java ActiveX dlls (npjpi*.dll, jp2iexp.dll). The second part prevents Internet Explorer from automatically opening JNLP files. It does this by clearing the ACL (access control list) of the JNLP protocol handler registry location (HKCR\JNLPFile), thus preventing all user apps from reading its contents.

This solution covers current and past versions of Java, as well as foreseeable future versions. It does not interfere with Java’s update mechanism either. In fact, the Fix it works as expected even if installed prior to any installation of Java. It can also be easily deployed making use of the non-interactive options of msiexec.

A mitigation.
When you cannot let go, block
Java in IE

- Cristian Craioveanu, MSRC Engineering, with help and support from Elia Florio and Gerardo Di Giacomo (thank you!)

A few more days before EMET 4

swiat — Wed, 29 May 2013 00:14:21 GMT

On May 8^th, we announced that EMET 4 would have been released today, May 28^th. Since that day, we had additional feedback and we are working on a few things that are requiring a little bit more time than expected.

This considered, we are not releasing EMET 4 today, and we will take a few more days to have everything prepared for the final release. We are sure that you will not be disappointed by the additions we are working on before the final release.

Also, at this point we don’t want to give a new release date yet, but expect to see EMET 4 in the next few days.

Stay tuned!

- The EMET Team.

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