Security Research & Defense

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

Security Research & Defense

  • 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)

  • Accessing 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

  • Assessing risk for the June 2014 security updates

    Today we released seven security bulletins addressing 66 unique CVE’s.  Two bulletins have a maximum severity rating of Critical while the other 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 XI Likely first 30 days impact Platform mitigations and key notes
    MS14-035

    (Internet Explorer)
    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. CVE count (59) is result of focusing on in-the-wild exploits last month. These are the May + June fixes for issues not under active attack.
    MS14-034

    (Word 2007)
    Victim opens malicious Office document. Important 1 Likely to see reliable exploits developed within next 30 days. Issue addressed in embedded font parsing. Reachable via either doc or docx.  Word 2010 and later not affected.
    MS14-036

    (GDI+)
    Victim open malicious graphics file or malicious PowerPoint document Critical 1 Likely to see reliable exploits developed within next 30 days. Issue addressed is in EMF+ record type parsing, an area we have not seen real-world attackers pursue recently.  (Hence, table lists Word security update ahead of GDI+ update.)
    MS14-033

    (MSXML)
    Victim browses to a malicious webpage or opens a malicious document, inadvertently sending local path name of downloaded file to attacker.  Path name by default includes the user’s login name. Important 3 Less likely to see widespread usage of information disclosure vulnerabilities. Information disclosure only.
    MS14-030

    (Terminal Services)
    Attacker acting as man-in-the-middle at the start of a Remote Desktop session may be able to read information from or tamper with RDP session. Important n/a Less likely to see widespread usage of vulnerabilities enabling tampering. Terminal Services NLA feature mitigates this vulnerability.

    MS14-031

    (TCP)
    Attacker initiates large number of connections with malformed TCP options.  Each connection temporarily consumes non-paged pool memory longer than it should, leading to resource exhaustion. Important 3 Less likely to see widespread usage of vulnerability allowing resource exhaustion denial-of-service only. Attacker must control TCP Options fields.  Attacker would be unable to cause denial-of-service for systems behind network infrastructure that overwrites the TCP Options field.
    MS14-032

    (Lync Server XSS)
    Victim clicks on a specially-crafted malicious link to an established Lync meeting.  Attacker can take action in context of Lync Server service that victim would normally have access to take. Important 3 Less likely to see widespread usage of this vulnerability. XSS style vulnerability.

     

    - Jonathan Ness, MSRC engineering team

     

     

  • An Overview of KB2871997

    An Overview of KB2871997

    Microsoft recently released KB2871997 for Windows 7, Windows 8, Windows Server 2008R2, and Windows Server 2012. This blog will give an overview of the feature changes, their impact, and some important configuration changes that can be made in conjunction with the update to further improve system security.

    1. Support for the Protected Users group

    “Protected Users” is a security group added to Windows Server 2012R2 domains. When a user account is added to the “Protected Users” group, several additional security restrictions are placed on the account:

      1. A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.
      2. The Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. This means that the domain must be configured to support at least the AES cypher suite.
      3. The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.

    In a nutshell, this setting blocks everything besides Kerberos authentication and applies hardening to the Kerberos authentication used (enforces AES encryption). We recommend you place high value accounts, such as accounts used by server administrators, in the “Protected Users” group to harden the accounts.

    Since a “Protected User” is restricted to Kerberos authentication they work well with “Authentication Policies and Silos”, a new feature introduced for Windows 2012R2 functional level domains. Authentication Policies and Silos allow you to place users and computers within a silo and apply policy (such as logon restrictions) to them. More information on “Authentication Policies and Silos” can be found here: http://technet.microsoft.com/en-us/library/dn486813.aspx.

    2. Remote Desktop Client support for the Restricted Admin RDP mode

    Part of Microsoft’s official guidance for reducing the risk of lateral movement (or pass-the-hash) attacks is to authenticate to servers using a “network logon” (a specific Windows logon type). Why? Because when a user authenticates to a remote server using a “network logon”, the users credential is never sent to the remote server. This means that even if the remote server is compromised, the users credential cannot be captured.

    Virtually every management tool Microsoft ships authenticates using “network logon”. This includes but is not limited to: PowerShell Remoting, WinRM, PSExec, WMI, etc… Prior to this update, Remote Desktop required the user send their clear-text password to the remote server (encrypted over-the-wire but decrypted on the remote server) so they could log on for an interactive session. With this update, it is now possible to use Remote Desktop without sending credentials to the remote server.

    Note that this update back ports changes to the Remote Desktop client, not Remote Desktop server. This means you can make Restricted Admin connects from an updated system, but you can only make Restricted Admin connects to a Windows 8.1/2012R2 system.

    Only administrators can use the “Restricted Admin” mode; members of the “Remote Desktop Users” group are not allowed to use the Restricted Admin mode. Because the users credential is not sent to the remote system, it is impossible for the user to make authenticated connections from the remote system to other systems. Since the user connecting to the system is an administrator (and can by-design impersonate other users on the system), we have made Restricted Admin connections automatically impersonate the computer account for remote connections. This allows a Restricted Admin to access network resources such as shares as long as the computer account has access.

    Microsoft recommends that Restricted Admin is used whenever possible, as this follows the “least privilege” principal. If you are authenticating to a server (even a highly trusted server) and do not need to “double hop” with your privileged account, it is recommended you use Restricted Admin. One common scenario that will greatly benefit from Restricted Admin is the “helpdesk scenario” where a helpdesk agent uses remote desktop with a privileged account to repair user workstations.

    Restricted Admin can be used by starting Remote Desktop as follows:

    Mstsc.exe /restrictedadmin

    3. LSA Credential Cleanup & Other Changes

    a. Removal of credentials after logoff

    As outlined in Microsoft’s Pass-the-hash whitepaper, Windows caches the credentials of a user in the LSASS process whenever the user logs in. This includes the user’s clear-text password, the users NT/LM password hash, and the users Kerberos TGT/Session key. When the user logs off, the credentials should be cleared out of memory. Prior to this update, this was not always the case. This issue preventing credentials from being cleared is now fixed, credentials will always be cleared from memory after a user logs off.

     b. New well known SID’s

    This update adds support for two new well known SID’s:

    1. LOCAL_ACCOUNT – Any local account will inherit this SID
    2. LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP – Any local account that is a member of the administrators group will inherit this SID

    These SID’s were introduced to make it easier to prevent local accounts from being used over the network (something attackers commonly do when performing pass-the-hash attacks). An administrator can configure the Group Policy settings “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services” using the above SID’s to prevent attacks from using local accounts over the network. More information on these settings (and detailed instructions) can be found in Microsoft’s Pass-The-Hash whitepaper.

    c. Removal of clear-text credentials from LSASS

    As noted previously, one of the credentials stored by LSASS is the user’s clear-text password. This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password. WDigest still stores the user’s clear-text password because it cannot function without the user’s password (Microsoft does not want to break existing customer setups by shipping an update to disable this). Microsoft recommends users look through their domain controller logs for Digest authentication logons (instructions provided below); if Digest authentication is not being used, customers can apply the FixIt found on the KB article to disable WDigest. Doing this will eliminate all clear-text credentials from LSASS memory.

    It’s important to realize that while clear-text credentials will no longer be stored, the NT hash and Kerberos TGT/Session key will still be stored and are considered credentials (without credential equivalents stored in memory, single sign-on would be impossible). Additionally, even though the clear-text credentials are no longer stored in memory, an attacker can use other techniques such as key loggers to recover clear-text passwords. Eliminating clear-text passwords from memory is useful and reduces risk, but it is not guaranteed to stop attackers.

                 

    Identifying WDigest use:

    WDigest use can be identified in two places: your domain controller logs, or your server logs (every server must be checked).

    1.       Domain Controller Security Event Logs: Event ID 4776

    Authentication Package:     WDigest

    Logon Account:    Administrator

    Source Workstation:             WIN2K12R2CLIENT

    Error Code:             0x0

     

    2.       Server Security Event Logs: Event ID 4624 (must be checked on all servers)

    An account was successfully logged on.

    Subject:

                    Security ID:                            NULL SID

                    Account Name:                     -

                    Account Domain:                 -

                    Logon ID:                               0x0

    Logon Type:                                          3

    Impersonation Level:                            Impersonation

    New Logon:

                    Security ID:                            TESTLAB\administrator

                    Account Name:                     Administrator

                    Account Domain:                 TESTLAB

                    Logon ID:                               0x2D8B63

                    Logon GUID:                          {00000000-0000-0000-0000-000000000000}

    Process Information:

                    Process ID:                             0x0

                    Process Name:                      -

    Network Information:

                    Workstation Name:              -

                    Source Network Address:    ::1

                    Source Port:                           57514

    Detailed Authentication Information:

                    Logon Process:                     WDIGEST

                    Authentication Package:     WDigest

                    Transited Services:                -

                    Package Name (NTLM only):              -

                    Key Length:                           0

     

     

     

    - Joe Bialek, MSRC Engineering

  • MS14-025: An Update for Group Policy Preferences

    Today, we released an update to address a vulnerability in Group Policy Preferences (MS14-025). Group Policy Preferences was an addition made to Group Policy to extend its capabilities. Among other things, Group Policy Preferences allows an administrator to configure:

    • Local administrator accounts (name of the account, account password, etc)
    • Configure a service or scheduled task (allowed to specify alternate credentials to run as)
    • Mount network drives when a user logs in (allowed to specify alternate credentials to connect with)

    Group Policy Preferences are distributed just like normal group policy: An XML file containing the settings is written to the SYSVOL share of the domain controllers, and computers periodically query the SYSVOL share (authenticating to it using their computer account) for updates to the group policy.

    Several of the Group Policy Preferences allow credentials to be specified. When this option is used, the password is symmetrically encrypted using a static key and written to the XML file along with the rest of the settings. What is this key you ask? It turns out, we document it on MSDN: http://msdn.microsoft.com/en-us/library/cc422924.aspx.

    If an attacker is able to get access to the SYSVOL share (which is open to all authenticated users, so a malicious or spear phished employee will have access to it) and obtain the AES encryption key used to encrypt/decrypt passwords set with GPP (which we document on MSDN), the attacker will be able to obtain the credentials set with GPP.

    Microsoft has observed that Group Policy Preferences abuse is one of the most common tactics used by attackers to elevate permissions in a domain. Multiple toolkits used by attackers such as Metasploit (http://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) and PowerSploit (https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) provide easy to use methods for retrieving and decrypting GPP passwords. In the worst case scenario, companies use Domain Administrator credentials in their Group Policy Preference accounts, resulting in a full domain compromise as soon as the attacker is able to access with SYSVOL share (and decrypt the passwords using the documented key).

    Microsoft has released an update to change the behavior for this issue, but companies using GPP need to take action. Microsoft has removed the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials. The only action that can be performed on such a Group Policy is “delete”. Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature. You can see in the picture below that when attempting to create a local account the “username” and “password” fields are disabled. If you attempt to create a user, an error dialog will be displayed.

    In addition to the change in behavior, Microsoft is providing customers with two PowerShell scripts. The first script, Enum-SettingsWithCpassword, will search existing GPO’s for use of the account password functionality. We urge companies to immediately run this script and delete vulnerable GPO’s detected.

    The second script, Invoke-PasswordRoll, can be used to set local administrator passwords on remote systems (something that Group Policy Preferences is commonly used for). The script takes a list of usernames and computers, and uses PowerShell remoting to connect to each computer and change each specified usernames password to a randomized password. The username/password combinations will be written recorded in a file on disk (which is encrypted, but optionally can be stored in clear-text). Note that the script enforces randomized passwords to ensure the local accounts cannot be used in pass-the-hash attacks.

    You can find both scripts at http://support.microsoft.com/kb/2962486.

    - Joe Bialek, MSRC engineering team

  • Load Library Safely

    Dynamically loading libraries in an application can lead to vulnerabilities if not secured properly. In this blog post we talk about loading a library using LoadLibraryEx() API and make use of options to make it safe.

    Know the defaults:

    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not contain an extension. If one is not specified, then the default library file extension, .DLL, is used. As a result of this feature, if a null is passed as library name it tries to load ".DLL" which could be exploited by placing a ".DLL" in the path searched.
    • The library file name passed to LoadLibrary() / LoadLibraryEx() call need not specify a directory path. If one is specified, library is loaded only from the specified path. Otherwise, following default DLL search order is used:
    1. The current process image file directory, application directory.
    2. The system directory.
    3. The 16 bit system directory.
    4. The windows directory.
    5. The current working directory.
    6. The directories listed in the PATH environment variable.
    • Windows maintain a list known DLLs, which are basically a set of system DLLs, that are always guaranteed to load from the system directory when absolute name is specified.
    • DllMain() function within the loaded library is called after loading the library into memory.

    Control the DLL search order:

    There are various option to modify the order in which the loading library is searched other than the default search order when absolute name is provided.

    Some of the APIs that can influence the DLL search order/path by the LoadLibraryEx() are as below:

    LoadLibraryEx() provide many flags that can be used to alter the default search order. Below table lists most of the flags and also depicts the DLL search order that is followed for each of them. Some of the options even consider the paths set with above mentioned APIs.

     
    Table 1: Depicting different options to the LoadLibraryEx and how it affects the DLL search order.
     

    Loading library as non-executable:
    It is not always required to load a library as an executable image. LoadLibraryEx() makes it possible to load a library as a data file, or an image resource, for example. For this purpose, it supports following different options:

    • LOAD_LIBRARY_AS_DATAFILE
    • LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
    • LOAD_LIBRARY_AS_IMAGE_RESOURCE
    • DONT_RESOLVE_DLL_REFERENCES

    These options helps in treating a file as a normal data file rather as an executable module. Loading with this option doesn't call DLLMain() and none of the memory space of the loaded DLL data is marked as executable.

    Blocking the library from loading:
    Sometimes it might be required to block a library or block an illegitimate library from loading into an application. Check out following facilities to aid that:

      • AppLocker is a policy based mechanism to block DLLs from loading into applications. These policies can be pushed via group policy. AppLocker can control executables, scripts and installers.
      • When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker calls the Application Identity component to calculate the file attributes. It duplicates the existing process token and replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL. AppLocker then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result of this check, the system either continues to load the DLL or stops the process.
      • AppLocker can block the DLL based on path, publisher or file hash.
      • Microsoft Authenticode technology can be used to sign the DLL, which is to attach digital signatures to the DLL to guarantee its authenticity and integrity.

    To summarize our discussion:

    To ensure secure loading of libraries

    • Use proper DLL search order.
    • Always specify the fully qualified path when the library location is constant.
    • Load as data file when required.
    • Make use of code signing infrastructure or AppLocker.

    Some common attack vectors we see:

    • Application directory attacks, especially from the temporary internet or download folder perspective. Particularly when the application is an installer, it is a common thing for people to download the installer into default directory and execute from there. Considering attacker can drop malicious file in the default directory can make use of application directory to load the DLLs. Manifest and .local redirection can also be used in this scenario.
    • Loading DLL from memory and also Powershell DLL injection. Which can be used by malwares to keep the loading of a malicious DLL from getting detected.
    • TOCTOU attacks when loading library from remote location.

    - Swamy Shivaganga Nagaraju, MSRC engineering team