<= Archives =>
Pingback: XML-RPC free for all
2014/04/09 11:45:23 CEST

Sucuri reporting on an XML-RPC vulnerability in Wordpress. Said in simple terms, host A can send a pingback request to host B, claiming that host C has linked to a ressource hosted by B. Host B processes it and checks against C. When there are many As contacting many Bs, C becomes the victim of a DDoS attack.

This is a well known issue within WordPress and the core team is aware of it, 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.

This could be an opportunity for some Wordpress bashing, but is the platform at fault?

One could think that a simple mitigation would be to implement some access control in Wordpress on the pingback.ping XML-RPC method. Why should not C be the only legitimate source of pingback requests for the links in its own ressource? In fact, someone thought about it many years ago for Wordpress:

I suggest allowing pingbacks only if the connection was opened from the host mentioned in the source URL.

But there is a catch, in the comments:

This is a tricky one. I think this suggestion will break for URLs where the host name is an alias for another host as the URL's hostname might be completely different to the hostname of the system where the pingback request comes from.

Indeed. And when looking at the Pingback specification, no provision can be found to prevent forgery. Consequently, beyond fetching the source URI, the pingback server has no way of determining the legitimacy of a request from a pingback client. It must accept whatever comes in and perform after-the-fact checks, otherwise it would be taking the risk of turning down legitimate requests. The specification even mentions the possibility of a "pingback gateway server". Oh dear...

If an analogy can be made with SMTP, Pingback enables the good old open relay and bogus bounces. That specification is bogus. It is amazing that it got published and adopted so widely.

What are the solutions (order matters)?

  1. the specification should be amended or dropped altogether
  2. implementations should, outside of the specification, agree on some strong access control rules - with the risk of temporarily breaking compatibility in some cases.
  3. (user) pingback should be disabled
  4. (user) access to the pingback.ping method should be limited either through a hack in the implementation or with firewall rule - good luck doing it right in either case.

It is irresponsible to leave the situation as it is today.

I wonder how other blogging platforms are handling pingbacks.

Tags security