Over the weekend we received a report from our partners about a possible unpatched Internet Explorer vulnerability being exploited in the wild. The exploit code uses a memory corruption bug triggered from a webpage but it deeply leverages a Flash SWF file in order to achieve reliable exploitation and code execution. The Flash file is made of a sophisticated ActionScript code that allocates certain objects in memory in such a way that they can be corrupted later by the Internet Explorer bug in order to give unsafe access to memory regions to the Flash ActionScript code that will carry on the entire exploitation.
In summary, our analysis of this exploit sample revealed the following:
The good news is that the memory corruption vulnerability used in this attack - CVE-2013-3163 - has been already addressed by yesterday’s Microsoft Security Bulletin MS13-055. If you have not yet updated, please do so at the earliest possible. EMET 4.0 was able to stop this exploit variant before the patch with the following mitigations:
Advice for detection and indicators
The common pattern for this limited targeted attack is a drive-by webpage “vid.aspx” or “list.aspx” used as starting point to trigger the bug and run the secondary Flash payload; below we are providing some URL patterns that can be useful for log and network traffic analysis:
As of July 7th, some of the specific Flash samples were still undetected by most of the AV community according to VirusTotal; hashes and filenames of these samples are listed also below to facilitate detection for AV vendors:
The shellcode used by the sample received attempts to download a graphic file (pageerror.gif) which contains appended an encrypted and compressed malicious executable, possibly launched from %TEMP% folder using “javae.exe” filename.
Cristian Craioveanu, Elia Florio
Today we released seven security bulletins addressing 34 CVE’s. Six bulletins have a maximum severity rating of Critical, and one has a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
(win32k.sys and TTF font parsing)
Additional attack vector involves victim browsing to a malicious webpage that serves up TTF font file resulting in code execution as SYSTEM.
Kernel-mode portion of TTF font parsing issue (CVE-2013-3129) addressed by this update.
(.NET Framework and Silverlight)
Unlikely to see wide-spread infection as low privileged users do not have permission to write to root of system drive by default.
- Jonathan Ness, MSRC Engineering
Today we announced the upcoming Mitigation Bypass Bounty, the BlueHat Bonus for Defense, and the Internet Explorer 11 Preview Bug Bounty program. It’s very exciting to finally take the wraps off of these initiatives and we are anticipating some great submissions from the security research community! These programs will allow us to reward great work by researchers and improve the security of our software – all to the benefit of our customers. Also, we just like to analyze and fix cool bugs!
Security features such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) have made it increasingly difficult and costly to exploit vulnerabilities on modern systems. As a consequence of this, good exploitation techniques that work reliably when exploiting vulnerabilities on modern systems have become increasingly valuable. By learning about novel exploitation techniques, we can design better defenses that help protect our customers even when they are running software with an unknown vulnerability or a vulnerability that has not yet been addressed through a security update. This is why we are announcing the Mitigation Bypass Bounty program.
Anatomy of a good report
A high quality submission to the mitigation bypass bounty program will describe and demonstrate a truly novel method of exploiting one or more memory corruption vulnerability classes when all modern mitigations are in place (e.g. DEP, ASLR, SEHOP, and so on). For a submission to eligible, it must include a detailed whitepaper and a functioning exploit which demonstrates the exploitation technique against a real world remote code execution vulnerability. The technique must also meet a high bar: it must be generic and reliable, it must have reasonable requirements, it must apply to a high-risk user mode application domain, and it must be applicable to the latest version of our products. The complete set of requirements can be found in the official rules.
A good example of an exploitation technique that could have qualified for the mitigation bypass bounty program is JIT spraying. This technique was publicly described for the first time in 2010 by Dionysus Blazakis. It outlined a method of leveraging a Just-In-Time compiler to generate large amounts of partially controlled instructions that could enable alternative instruction streams if executed at a misaligned offset. As a result, an attacker can implicitly bypass DEP and ASLR and thereby more easily exploit many classes of memory corruption vulnerabilities. In response to this exploitation technique, multiple software vendors have released JIT compilers that include built-in mitigations for JIT spraying.
BlueHat Bonus for Defense
In addition to encouraging researchers to report novel exploitation techniques, we also want to encourage submissions to include recommendations on how an exploitation technique can be mitigated. Submissions that include a whitepaper that describes an effective, practical, and robust mitigation for a qualifying exploitation technique may qualify for up to an additional $50,000 USD bonus.
The Security Research and Defense team worked with the core bounty program team to develop the bounty program bug bar for the Internet Explorer 11 Preview Bug Bounty:
Proof of concept
Base Payout Tier
Important or higher severity design-level vulnerability
Proof of Concept is
Eligible security bugs that also have privacy implications
ASLR Info Disclosure Vulnerability
Sandbox Escape Vulnerability
More detail on the submission criteria is available in the official guidelines. One area worth highlighting is our additional focus on eligible security bugs that also have privacy implications. While these bugs would be considered as vulnerabilities in their own right, we thought it was important to highlight them and actively incentivize research that furthers our longstanding commitment to privacy.
The quality and completeness of a submission determines not only the payout but also the priority in which it will be reviewed. High quality submissions should include a detailed analysis of a vulnerability’s root cause in addition to a proof of concept that reliably reproduces the issue. This information helps us rapidly confirm your findings so that you can get paid!
The highest rewards will go to submissions that include a fully functioning exploit which concretely demonstrates that remote code execution is possible. This means the exploit must be capable of bypassing exploit mitigations such as DEP and ASLR. These submissions allow us to study the exploitation techniques that were used to achieve code execution and thereby identify opportunities for new exploit mitigation features. In this way, we can increase the cost and difficulty of exploiting entire classes of vulnerabilities rather than simply addressing a single vulnerability at a time.
The SRD team is also responsible for technical triage on issues as they come in. We’ve invited several security researchers on contract with Microsoft to help us in this effort. Our current roster of analysts is as follows:
We are currently aiming to provide feedback and confirmation of payout within two weeks of a report.
Finally, please remember that the IE11 Preview Bug Bounty runs between June 26 and July 26, 2013, so make sure to get your reports wrapped up and submitted in time.
We are incredibly excited to get these programs underway and are really looking forward to seeing the submissions that come in.
- Matt Miller and David Ross, SRD Bloggers
*Postings are provided "AS IS" with no warranties, and confer no rights.*
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 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:
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.
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.
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
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.
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, blockJava in IE
- Cristian Craioveanu, MSRC Engineering, with help and support from Elia Florio and Gerardo Di Giacomo (thank you!)
On May 8th, we announced that EMET 4 would have been released today, May 28th. 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.
- The EMET Team.
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.
ZDI reported five separate vulnerabilities to Microsoft as a result of the contest:
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.
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
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.
(Internet Explorer 8)
Vulnerable code is also present in IE9 but not vulnerable in same way. Update for IE9 is included as defense-in-depth measure.
(Kernel mode drivers, win32k.sys and dxgkrnl.sys)