I’ve just released version 0.95 of WordPress Exploit Scanner.
This release fixes a number of bugs and makes it easier to scan for exploits and read the results.
I’ve added an “Exploits” scan level which looks for obvious code that hackers use. It will return a few false positives but it’s a good first scan to try if you suspect your website has been hacked. You can then use the “Blocker” and “Severe” to scan for ever more suspect strings.
Scans are now done 50 files at a time, with the page reloading after each. The scan results are saved in the database (in your options table as not-autoloaded records to minimize load on your blog) and you can open another browser window or tab on the Exploit Scanner admin page to view the saved results even before the scan is completed.
MD5 hash records for WordPress 2.9.2 have been added, and the hash records for 2.9.1 were corrected.
In other news I’m looking for testers to try out the almost ready WordPress MU 2.9.2. More details are on the forum thread above.
Hello. What do I do after the scan running, will I then deactivate the plugin or it is ok to leave it activated at all times and run the scan from time to time. Interesting, I will install the new Exploit Scanner 0.95 and run it on my blog as a precaution and to see if there was some possible danger in my files. Thank you. Sounds like a good fun, will let you know.
Looking good! The exploit level makes it much easier to digest and analyze the report. Thanks for adding it…
I still think it might be nice to have a flag for newly found warnings.
Let’s say I run the scanner regularly: after each install or upgrade of a plugin, upgrade of WordPress and maybe at regularly-scheduled intervals.
Then it works like this: I set up a clean install of WordPress and run the Exploit Scanner immediately. I can pretty safely assume that everything it found was a false positive.
Next, I install a plugin and run the scanner again. This time, the new warnings (most likely false positives generated by the new plugin) are displayed. I can quickly sort through those (ignoring the previously found false positives). If I’m satisfied that the new warnings are false positives, I can disregard them
Now, this is where it gets good. If I’m running after every upgrade or install of plugins or WordPress, AND I’m running at regularly scheduled intervals, I should see no new warnings at my regularly scheduled scans. That is, any new warning that comes up at a regularly scheduled scan should be analyzed very closely, since it was most likely not triggered by an upgrade of WordPress or a plugin.
Seems like this would be a pretty easy feature to implement – just put a flag next to each warning that wasn’t in the previous set of warnings.
What’s your take?
Thorsten and I were talking about that the other day. The problem with it is that it would be very easy for a hacker to insert fake data to fool the plugin into thinking that a file was ok when it really wasn’t.
You could make life a *lot* harder for hackers by salting the md5 hashes of the files with the a password, but a dedicated hacker could figure it out by comparing the MD5 values of known files like those in plugins with the stored hash values. With a short password it wouldn’t take too long to figure out..
Paranoid? Sometimes you gotta be!
Anyway, it is something that will go in, probably in the next release.
Scanning does not work very well – it ends with “Working on 600 to 650 of 570 files!” 🙂
Scanning worked fine, although it took a bit to allocate enough memory on shared hosting. Memory monster, but a great plugin anyway.