The Attack of the TINY URLs

Thu, 16 Nov 2006 02:41:30 GMT
by pdp

Just for fun I recently shrank a few URLs with the infamous tinyurl.com. Well, it worked. After submitting the URL in question, I had around 26 characters long string which was perfect for the job.

I have been playing with tinyurl before. Since the service started in 2002, on numerous accessions I have been shrinking URLs like crazy. This time was different though. After finishing up all the remaining work on AttackAPI's new interface, which I recommend to check out, I started thinking how tinyurl can be employed for evil.

So, I am there in the corner, holding a can of coke in one hand and scratching my head with the other. The room is dark. It is around 5:30pm ' 6:00pm Asian time. Then it suddenly came to me; REMOTE STORAGE.

Yes, I know. This thing has been known for ages. Back in 2002 people knew how to take advantage of tinyurl's service to store different files online by breaking the data into URL like segments that are indexed by a simple text file. This time was different though. I was thinking of something more agile, something that is alive. I was thinking in terms of JavaScript; moreover, malicious JavaScript.

A true self propagating worm is one that does not rely on external resources. Otherwise it will be too easy to kill. But how does a fat worm move its frame while keeping its agility? Since there is no global file system, AJAX worms may use services like tinyurl to hack around this limitation.

For the purpose of this exercise I employ a single technique that I discussed in detail over here. What this technique shows is that although parent documents cannot read the content of child iframes, child iframes can assign values to their parent's fragment identifier. In conjunction with tinyurl storage capabilities and a simple trick, this technique can be used to make AJAX worms live and bread on the web.

The receipt for making such a worm is quite straight forward. First of all we need some type of data that is about to be stored in tinyurl. We break that into segments and base64 encode each one of them. Shrink each segment with tinyurl while keeping an index of it. Than we base64 the index and shrink again. One thing that you must remember is that we are going use fragment identifiers (#hash) to access the data. So, the actual URL that will be shrunk must have capabilities of sending data back to the parent hash and be formated in something like the following:

http://<site>#<segment>

When the iframe is loaded, the the underlying logic will send the current hash data back to the parent hash. Of course there is another way of achieving the same result. And I repeat, tinuyrl is NOT vulnerable to XSS. And I repeat, tinyurl is NOT vulnerable to XSS and I repeat.

So, all the worm needs to remember is a 26 characters long string which eventually will expand to a quite big file. When the file is needed, the following algorithm is applied:

  1. Load the end URL in an iframe.
  2. Wait for a change in the hash.
  3. Read the fragment identifier and base64 decode it.
  4. Read the content of the data to find each segment.
  5. Load the segment.
  6. Repeat the process for each segment.

Apart from tinyurl there are several other services that offer similar functionalities. One of them is urlic.com which is top to bottom AJAX. I wonder what else we can do with it.

Archived Comments

malucmaluc
Actually, tinyurl does have a persistent XSS. So i think the more accurate sentence would be "This does NOT use an XSS on tinyurl." And you say it's to use for remote storage, but what sort of example storage would a javascript worm need? i mean, i can't think of a way to load any dynamic flash or file like this with IE. Like can you think of a sample attack using it? i'm just drawing a blank.. It's a good idea if it does have some use.. but there's alot of ways to use remote storage. For example, putting it on a myspace page.. then using your double proxy iframes method to extract it. You can put it on anyy site that allows user content - forums, comments, wordpress, etc. Assuming it can handle the bandwidth of a worm. -maluc
pdppdp
maluc, I tried to be ironic. tinyurl does have persistent XSS but I am not disclousing that, and it doesn't matter anyway.
And you say it's to use for remote storage, but what sort of example storage would a javascript worm need? i mean, i can't think of a way to load any dynamic flash or file like this with IE. Like can you think of a sample attack using it? i'm just drawing a blank..
This is easy. Get the base64 value and append the following in front of it: data:application/x-shockwave-flash;base64,. Put that into an iframe src attribute and you have the flash running. This doesn't work on IE though. More on that here and here.
... but there's a lot of ways to use remote storage ... you can put it on any site that allows user content
Yes I agree on that, but I want something that is more agile, as I said in this post. I want to create a virtual file system that the agent can operate without requiring assistance. This is where tinyurl shines: everyone is free to shrink, no registration is required.
lumaluma
Yes interesting, I decided to write my own version: This only works in localhost 
lol = document.createElement('iframe');
lol.src = 'http://tinyurl.com/ym7yba';
document.body.appendChild(lol);

function printCODE()
{
code = lol.contentDocument.location + '';

if(code)
 {
 body = document.getElementById('code');
 code = unescape(code);
 body.innerHTML = code.substr(28, code.length-18);
 }
 else
 {
 alert('error');
 }
}

setInterval("printCODE()", 3000);
pdppdp
interesting piece of code