|
How do I remove a trojan core?
I found that someone had compromised one of the wordpress sites on my server. It is the trojan that adds base64 encoded javascript to all of your index.php files. I found the suspect file, deleted it, cleaned all the index.php files, locked down FTP and then, after about 10 minutes, all of the code was added back to the index.php files. And it did it without modifying the timestamp.
I went through the entire process again and rebooted the computer to make sure nothing was running in memory. I ran avg on the entire site and it finds nothing. I run rkhunter and it finds nothing. But the index.php files keep self-modifying so I have some sort of virus running in a process somewhere. Any idea how to find it? I did set the permissions on critical index.php files to 440 so that they cannot self-modify and that seems to help. But I need to find the culprit process and stop it. ps -ax yeilds the following: Code:
PID TTY STAT TIME COMMANDAnything look suspicious? I am a little concerned about the next to last line. Why would 197.122.66.229 be starting sendmail? Help please!! |
Hi, just a loose thought, run iotop to see what accesses the drive and how much. As soon as the clean-up is done, "it" should get back to work. At that point, it should consume a lot of disk activity...
Next, look at the /etc/passwd file to see what/who has root privz besides the root. That could be a clue to a possilbe "shadowroot"... If you can spot where what comes from, start the system with a clean Live CD and snip where possible, Knoppix is a good one, has great tools... And, by the way, if the IP address sendmail uses is foreign...it stands to reason that's the hacker's contact line...cutting that may alert him/her, so be careful there... Oh, did you try a netstat of the system itself? Maybe something could come from that angle too... Shape up the fire wall, after the clean-out, it's useless to do that now, the trojan will simply rewire it anyway. By the way, the trojan may need root rights, deleting the entry from the passowrd file(s) can help... Good luck Thor |
From what I've been reading all day, the culprit is a compromised php file somewhere. That file is a page that is triggered remotely by accessing it's URL. It then goes and re-writes the trojan into all of the index.php files. I cleaned everything, cleaned by http access files and then started httpd waiting for it to occur. After about 30 minutes it did so I am now analyzing log fines to see if I can determine which page has the compromised code on it. What a hassle. I don't know what code to look for in the 'parent file.
|
Okay, let's be rational...it is possible the hacker is not even calling up the file anymore...this is automated now (real clever, granted). However, it's got to be something that is allowed to write to the local disk. I suspect that php file to call an external file: the trojan.
Okay, the trojan could be anything, but perl comes to mind. Possibly part of a rootkit (sorry, dude), so, I'd go for a grep-seek for anything a php file calls to the "outside", php has an include syntax, it goes something like this Quote:
Keeping my ears open... Thor |
Well, I did find some perl files with AVG that had been uploaded to the wordpress directory structure. But I deleted than and completely removed that particular blog and the trojans still came back. Is there a way to log disk writes to a file so I can inspect that?
|
Quote:
wait, maybe we can lure 'im out. Make a folder in the wordpress setup, only give yourself write access, make it world readable. Put a php file in there, fire op iotop and watch. There should be a process knocking at the door of that new folder... Maybe a hint... |
op iotop ?
|
typo, I meant to say "start up iotop"
Oops... |
FYI, I found this: http://www.cyberciti.biz/tips/linux-...to-a-file.html
|
Cool, just...what file will you be auditing? There's quite a few out there, I guess...
Unless you want to watch the "baitfile"...then, that's clever...do it! Let's see where the eagle splats down... :D Thor |
I am auditing one of the index.php files that I know will have code injected into it in a few minutes... (waits with baited breath)
|
...keeping my fingers crossed here...
|
meanwhile, back at the ranch, I want to run a script to clean all of my index.php files. I wrote this:
#!/bin/bash sed -i "s/eval(base64_decode('a-long-string-of-characters-goes-here'));//g" index.php but it doesn't work. This isn't a very difficult command. What am I doing wrong? I basically just want to strip out that long eval. Do I need to escape some character? Also, how can I get it to recurse though all sub directories in my 'sites' folder? Thanks if you have an answer. I have looked at various googled-results and all seem confirm my syntax. |
Okay, maybe this threeliner could help
Quote:
Keeping mileage in account here, it's one-o-clock (in the morning) here so... Edit... Quote:
Quote:
(turning in for the nite *yawn* ) |
- Stop the web server during maintenance,
- Check if your WP version is the latest version. BTW there are no compelling reasons not to run the latest version, - Check plugin usage. Update plugins if updates are available or disable them if they are no longer updated or maintained (also see this WP/TimThumb thread.), - Check for any files in the upload directory (for instance files having a .jpg extension doesn't mean they are JPEG files), - Harden the machine. If you host WP yourself then the OWASP mod_security rules (CVS rules tarball) may help you beef up security. - If there's anything else to address then would be the time, before you expose the machine to the 'net again. * Please check prioritisation of tasks at hand. Cleaning up base64-encoded crud may seem the most important to you but it is not. If you do not combat the cause first then you'll be experiencing the symptoms again and again. |
Thanks unSpawn. I understand that. I have about 100 websites running on that machine and only a handful are WP but AVG found the trojan scripts attached to one of the WP files. As you can see from my thread with Thor, the focus has been on finding the source. I only asked for help with the SED issue while I was waiting for the audit to trigger.
|
Quote:
|
That's my point. I perform those tasks to get a clean slate so I can try to watch the injection as it is happening.
I need to find out why they keep reappearing. The structured approach is I installed the kernel audit program and found something strange. I set the audit to watch the index file in an unused openx installation I have. Then, I cleaned all my files and let time go by. After about 20 minutes, I ran ausearch and got this... type=PATH msg=audit(02/25/2012 19:04:43.721:2118) : item=0 name=/home/httpd/sites/ads/doc-root/openx/index.php inode=68419586 dev=fd:02 mode=file,644 ouid=gfxweb ogid=gfxweb rdev=00:00 type=CWD msg=audit(02/25/2012 19:04:43.721:2118) : cwd=/home/httpd/sites/mlmblog/doc-root/wp-content/themes/classic type=SYSCALL msg=audit(02/25/2012 19:04:43.721:2118) : arch=i386 syscall=open success=yes exit=62 a0=1f7a1ec a1=0 a2=1b6 a3=1f7a1ec items=1 ppid=9129 pid=9136 auid=dougw uid=gfxweb gid=gfxweb euid=gfxweb suid=gfxweb fsuid=gfxweb egid=gfxweb sgid=gfxweb fsgid=gfxweb tty=(none) ses=20 comm=httpd exe=/usr/sbin/httpd key=hacked why would an httpd process coming form a blog site hit the openx index.php file? So I looked in that wp subdirectory and there are no scripts that I can find. Nothing immediately jumps out anyway. I found a stray index.html file with a bunch of javascript in it that I hadn't see before. That was promising but after cleaning it, the other index.php mods came back. |
selinux
Dougwo,
From the log snippet, it looks like you have SELinux disabled. Maybe you don't have the luxury right now of putting it in enforcing mode, but you could set it to permissive mode, wait a while, then do a "ausearch -m avc -ts this-year" to see what kind of AVC messages turn up. You could also do a "ausearch -m avc -ts this-year | audit2allow" to make some quick inferences about what would NOT be allowed were you in enforcing mode. Later, when you get everything cleaned up, put SELinux in enforcing mode and create policy modules for your needs. |
Thanks agentbiuzz. I was just thinking today of enabling SE linux. My first experiments a couple years back were a disaster (had to leave installs in standard locations, etc.) where I like to move things around for security by obscurity.
I think I solved the problem. I found it by running auditctl on a file I knew was going to be targeted. Then, when the log showed that the target file was modified by a wordpress theme directory, I investigated. But there was nothing in that directory that was suspicious. Until I looked in the server logs and found that the culprit was a file called functions.php. But functions.php didn't exist in that directory??? So I looked in my backups (infected ones) and found that there was a file called functions.php in a that same theme directory that had all sorts of javascript in it. Apparently, my partner had a virus on his PC that exposed his WP password to the culprit. That culprit then logged in as admin to a wordpress site and uploaded a theme -- his own theme with compromised code. Then, he switched to his new theme for just a second that executed the code then switched back. We never knew it happened until after the fact. the code was clever enough to delete functions.php after it ran so we couldn't find it. I suppose it was luck that this morning's backup grabbed a copy. Hope this little adventure helps someone else int he future! Thanks everyone for their help. |
Maybe as a closing remark, there are some vulnerabilities with wordpress...maybe worth a look as well?
Glad it turned out okay. Safety of a system is defined by the safety of its parts, security is everyone's concern. But, that's just me... Thor |
Fundamentally, you need to make sure that the PHP files are not writable by anyone.
I always set up a private maintenance account, with its own private group, and chown all files to it. No one else anywhere has permission to touch the files. You must also check for Access Control Lists (ACLs), which, if present, will supersede the simple Unix permissions-mask. If the site is on a shared host, then realistically any other system user might be doing it. Shared hosts customarily define a ftpusers group that everyone on their planet belongs to . . . |
Quote:
Quote:
Quote:
Quote:
Thor |
To follow-on to my suggestion, yes, putting stringent permissions in place does limit what you as an administrator can do to a site. But this is easily handled. Simply construct your site and manage it on an internal, inward-facing-only web site. Then, periodically, "publish it" to the public web site location by means of a script (external to WP). This script must be executed by the one maintenance user-id which does have read/write access; a user-id that is used for no other purpose. This script uses chmod to make the files read/writable to itself, then does an rsync to synchronize the directories, then it executes another chmod to make the files read-only, even to itself, once more.
This script should also perhaps use another rsync (or maybe gzip) to make a backup copy of the site before and after. Each backup that is taken is unique, and it is immediately made read-only. It is a good idea to set the Unix permissions-mask to "no access" so that only an ACL entry permits access to anything .. and the access that is granted is strictly, "need to know, need to do." For instance, if Apache becomes nobody while running, then nobody can use the directories, and the maintenance userid of course can, but no one else anywhere can even see what the directories contain. Database content is synchronized in a similar manner, and table permissions are likewise stringently controlled. If WordPress needs to consult a table on the production database, then it cannot modify it. And so on. This is called the principle of least privilege. Computers suck at saying "yes," but they're excellent at saying "no." |
| All times are GMT -5. The time now is 08:58 PM. |