SecurityvulnsSECURITYVULNS:DOC:15856Weaknesses in Pingback Design
Advisory: Weaknesses in Pingback Design
Advisory ID: 4tphi-sa-20070111-pingback
Release Date: 01-24-2007
Author: Blake Matheny ([email protected])
Software: Multiple
Impact: Remote DoS
Overview:
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.
Description:
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.
Details:
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.
Recommendations:
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.
Disclosure Timeline:
01-24-2007 - Released
01-16-2007 - Received reply from [email protected]. Errata added to
the 1.0 specification.
01-14-2007 - Notified [email protected],[email protected]
LEGAL NOTICES
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 protected]
http://mobocracy.net