12.8% of Sites Have Sensitive File Disclosure Vulnerabilities

As you probably know we launched Gravityscan this May. Gravityscan is a security scanner for any website that serves as a great complement to Wordfence. Yesterday we were analyzing aggregate scan result data from Gravityscan, and we noticed data that surprised us: 12.8% of sites we scan have at least one sensitive file visible to anyone on the internet.

That means that 1 in 8 of you likely have a self-inflicted security vulnerability on your site that needs attention. The good news is that this problem is easy to fix once you know about it.

What does this mean?

A sensitive file exposure vulnerability is a situation where a file that is supposed to be private is accessible to the outside world via your web server. Gravityscan checks for hundreds of files that our security analysts deem to be potentially sensitive. They fall into one of the following categories:

Configuration Files – these are files that tell WordPress (or other website software) how to function. Examples of configuration files are ‘wp-config.php’ and ‘php.ini’. Files of this type often contain information an attacker could use to compromise your site including database credentials. An attacker with database access can create an admin user for themselves and take over your site.

Utilities – Utilities are scripts that can be used for a wide variety of administrative and debugging tasks. They are often quite powerful, giving the user the ability to do things like query your database and make changes to files. Popular examples include phpMyAdmin and Adminer. We wrote about a popular one back in July called searchreplacedb2, that hackers were actively probing for and exploiting.

Log Files – Your operating system and other software on your web server records events in log files. These files are often helpful for site owners and administrators who are troubleshooting an issue. In many cases entries will include information that an attacker might find useful.

Test and Backup Files – Often test sites and backup files are left laying around on a web server. In many cases they include sensitive information an attacker might use to exploit your production website.

How to check your site

As you know, we make Wordfence, which is a firewall and security scanner designed specifically for WordPress. And our team also created Gravityscan to find vulnerabilities and malware in a large number of other web applications, including WordPress, Joomla, Drupal, Magento and others.

If you use Wordfence, you can simply run a Wordfence scan and it will find file disclosure vulnerabilities that are WordPress specific, like backup and leftover temporary copies of wp-config.php.

Alternatively, you can use Gravityscan to find file disclosure vulnerabilities in WordPress and other products like Drupal, Joomla, Magento and more.

In this case we could like to recommend that you run a Wordfence scan and a Gravityscan if you are a WordPress user. The reason we suggest this is because there are actually hundreds of file disclosure vulnerability checks that Gravityscan does. Some of these checks are for utility scripts like searchreplacedb2. These are not WordPress specific scripts, but they are occasionally used by WordPress site owners. By using Gravityscan, you check for these non-WordPress scripts too.

To scan with Wordfence, simply sign into your WordPress website and hit the Wordfence “Scan” button.

To check your site with Gravityscan, simply head over to Gravityscan.com and run a scan. Make sure you install the Accelerator for faster and more thorough scans.

The title for these findings will be ‘Private file visible’ and will be assigned a type of ‘vulnerability’ and the product will be ‘Content’. You will need to upgrade to Pro to see the vulnerability details (14 day free trial available). The description will show you the name and location of the file, something like ‘https://yoursite.com/phpMyAdmin-2.6.3-rc1’.

What to do if your site has this issue

The first thing you need to do is to decide whether you really need the file on your website. In many cases, old log or test files are no longer needed. If possible, delete them from your server to solve the issue.

In some cases the file may be necessary, needs to be public-facing, is in the right place and doesn’t contain sensitive data. In those cases simply mark the scan finding as a false positive in Gravityscan.

Finally, for configuration files, you need to make sure you have permissions set correctly. Here are resources for some of the most important WordPress files:

Conclusion

A high percentage of website owners inadvertently leave sensitive files exposed on their websites. To secure your website, it is important to avoid leaving test files, backups, log files and utilities lying around in public facing web directories. If you don’t need a file anymore, delete it. If you need it, store it somewhere that isn’t accessible to the world.

Make sure the permissions for the configuration files on your website are set up with security in mind. A huge percentage of the malicious requests the Wordfence firewall blocks are attempts to download configuration files, especially wp-config.php.

Finally, scan your site regularly with a full featured security scanner like Wordfence or Gravityscan. With free security monitoring available, there is no excuse not to.

Did you enjoy this post? Share it!

Comments

5 Comments
  • Thanks Dan. This is good to know. Will do a thorough check on my website

  • Good write and as always on your blog, it reminded me of some todos. Just last week looking at a client’s wp site I found some iffy items that needed quick fixing and the reason I knew they were iffy was after reading your excellent blog. Thanks
    Saku

  • So what do we do if some other file, like user.ini, is flagged (as it was on one site)? I have no idea whether other files present a risk or not.

  • I just ran a scan on a website I manage with a hosted shopping cart and received the warning "Root Certificate Scheduled to be Distrusted
    Description: Google has announced their plan to distrust certain Symantec certificates: https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html. This site's certificate will be affected."
    I read the blog and it indicated that the SSL/TLS Certificate issued by RapidSSL was to be affected. However, when I contacted the cart platform tech about it he replied, "this announcement you see in that link does not cover the recent negotiations and details of what has been worked out for everyone... that is from September and again is old news that recently things were worked out, so your ssl is not going ot be affected here."
    Does GravityScan need to update its information?

    • That is a valid result. The full details are in the link you included in your comment. This is still valid and in fact Chrome version 62 has started issuing warnings about this in the browser console.