From owner-freebsd-questions@FreeBSD.ORG Tue Feb 8 15:58:20 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF95416A4CE for ; Tue, 8 Feb 2005 15:58:20 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CB9F43D1F for ; Tue, 8 Feb 2005 15:58:20 +0000 (GMT) (envelope-from mag@hamletinc.com) Received: from [192.168.12.99] (c-24-19-27-240.client.comcast.net[24.19.27.240]) by comcast.net (rwcrmhc11) with ESMTP id <2005020815582001300g052ve>; Tue, 8 Feb 2005 15:58:20 +0000 Message-ID: <4208E148.8060301@hamletinc.com> Date: Tue, 08 Feb 2005 07:56:56 -0800 From: "Mark A. Garcia" User-Agent: Mozilla Thunderbird 0.6 (X11/20040519) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bret Walker References: <014901c50de3$15518b10$17336981@medill.northwestern.edu> In-Reply-To: <014901c50de3$15518b10$17336981@medill.northwestern.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 15:58:20 -0000 Bret Walker wrote: >Last night, I ran chkrootkit and it gave me a warning about being infected >with Slapper. Slapper exploits vulnerabilities in OpenSSL up to version >0.96d or older on Linux systems. I have only run 0.97d. The file that >set chkrootkit off >was httpd which was located in /tmp. /tmp is always mounted rw, noexec. > >I update my packages (which are installed via ports) any time there is a >security update. I'm running Apache 1.3.33/PHP 4.3.10/mod_ssl >2.8.22/OpenSSL 0.97d on 4.10. Register_globals was on in PHP for a couple >of >weeks, but the only code that required it to be on was in a .htaccess/SSL >password protected directory. > >Tripwire didn't show anything that I noted as odd. I reexamined the >tripwire logs, >which are e-mailed to an account off of the machine immediately after >completion, and I don't >see anything odd for the 3/4 days before or after the date on the file. >(I don't scan /tmp) > >I stupidly deleted the httpd file from /tmp, which was smaller than the >actual apache httpd. And I don't back up /tmp. > >The only info I can find regarding this file being in /tmp pertains to >Slapper. Could something have copied a file there? Could I have done it >by mistake at some point - the server's been up ~60 days, plenty of time >for me to forget something? > >This is production box that I very much want to keep up, so I'm seeking >some sound advice. > >Does this box need to be rebuilt? How could a file get written to /tmp, >and is it an issue since it couldn't be executed? I run tripwire nightly, >and haven't seen anything odd to the best of my recollection. I also >check ipfstat -t frequently to see if any odd connections are happening. > >I appreciate any sound advice on this matter. > >Thanks, >Bret > > Slapper is a linux only virus. You shouldn't have to worry about it doing harm on your freebsd machine. Seeing as the binary was in your tmp directory on your system, and that you might have not placed it there, this could be a good reason for a host of other things to look into. The httpd binary with 96d<= ssl is not a virus itself, just a means to carry out the exploit. The slapper virus is a bunch of c-code that is put in your tmp directory and the exploit allows one to compile, chmod, and execute the code, leaving open a backdoor. chrootkit does scan for the comparable scalper virus which is a freebsd cousin to the slapper (in that they attempt to exploit the machine via the apache conduit.) I would think real hard, if you did put the httpd binary in there. If you are sure you didn't, and you are the only one with access to the system, then I would be very very worried. Running tripwire and chrootkit on a periodic basis should help. Re-installing the os isn't your only solution, but it does give comfort knowing that after a reinstall, and locking down the box, no one has a in on your system. This could be overboard though. You also might want to consider enabling the clean_tmp scripts. Next time tar up those suspicious files, a quick forensics on them can do wonders (md5sum, timestamps, ownership, permissions.) Cheers, -.mag