Tarpits for Microsoft Worms

temporary measure! by Pooh22 · 2001-09-20 01:36 · Score: 5, Insightful

Ok, so the next version will close the connection in 1 minute. I don't see this helping in the future...

Re:temporary measure! by interiot · 2001-09-20 02:47 · Score: 3, Interesting

From observation, it seems to me that it takes quite a while for obvious improvements to be included in new worms.

For instance, it's somewhat obvious to me that it'd be good (for a virus) to leave open backdoors, so that your future viruses can springboard off your installed user base. If an old virus can spread from one computer to 20,000 in a week, then a virus that piggybacks on another virus could go from 20,000 infections to 40,000,000 in a week. AFAIK, CodeRed + Nimda was the first to do this.
Re:temporary measure! by Phil+Gregory · 2001-09-20 03:47 · Score: 5, Insightful
Well, LaBrea operates below the level of most Windows network programs. From the program's point of view, it establishes a TCP connection to the server and issues the necessary HTTP commands. More things happen "on the wire" though. Here's a simplified timeline:
1. Program calls connect() to reach the other host.
2. OS's TCP/IP stack sends a SYN packet to the other host.
3. One of several things happens:
  - The host does not respond and the connection eventually times out. Result: failed connection attempt after a short timeout.
  - The host is reachable but isn't listening on that port. It sends a RST packet. Result: The connection fails almost immediately.
  - Some other network error. At most, the connection will time out in a relatively short period of time.
  - The host is listening on the port and sends back a packet with both the SYN and ACK bits set
4. Presuming the TCP/IP stack got a SYN ACK, it sends its own ACK and considers the connection established.
5. The TCP/IP stack reports to the calling program the result of the connection attempt. If the three-way handshake went as normal (SYN, SYN ACK, ACK), it considers the connection open.
6. If the connection was successful, the program starts sending data.
7. The TCP/IP stack accepts the data, breaks it into packets to be sent, and doesn't return to the program until it's done.
8. For each packet of data the TCP/IP stack sends out, it waits for an ACK of that packet, retransmitting the packet if it doesn't receive the ACK with a certain period of time. It will wait longer and longer after each transmission before eventually giving up on the connection altogether. The ultimate timeout on an established TCP session is relatively large (and possibly implementation-dependent; I don't remember exactly that part of the spec).
Most firewalls only deal with the first SYN used to set up the connection. Either they reject it (send a RST) or drop it, leaving the connection to time out. La Brea responds to the initial SYN, then ignores everything else, leaving the TCP session to time out. That timing out usually takes a while (the author estimates about 15 minutes for Windows machines), and the program is unable to do anything while it's waiting for the TCP/IP stack to finish sending its data.

Ok, enough background. The point is that, with standard programming practices, the program doesn't get to pick how long it waits before giving up. That is dependent on the OS's TCP/IP stack. The ways around it are harder. One workaround is to use raw TCP sockets (and this may not even work; I'd have to check my copies of Unix Network Programming, and they're at home). (Anyway, Windows XP will be the first WIndows to support raw TCP sockets.) The other is to use nonblocking I/O, which requires a lot more state keeping in the program. (But it would allow the program to fire off connections to a number of hosts and wait to deal with the responses as they come in.) I suspect most work writers would just count on very few people running things like LaBrea and write the simpler code.

So, in summary: LaBrea is pretty nifty and a program can't just shorten its timeout period to get around the delay. The only workaround I can think of at the moment is nonblocking I/O, but that has its own drawbacks (and, depending on the program design, could still be slowed down by LaBrea).

--Phil (Crazy network programmer.)
--
355/113 -- Not the famous irrational number PI, but an incredible simulation!

Viruses Preserved... by GreenJeepMan · 2001-09-20 01:38 · Score: 5, Funny

This way 10,000 years into the future, the viruses will be magically rediscovered in prestine condition.

Pointless by scott1853 · 2001-09-20 01:46 · Score: 3, Interesting

It's a cool little program. It's purpose, to use up your own resources to prevent other peoples resources from being used up. There seems to be a little flaw in that logic to me. Personally, I like the scripts that connect to servers that have tried to infect them, and send those servers a bit of code to reboot the machine. I'd rather them install the patch automatically and then reboot the machine though. That seems like a much more effecient use of resources.

