Oct 21

The WordPress Exploit Scanner has been updated, with lots of help from Jon and Ryan.

In recent weeks blogs running older versions of WordPress were exploited. If you’re concerned that your blog might have been broken into, download the plugin and run it. It will find false positive results but it will do a reasonably good job of finding the code that’s inserted into a hacked site.

The plugin works by scanning every directory on your site. This is done recursively which unfortunately takes up quite a bi of memory. If you get an out of memory error please read the readme.txt as it has a suggestion for fixing the problem.

PS. WordPress 2.8.5 was released last night. Make sure you upgrade! A WordPress MU release will follow shortly.

You might also like

If you like this post then please subscribe to my full RSS feed. You can also click here to subscribe by email. There are also my fabulous photos and funny videos to explore too!

20 Responses to “Exploit Scanner 0.5”

  1. Bugs says:

    Hi,

    I just tried your script on 3 of my blogs. It runs fine on one, but one the other two I get the following error:
    Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 4456448 bytes) in /home/mmfrog/public_html/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 80

    Any ideas why?
    They are all hosted on the same server (different root folders) and run 2.8.5

    Cheers,
    S.

  2. Bugs says:

    Oh dear… now that I am reading your post with more attention you are pointing out to the readme… RTFM… sorry :)

    • Donncha says:

      Hehe Bugs, that’s alright. Hopefully increasing the memory limit will help although sometimes it doesn’t unfortunately. If you have lots of extra directories on your site, try move them out of the way and add them back and forth when the plugin starts working again so that they’ll all be scanned eventually.

  3. Bugs says:

    Indeed, it did not work…
    what happens is that I have one top directory for one blog, then emmbedded in that one I have my second blog, and so on for the 3 blog…

    The plugins only work on the 3rd blog.

    Even if I increase the memory it does not work for blog 1 and 2…
    I thought about moving the directories but I can’t really do that as they are live blogs.

    Could it be possible to have a list of directories as a black list? meaning, to ignore? This could help solving the memory issues…
    or better still, an option to only scan the core WP directories (wp-admin, wp-include, etc)?

    • Donncha says:

      An ignore list or some sort of UI for picking the sub directories to scan would solve the memory problems.

      The recursive function could dig down 2 or 3 levels rather than as far as possible. Problems occur when directories are very deep, but it doesn’t matter how many directories you have in a particular directory as memory is freed when the recursion “backs out” of a directory.

  4. Bugs says:

    Version 0.6? ;)

  5. Guran says:

    Just loaded and ran this at the same time I upploaded WP 2.8.5
    Then I ran the Exploit Scanner and it worked like a dream.
    Found a great list of what looked to me like innocuous entries (not really a geek)
    But I think I would be able to see, using your brief warnings, if these ‘entries’ were either malicious or looked it. Many Thanks

  6. René says:

    Thank you for the script. Helped me alot with a clients blog.

  7. Adi R says:

    I too have sub-sites off my main site, so it scans Tons of unnecessary files, finding lots of “false positives”.

    Perhaps a simple checkbox on Admin screen to tell it “only scan Wordpress folders”?

  8. Otto says:

    Some hosts I’ve seen don’t let you use ini_set to adjust memory settings. However, these same hosts sometimes have ways for you to use “local” php.ini files to achieve the same thing. This is very dependent upon the hosting service. Ask them how to increase available memory for a PHP script.

    Also, I’ve seen malicious code with uudecode in it (instead of base64_decode). Might be worth adding.

    Another brilliant method I once found to execute arbitrary code was to use create_function to wrap their code in, then to execute it. Like so:

    $a=create_function("",'bad code here, possibly from elsewhere');
    $a();

    No eval, but the code still gets run. Might check for create_function as well, ignoring places it’s used in core files.

  9. Kevin says:

    Glad to hear about the MU release.

  10. Sarah Johns says:

    thanks for the script. we will try this for our new company blog

  11. Johan Wowor says:

    Hallo Donncha,

    I found “base64_decode” at /wp-content/plugins/wp-super-cache/wp-cache.php after scan with “Exploit Scanner”
    Is it normal? Ty :)

  12. Joe says:

    Is there a resource available to help with interpreting the results (forum maybe)?

    It seems that the vast majority of reported issues are actually non-issue ‘heads-ups’. It is hard for me to distinguish these small warnings from actual real security breaches.

    Thanks.

  13. Johan Wowor says:

    More than a month, i lost my traffics till 50% (normally, 50.000 – 60.000/day). I never found any clues that my site got hacked by spam link, database exploit or something like that …
    Two days ago, after i found “base64_decode” at /wp-content/plugins/wp-super-cache/wp-cache.php, i disabled wp super cache plugin .. and today, my traffic is going to normal …
    I’m using VPS for my site .. at normal situation (without being banned by Google), my server always got down if I don’t use wp super cache ..

    I’m in a dilemma ..

  14. Diego says:

    There is any script like that standalone? or just as a plugin for wordpress?

Leave a Reply

preload preload preload

Holy Shmoly! is Digg proof thanks to caching by WP Super Cache