Hi All,

Ok, so here is the situation. I have two servers, on two different IP's and it's the exact same on each server.

RedHat 9 is installed. When RedHat EOL'd RH9, I *stupidly* didn't worry about it. So, I stopped getting updates, leaving me with a very insecure version of PHP.

We noticed some heavy WAN traffic the other day. After some in-depth investigation, I found out it's the Lupper Worm. So, I killed the rogue processes, and cleared the /tmp directory.

To do updates, I went to fedoralegacy.org and setup YUM to update. For some reason it will only update to PHP 4.1.2-7.3.17

According to this security advisory, this version that I'm getting should fix the vulnerabilities.:
dub dub dub dot fedoralegacy dot org /updates/FC2/2005-07-10-FLSA_2005_155505__Updated_php_packages_fix_security_issues dot html

However, from what I've read elsewhere, I need a higher version of PHP.

So, anyways, with the update from fedoralegacy I'm still getting compromises on my servers. I keep killing the processes and deleting files in the /tmp directory.

Can anyone help me figure out what's going on and whether or not the fedoralegacy advisory is correct that the new version of PHP that I have should have fixed the vulnerabilities??

Thanks!

-Mike

RedHat 9 is installed. When RedHat EOL'd RH9, I *stupidly* didn't worry about it. So, I stopped getting updates, leaving me with a very insecure version of PHP.
Well at least you're clear on how bad of an idea that was..

To do updates, I went to fedoralegacy.org and setup YUM to update. For some reason it will only update to PHP 4.1.2-7.3.17
According to the Fedora legacy repository, you should be gettting php-4.2.2-17.17.legacy.i386.rpm (2 Dec 2005). Are you sure you have your repo configured properly in YUM?

However, from what I've read elsewhere, I need a higher version of PHP.
There are more current releases (technically 5.1.2 is most current), however the fedoralegacy versions are backported patched versions and should be secure against reported vulns.

So, anyways, with the update from fedoralegacy I'm still getting compromises on my servers. I keep killing the processes and deleting files in the /tmp directory.
Note that with each compromise you are significantly increasing the risk that one will be more extensive. Even one is enough that I would recommend rebuilding the box from trusted media unless you can be sure that a more extensive compromise hasn't already occurred.

Can anyone help me figure out what's going on and whether or not the fedoralegacy advisory is correct that the new version of PHP that I have should have fixed the vulnerabilities??
First off I'd try running YUM in list mode and verify that it sees the the updates it needs and then run in debug mode to see if you can diagnose why it isn't getting them. Then I'd immediately take the machine offline until you can be sure of it's integrity. From there, try manually downloading and installing the updated php version. I'd also absolutely recommend running chkrootkit and/or rkhunter on the system as well. You should also take note of the list of running processes, listening network sockets, and look over the logs in detail for anything else that appears suspicious. Running an AV product (like clamAV, panda or Kaspersky labs) should identufy any other infected files on the system.

Capt_Caveman:

I've done as you said. Apparently I am getting the correct version of PHP. The tool I was using to assess the system is incorrectly reporting it.

Here's an update on the issue:

When the machine is compromised, if I do a ps -aux I get some weired processes. One of them being:
[<sh defunct>] under the user Apache
Also, the user Apache has many many many httpd processes
some of them labeled like this: [httpd] and some without the brackets.

When I do "service httpd restart" The service stops but will not start because it says something else is already running on port 80. So the only way I can get my webpages back up is to reboot the system.

I've run chkrootkit and panda av... all come back clean. Do you think my apache service is compromised??

I really can't rebuild these boxes... They have a ton of stuff already configured on them... It would be a big pain to do it.

Any suggestions?

Thanks!

-Mike

You really should wipe it and reinstall if you keep getting compromised. But if it looks like its only apache that's been hacked, ie. they haven't got root yet, maybe try focusing on the apache user - make sure its disabled for example. And get rid of the php scripts which are causing the compromises.

When the machine is compromised, if I do a ps -aux I get some weired processes. One of them being:
[<sh defunct>] under the user Apache. Also, the user Apache has many many many httpd processes
some of them labeled like this: [httpd] and some without the brackets.
Get the PIDs of any of the strange processes and look up the location of the binary under /proc/<PID)/cmdline. From there you can get a full path and do some investigating in that dir.

I've run chkrootkit and panda av... all come back clean. Do you think my apache service is compromised??
Don't know yet. Try doing rpm -Va and see if that flags any files (especially the apache binary).

Also to take a step back, how are you sure that it was the lupper worm anyway? What exactly did you find in temp?

I really can't rebuild these boxes... They have a ton of stuff already configured on them... It would be a big pain to do it.
Personally I agree with tkedwards and suggest a full reinstall. You can backup any config files or webpage content as long as you can visually inspect the contents, so no binaries. Frankly, cuting corners is what got you into this position, so I would recommend biting the bullet and doing things the right way.

Hi All,

Thanks for all the help. I found out what the problem is. Apparently the version of PostNuke that I was running had a flaw in it. The file "xmlrpc.php" can be used to "POST" executable code. I was looking through my httpd logs and found out that was the file they were abusing. It appeared to be an automated script because it was scanning for other files (/wordpress, /blog, /blogs, etc).

I deleted the xmlrpc.php file, cleared the /tmp folder, and rebooted... Since then everything has been peachy. No rogue processes, no strange network traffic. I'll give it another day or so to make sure, but I think it's fixed.

Thanks again,

-Mike