Why has nobody either sent out a worm to patch machines, or created a script to patch the sender of a worm? The bandwidth used would be minimal to what is being eaten by these worms, and it would SOLVE the problem. Of course, in this day and age, nobody wants to actually solve a problem, they have to create some technically incredible way of ignoring a problem, or placing blame on the common scapegoat of MS or stupid admins, or doing some trivial task just to prove they can do the same type of thing as the virii spreaders.

BTW, this article was posted on Wired yesterday afternoon, why did it take so long to get here?

Re:Pointless by Gleef · 2001-09-20 02:26 · Score: 4, Interesting

scott1853 writes:

It's a cool little program. It's purpose, to use up your own resources to prevent other peoples resources from being used up. There seems to be a little flaw in that logic to me.

It's a program to use a little bit of resources on one machine to reduce large resource impacts on many other machines. In addition, it allows you to detect and contact the owner of the infected host, hastening repair of the system and speeding up recovery of the net.

If you have a large network, you might very well be helping yourself far in excess of the bandwith used by the tarpit, certainly a win in my book. Even for those with small networks, some people might well be interested in sacrificing a small, controllable amount of bandwidth to help the general health and well being of the internet as a whole.

Why has nobody either sent out a worm to patch machines, or created a script to patch the sender of a worm? The bandwidth used would be minimal to what is being eaten by these worms,

That is highly debatable.

and it would SOLVE the problem.

But the problem isn't "Code Red", that's just a symptom of the problem. The problem is a combination of low security on the internet and the fact that Microsoft's monopoly has the side effect of making many identical security holes on thousands of machines.

Of course, in this day and age, nobody wants to actually solve a problem,

Nobody particularly wants to waste a great deal of bandwith to put a band aid on other people's sites for each worm that comes out, which is what you seem to recommend.

Real solutions to the problem aren't easy, but most of them are being actively worked on:
* Increase competition in internet server platforms and applications;
* Improve the distribution of security information and patches to the end users;
* More commercial internet monitoring and response services (eg. Counterpane);
* Security-conscious internet insurance plans
* Segregate the typical broadband customer behind transparent firewalls (I'd pay extra for a premium broadband service to give me a real IP if it would get the bozos who shouldn't have a computer much less an internet server off the real IP space).

--

----
Open mind, insert foot.
Re:Pointless by PhilHibbs · 2001-09-20 02:46 · Score: 3, Informative

Why has nobody either sent out a worm to patch machines, or created a script to patch the sender of a worm?
Already happening. Unfortunately I think that self-destructing worms are by definition going to be less virulent than worms that take over a machine completely and keep trying to spread until they are removed.
Re:Pointless by scott1853 · 2001-09-20 03:16 · Score: 4, Interesting

Don't give me "it's a symptom of the problem" bullshit. The PROBLEM as it is right now, is the worm itself. Stop this worm, stop the next, give the people time to make the server secure and all the idiots time to figure out what they've gotten themself into by assuming they can run w2k. So your plan would be to just wait for MS to fix ALL their security holes and make it so my grandma can setup a W2k box and never have a problem? How long will that take, 5, 10, 15 years? And the fixes will introduce new bugs. So the answer is to do what gives the biggest response NOW, not a decade from now.

I don't know what you're referring to in saying that I want everybody to waste their bandwidth. Somebody would need to release a worm that fixes the whole, spreads itself, and removes itself. I'm not saying everybody should install the script that simply reboots the machine, that does nothing but give the machine a 2 minutes break in between infections. I'm not saying the worm should scan a thousand IP addressed to see what machines are infected. Let it check log files if they exist, find any machines that tried to infect it, check and see if those are still infected, if not the worm should delete itself.
Re:Pointless by Gleef · 2001-09-20 07:28 · Score: 3, Informative

scott1853 writes:

Don't give me "it's a symptom of the problem" bullshit. The PROBLEM as it is right now, is the worm itself. Stop this worm, stop the next, give the people time to make the server secure and all the idiots time to figure out what they've gotten themself into by assuming they can run w2k.

OK, we disagree on what the basic problem is. No big deal, we can talk about how to deal with an arbitrary worm (the worm du jour seems to be Nimda).

So your plan would be to just wait for MS to fix ALL their security holes and make it so my grandma can setup a W2k box and never have a problem? How long will that take, 5, 10, 15 years? And the fixes will introduce new bugs. So the answer is to do what gives the biggest response NOW, not a decade from now.

