Security Research & Defense

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

June, 2014

  • 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