UNPATCHED Windows Vista/2008/7 SMB2 Vulnerability

[Kevin Hayes <krhayes () OAKLAND EDU>]

There is currently a 0-day vulnerability affecting Windows Vista, 7
and 2008 Server, causing a remote attacker to BSOD and reboot
vulnerable machines.  The following is an analysis done by Brian
Eckman from the University of Minnesota.

------

Folks,

A vulnerability in SMB2 was reported at http://g-laurent.blogspot.com/
yesterday (September 7th), along with Proof of Concept (PoC) code that
could allow a remote, unauthenticated attacker to cause a page fault,
resulting in a "Blue Screen of Death". Presumably, the affected versions
of Windows will all reboot automatically once this page fault occurs,
unless that feature was turned off by an administrator.

Today's Microsoft "Patch Tuesday" bulletin for September 2009 includes
five patches that fix remote code execution vulnerabilities. The
aforementioned SMB2 vulnerability is NOT one of them. In fact, it does
not appear that Microsoft has publicly acknowledged this vulnerability
yet. However, I do know and trust a Windows 2008 server admin who
confirmed that his system promptly rebooted upon receiving the existing
exploit code, and I've seen several others report that the exploit
worked when they tested it.

Earlier today, another researcher made the claim that this vulnerability
could be exploited to allow arbitrary code execution, presumably with
SYSTEM permissions. The first claim of this I have seen is at
http://www.reversemode.com/index.php?option=com_mamblog&Itemid=15&task=show&action=view&id=64&Itemid=15
.
I have not otherwise seen or heard about PoC code existing that allows
code execution, but the day is barely half over...

In response to this vulnerability, Symantec has raised their "Threatcon"
to yellow. They posted a summary of the currently-known public details
at http://www.symantec.com/security_response/threatcon/index.jsp.

SMB2 is only available in Windows Vista, Windows 2008, and Windows 7. It
reportedly is turned on by default on these systems. Windows 2000, 2003,
XP, etc., are not affected.

The default port to exploit this is 445/tcp. Hosts that do not need to
act as a Windows file server can likely mitigate most of the risk of
this vulnerability by configuring their firewall to deny inbound File
and Print Sharing, or by changing their network location to "Public". (I
imagine connecting to a malicious SMB2 server could still allow
exploitation, but that seems rather unlikely to me at the moment.)

Since the vulnerability is within SMB2 protocol negotiation, I would
*assume* that disabling SMB2 would be an effective mitigation.
(Microsoft mentioned disabling SMB2 as a workaround for MS07-063.) I ask
that administrators of Windows 2008 servers[1] immediately start
_preparing_ to implement[2] such a mitigation should further research
(before a patch for this vulnerability is released) result in an exploit
that will execute arbitrary code. Note that disabling SMB2 requires a
reboot, so you would need to account for things like scheduling an
emergency reboot, notifying end users of an outage, and such.

Instructions on how to disable SMB2 can be found at the bottom of
http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx
.
Note that the steps taken for servers require a registry change and a
reboot, while disabling the SMB2 client appears to only require a couple
commands to be run.

NOTE: The exploit code that causes affected systems to reboot has
reportedly already made it into a Metasploit module - less than 24 hours
after it was released. Should an updated exploit allow arbitrary code
execution, the window of time to mitigate the risk before widespread
exploitation occurs will likely be *very* small.

Cheers,
Brian

[1] Obviously, any Windows systems with SMB2 that do not prevent access
to the SMB service are at risk, and should quickly investigate potential
mitigation options. Those that limit access to a small group of IP
addresses, such as the local subnet, have much less potential exposure.
I singled out Windows 2008 due to the increased likelihood that it
exposes SMB shares to many different subnets - perhaps the entire campus
in some cases - as well as the likelihood that spontaneously rebooting
it to apply a fix may adversely affect more than a few users.

[2] I am advising that administrators of affected Windows systems
immediately begin planning to implement an emergency mitigation, which
is not the same as immediately implementing the mitigation. For example,
if your unit requires emergency maintenance to be performed after 5pm,
perhaps making sure someone will be available after 5pm, if needed, is
in order. You might also want to prepare the outage notification in
advanced, so should you need to send it, you can do so on short notice.
In the meantime, unless functioning exploit code that allows arbitrary
code execution is released and/or reported as being in use, I advise you
to "stay tuned" - I suspect Microsoft will be issuing an advisory (but
not a patch) within the next day or two that will more accurately
outline what workarounds are available.

--
Brian Eckman, Security Analyst
University of Minnesota
Office of Information Technology
Security & Assurance










Kevin Hayes
Network Security Analyst

225 Dodge Hall
Oakland University
(248) 370-2546