Remote Code Execution Attempts via REST API Vulnerability

This article was co-authored by Security Researcher Wyatt Morgan from SiteLock Research.

In the continuing saga of the WordPress REST API vulnerability in WordPress 4.7 and 4.7.1, SiteLock has identified that at least one hacker has launched a campaign specifically attempting remote code execution (RCE) on WordPress websites. The attacks aim to take advantage of WordPress websites using plugins that enable PHP to run inside of posts. If successful, the attack injects a line of code that ultimately downloads a series of malicious files from a Pastebin repository. These malicious files are used to install backdoors and automatically steal information from websites. When unsuccessful at remote code execution, the attack overwrites existing posts and leaves behind PHP shortcode.

We’ve established that in order for the RCE portion of this attack to be successful, the following criteria must be met.

1. The website is running WordPress 4.7 or 4.7.1.
2. The website has the REST API enabled (enabled by default).
3. The website is using a WordPress plugin that allows for PHP to be executed in posts.
4. The website is not using a Web Application Firewall (WAF) that protects against exploitation of the REST API (such as SiteLock TrueShield).

We identified the hacker’s activity after several unsuccessful RCE attempts against some of our customers. The attacks appear to be blindly targeting WordPress 4.7 and 4.7.1 websites, regardless of whether or not they use a plugin that allows PHP in posts. Even while remote code execution is not successful, injection of the code that failed to execute is evident in the posts that it overwrites.

In reviewing the files within the Pastebin location above, we found that the script calls three additional files and sends stolen information from the compromise to the hacker. We’ve concluded that the individual launching this particular campaign is most likely not the original author of the exploit, but rather a third party that has acquired and rebranded the exploit for their own purposes. This inference was made based on the format of the code and the many variations of internal and external brag tagging. Based on this data, we have determined that exploits against the REST API are likely becoming more widely available in various hack forums and shared among script kiddies and hackers alike.

Among the additional files are a long obfuscated script and a classic FilesMan-based backdoor.

The steps to avoid being impacted by this attack are simple — update to the latest version (WordPress 4.7.2) immediately.

If you’ve fallen victim to this remote code execution campaign, your first steps should be to work with your hosting provider to assist with limiting the impact of the compromise and locate backups of your website from before the compromise. It is imperative that you scan your website files for malware to identify the extent of the damage. SiteLock offers malware scanning services, as well as automatic removal. Once the malware threat has been addressed, your next course of action should be to fix any impacted posts by following the steps below.

1. Perform a file and database backup of the impacted website and save it to a secure location. This will ensure your data is safe if any critical failures occur in the following steps.
2. Update WordPress to the latest version, version 4.7.2 if you haven’t already.
3. Login to /wp-admin/ and verify which posts have been impacted by the defacement by looking in the title and body of the post for content that you did not put there. From the “edit post” menu, for each impacted post, check the revision history of the post to see if the original content is intact in a previous revision. If a previous revision is available, restore the post to that revision. Be sure to also check if the permalink for the post has been modified.

In many cases, following the above steps will remove the defacement and no further action is required. If you were not able to recover all of your post content, please continue with the following steps.

4. Locate your most recent database backup from before the attack and restore it to the production database.
5. Login to /wp-admin/ to check if any database clean-up is required to synchronize to the current WordPress version on the production site.
6. If WordPress indicates database changes are needed, allow it to run through the changes.

Once again, we want to reiterate that some web application firewalls (WAF) are equipped to defend against these types of attacks, including SiteLock TrueShield™. We strongly recommend considering a cloud-based web application firewall to prevent attacks like these in the future. As always, feel free to reach out to us with any questions. We’ve got your back!