Security Incidents mailing list archives

Re: Strange & Consistent RST/ACK packets


From: dittrich () CAC WASHINGTON EDU (Dave Dittrich)
Date: Tue, 11 Apr 2000 11:15:42 -0700


On Sat, 8 Apr 2000, Security Guru wrote:

At one of my customer sites, I keep seeing uninitated RST/ACK packets with
an acknowledgement number of 674719802.  These packets come from many
different source IP addresses and range from a few packets a day to a few
hundered.  Is there a known 'attacker' tool that generates these SYN or
SYN/ACKS with a sequence number of 674719801?  Or is this just a scanning
tool that looks for ICMP unreachables from my customer's border router?

Yeah, synk4.c:

        #define SEQ 0x28376839

(0x28376839 is decimal 674719801).

synk4 takes a source address on the command line for outgoing packets,
and if zero, it generates them randomly using this code:

        . . .
        for (i=1;i>0;i++)
          {
             srandom((time(0)+i));
             srcport = getrandom(1, max)+1000;
             for (x=lowport;x<=highport;x++)
               {
                  if ( urip == 1 )
                    {
                       a = getrandom(0, 255);
                       b = getrandom(0, 255);
                       c = getrandom(0, 255);
                       d = getrandom(0, 255);
                       sprintf(junk, "%i.%i.%i.%i", a, b, c, d);
                       me_fake = getaddr(junk);
                    }
        . . .

Synk4 is not a distributed tool, so unless there are many people (or a
DoS bot) running synk4 at the same time, the packets should all be
coming from the same host (and would thus have the same source address
for a given attack.)  What do the source ports look like?

If you are doing egress filtering on your network -- EVERYONE IS DOING
EGRESS FILTERING, RIGHT?! -- then a host running synk4 on your network
would cause what you are seeing, but I would think the packets should be
coming in quick succession (you don't mention the timestamp variance
or how many bits your subnet uses.) For information on egress
filtering, see:

        http://staff.washington.edu/dittrich/misc/ddos

Since you seem to be seeing a smaller number of packets than would
indicate a flood originating from your network, it would seem like there
must be more than one host flooding and using random source addresses.
Because of the poor seeding of the random number generator,
it could just be that many people independantly using synk4 are
generating random sequences that happen to include your network
block over time.  If this is the case, I would assume really random
distributions of incoming times for the RST/ACK packets.

While checking, I noticed that stacheldraht also uses a fixed sequence
number for flooding (including SYN flooding) that is really close to
what you are seeing:

        syn.c:#define SEQ 0x28374839

This happens to be exactly 0x00002000 smaller than what you are seeing.
Stacheldraht fakes source addresses this way:

  . . .

  if (nospoof < 1)
    return (u_long) random ();

  hax0r.s_addr = htonl (myip);

  srandom ((time (0) + random () % getpid ()));  /* supreme random leetness */

  sscanf (inet_ntoa (hax0r), "%d.%d.%d.%d", &a, &b, &c, &d);

  if (nospoof < 2)
    b = getrandom (1, 254);
  if (nospoof < 3)
    c = getrandom (1, 254);
  d = getrandom (1, 254);

  sprintf (convi, "%d.%d.%d.%d", a, b, c, d);

  return inet_addr (convi);

  . . .

As you can see, if the agents are able to spoof all 32 bits of the
source address, they do.  If not, then it spoofs at level 3 (just
the final octet).  For details, see:

        http://staff.washington.edu/dittrich/misc/stacheldraht.analysis

If the source addresses are all within a /24, and come in quick
succession, this could be stacheldraht (doesn't sound like it, though.)

--
Dave Dittrich                 Client Services
dittrich () cac washington edu   Computing & Communications
                              University of Washington

<a href="http://www.washington.edu/People/dad/";>
Dave Dittrich / dittrich () cac washington edu [PGP Key]</a>

PGP 6.5.1 key fingerprint:
FE 97 0C 57 08 43 F3 EB  49 A1 0C D0 8E 0C D0 BE  C8 38 CC B5



Current thread: