Security Research & Defense

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

Security Research & Defense

  • Additional information about CVE-2014-6324

    Today Microsoft released update MS14-068 to address CVE-2014-6324, a Windows Kerberos implementation elevation of privilege vulnerability that is being exploited in-the-wild in limited, targeted attacks. The goal of this blog post is to provide additional information about the vulnerability, update priority, and detection guidance for defenders. Microsoft recommends customers apply this update to their domain controllers as quickly as possible.


    Vulnerability Details

    CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).

    The exploit found in-the-wild targeted a vulnerable code path in domain controllers running on Windows Server 2008R2 and below. Microsoft has determined that domain controllers running 2012 and above are vulnerable to a related attack, but it would be significantly more difficult to exploit. Non-domain controllers running all versions of Windows are receiving a “defense in depth” update but are not vulnerable to this issue.

    Before talking about the specific vulnerability, it will be useful to have a basic understanding of how Kerberos works.

     


    One point not illustrated in the diagram above is that both the TGT and Service Ticket contain a blob of data called the PAC (Privilege Attribute Certificate). A PAC contains (among other things):

    • The user’s domain SID
    • The security groups the user is a member of

     

    When a user first requests a TGT from the KDC, the KDC puts a PAC (containing the user’s security information) into the TGT. The KDC signs the PAC so it cannot be tampered with. When the user requests a Service Ticket, they use their TGT to authenticate to the KDC. The KDC validates the signature of the PAC contained in the TGT and copies the PAC into the Service Ticket being created.

    When the user authenticates to a service, the service validates the signature of the PAC and uses the data in the PAC to create a logon token for the user. As an example, if the PAC has a valid signature and indicates that “Sue” is a member of the “Domain Admins” security group, the logon token created for “Sue” will be a member of the “Domain Admins” group.

    CVE-2014-6324 fixes an issue in the way Windows Kerberos validates the PAC in Kerberos tickets. Prior to the update it was possible for an attacker to forge a PAC that the Kerberos KDC would incorrectly validate. This allows an attacker to remotely elevate their privilege against remote servers from an unprivileged authenticated user to a domain administrator.

      

    Update Priority

    1. Domain controllers running Windows Server 2008R2 and below
    2. Domain controllers running Windows Server 2012 and higher
    3. All other systems running any version of Windows

     

    Detection Guidance

    Companies currently collecting event logs from their domain controllers may be able to detect signs of exploitation pre-update. Please note that this logging will only catch known exploits; there are known methods to write exploits that will bypass this logging.

     


    The key piece of information to note in this log entry is that the “Security ID” and “Account Name” fields do not match even though they should. In the screenshot above, the user account “nonadmin” used this exploit to elevate privileges to “TESTLAB\Administrator”.

    After installing the update, for Windows 2008R2 and above, the 4769 Kerberos Service Ticket Operation event log can be used to detect attackers attempting to exploit this vulnerability. This is a high volume event, so it is advisable to only log failures (this will significantly reduce the number of events generated).

     

    After installing the update, exploitation attempts will result in the “Failure Code” of “0xf” being logged. Note that this error code can also be logged in other extremely rare circumstances. So, while there is a chance that this event log could be generated in non-malicious scenarios, there is a high probability that an exploitation attempt is the cause of the event.

     

    Remediation

    The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately.

     

    Additional Notes

    Azure Active Directory does not expose Kerberos over any external interface and is therefore not affected by this vulnerability.

     

    Joe Bialek, MSRC Engineering

  • MS14-072: .NET Remoting Elevation of Privilege Vulnerability

    Today Microsoft shipped MS14-072 to the .NET Framework to address an Elevation of Privilege (EOP) vulnerability in the .NET Remoting feature. This update fixes a specific issue in .NET Remoting that permitted specially crafted remote endpoints to take advantage of this vulnerability.

    What is .NET Remoting?

    .NET Remoting is a layer within the .NET Framework that facilitates communication between application domains (AppDomains). This permits managed objects to communicate across AppDomain, process, or machine boundaries.  Objects can be passed by-reference across these boundaries.  When methods are called on these objects, control again passes across the boundary to execute within the boundary where the object originated. Refer to .NET Remoting for more details.

    Typical use of this is a .NET Remoting service that returns objects by-reference to the client.  When the client invokes methods on these objects, code is executed on the server.  Similarly, a client can pass an object by-reference to the service, and when that service invokes methods on that object, code executes on the client.

     

    Use WCF instead of .NET Remoting

    .NET Remoting is a legacy technology that is inherently less secure than WCF. It is unable to preserve isolation of trust levels across the client/server boundary, allowing specially crafted messages to exploit the use of by-reference objects to achieve an elevation of privilege.  It also uses a legacy serialization technology that makes the server vulnerable to denial-of-service attacks. Because of this we recommend developers of distributed applications based on .NET Remoting to consider porting their code to Windows Communication Foundation (WCF) which is more secure.

    The boundary transparency in .NET Remoting makes it possible for a remote untrusted endpoint to take control of a .NET Remoting service. Because the service typically executes with full privileges, this permits a remote endpoint with lower privileges to elevate themselves using functionality exposed by .NET Remoting services. Within a completely trusted environment, this is normally not a problem.  But if the .NET Remoting service is exposed to untrusted remote endpoints, this becomes an issue as it crosses the security boundary.

    Read about how .NET Remoting works to know more information around why we recommend moving away from it.

    The Windows Communication Foundation (WCF) unified programming model is designed to be robust when communicating with untrustworthy endpoints. In many cases this may be a small exercise to move to the newer, more supported technology. The MSDN article entitled How to: Migrate Managed-Code .NET Remoting to WCF provides a number of examples and code samples to help ease this transition process.

     

    Securing .NET Remoting services

    Moving to newer technology takes time, meanwhile here are some steps to make .NET Remoting service more secure:

    This enables encryption and digital signatures if the remoting system determines that the channel implements ISecurableChannel.

    • Always authenticate clients and encrypt the communication streams:

    There is no authentication or encryption by default, developers have to do this explicitly.

    • Keep the permission level of the .NET Remoting service at minimum to what is required so as to avoid having a big security boundary.

     

    - Swamy Gangadhara (MSRC) & Ron Cain (.NET)

  • Assessing Risk for the November 2014 Security Updates

    Today we released fourteen security bulletins addressing 33 unique CVE’s. Four bulletins have a maximum severity rating of Critical, eight have a maximum severity rating of Important, and two have a maximum severity rating of Moderate. This table is designed to help you prioritize the deployment of updates appropriately for your environment.

    Bulletin

    Most likely attack vector

    Max Bulletin Severity

    Max Exploitability

    Deployment Priority

    Platform mitigations and key notes

    MS14-064

    (Windows OLE Component

    User opens malicious Office document.

    Critical

    0

     

    1

    CVE-2014-6352 used in limited, targeted attacks in the wild.

    MS14-066

    (SChannel)

    A malicious user sends specially crafted packets to an exposed service.

    Critical

    1

    1

    Internally found during a proactive security assessment.

    MS14-065
    (Internet Explorer)

    User browses to a malicious webpage.

    Critical

    1

    1

    MS14-069
    (Office)

    User opens malicious Word document.

    Important

    1

    2

    Office 2010 and later versions are not affected by any of the vulnerabilities in this bulletin.

    MS14-067
    (MSXML)

    User browses to a malicious webpage.

    Critical

    2

    2

    Only MSXML 3 is vulnerable.

    MS14-073
    (SharePoint)

    User opens a malicious link.

    Important

    2

    2

    This is a Cross Site Scripting vulnerability.

    MS14-078

    (IME)

    User opens a malicious PDF document with Adobe Reader.

    Moderate

    0

    3

    CVE-2014-4077 used in one targeted attack in the wild to bypass Adobe Reader Sandbox via binary hijacking using malicious DIC file.

    MS14-071

    (Windows Audio Service)

    User browses to a malicious webpage.

    Important

    2

    3

    Local elevation of privilege only, could potentially be utilized as a sandbox escape.

    MS14-070

    (tcpip.sys)

    An authenticated Windows user runs a malicious program on the target system.

    Important

    2

    3

    Local elevation of privilege only.

    MS14-072

    (.NET Framework)

    Attacker sends malicious data to a vulnerable web application.

    Important

    2

    3

    Applications not using .NET Remoting are not vulnerable.

    MS14-076

    (IIS)

    A whitelist-only site could be accessed by an attacker not connected to the proper domain. A blacklist could be similarly bypassed.

    Important

    3

    3

    The vulnerability manifests itself in configurations where the Domain Name Restrictions whitelist and blacklist features are used with entries that contain wildcards.

    IP Address Restrictions are not affected

    MS14-074

    (RDP)

    An authorization audit log could be bypassed in some scenarios.

    Important

    3

    3

    The vulnerability only applies to failed AuthZ scenarios, and not to failed AuthN. For example, if a valid user logon is attempted for a user that does not have privilege to RDP into a server, that event log may not be recorded. Event logs will still be recorded if an invalid user or password is presented.

    MS14-077

    (ADFS)

    An authenticated user could not be logged out in some configurations.

    Important

    3

    3

    Manifests itself in a specific configuration where the ADFS server is configured to use a SAML Relying Party with no sign-out endpoint configured.

    MS14-079

    (Kernel Mode Drivers [win32k.sys])

    User browses to malicious webpage.

    Moderate

    3

    3

    The vulnerability leads to denial of service only.

    - Suha Can, MSRC Engineering

     

  • EMET 5.1 is available

    Today, we’re releasing the Enhanced Mitigation Experience Toolkit (EMET) 5.1 which will continue to improve your security posture by providing increased application compatibility and hardened mitigations. You can download EMET 5.1 from microsoft.com/emet or directly from here. Following is the list of the main changes and improvements:

    • Several application compatibility issues with Internet Explorer, Adobe Reader, Adobe Flash, and Mozilla Firefox and some of the EMET mitigations have been solved.
    • Certain mitigations have been improved and hardened to make them more resilient to attacks and bypasses.
    • Added “Local Telemetry” feature that allows to locally save memory dumps when a mitigation is triggered.

    All the changes in this release are listed in Microsoft KB Article 3015976.

    If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation. Alternatively, you can temporarily disable EAF+ on EMET 5.0. Details on how to disable the EAF+ mitigation are available in the User Guide. In general we recommend upgrading to the latest version of EMET to benefit from all the enhancements.

    We want to particularly thank Luca Davi, Daniel Lehmann, and Ahmad-Reza Sadeghi from System Security Lab at Technical University Darmstadt/CASED, and René Freingruber form SEC Consult for partnering with us.

    Your feedback is always welcome as it helps us improve EMET with each new release, so we encourage you to reach out using the Connect Portal or by sending an email to emet_feedback@microsoft.com.

    - The EMET Team

  • More Details About CVE-2014-4073 Elevation of Privilege Vulnerability

    Today Microsoft shipped MS14-057 to the .NET Framework in order to resolve an Elevation of Privilege vulnerability in the ClickOnce deployment service. While this update fixes this service, developers using Managed Distributed Component Object Model (a .NET wrapped around DCOM) need to take immediate action to ensure their applications are secure.

    Managed DCOM is an inherently unsafe way to perform communication between processes of different trust levels. Microsoft recommends moving applications to Windows Communication Foundation (WCF) for inter-process communication instead of using Managed DCOM. Exposing Managed DCOM containers or servers to lower trust callers can result in elevation of privilege vulnerabilities. Please note that DCOM is considered to be secure; only Managed DCOM is considered to be insecure.

    More Information:

    For more information around why we recommend moving away from Managed DCOM, it is helpful to understand how COM and DCOM work.

    COM is a platform-independent, programming language independent, object-oriented system for creating software components that interact. Traditional COM occurs within a single process boundary.

    DCOM is similar to normal COM except it allows for objects to be created in different processes or even different computers. This can be useful for distributed computing, or for scenarios where a client application needs to communicate with a server application.

    Unfortunately the communications wrapper that the .NET Framework uses to talk to DCOM (also known as Managed DCOM) is unable to maintain this security boundary. If you use managed code to implement either a server or a container, it’s possible for the remote end of the communication channel to take over the managed process. In scenarios where the interaction is taking place inside the same process or between two processes running with the same privilege, this isn’t a problem. However, when the processes communicating with each other run with different levels of privilege, this becomes an issue.

    Fortunately there is a solution for developers that rely on this functionality. The Windows Communication Foundation (WCF) unified programming model is designed to be robust when communicating with untrustworthy endpoints. In many cases this may be a small exercise to move to the newer, more supported technology. The MSDN article entitled How to: Migrate Managed-Code DCOM to WCF provides a number of examples and code samples to help ease this transition process.

    For MS14-057, Microsoft removed the ClickOne deployment service dependency on Managed DCOM. We suggest all developers do the same if they are currently using Managed DCOM to communicate between components running with different privilege.

     

    -Reid Borsuk (Product Security) and Joe Bialek (MSRC)

  • Assessing Risk for the October 2014 Security Updates

    Today we released eight security bulletins addressing 24 unique CVE’s. Three bulletins have a maximum severity rating of Critical, and five have a maximum severity rating of Important. This table is designed to help you prioritize the deployment of updates appropriately for your environment.

    Bulletin

    Most likely attack vector

    Max Bulletin Severity

    Max exploitability

    Platform mitigations and key notes

    MS14-058

    (Kernel mode drivers [win32k.sys])

    Attacker loads a malicious font on the user’s computer using an Office document or web browser which results in remote code execution.

    Critical

    0

    Exploitation of CVE-2014-4148 and CVE-2014-4113 detected in the wild.  CVE-2014-4148 is used for remote code execution. CVE-2014-4113 is used for elevation of privilege.

     CVE-2014-4113 is not exploitable on 32bit platforms if NULL-page mapping mitigation is enabled (configurable on Windows 7, enabled by default on Windows 8 an above).

    MS14-056

    (Internet Explorer)

    Victim browses to a malicious webpage.

    Critical

    0

    Exploitation of CVE-2014-4123 detected in the wild. Used as a sandbox escape.

    No remote code execution vulnerabilities being addressed in this update are known to be under active attack.

    MS14-057

    (.NET Framework)

    An attacker sends malicious data to a vulnerable web application.

    Critical

    1

    MS14-060

    (Windows OLE Component)

    Victim opens malicious Office document that exploits the vulnerability resulting in a malicious executable being run.

    Important

    0

    Exploitation of CVE-2014-4114 detected in the wild.

     Using a non-administrator account or setting UAC to “Always Prompt” helps mitigate the impact of this vulnerability.

    MS14-061

    (Word)

    Victim opens a malicious Word document.

    Important

    1

     

    MS14-062

    (Kernel mode drivers [msmq.sys])

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM.

    Important

    1

    This vulnerability only affects Windows Server 2003.

    MS14-063

    (Kernel mode drivers [fastfat.sys])

    Important

    2

     

    Requires the ability to physically plug a USB stick in to the computer.

    MS14-059

    (ASP.NET MVC)

    Victim opens a malicious link

    Important

    3

    This is a Cross Site Scripting vulnerability. The XSS Filter, which is enabled by default in IE8-IE11 in the Internet Zone, prevents attempts to exploit this vulnerability.

     

    - Joe Bialek and Suha Can, MSRC Engineering

     

  • Assessing risk for the September 2014 security updates

    Today we released four security bulletins addressing 42 unique CVE’s. One bulletin has a maximum severity rating of Critical and the other three have maximum severity Important. This table is designed to help you prioritize the deployment of updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploitability Index Rating Platform mitigations and key notes
    MS14-052

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 0

    Exploitation of CVE-2013-7331 detected in the wild as an information disclosure to determine whether EMET or a third party anti-malware product is installed prior to launching exploit for different vulnerability.

    No remote code execution vulnerabilities being addressed in this update are known to be under active attack.
    MS14-054

    (Task Scheduler)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1  
    MS14-053

    (.NET Framework)

    Attacker causes compute resource exhaustion denial of service on ASP.NET webserver by sending maliciously crafted HTTP/HTTPS requests. Important 3 Systems only affected if ASP.NET is explicitly installed, enabled, and registered with IIS.
    MS14-055

    (Lync Server)

    Attacker causes Lync server to fail by sending maliciously crated SIP invite requests to victim Lync server. Important 3 Vulnerability is remote, unauthenticated denial-of-service but attacker must first have access to information present in a valid Lync Server meeting request.

    - Jonathan Ness, MSRC

  • Assessing risk for the August 2014 security updates

    Today we released nine security bulletins addressing 37 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other seven have a maximum severity rating of Important. This table is designed to help you prioritize the deployment of 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
    MS14-051

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 0 Exploitation of CVE-2014-2817 detected in the wild.  Used as a sandbox escape.  
    MS14-043

    (Media Center)

    On Media Center-equipped workstations (Win8.x Pro and all Win7 except Starter and Home Basic), victim opens malicious Office document or browses to malicious webpage that instantiates Media Center ActiveX control. Critical 2 Less likely to see reliable exploits developed within next 30 days. Server SKUs not affected. Windows 8 and Windows 8 RT not affected. Win7 Starter and Home Basic not affected.

    Our repro is via Office document (Important class vector) not via ActiveX control but we believe the code is reachable via ActiveX.

    MS14-048

    (OneNote)

    Victim opens malicious OneNote file that creates a file in startup folder leading to arbitrary code execution on next login. Important 2 Less likely to see reliable exploits developed within next 30 days. OneNote 2010 and OneNote 2013 not affected. (Only OneNote 2007 affected.)
    MS14-045

    (Kernel mode drivers [win32k.sys])

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 2 Less likely to see reliable exploits developed within next 30 days.  
    MS14-049

    (Microsoft Installer)

    Attacker already running code at low privilege on a system where an MSI source location is available to low privilege users can tamper with the MSI and initiate a Repair operation to potentially run code as LocalSystem. Important 2 Less likely to see reliable exploits developed within next 30 days.  
    MS14-044

    (SQL Server denial-of-service)

    Attacker able to authenticate at user level to SQL Server can run a TSQL batch command that causes a stack overrun that causes the server to stop responding. Important 2 Less likely to see reliable exploits developed within next 30 days.  
    MS14-050

    (SharePoint)

    Victim installs a malicious third party SharePoint app that could potentially run arbitrary JavaScript that is run as the victim user as a custom action. Important 2 Less likely to see reliable exploits developed within next 30 days.  
    MS14-046

    (.NET Framework 2.0 ASLR bypass)

    Attacker combines this vulnerability with a (separate) code execution vulnerability to compromise a system. Important 2 Less likely to see reliable exploits developed within next 30 days. This vulnerability does not result in code execution directly. However, it is a component attackers could potentially use to assist in bypassing ASLR. This potential ASLR bypass is not known to be in use in real-world attacks.
    MS14-047

    (LRPC ASLR bypass)

    Attacker already running code on a machine can combine this vulnerability with a (separate) code execution vulnerability to compromise a system by connecting to locally-listening service and filling address space to more accurately predict future memory allocation. Important 3 Unlikely to see reliable exploits developed within next 30 days. This vulnerability does not result in code execution directly. However, it is a component attackers could potentially use to assist in bypassing ASLR if attacker is already running code locally.

    - Jonathan Ness, MSRC

  • Announcing EMET 5.0

    Today, we are excited to announce the general availability of the Enhanced Mitigation Experience Toolkit (EMET) 5.0. As many of you already know, EMET is a free tool, designed to help customers with their defense in depth strategies against cyberattacks, by helping detect and block exploitation techniques that are commonly used to exploit memory corruption vulnerabilities. EMET 5.0 further helps to protect with two new mitigations and several other improvements. You can download EMET 5.0 from the Microsoft Download Center.

    Let’s start with the two new mitigations, which we initially introduced in EMET 5.0 Technical Preview: the Attack Surface Reduction (ASR), and the Export Address Table Filtering Plus (EAF+). We already described details about these two new mitigations in the Technical Preview announcement blog post, but let’s talk briefly about the improvements made during the preview period.

    Attack Surface Reduction (ASR)

    The ASR is a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET 5.0 to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET 5.0 to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.

    During the preview period we have performed several tests and collected your feedback to finalize the default configuration for this mitigation. We aimed at having a configuration that provided security, and at the same time, did not limit the user experience with the applications protected by EMET 5.0. By default, EMET 5.0 is configured to block some modules and plug-ins from being loaded by Internet Explorer while navigating to websites belonging to the Internet Zone, and to also block the Adobe Flash plug-in from being loaded by Microsoft Word, Excel, and PowerPoint. We have chosen modules that are commonly used in certain exploitation scenarios, but like all EMET features and mitigations, the ASR is completely configurable to satisfy everybody’s needs and to be tailored to specific systems’ requirements.

    Internet Explorer ASR default configuration

    Export Address Table Filtering Plus (EAF+)

    The EAF+ starts by the same concept as the existing Export Address Table Filtering (EAF) mitigation, but it amplifies its scope and robustness. During the Technical Preview, we have presented the EAF+ as an extension to the EAF. During the last couple of months we have made several improvements to it, and we decided that it should be a new mitigation on its own.

    As already mentioned in the Technical Preview blog post, when EAF+ is enabled it adds the following additional safeguards:

    • Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules
    • Prevent memory read operations on the PE header, sections, import/export table pointers of selected modules when they originate from suspicious code that may reveal memory corruption bugs used as “read primitives” for memory probing

    These improvements help detect and disrupt some current techniques used to dynamically discover ROP (Return Oriented Programming) gadgets and reliably execute code when a vulnerability is exploited.

    Additional improvements

    EMET 5.0 introduces many other improvements. Let’s go through them and see what customer benefits they add.

    64-bit Return Oriented Processing (ROP) mitigations

    Many ROP mitigations are now available also for 64-bit processes: Deep Hooks, Stack Pivot, Load Library, and MemProt. Although we have not yet detected exploits that use ROP techniques to exploit 64-bit applications, we decided to extend the anti-ROP mitigations to this architecture to be ready when the time comes.

    Strict checks for Certificate Trust rules

    The Certificate Trust’s pinning rules can now be configured with a more aggressive “blocking” mode (not enabled by default), so that EMET 5.0 can force Internet Explorer to terminate the SSL connection without sending session data instead of just detecting the untrusted certificate.

    Certificate Trust Blocking Rule option

    EMET Service

    We have added a new service, called EMET Service, which is taking in charge many duties that EMET Agent used to do in previous versions. The EMET Service, among other things, takes care of evaluating the Certificate Trust rules, appropriately dispatching EMET Agents in every user’s instance, and automatically applying Group Policy settings pushed through the network. Also, a service offers more resiliency and better ability to being monitored.

    Hardening and better application compatibility

    We have seen a technique to potentially bypass some of the EMET 4 mitigations. This technique is possible when a memory corruption within an EMET-protected application can be abused to overwrite selected memory areas and corrupt data belonging to EMET itself. We have also seen techniques aiming at disabling the EAF mitigation by invoking some specific API calls. In EMET 5.0 we worked to harden against potential bypass techniques.

    We also refactored many components of the EMET 5.0 engine, in order to maximize application compatibility, also with some popular anti-malware products, and reduce potential false-positives.

    We have done a lot of work to bring EMET 5.0 to life, and we want to thank all those who provided feedback during the Technical Preview time frame, either through emet_feedback@microsoft.com or through the EMET Connect Portal (which we’ll continue to use). Your feedback helped to create a great version of EMET. Now, we are giving you back the product that you helped us build. We invite you then to download EMET 5.0, install it, and let us know what you think.

    The EMET Team:

    Adam Zabrocki, Andy Renk, Chengyun Chu, Cristian Craioveanu, Elia Florio, Elias Bachaalany, Gerardo Di Giacomo, Neil Sikka

  • Assessing risk for the July 2014 security updates

    Today we released six security bulletins addressing 29 unique CVE’s. Two bulletins have a maximum severity rating of Critical, three have maximum severity Important, and one is Moderate. 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
    MS14-037

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses 23 remote code execution issues and one lower severity Security Feature Bypass vulnerability.
    MS14-038

    (Windows Journal)

    Victim opens malicious .JNT file or navigates with Explorer to a WebDAV share under attacker control where a malicious .JNT file is automatically rendered. Critical 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-040

    (AFD.sys)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-041

    (Sandbox escape via DirectShow)

    Attacker running code at low integrity level runs exploit binary to elevate to context of logged-on user. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-039

    (Sandbox escape via on-screen keyboard)

    Attacker running code at low integrity level runs exploit binary to elevate to context of logged-on user. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-042

    (Service Bus)

    Attacker could cause Service Bus to stop responding to incoming AMQP messages. Moderate n/a Lower severity issue unlikely to see significant attacker interest. Windows Azure not affected.

    - Jonathan Ness, MSRC