Tarpits for Microsoft Worms

Digital_Quartz writes: "Wired News is reporting on a clever little tool by Tom Liston called LaBrea which uses unused IP addresses on a network to create virtual computers for worms and hackers to attack. LaBrea responds to requests in such a way as to keep the connection open forever, creating a "tarpit" in which worms like Code Red will get "stuck"."

Comments

temporary measure!

[Pooh22]

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

Re:temporary measure!

[Phil Gregory]

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.)

Viruses Preserved...

[GreenJeepMan]

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

LaBrea is not the solution

[davidu]

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