Category: URI Analysis


Earlier this week, we explored a new way of phishing via URI.

You can display a full, let me state that again, a full working website using data URIs. In this article, I will show you the steps to change a URL to a URI and how (if) exploit kits can take advantage of this feature.

Lets take this simple page that I made. It utilizes an external file, specifically a 3rd party javascript, to determine the value of the loop. Now, we want our URI to not contain any external URLs, so we need to get the source of the javascript file first.

Remember our syntax for data URI:

data:text/<javascript/html>;base64,<data> where <data> is our base64 encoded string.

In this case, we have a javascript file, so naturally we will use data:text/javascript. Lets use our Base64 Converter to obfuscate the content of code.js.

var ran = Math.floor(Math.random()*(10-1+1))+1; becomes

dmFyIHJhbiA9IE1hdGguZmxvb3IoTWF0aC5yYW5kb20oKSooMTAtMSsxKSkrMTsNCg==

We then enclose the data as follows:

<script src=”data:text/javascript;base64,ourcode“></script>

Which is simplified to this:

PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC9qYXZhc2NyaXB0O2Jhc2U2NCxkbUZ5SUhKaGJpQTlJRTFoZE
dndVpteHZiM0lvVFdGMGFDNXlZVzVrYjIwb0tTb29NVEF0TVNzeEtTa3JNVHNOQ2c9PSI+PC9zY3JpcHQ+

Now all we have to do is put <script> tags around our main javascript and base64 obfuscate it! You should get something like this:

PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPg0KZnVuY3Rpb24geChzKSB7DQogICAgZG9jdW1lbnQuYm9keS5p
bm5lckhUTUwgPSBkb2N1bWVudC5ib2R5LmlubmVySFRNTCArICI8YnIgLz4iICsgcw0KfQ0KeCgiVGhpcyBpcyBhIHNpbX
BsZSBwYWdlIikNCngoIldlIHdpbGwgY2hhbmdlIHRoaXMgdG8gVVJJIikNCngoIkJ1dCBpdCB1c2VzIGFuIGV4dGVybmFsIG
xpbmsiKQ0KeCgiU28gd2UgbmVlZCB0byBjb252ZXJ0IHRoYXQgZmlyc3QiKQ0KZm9yKHZhciBsb29wID0gMDsgbG9vcCA8
IChyYW4rMSk7IGxvb3ArKykgew0KICAgIHgobG9vcCkNCn0NCjwvc2NyaXB0Pg==

Testing it out, I get this error:

TypeError: document.body is null
Due to the nature of the DOM, we need to first write our document before we can add code to it in javascript. We will use a simple HTML5 declaration.
<html><body></body> (no </html>) becomes
PGh0bWw+PGJvZHk+PC9ib2R5Pg==

We insert this before the other two snippets.

We then get this:

data:text/html;base64,PGh0bWw+PGJvZHk+PC9ib2R5Pg==PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC
9qYXZhc2NyaXB0O2Jhc2U2NCxkbUZ5SUhKaGJpQTlJRTFoZEdndVpteHZiM0lvVFdGMGFDNXlZVzV
rYjIwb0tTb29NVEF0TVNzeEtTa3JNVHNOQ2c9PSI+PC9zY3JpcHQ+PHNjcmlwdCB0eXBlPSJ0ZXh0L
2phdmFzY3JpcHQiPg0KZnVuY3Rpb24geChzKSB7DQogICAgZG9jdW1lbnQuYm9keS5pbm5lckhUTUw
gPSBkb2N1bWVudC5ib2R5LmlubmVySFRNTCArICI8YnIgLz4iICsgcw0KfQ0KeCgiVGhpcyBpcyBhIHN
pbXBsZSBwYWdlIikNCngoIldlIHdpbGwgY2hhbmdlIHRoaXMgdG8gVVJJIikNCngoIkJ1dCBpdCB1c2Vz
IGFuIGV4dGVybmFsIGxpbmsiKQ0KeCgiU28gd2UgbmVlZCB0byBjb252ZXJ0IHRoYXQgZmlyc3QiKQ
0KZm9yKHZhciBsb29wID0gMDsgbG9vcCA8IChyYW4rMSk7IGxvb3ArKykgew0KICAgIHgobG9vcCk
NCn0NCjwvc2NyaXB0Pg==

So, now we are focusing on shrinking our code. We can use the dreaded document.write instead of document.body.innerHTML, thus <body> tags are not required. Our shrunk code looks like this. Our obfuscated URI looks like this:

