W32.Spybot.Worm and fileshares

[Nathan Eady]

I run a small heterogenous network at a small public library. Today, one of
the WinXP systems, which has Norton AV, popped up a warning that it had found
a virus. The info link pointed here:
http://securityresponse.symantec.com/avcenter/venc/data/w32.spybot.worm.html

I let it quarantine the file (explorer.exe in a folder where there would not
normally be a file by that name) and began investigating. I doublechecked
for KaZaA (which the Symantec page mentions as the most probably entry point)
but as I knew already it's not installed. (I get rid of such things when I
find them. Had a very bad experiece with KaZaA and network performance once.
I don't allow Gator either, or Bonzi, or AIM...) That leaves (according to
Symantec) trojan backdoors, especially the IRC variety, so I pulled up regedit
and had a look, but I'm pretty sure everything in the various Run keys is
legitimate.

So I pulled up the Quarantined Items report and had a look-see at the location
where it found the thing. (The whole path was not visible in the original
dialog.) Hmmm... the place where it found it is the Shared Documents folder.

I'm speculating at this point that the PC that found the thing is not the
one that was infected per se, that the infected PC merely dropped the thing
in that folder over the network. With, incidentally, the hidden attribute.
So I started checking other PCs. There's another WinXP PC, and it had the
same situation exactly -- the file was there, but no other evidence of
infection. I quarantined the file there too.

So, I have several questions...

* Is this behavior known? Can someone confirm that it does this?
Does Symantec know that the worm does this, and if we can confirm
it, shouldn't it be mentioned on the writeup?

* Is the infected computer necessarily on my LAN, or could it be
elsewhere on the internet? (Assume we have no firewall[1].) My
tendency is to believe that it is coming from outside the LAN,
since the WinXP computers are the only ones infected. (The Linux
and Win9x and Mac OS X systems all use password protection on the
fileshares, but I haven't figured out how to do that with WinXP.
(I was highly annoyed when I installed my first WinXP system and
discovered that the filesharing dialog didn't have an entry box
for password, but that's another discussion for another day.) If
the infected computer were inside the LAN, it would be likely
to have passwords in the keyring thingy and thus be able to gain
access to the fileshares on the Win98 systems at least, but I
am not finding the infected files there. Does that make sense,
or am I jumping to confusions? Am I wrong in assuming that a worm
running on the system would be able to use the keyring passwords?
(Either way, of course, I will be checking all our Windows systems
as soon as I get a moment.))

* Assuming we don't execute hidden executables from the shared
documents folder, there's no risk to the PC hosting the fileshare,
correct?

[1] I know, I know, we should have a firewall... it's on my agenda.
I want to put all the non-server systems behind IP Masquerade if
possible, but I haven't got there yet. We have a limited budget
and I don't get to set the priorities. Ad interim, we don't use
known-dangerous applications (IIS, sendmail, Outlook, IE, ...)
and I try to pay some attention to security patches.

 

[Nick FitzGerald]

I run a small heterogenous network at a small public library. Today, one of

So, I have several questions...

* Is this behavior known? Can someone confirm that it does this?
Does Symantec know that the worm does this, and if we can confirm
it, shouldn't it be mentioned on the writeup?

Many of the more recent bot-net agent variants have added file share
spreading. Some do it by explicitly looking for network mapped
drives, others by (randomly) probing the network for open shares or
for machines with shares with easily guessed (admin) passwords.

If this feature is available in the Spybot variant you caught then
the odds are very high that it got to your network through an
Internet-exposed share. If this is what happened to you, install a
protocol that won't be routed over your Internet connection (usually
only TCP/IP willbe so routed and that is the default Windows
networking protocol for _all_ TCP/IP capable services, including
F&PS), bind F&PS to that protocol, unbind F&PS from TCP/IP, repeat
for all machines in your network (personally, I prefer IPX/SPX for
LAN-based F&PS but you could use NetBEUI).

* Is the infected computer necessarily on my LAN, or could it be

<<snip>>

See above.

* Assuming we don't execute hidden executables from the shared
documents folder, there's no risk to the PC hosting the fileshare,
correct?

Wrong.

Depending on the version of XP and the config (sounds like you have
pretty much default and possibly with very weak admin passwords) all
manner of nastiness can be remotely delivered to and executed on your
XP machines.

Password protect them and do it soon. And, regardless of that, F&PS
(well, SMB networking in general) is _NOT_ a service that you should
expose to the Internet at all.

Ohhh, and you mentioned in part of what I snipped that you have Win9x
machines. Make sure they patched for MS00-072 vulnerability, for if
they are not they effectively have one-byte passwords, no matter how
long, complex, etc your chosen passwords are (and, there is a very
extensively spread worm, Opaserv, that abuses just this flaw).

 

[Nick FitzGerald]

Wow, lots of stuff there I didn't realise before. Firstly, since

