Advisory: Weaknesses in Pingback Design Advisory ID: 4tphi-sa-20070111-pingback Release Date: 01-24-2007 Author: Blake Matheny (email@example.com)
Software: Multiple Impact: Remote DoS
From Wikipedia, "A Pingback is one of three types of Linkbacks,
methods for Web authors to request notification when somebody links to one of their documents."
The design of pingback 1.0 failed to include a basic service or URI
authentication model, making it susceptible to abuse. Additionally, the recommended server implementation is vulnerable to DoS. The issues described in this vulnerability affects several vendors, who have been contacted.
The pingback specification details a method for allowing site A to
communicate to site B that it has been linked to. The specification and most implementations use an XML-RPC interface for communication. The described interface contains a single method that accepts two parameters. The method prototype is as follows:
string|Fault pingback.ping(string sourceURI, string targetURI)
For this method the sourceURI contains the URI to the post on site A, and the targetURI contains the URI to the post on site B. The specification recommends that server B fetch sourceURI and verify that it indeed links to the targetURI, in order to prevent pingback spam.
The pingback specification does not detail how to handle
authentication as it relates to the requestor. A malicious user can submit any sourceURI to a pingback enabled site, causing sourceURI to be retrieved. For instance the following POST submitted to b.example.com would cause it to fetch data from a.example.com. <methodCall> <methodName>pingback.ping</methodName> <params> <param> <value><string>http://a.example.com</string></value> </param> <param> <value><string>http://b.example.com/#p</string></value> </param> </params> </methodCall> The implication is that any user can anonymously cause a server to fetch an arbitrary URL. Not only is no authentication required to use the pingback service, but no authentication is required for the sourceURI. This particular issue has been verified with multiple implementations.
Problems also exist with the specification recommended server
implementation, and how that has been applied practically. The specification doesn't recommend that the server check the Content-Type, or limit the amount data retrieved as part of the verification process. A malicious user may therefore request that a server retrieve large, non-text files that consume resources such as bandwidth and memory for processing. This could potentially lead to a DoS where the attacker has to use very few resources. This particular issue has been verified with multiple implementations. In testing, a single PC on a T1 connection was able to cripple two dual Xeon apache servers on separate 100Mb connection. This was accomplished by sending out multiple requests to server A specifying a sourceURI on server B that was a 1GB media file.
The authors added a recommendation to limit the size and rate of data
transfer of the source URI if the server fetches content. The original recommendations are below.
Requiring authentication to the pingback service is not in the spirit
of the specification so it has not been suggested. Adding a step to the server that confirms that the host of the sourceURI is the same as the host submitting the service request would disable arbitrary URLs being submitted. This might however be problematic for web farms where the load balancer does not keep state after the handoff. It is also recommended that if the client does not return a text/* Content-Type, the response is not parsed. Although this is mentioned in the example, this is not part of the recommendations and has not been implemented by several vendors.
01-24-2007 - Released 01-16-2007 - Received reply from firstname.lastname@example.org. Errata added to the 1.0 specification. 01-14-2007 - Notified email@example.com,firstname.lastname@example.org
This advisory is being provided to you under the RFPolicy documented at http://www.wiretrip.net/rfp/policy.html. You are encouraged to read this policy; however, in the interim, you have approximately 5 days to respond to this initial email.
-- Blake Matheny email@example.com http://mobocracy.net