That wasn't my plan, although a piece of what I was discussing does involve Microsoft (and other vendors) streamlining their security patch process. There is no way that *any* vendors can fix *all* security holes. Waiting for that would be ludicrous. Regardless, I was referring to how to reduce the impact of future worms (and other internet badness), not how to deal with a worm in the wild now.

Worm in the wild now: As of this writing, the last three major worms were "Code Red", "Code Red II" and "Nimda". All three of these exploit holes in Microsoft software, and these holes were discovered and a patch written months ago. In addition, Nimda exploits holes opened up by an active Code Red II infection. Any competent administrator unfortunate enough to have to manage an IIS installation has taken their machine offline, made sure their machine is worm-free, patched NT/2000 and IIS, and put it back online. Your main concern is those admins who have not done this, and there are a disappointingly large number of them.

I don't know what you're referring to in saying that I want everybody to waste their bandwidth. Somebody would need to release a worm that fixes the whole, spreads itself, and removes itself.

Where do you think the bandwidth issue comes from? When a worm scans host machines to look for places to spread, it uses a lot of bandwidth. This is what most people here are complaining about. Your proposed worm may fix bad IIS installations, but it would have to use at least as much bandwidth as the worm it's designed to fix.

The people here (me included) won't thank you, since they care more about how these worms impact bandwidth than whether someone has an infected machine somewhere. The administrator of the machines you've "fixed" won't thank you, because now they've had two or three intrusions while they were napping, rather than one.

If the repair worm has a minor bug in it, it could potentially do more damage than the original worm, or open up a new security hole as it fixes the others. In such a case, at best you are looking at a lawsuit against you; at worst, multiple felony convictions in multiple countries.

I'm not saying everybody should install the script that simply reboots the machine, that does nothing but give the machine a 2 minutes break in between infections.

Good, because while I'm not sure what you're talking about here, it doesn't sound like a good idea.

I'm not saying the worm should scan a thousand IP addressed to see what machines are infected.

In order for a worm like you describe to work, it probably would have to scan thousands of machines for a vulnerability, infect the machine with your worm, and then detect whether or not the worm is present from the inside.

You *might* be lucky and target a worm which leaves external evidence so you can scan thousands of machines for the presense of the worm. Both Code Red II and Nimda can be detected from the outside, but the check I know of for Nimda uses a lot of bandwidth. Regardless, a worm would have to scan thousands of machines to impliment your idea, it's just a question of what it scans for.

Let it check log files if they exist, find any machines that tried to infect it, check and see if those are still infected, if not the worm should delete itself.

What log files are you talking about? None of the worms leave a log that I know of. Neither NT nor 2000 log intrusion attempts without extra software. I would wager that very few of the infected machines have IDS software installed. In order to write a worm to effectively track down and eliminate worms, you have to use scans at least as extensive as the ones the target worms are using. Unless the target worm has a buggy scanning algorhithm, any repair worm would kill at least as much bandwidth as the original worm.

This cure is worse than the disease, in my book. I'd rather focus my attention on long-term solutions that will reduce the overall problem.

--

----
Open mind, insert foot.

LaBrea is not the solution by davidu · 2001-09-20 01:51 · Score: 5, Interesting

Tools like LaBrea are cool, but aren't more then hacks. By wasting the TCP timeout on these worms it just forces the next worm writer to create a multi-threaded worm which would instantly be immune to such a defense.

A better defense, which I admit is more costly in terms of CPU is to run border IDS systems and simply have rulesets to filter this kind of traffic out.

For Example: Here is a snort ruleset for Nimba and Codered and possibly other worm varients against Windows OS's:
alert tcp any any -> any 80 (content: "cmd.exe";msg: "cmd.exe access in HTTP!!";react: block;)
alert tcp any any -> any 80 (content: "root.exe";msg: "root.exe access in HTTP!!";react: block;)

If you're running BigIP switches:
rule block_nimda {
if (http_uri starts_with "/scripts" or http_uri contains "root.exe") {
discard
} else {
use ( server_pool)
}
}

The point is...
It's better to stop these things on border routers and on the edges of Lan's then on individual machines or IPs. LaBrea does nothing to protect other machines aside from slowing down the worm which is almost futile.

Just my $.02,
dave

--

# Hack the planet, it's important.

Couldn't a decent firewall do the same thing? by lar3ry · 2001-09-20 01:52 · Score: 3, Interesting

