Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I unfortunately found today that I have a malicious script on my website. It is chmodded 644, but I cannot delete it. Directories above it would permit me to delete it normally. The interface is cPanel.

I found out the name of the creator from the bottom of the source code behind it.

This script is very nasty, and is in every directory of my website. Fortunately, I have a clean backup and I plan on restoring that ASAP.

From the source, I have derived that it is used to "crack" ftp passwords, mysql databases, security in general, and it can (unfortunately) do a lot more than that too, including have direct access to every single file on my account. It targets certain scripts, namely phpbb, smf, and vbulliten, but I have none of these running on my website.

Is there a script to force-remove this virus/worm/whatever the heck it is without triggering it?

It appeared in all directories where the chmod was at least 755 for a fact, and a few where it was 644 somehow.

What do I do? Nobody has run it yet, it is simply sitting there in place. No access logs have any record of anybody doing anything with it (yet)

Whats the best path for me to take? I have been hearing that it is on the whole server, not just my account.

Also, sorry if this site is not the right place to ask it, I figured this was the best though because it directly relates. Any way to just blacklist the file name?

share|improve this question
2  
What would help is the output of ls -la and lsattr -a for the directory that the file is contained in. –  womble Jul 26 '09 at 0:19
add comment

4 Answers

up vote 11 down vote accepted

I can not stress this enough; you need to rebuild the server. You can not be certain that there isn't any backdoors installed or trojaned binaries. The fact you couldn't delete the script suggests something is not right with the server. The only way to be certain is to reinstall. This shouldn't take too long considering you have backups.

If you do not control the server, then insist that the person who does control it reinstalls the system. If they do not, I suggest you move to an alternative hosting provider, as they do not take security seriously.

share|improve this answer
    
I don't control it, and I am switching immediately. Thanks so much! Would it help if I gave the file name? Its pretty specific, and a google search can find it. –  Cyclone Jul 25 '09 at 21:28
    
He probably can't delete the file because it's owned by Apache instead of the user. –  ceejayoz Jul 26 '09 at 15:55
    
I switched servers, it okay now. –  Cyclone Jul 26 '09 at 22:24
add comment

What you are describing is the "immutible" bit, which functions like a "master read-only". Once set, the file cannot be deleted, but you can always unset the bit and delete the file. Of course, you will want to back up what you can, scrub your setup, and rebuild from scratch. It's always best to nuke from orbit.

share|improve this answer
    
Too bad I am on a "shared" hosting account >.< –  Cyclone Jul 26 '09 at 0:32
add comment

A common thing for rootkits and other malicious stuff to use is use extended attributes (especially the immutable attribute) to make it harder to clean up. It's likely that inexperienced admins wouldn't know or think to check extended attributes. For info, man lsattr or chattr.

And of course, you really need to rebuild the systEm, as other answers have pointed out.

share|improve this answer
add comment

There are lots of php exploits that can be used to insert files such as these. From what you described it sounds like you are in a shared hosting environment? If so, it is likely other people on your server are suffering the same fate. I disagree that you should rebuild the entire server. Often times these files are inserted and the owner is nobody or a random UUID so that could explain why you can't delete the files.

Specifically in a cPanel environment there are settings to control open_basedir that can inadvertently allow things like this to happen. This usually affects only directories in /home or higher.

If you control the server, make sure the files are owned by your user with ls -l <filename> If they are not owned by your user you will need to contact the admin to have him chown the files and/or delete them.

share|improve this answer
    
I just switched servers, its okay now. –  Cyclone Jul 26 '09 at 22:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.