Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
MS07-063 addresses a weakness in the SMBv2 message signing algorithm. SMB signing is a feature enabled by default on domain controllers to prevent man-in-the-middle attacks. As you can imagine, if an attacker on your local subnet can tamper with the SMB network traffic between your domain controller and domain-joined clients, they can cause all kind of mayhem. Windows 2000 and 2003 domain controllers use SMBv1 which uses a secure signing algorithm. When Vista and Windows Server 2008 communicate, they attempt to use SMBv2. SMBv2 message signing was originally implemented insecurely and then fixed with this security update.
Unless you use SMB message signing with SMBv2, this one probably won't affect you today but please do apply the update in preparation for any move to either Windows Server 2008 or client-to-client SMB signing with Vista clients. Vista SP1 and Windows Server 2008 Release Candidate 1 (and, obviously, the final released version) will have the fix. MS07-063 changes Vista RTM ("Released to Manufacturing"... no service pack installed) to use the same secure algorithm that internal builds of Vista SP1 and WS2008 RC1 already use.
You can spot any SMBv2 conversations on your network between unpatched Vista machines by just listening on the wire. MS07-063 changed the SMBv2 version number from 2.001 to 2.002. Kevin from our SWI Defense team documented this as part of our security investigation so I wanted to paste in a couple captures that he made to show the pre-patch and post-patch version numbers on the wire. If you're sniffing on your network and see SMB 2.001, that is an unpatched Vista machine. And actually both ends of that conversation would have to be unpatched because patched Vista, Vista SP1, or WS08 RC1 will choose to downgrade to SMBv1 rather than talk SMBv2 v2.001.
Here is a Negotiate Protocol Request with Vista pre-patch:
And here is what that looks like post-patch:
And again remember that this vulnerability is only relevant for signed traffic. Kevin also built a network capture to show the signature field. If it is full of NULLs then the packet is not signed. If it contains data, the packet is signed. Here is an example signed packet.
Update: Blog reader Blake emailed us suggesting that we attach a full network capture showing signed SMBv2 traffic. Kevin from the SWI Defense team had a capture of SMB2 (version 2.001 - pre-patch) already prepared so we are attaching it here. You might notice that the capture includes some information about his test setup (machine name = "VM-Vista-RTM", login name = "Kevin"). We decided that data does not have privacy concerns so we didn't remove it from the capture.
Update: Blog reader Ronnie correctly pointed out that the screenshots above were taken from Wireshark, not NetMon. Sorry about that.
We are excited to have this outlet to share more in-depth technical information about vulnerabilities serviced by MSRC security updates and ways you can protect your organization from security vulnerabilities. You can read much more about the goals of the blog and about the SWI teams contributing to the blog in our “About” link: http://blogs.technet.com/swi/about.aspx
The two posts below are examples of the type of information we’ll be posting. We expect to post every “patch Tuesday” with technical information about the vulnerabilities being fixed. During our vulnerability research, we discover a lot of interesting technical information. We’re going to share as much of that information as possible here because we believe that helping you understand vulnerabilities, workarounds, and mitigations will help you more effectively secure your organization.
MS07-065 fixed a vulnerability in the Message Queueing service. On Windows 2000, a remote anonymous attacker could use this vulnerability to run code as local system on unpatched machines. Windows XP added defense-in-depth hardening to disallow remote access for this service that does not need to be exposed remotely. So on Windows XP, the attacker must be logged on locally on the box.
You'll see in the mitigations section of the bulletin that the MSMQ service is not started by default. Most installations of Windows do not require message queueing so the default install having it off by default reduces attack surface.
There is actually another mitigating factor present here that we didn't include in the bulletin because we could not authoritatively say that it was true in every case. The vulnerable code path only executes if your machine has a primary DNS suffix. Most of the time, only domain-joined machines have a primary DNS suffix. So it would have been great to say in the bulletin: "Machines not joined to a domain are safe" but that is not 100% accurate so we did not include that. Technically, an administrator could manually set a primary DNS suffix on a non-domain-joined machine.
You can check to see if your machine has a primary DNS suffix by running "ipconfig /all" and looking for the line that says "Primary Dns Suffix". If it is blank, your computer configuration is not vulnerable to this issue. If you do have a primary DNS suffix set, we would not recommend removing it blindly because that could affect many applications and the ability for your machine to access network resources.
We periodically identify workarounds or mitigations like this that we can't use for official guidance because they're either too nuanced or have some exception cases. When we discover something potentially useful but are uncomfortable listing it in the bulletin, we'll do our best to describe it here in this blog.