This post was originally published here by emily gladstone cole.
On Thursday January 26th, 2017 the WordPress support team released WordPress 4.7.2. On Wednesday February 1st, 2017 they disclosed an additional vulnerability within the REST API of WordPress that had been fixed with the 4.7.2 release. The vulnerability we are concerned with is a Privilege Escalation and Content Injection vulnerability in the REST API that allows an unauthenticated user to create, modify, or delete posts made via WordPress. There is currently no CVE assigned to this vulnerability.
Description
This vulnerability was reported by Marc-Alexandre Montpas of Sucuri. It applies to all WordPress installations running either WordPress 4.7.0 or 4.7.1, and unless mitigated, could lead to Privilege Escalation or Content Injection by an unauthenticated user. WordPress is one of the most popular software packages used in creating blogs and websites, and features an Application Program Interface (API) based on the RESTful standard allowing interaction from a client-side web application. A vulnerability in this API caused user-submitted strings to be treated as user IDs, allowing an unauthenticated user to pretend to be authenticated and update the blog or website. This vulnerability has resulted in the defacement of up to 1.5 million websites, according to some reports.
A patch release is now available, so all users are urged to update WordPress as soon as possible.
CloudPassage customers can use Halo to protect themselves by following these steps:
- Update the WordPress software by installing version 4.7.2 from https://wordpress.org/download/ as soon as possible.
- Use CSM to confirm that the latest version is in place.
- Use FIM to monitor for unauthorized changes in the WordPress directory tree.
- Use LIDS to search for evidence of activity on the website that may be suspicious.
CloudPassage’s advice: Upgrade to WordPress 4.7.2 as soon as possible.
Leveraging Halo
| Firewall | CSM | FIM | LIDS | SVA | SAM |
| No | Yes | Yes | Yes | No | No |
CSM
The best way to address this vulnerability is to update WordPress. A stub CSM policy which will check for the presence of the updated version is available here: https://github.com/cloudpassage-community/content-2017-02-10-wp472
Below is a screen shot of a check that will look for the presence of this mitigation.
FIM
FIM scans are useful to ensure that no unwanted changes have been made to a directory tree. They will be very useful in this case to monitor for unwanted alterations to a WordPress install tree.
In order to take advantage of this, create a FIM policy for WordPress based on the appropriate template and ensure that it refers to the correct directory path for the WordPress install. As this directory path is set by the server administrator (and is typically under the web server’s web root), it may vary from site to site. The code that is vulnerable to this Privilege Escalation/Content Injection exploit is in the wp-includes directory, within the rest-api/endpoints sub-directory.
Confirm that the WordPress software is updated and configured appropriately, and create a baseline against the appropriate server(s).
After the baseline is complete, monitor for any issues raised if the server changes from the baseline unexpectedly.
LIDS
Using LIDS to monitor activity on your WordPress site can be useful in finding suspicious traffic. Since the log entries for malicious traffic will look a lot like those for benign traffic, caution is advised in implementing any of the suggestions below.
We provide some strings to add to your existing LIDS policies that will require you to supply the location of the relevant web server or WordPress log files. Many WordPress logs are only accessible through the admin console without the use of a special configuration or plugin, however.
Traffic attempting to use the the REST API to exploit this vulnerability will include the path wp-includes/rest-api/endpoints (the beginning of this path will depend on the location of the WordPress install within the web root of the server), so this is one likely pattern to look for in your web server logs. It may also capture legitimate traffic, however.
One of the actors who has been responsible for many of the WordPress site defacements creates a userID of w4l3XzY3. The presence of that string in your WordPress logs may be evidence of a problem with the site.
Though IP Addresses can change often, the following have been listed as associated with many defacements, and the presence of these IP Addresses in your web server or WordPress logs may be evidence of a problem with the site:
● 176.9.36.102
● 185.116.213.71
● 134.213.54.163
● 37.237.192.22
● 144.217.81.160
● 2a00:1a48:7808:104:9b57:dda6:eb3c:61e1
Photo:Security Intelligence
