Windows has been around a long time. After years of evolving from one version to another, it is rare to find vulnerabilities that allow remote code execution from Windows XP to Windows 8.1 (32 and 64-bit) without any user interaction. In this blog post, I'm going to explain what I had to do to exploit this bug fixed in MS15-011 by Microsoft, integrating and coordinating the attack in one module. It should also be noted that on February 10, 2015 Microsoft released 9 fixes for their software including SMB.
Patch installed but not configured?
Although this fix was released some months ago, if the fix was installed but the "Hardened UNC paths" weren't configured, the user is still vulnerable to this attack. For the correct configuration, you can skip to the section "Configuring UNC Hardened Access through Group Policy" in this Microsoft Support article.
Bug explanation
When a computer joins a domain (e.g. "corp.contoso.com"), usually the client asks the domain controller for new policies (GPOs) via SMB. The file requested by the client is "gpt.ini", which is usually located at "\\DOMAIN_CONTROLLER\SysVol\corp.contoso.com\Policies\{UUID}". The file content is small and almost always is similar to this:
[General] Version=12345
When the client receives this file, it checks the version number. If it's different from the previous version, it starts to download new policies from the domain controller. In this schema, we assume that the domain controller is the real server. But what would happen if an attacker, through a MiTM attack, is able to re-direct the client connection to a fake domain controller? Microsoft decided to remediate this problem by adding a fix on the client side. The client checks if the domain controller is real -- this fix forces it to use “SMB signing” in SMB connections, but not by default. A complete description of the bug can be found here.
Attack scenario - "Coffee Shop"
When the fix was released, Microsoft gave a typical attack scenario, a "coffee shop". The victim machine asks for the "logon.bat" file to "Target Data system" (IP: 10.0.0.100). The attacker also poisons the "Local Switch or Access Point" via an "ARP Spoofing attack". As a result, the SMB client connection is redirected to a fake SMB server and the client finishes executing the "logon.bat" file from a malicious server with the same IP address as the real server (10.0.0.100). It would be interesting to see statistics on how many computers are actually used at coffee shops to log on domain controllers located outside of the local network. Note: In the logging process, the file "logon.bat" is downloaded and executed by clients from the domain controller, as long as the server administrator has enabled this option.
Attack scenario - "LAN networks"
Another possible scenario, and probably the most affected, is LAN networks. Usually, in small networks, the domain controller can be found at the same network segment as clients. Thus, a switch or computer could be poisoned via ARP Spoofing. As a result, a MiTM attack is feasible between computers and the domain controller. Theorizing a bit more, what happens if the domain controller doesn't belong to the same network segment as the clients? If that is the case, an attacker can use ARP Spoofing to poison the ARP tables of both switches and hosts, redirecting the traffic meant for the gateway to a MAC address of the attacker's choice, impersonating the domain controller. In medium and large networks, this scenario is the most common.
Exploitation
When a policy update is redirected to a new fake domain controller, via a "Man In The Middle Attack", it could send the client nefarious policies and change Windows registry keys, finalizing the attack with code running in the target as "system" user. Why "system" user ? ...Because GPOs are downloaded and applied from a Windows service. One file downloaded in the GPO update is "GptTmpl.inf", it contains a section called "[Registry Values]" where any Windows registry key can be added/changed/deleted.
Core Impact Pro's exploit
The goal of this exploit was to coordinate the entire attack in one module, so the user wouldn't have to pass any parameters. After more than two months of work, here’s the result! It was necessary to write:
- A "Default Gateway" spoofer
- A "Port Forwarder Rule Manager"
- A "Fake SMB" server
- The exploit
The "Default Gateway" spoofer
A small part of this module is focused on convincing targets located on the same network segment that the default gateway has a new mac address via "ARP Spoofing". It's not difficult to do if the switches used in the local network purposely allow this or are improperly configured. Another little part of this module is focused on automatically getting the default gateway address by asking for the DHCP server. Once the target was "cheated", all the network traffic sent to the default gateway, and therefore to the domain controller, will be received by the fake default gateway. Here's where we start to see a problem. If we don't want the target to realize it was cheated and instead to think it is working correctly, we should allow all traffic sent to the fake default gateway to be forwarded to the real default gateway. At this point, the functioning of this module is similar to the "port forwarding", where the MiTM receives connections at the IP spoofed address (the real default gateway address) and these connections are forwarded with another source IP address (public IP) to the real default gateway.
The "Port Forwarder Rule Manager"
The objective of this module is to set rules in the default gateway spoofer to redirect TCP/UDP connections to other destinations. In the case of this exploit, the SMB connections will be forwarded to a fake SMB server. The default gateway spoofer module receives data from the network using PCAP, and disassembles network packets using Impacket. This combination allows the module to modify any packet field over ethernet, IP or TCP/UDP/ICMP layer and recalculate the packet checksum to resend it to the network. Thus, a TCP connection can be re-directed to another IP by modifying only a couple of fields, all in the glory of Python.
The "Fake SMB" server
As I said before, the client finishes downloading new policies from a fake SMB server -- so what is the best SMB server to use? If the attack was launched from Windows, I could share a folder called "\SysVol\corp.contoso.com\Policies\{UUID}" where the UUID should be obtained in runtime. On the other hand, if the attack was launched from Linux, Samba could be used, repeating what we covered earlier. In general, the best option is to have a portable SMB server listening from a different TCP port than 445, redirecting SMB connections to it. This way, problems can be avoided when reusing the 445 TCP port, especially on Windows. The fake SMB server that I decided to use was "karmaSMB", it allows file sharing using UNC paths like "\\EVIL_SMB_SERVER\*\..\*\gpt.ini" where paths are ignored and only file names are used. This module was written by Alberto Solino (@agsolino) as a MS15-011 PoC and can be downloaded here.
The exploit
The registry key overwritten was "AppInit_DLL" located at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows". This key is used by Windows each time a program is executed, which allows to inject a DLL in the process memory when it's being launched. In my exploit, the registry value used was "\\DOMAIN_CONTROLLER\evil.dll", where the DLL requested is also redirected to the "Fake SMB server". It was necessary to check some situations because "evil.dll" is loaded by every single program launched in the target, from user programs as "calc.exe" to system programs as "svchost.exe". If the attack was successful, an Impact agent running as "system" user is installed on every vulnerable computer joined to an affected domain controller.
Attack sequence
This is a regular scenario, two computers located on the same network segment and the domain controller located behind the default gateway.
You can see "target" and "attacker" directly connected to the "Default Gateway".
The "attacker" starts the "ARP Spoofing" attack to cheat the "target".
The "target" was cheated and the MiTM starts to work. All connections sent to the "Default Gateway" are intercepted by the "attacker".
The "target" asks for new GPOs to the "Domain Controller".
The request for new GPOs is redirected to the "Fake" SMB server.
When the "target" receives new "fake" GPOs, the exploit starts finalizing the attack with the owned target.
Demo
In this demo, we can see the attack/exploit in real time. The target is Windows 7 joined to a domain controller. When it starts, new GPOs are downloaded from Core Impact Pro.
Final notes
When the fix was released, this attack was demonstrated here. While it’s definitely weird to find bugs remotely exploitable in Windows, it is increasingly common to see exploits that use more than one vulnerability to take control of targets. In this exploit, we could see a combination of:
- "ARP Spoofing Attack"
- "Default Gateway MiTM Attack"
- "Lack of SMB Server Checking" by the client (SMB SIGNING DISABLED).