Yeah -- what you have to realize is that when someone or some company
makes a terribly complex, challenging technology so easy pretty much
anyone can make it work, they are doing one of two things -- either
providing a _really_ dumbed-down, feature-poor version or they are
hiding great gobs of complexity from the user. As the first approach
is unlikely to meet market acceptance (especially if there is already
a lot of this complex "stuff" being done by real experts) and that
was the case with networking, you should not be surprised that MS
took the second approach here. Basically (they improved it a bit in
later OS versions, but still chose stupid defaults) the "make it so
any idiot can do networking" approach MS adopted was "bind every
protocol to interface and every service to every protocol it can work
over. As such a default install should be able to talk whatever with
whoever, it should work most of the time for most people in most
situations. And, as anyone with a hint of intelelct will immediately
realize, that _must_ raise all manner of chronically obvious security
issues that can only be hugely magnified if one of the most commonly
deployed network interfaces is some kind (dial-up, ISDN, satellite,
cable, DSL) connection to a public sewer of a network like "the
Internet".

But, MS did all this _before_ it discovered "Trustworthy Computing",
so maybe we should forgive it???

Yeah, right...

file and print sharing worked in Win9x without TCP/IP installed, I

How do your Win 9x machines do anything Internet-related?

Or do you mean, F&PS worked without TCP/IP installed initially...

had assumed that they didn't use TCP/IP and thus wouldn't be routed.
A little googling explained how to make that the case Not sure
why I never noticed these bindings before in the network properties,
perhaps because I was looking from the other end (the properties on
the bound item, rather than the bindings in the properties on the
protocol).

....and you did not realize/notice that when you added TCP/IP the
protocol installer and service binder decided that, of course, you
wanted to share over TCP/IP and thus expose your F&PS to the Internet?

I knew the default scenerio in XP was to route them over TCP/IP, but I
didn't realise that it was possible to disable this (without disabling
the sharing altogether), or to get smb to work without TCP/IP. Again, a

MS has a long history of not being able to get out of its own way.

It has an equally long, if not longer, hostory of sticking by really
decisions rather than fixing them properly and "breaking" the existing
but badly-configured, userbase. Oddly, precisely this "feature" of MS
products (but not painted in such negative connotations) is seen by far
too many people as one of MS's major strengths (these people are
clearly morons and for the public good clearly should not be allowed
to configure and connect computers to the Internet...).

little googling set me straight, once you told me what I was looking for.
(The terminology "unbind protocol" seems to be key here.)

Hmmmmm -- that's odd... The real issue is unbinding services. You
presumably "need" TCP/IP to get your web browsers, chat clients, etc
to work on the Internet, so you need the TCP/IP protocol bound to your
Internet facing network adaptor(s). However, if you only have one
such adaptor (say an Ethernet interface on a LAN that has an Internet
router of some sort) then you will need to bind the F&PS service to
some protocol that is bound to that adaptor. As we have decided that
that protocol should not be TCP/IP, you would need to bind another
protocol to that adaptor (if TCP/IP is the only currently bound
protocol), bind the F&PS service to that protocol and unbind the F&PS
service from TCP/IP.

Another possible solution is the lazy (so therefore crazily popular)
one of installing a firewall and simply blocking ports you do not
"need" to have open. Of course, properly configuring and maintaining
a firewall is a non-trivial exercise and requires more specialist
knowledge than properly binding services and protocols on your Windows
workstations...

So I'm converting all our file and print sharing to not use TCP/IP.

One possible problem I see here is that you said you use Samba on your
Linux machines. I presume that this can be made to work over other
protocols, but as I don't use it can't say for sure.

One remaining question...


Out of curiousity, how can it be remotely executed, if the only shared
folders are document folders from which nothing is normally executed?
Even though I am unbinding the MS networking stuff from TCP/IP on our
network (now that I know that's possible), I'm still interested in
understanding this.

The point here is NT-based OSes have installed and enabled by default
several RPC mechanisms to do these sorts of things to ease management
of distributed workstations in large LAN/WAN settings. _If_ your
NT/2K/XP boxen have weak admin passwords then it is trivial for an
"attacker" to remotely connect and perform various commands, including
running on your machine a program that exists locally on the attacker's
machine. A few utilities to do just that have been written -- perhaps
the best (certainly the best known) is PSExec by the clever folk at
Winternals -- this is included in many currently successful "worm kits"
that depend on weak, easily guessed admin passwords and default (i.e.
stupid) protocol and service binding (there are other, bigger issues
here than just F&PS). Thus, even if you unbind F&PS from TCP/IP you
still need to have really strong passwords on your NT/2K/XP boxen as
they are bound to be exposing other "attackable" interfaces that will
be easily compromised if you do not have strong passwords.

Well, I'm off to figure out how to get Samba to grok file and print
sharing over IPX/SPX.

Good luck with that...