data:text/html;base64,PHNjcmlwdCBzcmM9ImRhdGE6dGV4dC9qYXZhc2NyaXB0O2Jhc2U2NCxkb
UZ5SUhKaGJpQTlJRTFoZEdndVpteHZiM0lvVFdGMGFDNXlZVzVrYjIwb0tTb29NVEF0TVNzeEtTa3
JNVHNOQ2c9PSI+PC9zY3JpcHQ+DQpzb21ldGV4dCYjODIwMzsmIzgyMDM7JiM4MjAzOw0KPHNjc
mlwdD4NCmZ1bmN0aW9uIHgocykgew0KICAgIGRvY3VtZW50LndyaXRlbG4ocykNCn0NCngoIlRo
aXMgaXMgYSBzaW1wbGUgcGFnZSIpDQp4KCJXZSB3aWxsIGNoYW5nZSB0aGlzIHRvIFVSSSIpDQp4
KCJCdXQgaXQgdXNlcyBhbiBleHRlcm5hbCBsaW5rIikNCngoIlNvIHdlIG5lZWQgdG8gY29udmVydCB
0aGF0IGZpcnN0IikNCmZvcih2YXIgbG9vcCA9IDA7IGxvb3AgPCAocmFuKzEpOyBsb29wKyspIHsN
CiAgICB4KGxvb3ApDQp9DQo8L3NjcmlwdD4=

Give it a try!

With URIs, if the string is very long, looks suspicious, or is rendered improperly (URIs are handled differently than URLs, I have first-hand experience :P), the browser will not load the page properly, or won’t even load the page at all! This makes converting URLs to URIs by hand harder.

So, in simple words, no. I do not think that authors/contributors of exploit kits would spend explicit time converting their already-working kits to URI. However, I feel that new exploit kits might take advantage of this feature so the exploit kit never meets the internet, thus cannot be analyzed in-depth.

Stay safe,
~!Donovan

A smart man named Henning Klevjer recently discovered a new phishing technique. In which all sites can be hidden in a single link.

Before, phishing was contained on servers on the internet. Utilizing URIs, you do not need a server to make a phish site.

In this article, we will examine the method in which URI is received, implantation, sharing, and how antiviruses must react. This article is divided into 8 parts.

 

Part 1: Understanding The URI

Using the data URI scheme it is possible to present media content in a web browser without hosting the actual data on the internet. Data URIs follow this scheme: data:[<mediatype>][;base64],<data> [1]

So the general syntax would be data:[<metatype>][;base64],<data>

The mediatype is a MIME type string, such as “image/jpeg” for a JPEG image file. If omitted, defaults to text/plain;charset=US-ASCII

If the data is textual, you can simply embed the text (using the appropriate entities or escapes based on the enclosing document’s type). Otherwise, you can specify base64 to embed base64-encoded binary data. [3]

Ok, we want text/html or text/javascript. And the other part is base64. So our code so far looks like this:

data:text/html;base64,<data> where <data> is our base64 encoded string.

 

Part 2: Generating The Phish Page

This is when you would, like any other regular phish page, attempt to replicate as much of the website itself as possible without having to use a high amount of scripts. This can be done via using external stylesheets. For this test, we will use a basic javascript function.

<html><head><script>alert(‘test’)</script></head></html>

 

Part 3: Obfuscation Using Base64

Next, we will use a tool called Base64 Online [4] to obfuscate our code.

PGh0bWw+PGhlYWQ+PHNjcmlwdD5hbGVydCgndGVzdCcpPC9zY3JpcHQ+PC9oZWFkPjwvaHRtbD4=

 

Part 4: Implantation In The Browser

So now, the full code is:

data:text/html;base64,PGh0bWw+PGhlYWQ+PHNjcmlwdD5hbGVydCgndGVzdCcpPC9zY3JpcHQ+PC9oZWFkPjwvaHRtbD4=

Enter that in your browser and give it a try! You should be greeted with an alert box.

 

Part 5: Implantation On A Website

So now what we do is take our code and put it in a hidden iframe:

<iframe src=”data:text/html;base64,PGh0bWw+PGhlYWQ+PHNjcmlwdD5hbGVydCgndGVzdCcpPC9zY3JpcHQ+PC9oZWFkPjwvaHRtbD4=” width=0 height=0>​​​​​​​​​​​​

Check out the jsFiddle [5].

 

Part 6: Sharing The Payload

Generally, it’s easier to make your own link than to infect other sites, so how do we share a long url without making it look suspicious? Why TinyURL [6] of course!

TinyURL handles our code! [6]

Note that Google Chrome has a built-in feature that detects redirects such as this and prevents connection. However, if the user attempts to reload the page, the error doesn’t occur a second time. Note that this safety feature does not work with previous examples.

 

Part 7: How Antiviruses Must React (Conclusion)

Due to the nature that these links are not really ‘sites’, they don’t have IPs, which means you can’t blacklist them. This means that website heuristics is a must, and any suspicious elements found must be reported accordingly. Lets develop a ‘rough-draft’ of how we want to protect our users. I will use a mix of Lua and JavaScript as well as english.

If document.contains “data” then

If typeof data is script then

— Deobfuscate Base64 & Signature Check, if fails:

— Heuristics, if fails:

— Sandbox

end

end

 

Part 8: Resources

http://klevjers.com/papers/phishing.pdf [1]

http://www.idg.no/computerworld/article251936.ece [2]

https://developer.mozilla.org/en-US/docs/data_URIs [3]

http://www.motobit.com/util/base64-decoder-encoder.asp [4]

http://jsfiddle.net/ [5]

http://tinyurl.com/ [6]

 

Stay Safe,

~!Donovan