[unisog] Re: Correction: XP SP2 ports open to local subnet
eckman at umn.edu
Tue Jun 15 13:35:21 GMT 2004
(Below is a note I sent to another security list. I am copying it to
this list as I know not everyone on Unisog is on that other list and per
the request of several people I've spoken to about this issue. Sorry to
those of you who get it twice.)
(The context is worms/other malware and how they might replicate once
Windows XP SP2 is common.)
Niedens, Travis wrote:
> Honestly, I am certain with SP2 Betas being out that these guys are
> already working on one that gets in and shuts down the firewall. They
> have been pretty proficient in disabling, blocking and hindering most
> AV products (disabling services, adding in hosts file entries, etc.)
After a brief investigation, I tend to disagree. If you are an attacker,
there is no point shutting down the firewall and opening up your newly
0wned computer to other hax0rs when adding a simple registry key will
allow only your malware to bypass the firewall, while otherwise keeping
it intact. It's quite trivial in fact (assuming the functionality
doesn't change before its released). Simply create a key like this:
(change mybot.exe to whatever you want, and KaZaA to whatever you want
displayed to the end user if they ever bother to check their exceptions)
The "cool" thing is, now mybot.exe can listen on whatever port you want,
even random or multiple ports.
Of course, you could simply do this as well:
(Sorry, no million dollar prizes for whoever guesses what that setting
However, my point above stands - if you (the attacker) disable the
firewall, someone else might kick you off of that machine when *they*
compromise it. Also, the user is informed when the firewall is turned
off (unless Windows detects another firewall product installed). Of
course, I imagine that could be modified fairly easily as well.
The attacker also might want to do this:
"445:TCP"="445:TCP:127.0.0.1/255.255.255.255:Disabled:SMB over TCP"
"137:UDP"="137:UDP:127.0.0.1/255.255.255.255:Disabled:NetBIOS Name Service"
That way, the default exceptions for file sharing are gone. This again
helps prevent them from getting kicked off by another attacker.
BTW, I tested all of this on a RC1 computer, and the registry keys were
all modifiable by a .reg file run as an administative-level user. All
changes took place immediately, and functioned correctly. That is,
changing "EnableFirewall"=dword:00000001 to
"EnableFirewall"=dword:00000000 does indeed turn off the firewall.
(Instead of waiting for an attacker to do it, you can give your users a
.reg file with that last set of registry key modifications. If you can
get them to run it, the default exceptions for File and Print Sharing
will be turned off.)
As always, if an attacker can *successfully* run their code on your
computer ("successfully" often requires administrative or system
privileges, but not always), your computer is no longer yours. They can
defeat any protections that you have left once they run their code. Even
if you have Symantec Client Firewall, ZoneAlarm and such, that prevent
unblessed outbound communications, they can sidestep those as well.
(Agobot and others simply kill the running processes.) However, I'm sure
there are plenty of other ways around those firewalls when you can run
whatever commands that you want to run on the system. The only defense
against something like this is a firewall (or similar filtering) in
front of the compromised computer.
P.S. If you are upset that I posted any/all of these details, please
realize the bad guys already know it. It took significantly longer to
word this response and check it for proper spelling and grammar than the
actual research took.
OIT Security and Assurance
University of Minnesota
More information about the unisog