Early Vulnerability Disclosure Thwarts WordPress Hackers

In late January, WordPress was made aware of a new vulnerability in its code. Taking a proactive stance, the content management system (CMS) vendor immediately shared it with major web application firewall (WAF) vendors—including Imperva—to ensure wide-scale patch availability. Within a week WordPress published a new security release that addressed the vulnerability and other security issues.
Soon afterward, web attacks attempting to exploit the vulnerability started flooding the internet. What is interesting about this scenario is that, contrary to previous events, such incidents only started showing up after Sucuri’s full disclosure.
In this post we examine how the threat was identified, its timeline, the disclosure process that made it unique, and how Imperva was able to help our customers get ahead of it.

REST API Threat Communicated

During a research project, Sucuri found a severe content injection vulnerability affecting the WordPress REST API. Left unpatched, it lets unauthenticated users modify any post or page content within any WordPress site using versions prior to 4.7.2.
The researchers quickly disclosed the problem to WordPress, allowing their team to immediately develop and distribute the requisite patch. Acting responsibly and through the timely and inclusive communication of all parties, thousands of potential attacks were prevented.
The timeline:

January 20 – Sucuri researchers contact WordPress to initially disclose the vulnerability.
January 23 – WordPress contacts WAF vendors, including Imperva who then updates its SecureSphere/Incapsula WAF and delivers new mitigation.
January 26 – WordPress releases security patch 4.7.2 to address the vulnerability.
February 1 – Sucuri publishes the vulnerability.
February 2 – Imperva SecureSphere/Incapsula WAF blocks new WordPress attacks based on January 23 mitigation development.

Vulnerability in the Wild

Since the WordPress vulnerability was published, Imperva registered thousands of attacks against our customers. They started slowly a day after publication, picked up for a few days and then slowed down again (Figure 1).

Figure 1 – WordPress attacks trend on Imperva customers
More than half of the assaults (53%) originated from automated tools (python-requests/2.X.X) (see Figure 2) and were aimed at two vulnerable URLs (Figure 3). This likely means that attackers either created an automated tool specifically for this vulnerability or incorporated the new payloads into an existing tool.

Figure 2 – Distribution of user agents

Figure 3 – Attacked URLs
Most of the incidents contained the message “Hacked by <hacker alias>,” as shown in Figure 4.

Figure 4 – One attack URL yields a hacker signature message
Interestingly, performing a Google dork query for the hacker’s signature message resulted in a search hit that included thousands of infected websites (Figure 5). A Google dork query, sometimes just referred to as a dork, is a string that uses advanced search operators to find information not readily available on a website. This revealed just how quickly and efficiently an attack of this type can spread if not immediately abated.

Figure 5 – A Google dork search uncovered almost 8,000 attack attempts
In aggregating the results, Imperva identified tens of thousands of infected sites (see Figure 6):

Figure 6 – Infected sites
Below are two examples of what could have been splattered on an unpatched WordPress site if an attack had succeeded:

Steps to Protect Customers

Once Imperva received notification from WordPress about the vulnerability, our security team immediately went to work creating new rules to defend against the vulnerability and update both our SecureSphere and Incapsula Web Application Firewalls (WAFs) to protect customers from the soon-to-come attacks.
Our security team took the following steps to create the new rules and update Imperva WAF solutions:

First, we coordinated with the Imperva Defense Center research team to develop rules for Incapsula and SecureSphere WAFs to address the vulnerability. This can take a couple of minutes if the exploit already exists or up to a full working day if the vulnerability is not fully disclosed.
The rules were then tested in our staging environment. After passing stage testing, the rules were moved to production to analyze the number of false positive/negatives the new rules produced.
We reviewed the results, tuned the rules, and repeated the procedure until we received 100% accuracy.

Conclusion

In an effort to publish a quick solution, we’ve previously seen that vendors often rush to provide a patch that can be incomplete and/or isn’t sufficiently tested. During the Shellshock and PHPMailer onslaughts, for example, a series of fixes had been issued before all vulnerable code instances were fully addressed.
Therefore, the timely disclosure of vulnerabilities by parties acting in good faith is critical in gaining the upper hand in the fight against cyberattacks. Here, the initial proactive steps by the Sucuri researchers and WordPress enabled enterprises using a WAF (such as those using Imperva SecureSphere and Incapsula) to keep all applications intact, while negating any need to urgently apply code changes to their production WordPress environments. While we assume such organizations will eventually deploy the patched version, each is now able to do so on their own timetable.