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.