Reference: CERT-EU Security Advisory 2016-132

Title: SMB bug allows to leak user login and NTLMv2 hashes.

Version history: 03/08/2016 correcting hash threats and breaking links
for AV compatibility.


Summary:


The Server Message Block (SMB) protocol is a network protocol allowing
files and printers sharing over different networks (TCP/IP included).



There have been several versions of the protocol, SMB version 2.1 first
shipped with Win7, SMB version 3.0 with Win8 and Windows Server 2012 and
SMB version 3.2 with Win8.1 and Windows Server 2012 R2. Latest versions
of the protocol requires NTLMv2 based authentication.



According to recent researches [1,2], an old vulnerability affecting
WinNT/Win95 allows to silently forward to an external site the computer
name. user login and the NTLMv2 hash, when a resource downloaded from an
external server offers a shared object (typically a file or image)
through SMB. This circumvents the Default User Authentication Policy for
the browsers (IE, Edge/Spartan), which should pron for username and
password instead of sending the domain/local credentials. The
vulnerability is also present in all products which can communicate over
Internet using the Windows API, such as Outloook.



It is important to note:


- In Windows 8 and 10, the same bug has now been found to potentially
leak the user=E2=80=99s Microsoft Live account login and (hashed) password
information, which is also used to access OneDrive, Outlook, Office,
Mobile, Bing, Xbox Live, MSN and Skype (if used with a Microsoft
account) [3].

- If the system is connected using built-in VPN connection protocols
(IPsec, PPTP, L2TP) with MSCHAPv2 authentication then Windows would
transmit not your account credentials but VPN username and password hash
(EAP is not affected)






Products Affected:


All SMB versions deployed with Windows since WinNT/Win95.



We have checked the vulnerability of a system running Win7 SP1
(6.1.7601) with IE 8 on [3]. Take in account that if the server manages
to crack the hash the password of the system is stored in the test
server, so do not try with a platform in production.





Recommendations:


1. Mitigation:
Enforcing egress filtering on ports 137/138/139/445 and dropping any IP
packet leaving the host with any destination matching any of those
ports, having a public IP as destination address [2].


2. Detection strategy
Enabling AUDIT for NTLM, go to: Windows group policy =C2=BB Computer
Configuration =C2=BB Windows Settings =C2=BB Local Policies =C2=BB Security=
 Options
Network security: Restrict NTLM: Outgoing NTLM traffic to remote
servers. Setting "Audit all," the client computer logs an event for each
NTLM authentication request to a remote server. This allows to identify
those servers receiving NTLM authentication requests from the
client computer.

These logs can be checked with Event viewer: Applications and Services
Log/Microsoft/Windows/NTLM/operational checking for event id 8001,
target server: cifs/URL and name of the client process iexplore.exe or
outlook or any other process that can use SMB. These tasks can be
automated by your SIEM.






References:

[1]
htXps://medium.com/@ValdikSS/deanonymizing-windows-users-and-capturing-micr=
osoft-and-vpn-accounts-f7e53fe73834

[2]
htXps://www.blackhat.com/docs/us-15/materials/us-15-Brossard-SMBv2-Sharing-=
More-Than-Just-Your-Files-wp.pdf

[3]
htXps://www.perfect-privacy.com/blog/2016/08/01/security-issue-in-windows-l=
eaks-login-data/

[4]
htXps://hackaday.com/2016/08/02/microsoft-live-account-credentials-leaking-=
from-windows-8-and-above/



Best Regards,

CERT-EU Team (http://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: cert-eu@ec.europa.eu
PGP KeyID 0x46AC4383
FP: 9011 6BE9 D642 DD93 8348 DAFA 27A4 06CA 46AC 4383
Privacy Statement:
http://cert.europa.eu/cert/plainedition/en/cert_privacy.html