[unisog] WindowsUpdate hole (was MS04-007/011 scanner)

Clarke Morledge chmorl at wm.edu
Wed May 5 03:31:03 GMT 2004


On 4 May 2004, Daniel Bidwell wrote:

> Does anyone have a netreg dns configuration what will let widowsupdate
> work?  I would like to allow windowsupdate to work from the registration
> zone.

Daniel,

I really don't know how netreg could be made to work with this, but I know
the general problem involved with WindowsUpdate.  This is a lengthy
response :-(, but this is a complicated problem.  However, I give it
because I'd LOVE to hear about anyone who has come up with a good solution
(I'm stuck right now)!

What we would like to do is somehow put users in a VLAN/subnet where
basically the only thing they could do is run WindowsUpdate.  We would
scan the systems for vulnerabilities and if the systems were vulnerable,
place them in this restricted VLAN/subnet -- a "Penalty Box" of sorts.  
Or by default, just simply have a Registration network for new users (as
with netreg). The only way they would get out is to somehow show that
they've run WindowsUpdate.

SUS is a good solution (putting the SUS server on the registration
network), but it does require some touching of the box at some level.  In
our environment, we don't require the students to logon onto a campus
domain.  We've had a number of problems with trying to enforce this -- one
being that when students leave campus with their computers, we don't want
to deal with the hassle of students trying to logon onto the domain from
across the Internet (we block those ports required for MS networking at
the edge) or trying to get updates from our SUS server (no VPN here :-).

Like you, a solution whereby you can use something like netreg to register
MAC addresses and permit WindowsUpdate would be ideal.  Make sure the
systems are fully patched before you let them on the production network
(inspecting a virus/worm laden system that just shows up on the network is
a separate issue -- still thinking through this one :-).  We can probably
use IDS signatures to at least confirm if/when a system has run
WindowsUpdate.

Something like Perfigo or Bradford Software's Campus Manager would
probably fit the bill here, but if you are like us, we are already heavily
invested in our own home-grown network registration procedures.  Right
now, we sort of do something like this with Packeteer's PacketShaper, but
I'm having a terrible time trying to get this to work consistently; i.e.
block all traffic EXCEPT WindowsUpdate.

And here's the problem:  because Microsoft has who-knows how many
WindowsUpdate servers out there on the Internet through akamai (or
whatever), they play tricks with DNS so that they can rotate their
available WindowsUpdate servers around.   Since the DNS resolution for the
WindowsUpdate servers is such a moving target, you have a problem with
syncing up DNS entries on your DNS server with what the clients have in
their DNS caches.

I supposed you could just hand out specific WindowsUpdate DNS responses
that override what Microsoft dynamically hands out to just keep it static
(has anyone ever tried this??).

My hesitation here is that you the run the risk of sometimes picking some
DNS static responses that eventually go dead when Microsoft takes a server
offline for maintenance, etc.

The only consistent thing with WindowsUpdate is that when it uses HTTP it
uses consistent "Host" field entries in the HTTP Requests, irregardless of
method (GET, POST, etc).  Unfortunately, there is still a problem in that
some of the WindowsUpdate stuff runs over SSL, so packet inspection at
this level is lost.

Anyway, that's the problem as I see it.  Does anyone have any solutions?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187




More information about the unisog mailing list