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.
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.
Oh dear… now that I am reading your post with more attention you are pointing out to the readme… RTFM… sorry 🙂
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.
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)?
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.
Version 0.6? 😉
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
Thank you for the script. Helped me alot with a clients blog.
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”?
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.
Thanks Otto, I’ll add “create_function” to the checklist!
Glad to hear about the MU release.
thanks for the script. we will try this for our new company blog
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 🙂
Oh that dodgy plugin?
hehe. I’m pretty sure that file is ok! 🙂
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.
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 ..
That bas64_decode is probably ok. Download the plugin from WordPress.org again and compare with the version you have on your server.
There is any script like that standalone? or just as a plugin for wordpress?
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.
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!
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!
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. 🙂
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?
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.