Date: Fri, 28 Jun 2002 16:07:35 -0400 From: Rich Kulawiec <rsk@magpage.com> To: freebsd-security@FreeBSD.ORG Subject: Re: Apache worm in the wild [with POSSIBLE block] Message-ID: <20020628200734.GA2222@gsp.org> In-Reply-To: <20020628125817.O68824-100000@axis.tdd.lt> References: <20020628125817.O68824-100000@axis.tdd.lt>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 28, 2002 at 01:01:32PM +0200, Domas Mituzas wrote: > it finds. No source code available yet, but I put the binaries into public > place, and more investigation is to be done. SUMMARY: Thanks for putting these up. Point #2 contains a POSSIBLE method that may block the spread of this worm and which (AFAIK) doesn't carry any risks of its own. I welcome criticism/corrections of my rather hasty (and therefore flawed) analysis. 1. A very fast (<5 minutes) preliminary look at this tends to me make me think this MAY be intended as as DoS tool. Why? Well, for one thing, some TLD suffixes are apparently hard-coded in, e.g. ".gov" which someone contemplating a DoS attack would be wise to do. But more interestingly, these text strings are present: Size must be less than or equal to 9216 Cannot packet local networks Udp flooding target Tcp flooding target Sending packets to target Dns flooding target 2. I suspect that most of its propagation method is encapsulated here: rm -rf /tmp/.a;cat > /tmp/.uua << __eof__; __eof__ /usr/bin/uudecode -p /tmp/.uua > /tmp/.a;killall -9 .a;chmod +x /tmp/.a;killall -9 .a;/tmp/.a %s;exit; I would suggest that just as 14 years ago we found that insufficient error checking in the Morris worm led to a quick way to stop it via creation of a file in /tmp (the Purdue "condom" fix), that mkdir /tmp/.a chmod 000 /tmp/.a chown root /tmp/.a MAY stop this. Please don't consider this in any way a guarantee: like I said: < 5 minutes of analysis went into this. (My reasoning: shell script fragment above tries to use uudecode to turn uuencoded file /tmp/.uua into executable binary /tmp/.a; if .a already exists as a directory, not even route will be able to overwrite it via shell redirection. The chmod/chown is proabably not necessary but won't hurt. Systems which has daemons that periodically clean out /tmp might need to use cron to periodically re-do this.) However, it's worth pointing out that even if I'm wrong, this will do no harm, so I think the risk in trying it is minimal. 3. These strings occur as well: FreeBSD 4.5 x86 / Apache/1.3.22-24 (Unix) FreeBSD 4.5 x86 / Apache/1.3.20 (Unix) Speculation: are these the targeted (vulnerable) systems? If so, why no Apache 1.3.21? 4. I believe this IP address is hard-coded into it: 12.127.17.71 which reverse-resolves to dns-rs1.bgtmo.ip.att.net which I would guess is a DNS server in Bridgeton, Missouri? Why that IP address? Has the machine there been comprised? Or is the entire purpose of this to attack that single machine? 5. There is evidence that this binary knows how to connect to SMTP servers and send mail messages through them, forging headers to give the appearance that the message was sent by an AOL user: HELO %s MAIL FROM:<%s> RCPT TO:<%s> DATA QUIT Return-Path: <%c%c%c%c%c%c%c@aol.com> From: %s Message-ID: <%x.%x.%x@aol.com> Date: %s Subject: %s To: %s Mime-Version: 1.0 Content-Type: text/html 6. It may also use a subdirectory of /tmp; these strings occur as well: /tmp/tmp Unable to open temporary file for writing Error communicating with website Timed out while receiving data UNKNOWN-CHECKSUM-SUCCESSFUL Checksum for data failed mv /tmp/tmp /tmp/init;export PATH="/tmp";init %s which may mean that "mkdir /tmp/tmp;chmod 000 /tmp/tmp;chown root /tmp/tmp" might not be a bad idea. Once again, I apologize for the haphazard nature of this analysis, but thought it worth sending out if for no other reason than getting point #2 out for discussion in the community. ---Rsk Rich Kulawiec rsk@magpage.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020628200734.GA2222>