[caption id="attachment_18129" align="aligncenter" width="423"]Incapsula's diagram shows how the WP DDOS-enabling 'feature' works Incapsula's diagram shows how the WP DDOS-enabling 'feature' works[/caption] Hackers exploiting bloggers' wish to know when someone links to their content were able to trick more than 160,000 WordPress servers into participating in a DDoS attack on another WordPress server earlier this week. The March 10 WordPress attack against a popular but unnamed WordPress site exploited a problem with the XML-based remote procedure call (XML-RPC) function in WordPress, which allows automatic pingback notices to a WordPress site whenever another WordPress site posts a document with links to the first site. WordPress ships with XML-RPC enabled by default, making any site that hasn't shut the feature off vulnerable to unintentional recruitment into a DDOS-generating botnet without the effort of building one out of malware-infected PCs first, according to Daniel Cid, CTO of security firm Sucuri, Inc. who dissected the WordPress attacks in a blog entry March 10. Attackers in this case sent XML-RPC requests as part of normal HTTP traffic to legitimate WordPress sites, telling them to send pingback calls to nonexistent URLs on the site that was targeted for attack. Because the URLs didn't actually exist, the pingpacks bypassed the caching mechanism of the targeted site and forced it to try to serve full pages, rather than previously cached images, in response to every request. The tactic uses a fraction of the bandwidth of a typical DDOS attack and spreads the source of the attack across thousands of legitimate IP addresses, making them difficult to filter out; it also requires very little setup work. "Can you see how powerful it can be?" Cid wrote in the March 10 blog. "One attacker can use thousands of popular and clean WordPress sites to perform their DDOS attack, while being hidden in the shadows, and that all happens with a simple ping back request to the XML-RPC file." The flaw was noted as a bug as long ago as 2007, but hasn't been fixed because many developers and WordPress users consider simple and automatic pingbacks to be a useful feature. "This tradeoff in pingback’s design has been there for a decade now," WordPress project lead Matt Mullenweg told PCWorld via email. "It's seldom used outside of experimentation because it gets shut down by anti-spam providers like Akismet or web hosts when used at any scale." It is difficult to spot when a WordPress server has been enlisted, but looking through server logs for POST requests to the XML-RPC file with entries similar to the two below should reveal any subterfuge, Cid wrote in his blog entry: - - [09/Mar/2014:20:11:34 -0400] "POST /xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "POSTREQUEST:x0Ax0Apingback.pingx0Ax0Ax0Ax0Ahttp://fastbet99.com/?1698491=8940641x0Ax0Ax0Ax0A x0A yoursite.comx0A x0A x0Ax0Ax0A" – - [09/Mar/2014:23:21:01 -0400] "POST /xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "POSTREQUEST:x0Ax0Apingback.pingx0Ax0A x0A x0A http://www.guttercleanerlondon.co.uk/?7964015=3863899x0A x0A x0A x0A x0A yoursite.comx0A x0A x0Ax0Ax0A"
Disabling XML-RPC will block the exploit, but also stop the interactive content-notices on which many bloggers rely. Instead, Cid suggested, creating a plugin that adds a filter with the following code should do it:
add_filter( ‘xmlrpc_methods’, function( $methods ) { unset( $methods['pingback.ping'] ); return $methods; } );
(Note that Slashdot hasn't tested either the plugin code or the identifier above it.) "This is a well known issue within WordPress and the core team is aware of it," Cid wrote. "It’s not something that will be patched though. In many cases this same issue is categorized as a feature, one that many plugins use, so in there lies the dilemma." A blog posted in May 2013 by security firm Incapsula goes into more detail about the mechanism and potential fixes. A 2012 technical report from NFocus includes some of the text of the packets involved in pingback DDOS attacks. A WordPress plugin will shut off XML-RPC in Windows, for admins who don't want to do it by hand. And, if the WordPress server under attack is yours and you can't log in, this 2012 WordPress user post offers an alternative way to get into a site whose login page is blocked. There seems to be no likelihood the issue will be resolved by WordPress, which still considers it a feature. Workarounds like these seem to be the best alternative.   Image: Incapsula