Today Microsoft released a security update, MS08-068, which addresses an NTLM reflection vulnerability in the SMB protocol. The vulnerability is rated Important on most operating systems, except Vista and Windows Server 2008 where it has a rating of Moderate. This blog post is intended to explain why the issue is less severe on Vista and Windows Server 2008, and provide some additional details to help people determine the risk they face in their environment.
This vulnerability allows an attacker to redirect an incoming SMB connection back to the machine it came from and then access the victim machine using the victim’s own credentials. (Hence the term “credential reflection”). In typical Windows XP configurations where SMB sharing is enabled and the user is a member of the Administrators group, this allows the attacker to easily take over the machine. Public tools, including a Metasploit module, are available to perform this attack.
Typical attack vectors for this vulnerability will leverage HTML either via a web browser or e-mail. Resources within the HTML document (such as IMG tags) can be used to reference a file on the attacker’s machine, and these file are then retrieved using the SMB protocol. The attacker’s machine prompts the victim for credentials and then reflects these credentials to the victim’s machine, gaining access. In cases where the attacker is on the same network as the victim, even “trusted” websites can be leveraged to perform this attack – since network data can be modified before the victim receives it.
What happens when this attack is performed against a Vista or Windows Server 2008 machine? While both Vista and WS08 are vulnerable to this attack, and the credential reflection can succeed, several other factors mitigate the impact of this attack:
-
The first big difference between Vista and Windows Server 2008 and earlier versions of Windows is that File and Print Sharing is not enabled by default. A user must first enable File and Print sharing (which also enables an exception in the Windows Firewall) in order to be vulnerable to this attack.
-
In non-domain environments, the default system shares (admin$, c$) are not accessible remotely by admin users, even if File and Print Sharing is enabled and the Windows Firewall allows inbound connections. (See KB 951016 for more details).
Here is an example of connecting to a Vista machine, authenticating as a user that is a member of the Administrators group, and still not being able to access admin$ and c$:
C:\> net use \\10.10.10.1\ipc$ The password or user name is invalid for \\10.10.10.1\ipc$. Enter the user name for '10.10.10.1': swi Enter the password for 10.10.10.1: The command completed successfully.
C:> dir \10.10.10.1\admin$ Access is denied.
C:> dir \10.10.10.1\c$ Access is denied.
- In domain environments, if a user is logged on using a domain account which is a member of the local machine’s Administrator account, then the default system shares (admin$ and c$) will be accessible to them. (See [KB 951016](http://support.microsoft.com/kb/951016) again for details).
In the context of this vulnerability, a domain account with local Administrator permissions can successfully be used in a reflection attack, and the attacker will be able to connect back to the victim and access the admin$ and c$ shares. However, due to UAC and integrity levels, the attacker will connect back with the same integrity level as the victim. In most cases this will be Low or Medium integrity level (for non-elevated programs). Under Low and Medium integrity, the attacker would have read permissions (at most) to the admin$ folder. This means they would not be able to add new binaries or overwrite files in the system folder. They would also not be able to perform RPC operations that require High integrity (such as adding a service).
However, an attacker would be able to write to locations under the victim’s user folder, such as the Startup folder or Desktop. (Any other folder that the user has write permissions would also be vulnerable under a reflection attack). The Startup folder is a valuable target for an attacker. Although for non-admin users, the files placed here will run with non-admin rights.
- The Windows firewall will protect against this attack when the network profile is “Public”. Only the “Private” network profile will allow incoming SMB connections by default. People using public networks such as WiFi hot-spots will most likely be using the “Public” profile and therefore be protected.
- Customers behind NATs and edge firewalls are not vulnerable to attack from machines outside the firewall, since inbound SMB is not enabled in default configurations.
It should be noted that while the second point above is a real mitigation, there could still be non-default shares that are available on the machine that could be leveraged by an attacker and result in the target being compromised. If a user has made any shares available on their machine, then they are at increased risk.
In terms of general mitigations, the bulletin mentions several options. In almost all cases the greatest risk comes from machines on the internal network. It is still a good idea to block outbound SMB traffic, but if an attacker is already within the perimeter (or the user is on an untrusted network such as a public WiFi hot-spot), there are mitigations which fall into these categories:
- Disable File and Print sharing (assuming it is not needed on user’s machines).
- Block inbound SMB connections using the Windows Firewall
- Enable IPSec and require it on inbound SMB connections.
- Enable SMB message signing. This can be enabled on select “high value” servers, or on all machines. (Note that there may be a substantial performance impact)
\- Mark Wodrich, SVRD Blogger
\*Postings are provided "AS IS" with no warranties, and confers no rights.\*