There seems to be a lot of discussion regarding the 7 years it took for Microsoft to patch against SMBRelay (the name of a tool published in 2001.) There’s some speculation that Microsoft is only now addressing the issue because a Metasploit module was added in 2007 to exploit the vulnerability. Here’s our take.

Should Microsoft have patched SMB sooner? Why? Who has been adversely affected by the vulnerability? We’ve never had an Incident Response case that involved abuse of it. Given the fact that we now know there was a solution to the puzzle, chances are that solution was stumbled upon by accident in one of those “Eureka” moments. Once that idea was finally conceived, of course, it made sense for them to produce a patch, but do try to appreciate just what was at stake as they attempted to implement it and test it. Thousands, if not hundreds of thousands of 3rd party applications are based on SMB working just the way it does. Break it while patching the vulnerability and you’d have a lot of upset people.

First of all, you should know that the SMBRelay tool was intended to implement cracking concepts that had been published years before in a form that would automate the process of collecting and cracking password hashes. Previous tools took, for example, password hashes from the registry and cracked those. This required access to a server that had stored hashes (typically, a Domain Controller.)

SMBRelay was intended to avoid the need to actually compromise the DC, and instead collect the information off the wire. Sniffing password hashes had been known, and done, for many years prior to this. To crack an NTLM password hash one had to “guess” the challenge value that was sent by the server and used by the client to encrypt their password information. SMBRelay avoided this problem via man-in-the-middle proxying of the challenge/response traffic. In this way it would know the challenge value sent by the server and used by the client.

However, using Rainbow Tables is another effective method of cracking the client response obtained simply by sniffing the wire, thereby avoiding the need for any obvious system on a network.

Microsoft created NTMLv2 in an effort to strengthen the challenge/response encrypted presence on the wire to make sniffing less effective. Other features (SMB Signing, LMCompatability Level, etc…) were also introduced to mitigate some of the threats to NTLM.

At the end of the day, however, Microsoft could not avoid sending the response over the wire to the server. As such, it remained available to sniffing or stealing by any server the client attempted to authenticate against.

In other words, the vulnerability was present long before SMBRelay was ever published, and well understood by the security community (and hopefully Administrators of Microsoft systems.) It has certainly been demonstrated many times in penetration testing settings, but its actual use “in the wild” has never been documented (despite comments by Sir Dystic that suggest how easily this could be done via an email.)

SMBRelay offers one benefit that sniffing doesn’t; namely the ability to obtain the password hash from outside of the source network. However, to do this the source network must not only allow outbound traffic on port 139, but also inbound traffic on the same port, presumably from any address on the Internet. Many years ago abuse of the Windows Messenger Service (the one that provided a way to pop up a message on another system in your network) finally convinced many that they needed to block SMB from the Internet. Subsequent worms exploiting vulnerabilities in the server service convinced the others, including most home users. In other words, the benefits of SMBRelay versus local network sniffing have long since been thwarted.

It appeared that the only way this vulnerability was ever going to be “patched” was by Microsoft dropping NTLM altogether and opting for some other authentication protocol (such as Kerberos, which is where they’re going.)

Now Microsoft says that after many months of testing they finally believe they have patched the issues involved in SMBRelay. It is important to recognize that they have not fixed NTLM, or the ability to sniff hashes off the wire (unless you use SMB Signing.) They have, presumably, introduced functionality in SMB that can detect when a client’s own challenge response is used against itself, hence the term “SMB Credential Reflection Vulnerability.”

Finally, we come to the question of why now, or why so long after the tool was first published?
We believe that this issue could have been resolved sooner if there were actual threats in use. We believe that without actual exploitation, Microsoft simply worked on issues where there was a real threat, such as the out-of-cycle patch offered on October 23rd, 2008.

So kudos to Microsoft for finally addressing the issue, and a special congratulations to whomever came up with the idea of how to fix it. It took a lot longer than seven years to address this, given it was there for at least 8 years before Sir Dystic ever mentioned it.

Tags: Information Security, InfoSec, Microsoft Security Bulletins, Patching, risk, Vulnerabilities

This entry was posted on Tuesday, November 18th, 2008 at 9:41 pm and is filed under Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.