multicasts from hell

[yardley () UIUC EDU (Tim Yardley)]

a new look... multicasts from hell.. courtesy of spank.c
by Tim Yardley [yardley () uiuc edu -- lst @ efnet]

---------------------------------------------------
:: temp remedy (exec summary)
---------------------------------------------------

If you use ipfilter... This *MAY* help you... but the issue is quite a bit
different than the previous issue.

-- start rule set --
block in quick proto tcp from any to any head 100
block in quick proto tcp from 224.0.0.0/28 to any group 100
pass in quick proto tcp from any to any flags S keep state group 100
pass out proto tcp from any to any flags S keep state
pass in all
-- end rule set --

optionally, a rule like the following could be inserted to handle outgoing
packets (if they send from the firewall somehow) but you have bigger
problems than the attack if that is the case.

-- start additional rule --
block out proto tcp from any to 224.0.0.0/28
-- end additional rule --

That will help you "stop" the attack (actually it will just help minimize
the affects), although it will still use some CPU though

Note: If you use IPFW, there is no immediate way to solve this problem due
to the fact that it is a stateless firewall and you are dealing with
packets that are being forged with invalid (or possibly even valid
flags).  You can however use IPFW or any other firewall to block out
packets from multicasts.  If you are getting attacked, then temporarily use
ipfilter (or any other state based firewall) to slow the affects, ie keep
track of the states.  Otherwise, wait for vendor patches or read more about
the explanation for other possible workarounds.

-- ipfw rule for multicasts (with cars for the command and interface --
change accordingly) ---
$fwcmd add deny all from 224.0.0.0/28 to any via ${oif}
-- end ipfw rule --

FreeBSD "unofficial patch" by Don Lewis:
http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff

------------------------------------------------
:: explanation of spank.c attack
------------------------------------------------

NOTE: For this attack to work, you must have multicast enabled on the
network that you are attacking from, otherwise the packets should just get
dropped.  The adverse affect of this, is that it seems to destroy the local
net, and the affect on the remote net is unknown (since the localnet dies
too quickly).  This could become a problem with distributed DoS systems
because if a host on your internal net is compromised, then they can bring
your entire internal net down to a screaching halt.

This is a tad different than the previous release.  Stream/Raped mearly
flooded the host with ack's (or no flags) and came from random ips with
random sequence numbers and/or ack numbers.  The difference now is that
this not only does the previous stuff, but also directly attacks from and
to multicast addresses as well. There are also options to randomize the
attack more. Just as before, rate limiting should be done to counteract its
effect (the same idea as ICMP_BANDLIM).. and also the multicast handling in
the stack should be checked to verify that it is behaving properly.

The attacker specifies the port[s] that they want to send the attack to,
depending on what ports are selected, you will have different net
results.  If the port is an open port, then you will possibly have a longer
kernel path to follow before the drop.  Therefore, a smart attacker will
hit open ports, but havoc can also come about from random ports due to
states and processing.

In the best case scenario, you will experience only the lag of the flood
and the lag of the processing (currently) and then be fine when the
attacker stops,  In the worst case, you lockup, kill the network, and
possibly have to reboot.  Once you patch it, you deal with a lot less
processing time (the drops are handled without the RST flag when
appropriate -- bandlim type idea).  In other words, you go to the drop
routine instead of dropwithrst silencing your response, which decreases
your processing time, the hit on your network, and the effect of the flood
(once a threshold is reached, all those bad packets are silently dropped
and the attack has less of a net effect).  There are issues with not
producing RST's since they were put into the specs for a reason, so blindly
dropping all RST's is not a good plan.

The filters that were presented at the beginning of this email will block
all multicast packets that come in (and possibly out) of the tcp stack.  I
have been getting mailed a lot about the previous attack.  It should be
noted that receiving a packet with no flags is considered an illegal packet
(obviously) and is often dumped, however, as we have seen in the past..
illegal packets often wreak havoc and often go untested.  Hence the
reasoning behind the '-r' flag of this.

There is very little that "raped.c" or "stream.c" actually showed as
problems in the TCP/IP stacks.  The true problem lies more in the effects
of the response (caused by the attack).  This is the same concept as the
SYN floods of yesteryear, and the same type of thing will be done to handle
it.  The main difference is that it will be on a simpler note because there
isn't much need for a "cookie" based system.  One should just throttle the
response of the reset packets which in turn will help stop the storm that
you generate and in general, harden the tcp/ip stack to behave the way it
is supposed to in adverse conditions.