Should be simple to write a script that would examine your HTTP error_log file for '\.exe' and insert a rule into IPCHAINS to DENY all connections from that IP. The connection will time out, of course... but it will slow down the virus.

Much better than having your system get hit 15 times a second from Nimda probes, anyway.

--
"May I have ten thousand marbles, please?"

Filesystem loops by Ed+Avis · 2001-09-20 01:53 · Score: 3, Interesting

Within my home directory I have a couple of symlinks pointing back at the root of the home directory. Because it's exported by Samba to Windows machines, and Windows (or rather, Win32) doesn't know about symlinks, the 'Find File' utility from the Windows Start button would get stuck descending forever into these links. I can't say for sure, but it's possible that a few worms like ILOVEYOU were thwarted or slowed down by this, if they do a depth-first search for files to infect.

Unfortunately, I think that in the end Samba was reconfigured not to serve symlinks :-(. It would be nice to have an option to serve the first level of symlinks but not allow recursive ones.

--
-- Ed Avis ed@membled.com

Nimda around since July? by MS · 2001-09-20 01:56 · Score: 3, Informative

Some additions w/r to Nimda:

Strange: of the 27 hosts (IP-based) I run on a single box, the most popular got probed first, not the server with the lowest IP-number, so the worm seems not attacking the IP-numbers sequentially, but rather due to some reference somewhere else. This may also explain, why it spread so quickly: if the worm could replicate itself from a popular webserver, the chances are good for a quicker spread among many surfers... This worm is really an excellent piece of code - kudos to its author!

And here are some log-entries from another box (NT runnung Apache):

First suspect entries on July 12(!):

My Timezone is GMT+1 (That's mid-europe, one hour ahead of Great Britain)
(SR) stand for ServerRoot which I omitted here

[Thu Jul 12 03:39:40 2001] [209.3.150.130] File does not exist: (SR)/scripts/..%5c..%5cwinnt/system32/cmd.exe [Thu Jul 12 03:39:42 2001] [209.3.150.130] File does not exist: (SR)/msadc/..%5c/..%5c/..%5c/winnt/system32/cmd.ex e [Thu Jul 12 03:39:43 2001] [209.3.150.130] File does not exist: (SR)/_vti_bin/../../../../../../winnt/system32/cmd .exe

I had a few more interesting logs between Jul 28 and Aug 30... but the /. Lameness filter considers it a Junk character post, so I had to shorten it...

May this information be useful for someone!
ms

Re:NOT A TARPIT by Erasei · 2001-09-20 01:59 · Score: 3, Interesting

This is exactly like a tarpit. Tarpits don't instantly trap all T-Rexes everywhere in the world. A tarpit will trap the one T-Rex that got a little too close. If there are thousands of tarpits in the world, then a lot more T-Rexes will get trapped. I don't think the author of LaBrea aims to have his program stop all worms on the internet, but if it were to be run on a few thousand machines, it would certainly help.

--
visit my free wallpaper collection, wp.erasei.com

Re:NOT A TARPIT by interiot · 2001-09-20 02:19 · Score: 3, Interesting

Well, for one, this will immensely help corporations with large networks... once you filter incoming email for the specific .exe at the firewall, you need to start cleaning up internal IIS servers. LaBrea will slow the IIS servers down to keep them from hosing your network while you hunt them down and clean them up.

For two... (drum roll please...) What if we had a LaBrea Beowulf? If major network providers (eg. UUNet) implement this across their networks, it would save themselves bandwidth and thus cost, and would make their customers happier.

It doesn't kill worms, it just greatly reduces their impact on the network. Sounds good to me.

Sounds interesting by rabtech · 2001-09-20 02:29 · Score: 4, Insightful

it sounds rather interesting, but might I suggest securing the server in the first place?

For any IIS admins out there, you need to download and install URLScan. It is a free tool put out by Microsoft. It scans incoming requests and only allows ones that meet its criteria of rules (with a default blank ruleset, all requests are discarded.)

<a href="http://www.microsoft.com/Downloads/Release.a sp?ReleaseID=32571">http://www.microsoft.com/Downl oads/Release.asp?Rel easeID=32571</a>

There are a variety of other methods that can be used as well, and I am currently working on a guide to security for IIS admins. It isn't that hard... take the time to do it right.

--
Natural != (nontoxic || beneficial)

16 of 245 comments (clear)