While reviewing reports of WordPress plugin vulnerabilities for our Plugin Vulnerabilities service recently we came across an odd report from SiteLock. The claimed security issue in the plugin resolved around the fact that:
The File Browser plugin begins its security by determining if the plugin’s readme file is present. If it finds readme.txt, it then examines user levels to authenticate the user.
Their concern with that was:
But if the plugin’s readme file was renamed or removed, the authentication process fails and grants complete access to the plugins’ core functionality.
That would be a problem, but this really doesn’t seem like it is something likely to happen. Unless someone could take advantage of another security vulnerability that allows the deletion of arbitrary files, there really isn’t any reason that file should be change, right? Well SiteLock thinks so:
But the reliance on the presence of the readme file was dangerous as it’s not uncommon for a site owner or web developer to remove unnecessary text files, like readmes, as part of a site cleanup.
We have never heard of doing something like that, so we are not sure what the context is supposed be. But if they are talking a hack cleanup (they are a security company after all) that definitely wouldn’t be something you should be doing.
With WordPress plugins you can clean them in several ways: upgrading them (all the old files in the plugin’s directory in /wp-content/plugins/ get deleted during that), deleting the plugin’s files and replacing them with a clean copy, or comparing the plugin’s files with a clean copy and removing any malicious code (which gives you the advantage of seeing if the hacker made any changes). Deleting the readme.txt files, without replacing them, wouldn’t happen with any of those.
When you start messing with non-malicious files that can lead to bad things happening, like breaking the website, something SiteLock has managed to do in the past.