Originally Posted by hdm
Today, Microsoft released bulletin MS08-068, which addresses a well-known flaw in the SMB authentication protocol. This attack was first publicly documented by Sir Dystic during @tlantacon in 2001 and implemented in Metasploit 3 in July of 2007. The attack abuses a design flaw in how SMB/NTLM authentication is implemented and works as follows.
The SMB client tries to access a remote SMB service on an attacker's machine. A user can be forced to access the SMB resource if they are running Internet Explorer or Outlook by sending them to a UNC link. This can be accomplished with an IMG tag like the following:
The attacker's SMB server is configured to deny access to anonymous users (NULL sessions). This forces Windows to authenticate using the username, domain, and password of the logged-in user. The password is first hashed based on the LANMAN/NTLM mechanism. During the authentication process, a random eight byte challenge key is sent from the server to the client. The hashed LANMAN/NTLM password is then encrypted again with the server-supplied challenge key. The actual password hash sent across the network to the server is unique for a particular password and challenge key. The username and domain are sent in clear text.
The challenge key is where things get interesting. If the server intentionally picks a static challenge key for every connection, it is possible to perform a rainbow table attack against the password hash. In this scenario, the attacker would have precalculated the value of every possible password encrypted against the static challenge key. A set of rainbow tables for "HALF-LANMAN" hashes can be found at the Free Rainbow Tables web site. Even without a rainbow table, the challenge-key password hash can be brute forced with tools like Cain & Able and Ophcrack. This is the attack implemented by the original version of SMB Relay and the SMB Capture module of the Metasploit Framework. The MS08-068 patch does not address this issue, since its part of the protocol design.
Taking this further, the attacker can connect back to the victim, ask them for their challenge key, and then pass this key back to the victim's client connection. The client will then encrypt their hashed password against this key and send it to the attacker. The attacker then uses this hashed password to authenticate back to the victim, using their own credentials against them. This is the attack implemented by SMB Relay 2, the Metasploit Framework, and the one patched today in MS08-068.
The Metasploit module takes over the established, authenticated SMB session, disconnects the client, and uses the session to upload and execute shellcode in a manner similar to how psexec.exe operates. First, a Windows executable is created that acts like a valid Windows service and executes the specified Metasploit payload. This payload is then uploaded to the root of the ADMIN$ share of the victim. Once the payload has been uploaded, the Service Control Manager is accessed over DCERPC (using a named pipe over SMB) and used to create a new service (pointing at the uploaded executable) and then start it. This service creates a new suspended process, injects the shellcode into it, resumes the process, and shuts itself down. The module then deletes the created service. At this point, the attacker has a remote shell (or other payload session) on the victim.
There are some caveats. First, the victim must have ports 139 or 445 open and accessible to the attacker. Second, the victim's user account must have administrative access to their own machine. Third, if the victim's OS is Windows XP or 2003, they must have a password set for their account. Fourth, if the machine is XP, the system must be configured to allow remote network logins as the specified user and not Guest (the default). The exploitable setting becomes the default when the machine joins a Windows domain. Fifth, the user must have access to write to ADMIN$ and permissions to create and start Windows services. While most administrative accounts have these rights, domain policies can come into play. Finally, if SMB signing is configured as mandatory, this attack won't work because the signature will fail.
The MS08-068 patch addresses this attack only in the case where the attacker connects back to the victim. The patch works by checking the received challenge key against a list of active keys that its own SMB service has issued. If the challenge key matches the list, the authentication process fails. This form of the attacker is described as "reflection" by the Microsoft SWI team. The Karmetasploit implementation uses this attack by default, providing remote code execution in any environment where Metasploit can influence the network of the victim (WPAD, WiFi, MITM, etc). This attack works great even in very isolated environments, such as an airplane full of Windows users at 30,000 feet. You can find more details on this form of the attack and its resolution on the SWI blog.
The patch does NOT address the case where the attacker relays the connection to a third-party host that the victim has access to. This can be accomplished by setting the SMBHOST parameter in the Metasploit smb_relay module to a third-party server. There are many cases where this is useful, especially in LAN environments where various tools authenticate to all local hosts with a domain administrator account (vulnerability scanners, inventory management, network monitor software, etc). In this situation, the attacker would relay the connection to another local system (domain controller, workstation, etc) and abuse this to obtain remote code execution. The third-party attack can also be used to relay inbound SMB credentials to a remote non-SMB service that accepts NTLM authentication (POP3, IMAP4, SMTP, HTTP via IIS, etc). More information about non-SMB NTLM relaying can be found at the Squirtle web site.
Mandatory SMB signing can prevent this attack, but it also breaks backwards compatibility with older operating systems. The MS08-068 patch is an elegant solution to a particular method of exploiting a design flaw, but it does not correct the flaw itself. This patch should be mandatory for road warriors and anyone who uses an untrusted network (wireless or otherwise), since without knowledge or connectivity to a third-party host, the relayed credentials are not useful. The SMB protocol and NTLM authentication mechanism are quite fun to play with and relaying attacks are just the tip of the icerberg :-)
Update: Bob McMillan found this old advisory, which summarizes the reflection attack.