It’s always annoying when someone figures out a way to exploit intentional behavior, especially when it’s a key part of the design.

Sucuri reports on a denial-of-service attack that used thousands of legit WordPress sites to distribute the attack by sending fake pingbacks “from” the target site to all of the reflectors. Those blogs would all contact the targeted site to confirm the pingback and retrieve a title and summary…all at once, overwhelming it and taking it offline.

The quick-and-dirty solution is to remove XML-RPC functionality, but that also breaks certain plugins (like Jetpack) and the ability to connect to your blog using the WordPress mobile apps.

A little background on why Pingbacks work this way:

Waaaay back in the early days of blogging, most bloggers would interact by way of comments. If you wrote a blog post, and I was inspired to write a response, I would then go over to your site and post a comment letting you know about my own post. Two systems were proposed in 2002 to automate this process: pingbacks and trackbacks.

• Trackbacks sent a complete summary to the remote blog, including the title of your post, the link, and an excerpt (which you could manually craft, or let your software handle).
• Pingbacks sent a notice — a “ping” — to the remote site with the URL of your post, and then the remote site would retrieve it and extract the title and a summary.

This was also around the time that blog comment spam and spammy blogs were getting to be a big problem. What would happen is a spamming site would send out trackbacks to as many sites as possible claiming that they’d responded to some post, thereby getting backlinks on a zillion blogs and increasing their page rank. Pingbacks had an advantage: Because you were calling back already, your server could check to see whether the other site really had linked to you. It took a long time, but eventually this escalated into spammy blogs creating a temporary post with real links to the pages they pinged, then replacing it with a spam page after a short amount of time.

The problem now is: How do you block abuse of an as-designed behavior? That’s happened before: Back in the early days of the internet, it was considered polite to run your mail server as an open relay and rude to lock it down, but after spammers started massively abusing them, an open relay became a sign of a sysadmin who didn’t know what he was doing.

The comments on the Sucuri article suggest that Akismet, as a collaborative comment-spam filter, might be able to mitigate this type of attack. Wordfence’s collaborative security filter seems like another system well-positioned to detect it. But if that approach fails, pingbacks might just go the way of open relays.

Update March 18: Akismet has released a new version of the anti-spam plugin that mitigates this problem in two ways:

1. Spam checks on pingbacks are now done before the verification request is sent, so that once an attack is identified, Akismet will prevent blogs from participating.
2. An X-Pingback-Forwarded-For header is added to the verification request identifying where the pingback actually came from, making WordPress+Akismet a less attractive choice as a reflector by removing the anonymity.

Item #2, IMO, belongs in WordPress itself, not in a plugin, but I imagine this was a way to roll out the feature more quickly, at least to those sites using Akismet.

Update April 8: The X-Pingback-Forwarded-For header has been added to WordPress 3.8.2 and the upcoming 3.9.