Security Risk: High

Exploitation Level: Easy

DREAD Score: 9.8

Vulnerability: File upload

Patched Version: 6.9

Yesterday, the WordPress plugin File Manager was updated, fixing a critical vulnerability allowing any website visitor to gain complete access to the website.

Users of our WAF were never vulnerable to this exploit. The Sucuri firewall blocks malicious payloads by default using our generic exploitation rules.

Technical Details

The vulnerability originated from the remains of a development environment on version 6.4 nearly 4 months ago, where a file was renamed to test certain features. The renamed file was accidentally added to the project instead of being kept as a local change. The original file, provided by a third-party dependency elFinder, originally had the .php.dist extension and was to be used as a code example or reference during development, but was changed to .php by the File Manager team during development.

This change allowed any unauthenticated user to directly access this file and execute arbitrary commands to the library, including uploading and modifying files, ultimately leaving the website vulnerable to a complete takeover.

The solution applied by the plugin team was to delete this file, which was never used by the plugin itself, and all of the other unused files ending with .php-dist to prevent it from reoccurring.

One week before the plugin was updated and the vulnerability fixed, a proof of concept was publicly released on Github, indicating that this was publicly known before the plugin team was made aware of it.

elFinder

The elFinder package is an open source file manager for the web. According to its packagist page, it has been installed nearly 2.3m times — making it a very popular package.

Due to its nature, being a file manager, anyone able to access its features will have elevated privileges on the website by modifying, uploading and deleting files, but it also aims to be as easy as possible to set up and use. To get started, all you need to do is rename a single file — as per their installation instructions:

This makes it easy to locally test and develop features for the product without having to mess around with the surrounding environment such as WordPress, but makes a catastrophic vulnerability if this file is left as-is on the deployment. As a minimal file to get the project running, it lacks permission checks and overall safety mechanisms that would normally surround its use.

This is what happened in the case of File Manager. The file was renamed and left as-is on the 6.4 release, causing this massive vulnerability.

Exploit

This exploit quickly gained popularity due to its very high impact and low requirements, where we have currently seen hundreds of thousands of requests from malicious actors attempting to exploit it.

The first attack we noticed was on August 31st, one day before the plugin was updated, with an average of 1.5k attacks per hour. On September 1st, we had an average of 2.5k attacks per hour, and on September 2nd we had peaks of over 10k attacks per hour.

Timeline

• May 5, 2020: File manager releases version 6.4, introducing the vulnerability.
• Aug 25, 2020: A public exploit is released on Github against File Manager.
• Aug 31, 2020: We are starting to see attacks against this plugin.
• Sept 1, 2020: The plugin release version 6.9, fixing the vulnerability.

Conclusion

The barrier between unsafe code during development and the deployed solutions is a thin line for security vulnerabilities. One small file slipping through the cracks can cause a critical vulnerability for your users.

While these mishap can happen, a robust review process and a quick response time for security issues are your best response.

Thankfully, you can be protected from all known vulnerabilities and even more by using our WAF. 29SHARES