Over the weekend Incapsula mitigated a unique DDoS attack against a large gaming website, in which WordPress played a key role, yet again.
Typically, such application layer DDoS attacks are carried out by host botnets, but this time team Incapsula were surprised to see that the attack originated from approximately 2,500 WordPress sites, including some very large sites like Trendmicro.com, Gizmodo.it and Zendesk.com (see full list).
These sites were not compromised, taken over, or rooted. Instead, the attackers took advantage of an existing WordPress vulnerability and abused the site, herding it into a voluntary botnet. WordPress has a built in functionality called Pingback, which allows anyone to initiate a request from WordPress to an arbitrary site. The functionality should be used to generate cross references between blogs, but it can just as easily be used for a single machine to originate millions of requests from multiple locations.
It turns out that most WordPress sites are susceptible to this abuse. Since this feature is enabled by default, and there is no protection mechanism within WordPress against it.
This gives any attacker a virtually limitless set of IP addresses to Distribute a Denial of Service attack across a network of over 100 million WordPress sites, without having to compromise them.
Some of the largest news and media sites are hosted on WordPress these days and each of these sites carry lots of DDoS firepower that can be exploited in this way. Some of the more noticeable sites that were found to be exploitable included Venturebeat.com, TechCrunch.com, TheNextWeb.com, WordPress.org itself and apparently Kobe now has another Achilles’ heel at kobebryant.com.
How Easy is it to Exploit Your WordPress Site?
It doesn’t take any coding to take advantage of this vulnerability and induce these third party requests.Using a UNIX command line tool, it’s as easy as executing:
curl -d
'<?xml version="1.0" encoding="iso-8859-1"?><methodCall><methodName>
pingback.ping</methodName><params><param><value>
<string>http://attacked.site.com/link_to_post
</string></value></param><param><value><string>
</string></value></param></params></methodCall>'
This would cause example.com to send an HTTP request to the target. Run a few thousand of these in parallel, and you have the equivalent of a modest botnet, with a virtually unlimited pool of source IPs. Most websites cannot withstand even a few hundreds of requests per second – especially if these are requests that take up a lot of resources.
A Known Vulnerability that was (not) Fixed
The Pingback mechanism has been known to be a security risk for some time. In fact, just last December an exploit was posted on Github that allows users to perform port scanning using this mechanism. It was made public by Acunetix. At the time, Bogdan Calin from Acunetix also mentioned the possibility of launching Denial of Service attacks using Pingback, which was already a known issue.
The vulnerability (CVE-2013-0235) was fixed in WordPress 3.5.1, by applying some filtering on allowed URLs. This solved the issues of attempted port scanning and SSRF, but other than that left the functionality intact, without any additional mechanism to prevent abuse. The six year old bug #4137 – “Pingback Denial of Service possibility”, remains terminally open.
What has made this surface is the fact that, until recently, the whole xmlrpc mechanism was disabled by default. WordPress 3.5 was released with this feature enabled and exploitable, by default. Any website with Pingback functionality enabled is susceptible, and can be used by hackers to launch Denial of Service attacks.
Who is the Victim?
Most of these websites, especially the larger ones, felt very little impact from their participation in the attack. Beyond the attacked sites themselves, only the smallest websites might be penalized for increased bandwidth consumption, and only in extreme cases would a hoster feel a strain on their bandwidth or CPU.
If you leave a door open, someone will figure out how to exploit it, and the size of the internet amplifies it. Like misconfigured DNS resolvers allow attackers to amplify bandwidth attack, these websites allow attackers to amplify their IP distribution and add an extra layer between their targets and their true identity.
How to Mitigate the Vulnerability?
- All website using Incapsula are protected from such abuse.
- To do it yourself, log into your web hosting control panel (cPanel, H-Sphere, Plesk, etc) and delete or rename xmlrpc.php in the root directory of your WordPress installation.
[Via: Incapsula]
