TLP:WHITE – Details about the WordPress File Manager plugin exploit

by | Sep 25, 2020 | Incident Reports

On September 2nd 2020, a WordPress site under our umbrella has been compromised. Here is a summary of what happened. We hope it will help others to protect themselves.

In late September, a vulnerability was discovered in the File Manager plugin of WordPress, CVE-2020-25213. This vulnerability allowed unrestricted[1] and unauthenticated upload of files to vulnerable servers. By injecting PHP files in the right places, attackers are then able to trigger the injected code by making the right requests to the servers.

This vulnerability was first published on August 25th and August 26th, without any patch available until the official announcement on September 1st. Interestingly, it seems that while it was technically a zero day vulnerability, with an exploit published before the patch, the analysis of the compromised system only shows the first traces of scans on September 1st and the first exploitation on September 2nd. Timely patching could have prevented the hack!

We’ve been able to find different payloads injected into the system. We do not know if they all from the same malicious actor or not:

  • The first files injected only had the responsibility to find another place they could inject themselves and send back the resulting URL of the injected code. The final (obfuscated) injection basically support a version and eval function, acting as a remote shell.
  • The last injected set of files was modifying the base index file, injecting itself into all pages. This sample is more complex as it can support a set of plugin, encoded and saved in the same file, which can be added or removed after deployment. The installed plugin was checking every incoming requests against a remote server and was injecting code when instructed to.

After the attack, users of this WordPress could receive malicious redirects. From the observed behavior, these redirects followed specific rules, making the detection of the attack much more complicated:

  • It only triggered once per IP
  • The request needed to look like a browser request (based on its headers)
  • The request had to have a referrer pointing to a search engine, it could not be a direct access

After the attack was confirmed, the website was recovered from a previous backup, passwords and secrets were renewed and the list of installed plugins was reviewed, to remove non necessary ones.

To protect against such attacks, we recommend two mutually exclusive solutions, each with their sets of issues:

  • Make the site read only for the php user, preventing any malicious file injection.
    • Prevents exploit of zero days based on file injection
    • Does not prevent the exploit of vulnerability using different angles of attack
    • Regular updates have to be manual
  • Enable auto-update, including for plugins plugin.
    • Bad updates might break the site.
    • Plugins could be taken over by malicious actors and push malicious updates.

[1] The targetted folder had to be writable by the user running the site.