One Less Thing For You To Do: Monitor Your WordPress Core Files For Hacks!

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 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 cetain 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

Screenshot: iControlWP Security Plugin - WordPress Core File Scanner

Screenshot: WordPress Core File Scanner Options

The core file scanner comes with version 4.16.0 of the Simple Firewall plugin. 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 ‘Hack Protect‘ module in the Simple Firewall menu. In there you’ll see the Core File Scanner sub-section.  (You’ll also see options for the Plugin Vulnerabilities feature, released recently)

Questions / Comments?

Feel free to leave comments and questions about this feature below. We listen 🙂

Join the discussion 48 Comments

  • 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

    View Comment
    • Paul G. says:

      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.

      View Comment
  • Richard B says:

    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.

    View Comment
    • Paul G. says:

      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.

      View Comment
      • Richard B says:

        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.

        View Comment
        • Paul G. says:

          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.php file so we don’t mess up languages going forward.

          Thanks for reporting this!
          Paul.

          View Comment
          • Richard B says:

            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?

            View Comment
          • Paul G. says:

            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.

            View Comment
          • Richard B says:

            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';

            View Comment
  • Sander says:

    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?

    View Comment
  • Muhammad A says:

    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?

    View Comment
  • Norm Roussel says:

    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

    View Comment
  • Aarya says:

    Hey! Thanks for informing me about my Security and Core File Scanner and Automatic File Repair.

    View Comment
  • Richard B says:

    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’, ”);

    View Comment
    • Richard B says:

      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.

      View Comment
  • Teo says:

    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.

    View Comment
  • Richard B says:

    Suggestion. Add a feature where you can click on the setup page to force an immediate scan.

    View Comment
  • Mike W says:

    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?

    View Comment
    • Paul G. says:

      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.css file. 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.

      View Comment
  • Tony F. says:

    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

    View Comment
    • Paul G. says:

      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.

      View Comment
  • Heichou says:

    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?

    View Comment
    • Paul G. says:

      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!

      View Comment
      • Heichou says:

        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! 🙂

        View Comment
  • Heichou says:

    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?

    View Comment
  • Courtney says:

    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?

    View Comment
  • Mike says:

    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…

    View Comment
  • T. Gabor says:

    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?

    View Comment
  • Martin says:

    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?

    View Comment
  • anon says:

    wow this is great!!
    good work

    View Comment
  • Steve says:

    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

    View Comment

Leave a Reply