Created: 2001-02-19
Modified: 2002-11-15
By: Lawrence Baldwin
Background:
If you have received a myNetWatchman alert indicating that one of your IP Addresses
has been generating port probes (scans) targetting UDP port 137, there is a high
probability that your system has been compromised by one or more Internet worms which
propagate through open file shares--that is hosts which have enabled Microsoft File Sharing
and are allowing anyone on the Internet full (read/write) access to your local hard drive.
If the IP address we reported as the source of these probes is your firewall or NAT (Network Address
Translation) router, then the host that is infected could be one or more hosts *behind* your
NAT router or firewall.
Since sites protected by NAT or a firewall should protect against Opaserv infections sourced from
the Internet, often you will find that the infected host fits one of the following profiles:
- Is a laptop system which moves in and out of your network...it was likely infected when
connected to the Internet at some other location (home or hotel room) without the protection of a firewall.
- Is a stationary desktop system which has secondary Internet access (e.g. dialup, DSL) ... infection
occurs while secondary Internet connection was established
- Is a stationary desktop system which is utilizing Internet access clients (e.g. AOL!). When used in
pure TCP/IP mode through your normal Internet connection, the client establishes a VPN-like connection/tunnel
*through* your firewall and obtains a second *PUBLIC* IP address (an AOL address). Once this connection
is established the PC running the AOL client is subject to file share attacks from any hostile Internet host--
your firewall and/or NAT router provides ZERO protection against this vulnerability--unless you have
explicitly blocked the AOL client entirely (e.g. blocked TCP/5190).
Once ONE host becomes infected on your internal network, any other hosts which have open or vulnerable
file shares will become infected. Unless you address the root sources of the infection, simply running standard
anti-virus dis-infection procedures will produce nothing but frustration...as you disinfect one host, it will
be re-infected moments later by another host on your local network, or from one of the 100,000+ infected
hosts on the Internet.
Please read the remainder of this document carefully so you can understand this worm and take the
necessary methodical steps to eradicate it and prevent future infection.
Starting in early October 2002, the W32.Opaserv
worm was released. Since it's release
we have seen more than 1,500,000 unique source addresses emit udp/137 probes. Because of the
sheer volume of infected hosts currently on the Internet, we estimate that every single IP address
is attempted to be infected with Opaserv about once every *5 minutes*. This means that if you
connect a vulnerable host to the Internet (even on a dialup connection with a dynamic IP address) you
will likely be infected almost immediately.
Despite media assertions to the contrary, Opaserv demonstrates why it is critical to secure your system
with a firewall, regardless of your connection type, frequency and duration of access.
Anti-virus vendors have suggested that some of increase in Netbios probes may
be due to the more sinister W32.BugBear worm. Our own honeypot monitoring suggests
otherwise...over 90% of the activity on our honeypot is Opaserv not BugBear.
As of this writing, there are now NINE variants of Opaserv. If you are vulnerable to this attack, you are
likely infected by SEVERAL variants. As more and more variants become active on a given system, the PC
becomes more and more unstable, often crashing randomly.
Removal:
Step 1:
Disable File Sharing on your C: Drive. This is essential, otherwise you will likely be re-infected
before you even complete the dis-infection process!
Step 2:
Run an anti-virus scan using the product of your choice (make sure you have the latest virus signatures).
If you don't own an anti-virus product, then use one of the free online scan offered by several major
anti-virus vendors.
Step 3:
[optional, only if you need to have file sharing enabled]
a) Make sure your system is not vulnerable to share access using only the first character of
the share password, as discussed here:
NT BugTraq
b) Install a personal firewall to prevent Internet users from accessing your share.
Note: the free version of Zone Alarm is fine for most.
c) Re-enable Share
d) Establish a strong password on your file share!
Other worms which propagate through open file shares:
2002-01-01:
Starting in Jan 2001 myNetWatchman began detecting an marked increase in NetBios
Name Service scans. We believe that this pattern has been going on much longer,
however, our older agents (Win32/BlackICE) don't report these scans for some
reason. Whereas our newer Linux/IPChains agents report these attacks daily.
By reverse probing the attacking systems we determined that many were infected
with the Bymer
worm.
We believe that worms like Bymer and Qaz
exemplify the most serious threat to Internet stability. We see no technical
impediments to the creation of more sophisticated worms that inflict real, and
long-term damages (e.g. massive Distributed Denial-of-Service DDOS) rather than
just stealing CPU cycles. The press currently focuses on the email worms that
touch millions of people all at once (e.g. Melissa, Kalamari, etc.). Although
they make flashy news stories, we believe steathly, slow but methodically moving
worms are far more dangerous. This is akin to real viruses that have a extermely
long gestation period. Months later there is an outbreak that impacts so fast,
it's too late to stop it.
When the Qaz worm was rampant last summer, we were able to infer an infection
rate of about 3% of all PCs connected to a particular ADSL provider. Since QaZ
infects through open shares, that gives you an idea of the number of PCs that
have this exposure. What's to stop the next Bymer/Qaz worm from recruiting 100,000
zombies through open share infestation and then lauching a coordinated DDOS
attack against the top 100 Internet sites. That makes the 2-3 hours wasted cleaning
up after Mellissa/Anna look like a paper cut! It's going to take days/weeks
to track and clean up something like that.
False Positives:
A common cause of these probes is if the source is a Microsoft IIS web server AND
Netbios is bound to the public IP address of the server. IIS logging mechanisms
attempt to do a reverse name lookup on every IP address that surfs to the site.
Normally a reverse DNS lookup is attempted first, but if that fails, IIS will send
a Netbios name lookup directly to the user. If the user is running a firewall, it
will log a Netbios probe.
Although this is technically a false positive, enabling Netbios on your public
IP address is not usually desireable so you might want to consider disabling it.
Often web servers are connected to an internal PRIVATE network, and then access
the Internet via a NATed public IP. This is the most common cause of this problem
since it is normal to bind Netbios to a PRIVATE IP to faciliate file
transfers within the PRIVATE network.
In this situation, you should consider adding an outbound firewall rule
to block Netbios name lookups. This should reduce the number of false
positives that get reported to you due to this behavior.
|
