We’ve just raised the bar for WordPress security plugins with our WordPress Core File Scanner.
When someone hacks your WordPress site, at least one of your core files will be compromised.
Compromised? Yes, with access to your web hosting file system the hacker can change the contents of one or more files. Once they get this far, they’ll have full access to your site and can do whatever they want with it.
But, what if we can automatically remove file hacks without lifting a finger? Without clicking a button, or getting an email notification from our so-called security plugin?
This unparalleled protection is now possible. 😀 Introducing…
The WordPress Core File Scanner
With the version 4.16.0 of our Shield Security plugin you’ll have a new feature that scans your WordPress core files. It looks for any deviation, no matter how slight, from the official WordPress distribution.
But even better… you can have it automagically repair any files it finds to be tainted or missing.
You now have peace of mind knowing that your WordPress files are automatically secured!
How does the file scanner work?
Unless you have a funky file system setup, this should work perfectly well. It uses the WordPress.org API to get a list of MD5 hashes for core files and then compares your existing files against this.
If any hashes don’t match up, we are certain that a core WordPress file has been altered.
This scan runs once per day via the built-in WordPress cron.
Note – What the file scanner doesn’t do…
We have excluded several elements from the scanning. This is because these particular elements may be modified independently with newer releases. These include:
- The Hello Dolly plugin
- The nefarious Akismet plugin
- All the Twenty-something themes
How to turn on the Core File Scanner
The Core File Scan is a part of the Automatic WordPress File Scanner. It turns on by default as soon as you install and activate the plugin.
The option to automatically repair files is disabled, so you have to turn that on yourself. After all, you could be one of those crazy fools that likes to modify WordPress core files. ;-o
To toggle the feature, look for the ‘Scans & Integrity’ zone in the Shield Security menu. In there you’ll see Automatic WordPress File Scanner and other options.
You can select which areas should be scanned and list of file/folder paths that will never be scanned.
Questions / Comments?
Feel free to leave comments and questions about this feature below. We listen 🙂
Hi, first off I have to say the usual love the plugin thing, it is fantastic and helps me sleep at night.
I saw this feature being rolled out as beta and was quite excited about it as I’d been considering creating something similar myself, so you saved me a job!
On the first run of the plugin it has thrown up quite a few false positives and I thought you might appreciate the feedback.
The files it claimed were altered were:
– wp-includes/version.php
The files it claimed were missing were:
– wp-content/index.php
– wp-content/languages/en_GB.po
– wp-content/languages/admin-network-en_GB.mo
– wp-content/languages/admin-en_GB.mo
– wp-content/languages/admin-network-en_GB.po
– wp-content/languages/en_GB.mo
– wp-content/languages/admin-en_GB.po
– wp-content/themes/index.php
– wp-content/plugins/index.php
When I install WordPress I move all the core files into a /wp directory, leaving only index.php, wp-config.php, wp-content/ and wp/ in the root, might this have affected it? This should be easy to accommodate for as get_site_url() will give the correct position of the core files.
I understand how you can compare core files to hashes from wordpress.org, but out of interest are you using the Exploit Database (as used by Metasploit) as the basis of your scans of plugins?
Thanks and keep up the good work
Stuart
Hi Stuart,
Thanks for your feedback on this!
In the next release I’ll update it so it doesn’t review the languages folder and that’ll get rid of that warning.
Also, I’d check your version.php – there’s no reason why that should be any different.
You’re not the only one to receive notification for the index.php files. It seems that WordPress, when it installs on your site, is not actually using the exact files as they are found on the SVN. No idea why… it seems the version on SVN doesn’t have the trailing
?>Moving your files into subfolder also doesn’t affect the tool – all our sites are installed within sub-folder as standard and our tools built to accommodate this scenario 🙂
Thanks again for your feedback and sharing your thoughts!
Paul.
I received this:
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-content/themes/index.php
– wp-content/plugins/index.php
– wp-includes/version.php
I’m wondering if you are supporting non-US releases? I am running version 4.4.1–en_GB.
Hi Richard,
Yep, we use the WordPress locale to get the correct data for comparison. I’d be curious what’s different in your version.php… did you check?
As to the index.php, please see my reply above to Stuart’s comment about this.
Thanks!
Paul.
I have now checked the files against the official GB download (wordpress-4.4.1-en_GB.zip) and these files are all changed on installation, which is why they don’t match the download.
The themes and plugins index files both have their endings added to with “?>”.
The version file has this added to it at the end:
$wp_local_package = 'en_GB';So these are all false positives. I hope this helps.
Yep, I think with the WordPress patch upgrades, the index.php files don’t get updated – the
?>were all removed from these files some time back.I’m going to release a patch to the plugin to perhaps now exclude the
version.phpfile so we don’t mess up languages going forward.Thanks for reporting this!
Paul.
I got the update to 4.16.1 but then received the same message again this morning:
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-content/themes/index.php (WordPress.org source file)
– wp-content/plugins/index.php (WordPress.org source file)
– wp-includes/version.php (WordPress.org source file)
So is the fix for this another version that is not yet here?
Hi Richard,
It seems this fix didn’t do anything for your sites – I’m getting reports that it’s fixed them.
Is the email you’re receiving definitely pertaining to the site in question – i.e. do you have multiple WordPress sites and you could be mixing them? Also, did the plugin definitely update before that email was sent out?
For the site in question, could you tell me:
– do your index.php files end in ?> and are they 32 bytes long? I have coded in a very specific case to handle this. If your index.php files deviate from the very old versions and the current, this is a valid warning.
– do you have anything in your wp-config.php refering to WPLANG ? This may be affecting your locale that WordPress detects..
Thanks. It might be best to contact us on our support helpdesk – the comments isn’t the best place to work through this.
Paul.
Yes I have multiple sites. No I didn’t confuse them. Yes, the message was after the upgrade.
No, the index files are 30 bytes not 32 bytes. Here is the index file from the themes folder:
00000000h: 3C 3F 70 68 70 0D 0A 2F 2F 20 53 69 6C 65 6E 63 ;
The plugins index file is identical, also 30 bytes.
Here is my version.php file, 619 bytes long:
<?php
/**
* The WordPress version string
*
* @global string $wp_version
*/
$wp_version = '4.4.1';
/**
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
*
* @global int $wp_db_version
*/
$wp_db_version = 35700;
/**
* Holds the TinyMCE version
*
* @global string $tinymce_version
*/
$tinymce_version = '4208-20151113';
/**
* Holds the required PHP version
*
* @global string $required_php_version
*/
$required_php_version = '5.2.4';
/**
* Holds the required MySQL version
*
* @global string $required_mysql_version
*/
$required_mysql_version = '5.0';
Here is the official version of that file, which is 649 bytes:
<?php
/**
* The WordPress version string
*
* @global string $wp_version
*/
$wp_version = '4.4.1';
/**
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
*
* @global int $wp_db_version
*/
$wp_db_version = 35700;
/**
* Holds the TinyMCE version
*
* @global string $tinymce_version
*/
$tinymce_version = '4208-20151113';
/**
* Holds the required PHP version
*
* @global string $required_php_version
*/
$required_php_version = '5.2.4';
/**
* Holds the required MySQL version
*
* @global string $required_mysql_version
*/
$required_mysql_version = '5.0';
$wp_local_package = 'en_GB';
Hi Paul,
I received this from 25 of my client websites
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-content/languages/nl_NL.po
– wp-content/languages/admin-network-nl_NL.po
– wp-content/languages/nl_NL.mo
– wp-content/languages/admin-network-nl_NL.mo
– wp-content/languages/admin-nl_NL.po
– wp-content/languages/admin-nl_NL.mo
You should review these files and replace them with official versions if required.
These files are not compromised in any way. I’m guessing another false positive?
Hi Sander,
The next patch release will add the “wp-content/languages/” directory to the excludes list so that translations are not included in the core file scan.
Thanks!
Paul.
Great addition to the plugin. Do you plan to add a feature where we can see the file check sum check status? and if a file was replaced with original file by the plugin?
Hi Muhammad,
Not yet… for now it will remain on the WordPress cron and notifications will be sent out when discrepancies are detected and when files are fixed/replaced.
Thanks!
Paul.
Hi Guys,
Some of the older wordpress installs that have been upgraded form version to version have slight differences in some pages. For example I got emails alerting me to these files
– wp-content/index.php
– wp-content/themes/index.php
– wp-content/plugins/index.php
Upon examination the difference was the newer files don’t include the closing PHP tag on line 3.
vs
<?php
// Silence is golden.
Is there any way to check against older checksums or can you program to ignore this issue? I manage a lot of companies sites and I don't want constant false positive email warnings
Hey Norm,
Thanks for the comments… with a bit of investigation, we’ve discovered the same. Please see here for further details. I’ll be releasing an update to the plugin to handle this case.
Thanks!
Paul.
Hey! Thanks for informing me about my Security and Core File Scanner and Automatic File Repair.
Something went wrong there. Here is the hex version of my 30 byte long index files:
00000000h: 3C 3F 70 68 70 0D 0A 2F 2F 20 53 69 6C 65 6E 63 ;
00000010h: 65 20 69 73 20 67 6F 6C 64 65 6E 2E 0D 0A 3F 3E ;
I know you are thinking that is 32 bytes. It is very strange. Filezilla shows it is 30 bytes. After transfer to Windows, the properties there show 30 bytes. When I look at the file with a hex editor I see 32 bytes!
Here is the WPLANG section from wp-config.php:
/**
* WordPress Localized Language, defaults to English.
*
* Change this to localize WordPress. A corresponding MO file for the chosen
* language must be installed to wp-content/languages. For example, install
* de_DE.mo to wp-content/languages and set WPLANG to ‘de_DE’ to enable German
* language support.
*/
define (‘WPLANG’, ”);
OK I now understand why the index file seemed a different size. My hex editor was set to convert unix line terminators 0A to the standard 0D 0A.
Here is my 30 character file:
00000000h: 3C 3F 70 68 70 0A 2F 2F 20 53 69 6C 65 6E 63 65 ;
00000010h: 20 69 73 20 67 6F 6C 64 65 6E 2E 0A 3F 3E ;
Sorry for the confusion. This is the file you are comparing to, and flagging as incorrect.
The file really is 30 bytes, not the 32 bytes you were expecting.
Let me know if you need any more information to solve this.
Hi Paul,
I have the same issue where on most websites I manage, the index.php file from the plugins folder and the version.php files are fales positives.
The websites that I have issues on, where either configured on Windows and uploaded by FTP (date change?) or restored from a backup on the live website environment.
I am not an MD5 expert but I learned from a very short investigation that MD5 is very sensitive for any change to the file, even file date or attributes.
I have 2 very simple and stupid suggestions:
1. Take a WordPress core update as the starting point for calculating MD5 values from those files and use those to compare if files are changed. Take for granted that files are clean or maybe start with replacing files with original ones after an initial scan. In other words: calculate and compare checksums for the same files.
2. When you keep the current way the plugin works, not only check the MD5 values with the original files but also the file size and file date. If someone or something modifies a file, the chance the file is not diffent in size is very little, nor is the file date.
Suggestion. Add a feature where you can click on the setup page to force an immediate scan.
This will be made available in the next release by way of a URL parameter. It’ll be detailed in the FAQ.
Suggestion. When you manually force a scan, which one can now do, please could it send an email saying everything is OK, if it doesn’t find any problems. This provides positive confirmation that the check has taken place.
Great plugin. I made a change to a core CSS file to fix an issue with the stock media player’s CC button, and, a week later, received an email from the plugin telling me that a file had been changed. Since this is a needed change, is there a way to whitelist this file?
Hi Mike,
Sorry, but I’m not probably going to implement a white list system for this… it just adds too much complexity to support.
The best place to put your CSS is in your theme’s
styles.cssfile. If you’re not using a child theme, it’s very easy to setup, and this will protect you against upgrades. Much better this way, than having to fix CSS for every WordPress upgrade.Thanks for the suggestion, and I hope you understand why I’m not going to put in this feature…
Paul.
How do I get the plugin to “automatically repair any files it finds to be tainted or missing”? I can’t find the setting for this. Thanks
Hi Tony,
This setting is under the ‘Core File Scanner’ tab within the Hack Protection feature module… take a look at the screenshot in the article above and it shows you where to find it visually.
Thanks.
I keep getting email from few of my pages, saying something like
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-includes/js/jquery/jquery-migrate.js (WordPress.org source file)
– wp-includes/js/jquery/jquery-migrate.min.js (WordPress.org source file)
I get the same one everyday, at least from the one page… how can i end this?
Hi,
There are several ways to do this. If you look up into this article you’ll see there is an option to turn on auto-repair… if your WordPress site has disk-write access, this will solve the problem.
Alternatively you can follow the links in the emails to the source files, download the content, and replace the file contents on your web hosting manually yourself.
Or you could download the same source from WordPress.org and copy up the files to replace these files yourself.
If you are doing this, and it’s repeatedly coming back with a problem, you should start to carefully monitor these files. Check the modified dates on the files and ensure they are changing only when you do so. If not, you may have something that is writing to these files that you don’t want.
I hope that helps!
I had the automatic repair on other pages and i remembered i had it for this one too but after checking it looks like i had forgotten. Now the automatic repair is on and I hope it wont be sending those mails again, thank you! 🙂
I’m still getting the message, but it’s slightly changed. It says “We have already attempted to repair these files based on your current settings. But, you should always check these files to ensure everything is as you expect.”. Should I then try to copy the source code from the email and upload them to the server manually?
Hi! I’m having a similar problem to the one above. I get an email every single day that says:
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-admin/includes/upgrade.php (WordPress.org source file)
– wp-includes/functions.php (WordPress.org source file)
They have a lot of code and I don’t know how to compare them to the source files to see what might be different, so I turned on the auto-repair the other day, and still got the email. So then I went to the source files linked in the email and replaced the code for those to files. I am still getting the email.
Before I replaced the code on those files, I checked the modified date and they had not changed since I installed WordPress on this site. I just checked again, and they have not changed since I edited them other day.
I don’t know what to do! Should I be concerned? How do I know if I have a plugin that is modifying those files? I can’t imagine that any plugin would need to modify the “upgrade” file.
Any advice on what I should do?
When you turn on auto-repair, you do get another email, but the email is different. It tells you that the files have been replaced.
To compare two files, try using this tool: http://www.howtogeek.com/206123/how-to-use-fc-file-compare-from-the-windows-command-prompt/
If the files are exactly as they are on the source – and there’s a link in the emails to the source – then you wouldn’t be getting these emails. Something is different…
Thanks!
Hi! I’ve been meaning to follow up on this. After comparing the files I found that the only differences in those two files were some extra line breaks. None of the actual code was different, and in fact I compared the files several times before I finally realized what the difference was because the code was the same other than one of them having two line breaks between the lines of code instead of one. If possible, it would be good if you could make it so that it ignores things like that.
Thanks for the help!
Hi Courtney,
Unfortunately this isn’t how the scanner work… this may help explain it a bit further: https://icontrolwp.freshdesk.com/support/solutions/articles/3000048817
Thanks but this core scanner is only annoying for me, not useful at all, I’m getting following email every day for multiple websites:
The MD5 Checksum Hashes for following core files do not match the official WordPress.org Checksum Hashes:
– wp-includes/js/jquery/jquery-migrate.js (WordPress.org source file)
– wp-includes/js/jquery/jquery-migrate.min.js (WordPress.org source file)
– wp-includes/js/mediaelement/bigplay.svg (WordPress.org source file)
– wp-includes/js/mediaelement/controls.svg (WordPress.org source file)
I’ve compared the files and the content is exactly the same!
I’m switching of the core scanner…
Could you please zip up these core files and email them to our support? (See link below for the Support/Contact) page.
Could you also confirm the exact WordPress version that these files are from?
Thanks.
Paul.
I’ve exactly the same problem with the same files…! What could be wrong?
You discovered what’s the problem?
thanks!!
Hi Eduardo,
Use the ‘repair now’ links in the email to align your files. Then you wont get the messages.
Thanks
I have the next error message:
“Details for the problem files are below:
The following official WordPress core files are missing from your site:
– wp-content/plugins/magyar-video-embed/magyar-video-embed.php ( Repair file now / WordPress.org source file )
– wp-content/plugins/magyar-video-embed/readme.txt ( Repair file now / WordPress.org source file )
– wp-content/plugins/azigen/azigen.php ( Repair file now / WordPress.org source file )”
But I think, that the above files non-core files.
The plugins are no longer fresh:
–magyar-video-embed –> Last updated: 6 months
–azigen –> Last updated: 7 years
Can you give me information?
It turns out that the official Hungarian WordPress distribution comes with those plugins installed automatically. That’s why you’re getting this report.
I have added exclusion rules for this in the next plugin release.
About when you can expect the next plugin release?
Unless something serious arises before then, the next planned release is 29th February when we re-brand as Shield – https://www.icontrolwp.com/blog/shield-wordpress-simple-security-firewall-pro/
I have automatic update of my WordPress installation setup. Whenever WordPress updates, Shield sends me a warning which makes me nervous each time. Here’s the warning I got: Subject line “Warning – Core WordPress Files(s) Discovered That May Have Been Modified.” Body: http://pastie.org/private/hoywqn3hztgsaa9zeynjog (website address changed to example.com).
It happens always when WordPress updates and sends me a message like “Howdy! Your site at http://www.example.com has been updated automatically to WordPress .”
How should I react to this? Is this a false positive?
Hi Martin,
I’ve seen this pop up once or twice with other clients and the next release will have a guard in there to try and prevent this from being an issue going forward.
Thanks for reporting this!
It’s not a popup but an email.
Hi Martin,
I didn’t mean a “pop-up”… I meant it has “occurred” 🙂
wow this is great!!
good work
Hi, I keep getting a warning that the readme file is missing, but I removed that on purpose as a pen test reported that this file should be removed.
So I am fighting two security product here.
Who is right? Should readme stay or go. Can I add some sort of exclude rule to ignore this file being missing?
Thanks
Thank you. Nice post. Last year one of my website hacked and since then i am really focused on website security.
Hi Paul,
L-O-V-E the new interface, just a few suggestions for future versions of the plugin.
From habit, from the early days of WP when there was no security, we always remove certain files from the WP core as soon as we install it — licence.txt, wp-config-sample.php, readme.html, etc. Of course the Shield scan then gets its knickers in a knot because the ‘core files have been modified’.
Would it be possible in a future version to exclude unneccessary files like these from the scan altogether? If they have been modified, fair play, that is a red flag, but if they have been deleted then surely that is a GOOD thing?
Also by default Shield flags ALL inactive themes as potential threats, even though WordPress itself recommends having a backup default theme in case the active theme fails, and the other ‘inactive’ theme in our case is the parent theme for our child theme, which is obviously needed. Maybe in a future version you could check if the default theme is a child theme, in which case the parent theme is needed, and maybe exclude ONE default theme (TwentySomething) and warn if there are multiple inactive, unneccessary themes?
Hi Terry,
Glad you like the new v7 interface.
The exclusions you mention for that scanner used to be in place but they got “lost” in the transition to v7. We’ve reinstated these and those filed will be ignored in the scan from v7.1 onwards.
Shield should be ignoring inactive themes and it already detects child/parent themes. Have a check to make sure your child-parent setup is exactly as you think it is. We’ve seen several cases where people thought it was setup as a child-parent, but it wasn’t…
Thanks!
Paul.
Great post, Thanks for sharing this informative blog post. Very useful for me and really Appreciate you keep blogging.
Hi,
Does Shield probe for exploitable files over HTTP/S?
I ask because I’ve spotted many probe requests to eg: /404testpage4525d2fdc? , /RDWeb/Pages? . /invoker/readonly – and many others, all invariably resulting in 404, but all purporting to come from the server IP itself.
I wasn’t sure whether these might be a legitimate Shield scan (requests sent from the server/via wp-cron job), or whether a bad actor probing with a spoofed IP address in the packet header?
Thanks for any advice.
Rob Cain
Hi Rob,
Shield doesn’t actively probe for exploitable files over HTTP/S as part of its standard functionality. The requests you’re seeing do not belong to Shield and it doesn’t generate requests to arbitrary paths like these as part of its security scanning processes.
It’s more likely that these requests are coming from external sources.
Regarding the source IP address, without further investigation, it’s challenging to determine definitively whether these requests are spoofed or originate from legitimate sources. You can use Shield IP Management tool detailed here to analyse and get the most important information and activities for the IP addresses.
To further investigate these requests and assess whether they pose a threat to your WordPress site, you may consider reviewing your web server’s access logs, including the source IP addresses and any patterns or recurring behaviors that could indicate malicious activity.
We also recommend you to run WordPress Security Audit by using our guide here.
Regards,
Jelena