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.
26 Comments
Bugs on October 21, 2009 at 12:07 pm.
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.
Bugs on October 21, 2009 at 12:09 pm.
Oh dear… now that I am reading your post with more attention you are pointing out to the readme… RTFM… sorry
Donncha (1707 comments.) on October 21, 2009 at 12:15 pm.
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.
Bugs on October 21, 2009 at 12:22 pm.
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 (1707 comments.) on October 21, 2009 at 12:45 pm.
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.
Bugs on October 21, 2009 at 12:52 pm.
Version 0.6?
Guran (1 comments.) on October 21, 2009 at 1:54 pm.
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
René (1 comments.) on October 21, 2009 at 2:06 pm.
Thank you for the script. Helped me alot with a clients blog.
Adi R (1 comments.) on October 21, 2009 at 2:20 pm.
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”?
Otto (15 comments.) on October 21, 2009 at 2:25 pm.
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.
Donncha (1707 comments.) on October 21, 2009 at 2:30 pm.
Thanks Otto, I’ll add “create_function” to the checklist!
Kevin on October 21, 2009 at 2:30 pm.
Glad to hear about the MU release.
Pingback: Secure your WordPress install by using WordPress 2.8.5
Sarah Johns (1 comments.) on October 23, 2009 at 4:23 pm.
thanks for the script. we will try this for our new company blog
Johan Wowor on October 24, 2009 at 4:32 am.
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
Donncha (1707 comments.) on October 24, 2009 at 9:55 am.
Oh that dodgy plugin?
hehe. I’m pretty sure that file is ok!
Joe on October 25, 2009 at 3:31 pm.
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.
Johan Wowor on October 27, 2009 at 12:59 pm.
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 ..
Donncha (1707 comments.) on October 27, 2009 at 1:11 pm.
That bas64_decode is probably ok. Download the plugin from WordPress.org again and compare with the version you have on your server.
Diego on October 27, 2009 at 11:44 pm.
There is any script like that standalone? or just as a plugin for wordpress?
TexInWien (8 comments.) on February 15, 2010 at 12:08 pm.
I’d like to echo Joe’s request above. Thanks for the plugin, but I have to say that the results I get from the scan using version 0.94 on my WordPress 2.9.1 blog are somewhere between difficult and impossible to interpret.
If I copy the results of the scan to a plain text file, the file is 5496 lines long. That suggests on the order of 1400 messages with one of the following severities: Blocker, Severe, Warning or Note.
I’ve searched for a guide or support that would help me weed out the false positives and determine whether I have any actual vulnerabilities that need attention, but I haven’t found anything yet.
It would take ages to manually check every warning to decide whether it’s an actual hack or not. With no additional help or resources, I have to assume that the exploit scanner is either broken or displays too many false positives to be of any actual use at this time.
Donncha (1707 comments.) on February 16, 2010 at 11:36 am.
I’m working on paging the scan so it breaks it down into 50 files at a time rather than the whole lot. I also discovered a bug in the hashes file for 2.9.1 – there was an extra dot in front of every filename listed. Don’t know how that got through.
Paging is working well though, I just need to store the results and present them correctly now!
TexInWien (8 comments.) on February 17, 2010 at 3:28 pm.
Hi Donncha,
Thanks for the update. I’d love to install and use this plugin. It seems like a great tool, but 1400 warnings with no easy way to weed out the false positives is daunting. I’m guessing (and hoping) that all 1400 are false positives. That’s about all I can do at the moment, since analyzing each and every one is out of the question — especially when multiplied by several blogs!
I’ll keep an eye on the plugin and look forward to the next update. Keep up the good work!
Donncha (1707 comments.) on February 17, 2010 at 3:32 pm.
Can you try the development version off the download page? I really need feedback on that as I restructured how it scans.
While it’s scanning you can even open the exploit scanner admin page in another browser tab and see the results that have already been collected.
TexInWien (8 comments.) on February 17, 2010 at 3:54 pm.
Hi, just ran it – works well except that it seems to want to go one step too far in the scan. I got this message at the end of the scan:
Working on 1100 to 1150 of 1088 files!
Warning: in_array() [function.in-array]: Wrong datatype for second argument in /www/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 439
I also still get a whole bunch of warnings. I didn’t count, but I guess I got just as many warnings as I did with the production version. I’m still not sure how useful 1400 warnings are, when the few that I analyzed seem to be false positives. I’m trying to figure out how I can actually use the results.
A thought: maybe a feature that compares separate scans would help out. I could install a clean blog and run the scan. I could save the results with a name and date.
Then I could re-run the scanner after I install new plugins or after a certain amount of time passes, saving and renaming these scans, as well. On each scan, I could choose to mark all found items as false positives. On each subsequent scan, I could choose to suppress warnings previously marked as false positives. This way, if I run the scanner regularly or after major events (upgrading WP, installing a new theme or plugin, etc.), I could see a list of only the new warnings.
Or am I simply misunderstanding the purpose of this plugin? How would you go about analyzing a report that includes 1400 warnings?
Donncha (1707 comments.) on February 17, 2010 at 4:35 pm.
Originally the plugin searched for specific strings left by hackers but it has since expanded to show a lot more functions and code that might cause problems. You can already decide what “level” of scan to do so I may just add another, “exploits” with strings found from hacks and less commonly used functions that hackers use.
That would reduce the number of false positives by a huge amount, but of course might miss out something.