The main effect of this attack is that you are shooting back RST+ACK's at
all the spoofed hosts.  In the case of the new attacks, this happens to
mean that you are directing them at multicast addresses.  Obviously, a lot
of these hosts will not exist and you will get ICMP unreaches (as an
example) bounced back at you.  There are other possibilities as well, but
unreach would be the most common (redirects might be common as well
although i did not spend the time to analyze that).  The ones that don't
respond back may send you some packets back as well (depending on if the
port was valid or not and what their firewall rules are).  This type of
attack is complicated by the multicasts, and the effect is amplified as
well.  All in all, it becomes very nasty very quick.  Basically, this
causes a nice little storm of packets, in the ideal case.

Note that I said ideal case in the previous paragraph.  This is not always
the observed behavior.  It all depends on what is on the subnet, what type
of packets are recieved, what rules and filters you have setup, and even
the duration of the flood.  It has been pointed out several times that the
machine will go back to normal once the attack is stopped, which is exactly
why something like ICMP_BANDLIM will work.

I have also been asked a lot about what this "bug" affects.  I have seen it
have effects on *BSD, Linux, Solaris, and Win* as far as OS's go (due to
the previous stuff).  The new multicast code seems to affect the local lan
(routers, gateways, and switches) more so than it affects anything else but
due to how it works (when it works), it is somewhat difficult to
test.  Therefore, no blame is being directly placed on any specific
platform or architecture.  Entire subnets have "disappeared" briefly after
the attack and have required route purgings to correct the issue.  The
multicast attack seems to be more deadly to the network than the previous
attack and its affects get amplified and even carried over to the rest of
the network (bypassing secluded network bounds).  I don't have more
specifics on the systems affected because of the difficulty in testing it
(and keeping the network up) since I do not have local access to the
networks that I tested on, and remote access gets real ugly real
fast.  Everyone elses mileage may vary... but I have seen results under 2
different types of configurations.

Another possibility that has been suggested as to why some machines die is
that the machine's route table is being blown up by the spoofed
packets.  Each spoofed packet has a different source address which means
that a temporary route table entry is being created for each one.  These
entries take time to timeout.  Use 'vmstat -m' and check the 'routetbl'
field while the attack is going on.

Route table entries can be controlled somewhat under freebsd with:

[root@solid]::[~] sysctl -a | fgrep .rt
net.inet.ip.rtexpire: 3600
net.inet.ip.rtminexpire: 10
net.inet.ip.rtmaxcache: 128

You can do the following, to help if the route table is at least part of
the problem:

sysctl -w net.inet.ip.rtexpire=2
sysctl -w net.inet.ip.rtminexpire=2

Things that will help:

1 -- drop all multicast packets (ingress and egress) that are addressed to
the tcp stack because multicasts are not valid for tcp
2 -- extend bandwidth limiting to include RST's, ACK's and anything else
that you feel could affect the stability of the machine.
3 -- dont look for listening sockets if the packet is not a syn

I hope that this helps, or explains a little more at least.

-----------------------
:: conclusion
-----------------------

This bug was found in testing.  It seems a bit more lethal than the
previous and should be addressed as such.  Patches should be available now,
but I do not follow all the platforms.

--------------------
:: references
--------------------

This was done independantly, although some of the analysis and reverse
engineering of concept was done by other people.  As a result, I would like
to give credit where credit is due.  The following people contributed in
some way or another:

Brett Glass <brett () lariat org>
Alfred Perlstein <bright () wintelcom net>
Warner Losh <imp () village org>
Darren Reed <avalon () coombs anu edu au>
Don Lewis <Don.Lewis () tsc tdk com>

Also, I would like to send shouts out to w00w00 (http://www.w00w00.org/)

-------------------
:: attached
-------------------
These programs are for the sake of full disclosure, don't abuse
them.  Spank was written with libnet, so you will need to obtain that as well.

for an "unofficial" patch:
http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff

for spank.c:
http://solid.ncsa.uiuc.edu/~liquid/code/spank.c

NOTE: These are just temp locations.  They will not be there forever and I
reserve the right to remove them at anytime.

/tmy

-- Diving into infinity my consciousness expands in inverse
    proportion to my distance from singularity

+--------  -------  ------  -----  ---- --- -- ------ --------+
|  Tim Yardley (yardley () uiuc edu)    
|  http://www.students.uiuc.edu/~yardley/
+--------  -------  ------  -----  ---- --- -- ------ --------+