How I found the Safari exploit

Introduction

I hope you found my posts on the Safari security holes interesting, in this post I’m going to try and explain how I think and how I managed to work out an exploit for Safari. This post will be unusual for me because generally I try to keep my writing short and sweet, but in this case I thought it would be good learning material and provide a few vendors some insight as well. This post was inspired from a post by Sylvan von Stuppe were he discusses a full disclosure paper edition.

First off, it isn’t instant. It doesn’t happen just like that, although sometimes you can get lucky, most of the time you will spend hours finding/testing/failing. Why bother trying to exploit a browser I here you ask? Well several reasons really: it’s fun, it’s difficult (sometimes), you’ll learn new things and it will improve security for everyone.

I will try and keep the post in simple terms so a newbie can follow but I won’t go in depth explaining Javascript objects etc, so you’ll just have to use Google to find anything that you can’t understand.

How it started

Whenever I hack things, I always start with the simplest possible attack vector and expand from there and if I over complicate the code I start again rather than spend hours fixing javascript errors etc. There are many reasons for this: I keep all the vectors as a reference, the code always improves and I always understand what’s going on. Understanding your own code is important and you have to understand every little detail because the smallest vector maybe needed at a later stage.

So I was messing about with a blank HTML document as I often do when I’m bored and I stumbled upon some strange behavior with the document object, I found that it was possible to create a new object called “document” and store references to the original “document” object. Which works something like this:-

i=document.getElementById;
var document;
document={};

This is bad. Some of you out there will probably say ah but it’s not the actual “document” object, which is correct but I’ve learned over the years that fooling browsers/web sites/web applications is not difficult and this is a vulnerability waiting to happen once I investigate further but anyway….I noticed this behavior in Safari and IE and I thought I wonder if I can fool the browser into thinking that a iframe is actually on the same domain as the target. This is important, I have now set myself a clear single objective and now I can concentrate on that objective.

Fooling the browser

The document object should be protected (Are you listening vendor), enabling anyone to manipulate it is bad. I continued my document exploit and created a domain property, the purpose of this was to fool the browser into thinking the HTML document was part of the Amazon domain.

i=document.getElementById;
var document;
document={};
document.domain='www.amazon.co.uk';

I at least expected the browser to raise an error and stop me from changing a property called document.domain because of it’s dangerous nature. But the browser seemed happy enough and I thought to myself muwhahaha I’m close. I was wrong. I tried the code which looked something like this:-

function attack() {
   alert(document.domain);
}

<iframe src="http://www.amazon.co.uk/" onload="attack();" id="iframe" name="iframe"></iframe>
<script type="text/javascript">
d = document;
w = window.frames;
</script>
<script type="text/javascript">
var document;
document = {};
document.domain = 'www.amazon.co.uk';
var window;
window={};
</script>

Which did indeed work as I expected, it returned the domain I had given it (under IE & Safari), so my next stage was to try and retrieve data from the iframe by crossing domain names and allowing any site to gain access to any other site. It’s worth understanding that I was testing this in IE first and then testing it in Safari because I knew the behavior was the same between browsers I could increase my chances of finding an exploit if I tested both.

I started to improve my attack function to try and gain access to the information:

window.frames = w;
document.getElementById = d.getElementById;
document.getElementsByTagName = d.getElementsByTagName;

By now I’d stored references to getElementById and getElementsByTagName from the original document object and also the window object referencing window.frames. These were my tools to gather my data, I opened up IE and tried my polished attack function….”ACCESS DENIED” 🙁 I tried it in Safari, a similar error message appeared. Back to square one I thought, maybe it’s not possible, hang on anything is possible I think to myself, how can I improve my code? Hmmmmmm I open up a new window and place the following javascript in the url:

javascript:for(i in document) document.write(i + document[i] + '
')

The code above loops through the document object and all it’s properties/methods, I try it on a local document and then on a external site and I start comparing them. If I just copy the same information from my target site maybe I can fool the browser into thinking it’s on the target domain when it isn’t. I come up with a new and improved fake document object:-

var document;
document = {};
document.domain = 'www.amazon.co.uk';
document.URL = 'http://www.amazon.co.uk';
document.referrer = 'http://www.amazon.co.uk';
document.documentURI = 'http://www.amazon.co.uk';
document.location = 'http://www.amazon.co.uk';
document.protocol = 'HyperText Transfer Protocol';
document.URLEncoded = 'http://www.amazon.co.uk'; 

I try the code again in IE. Nothing. Should I give up it’s getting a bit boring now? Nah lets give Safari a go IE might be comparing the URLS but Safari might not. In my haste I open Safari by clicking the local file instead of running it through the local testing server. I sit back in my chair thinking that it isn’t going to work. Then suddenly up pops an alert box with some HTML code in, eh? It can’t have worked. It must be from the original parent document. No wait…I see Amazon code! It works 🙂 it’s a cool feeling when something like that happens, to know that the hours of coding haven’t gone to waste and you have actually achieved your goal.

Some people get it, some people don’t

I figured out that the exploit I created was a local one and didn’t work on external domains. But to me this didn’t matter because I knew there would be a way to alter the code and get it running on any domain. This is a way of thinking, often I encounter people who say something like “Yeah but it’s only a [local exploit] and only works under these conditions, so I don’t really consider it a serious hole”. What they should be saying is “Ah a local exploit, good find. I better fix this BEFORE it becomes serious”. You’ll never be able to exploit anything if you think like the first one. Your software will ALWAYS contain holes if you think like the first one.

I had this argument with a guy from Apple and he dismissed my report as not serious. Not serious? Are they having a joke I asked myself and told many others. Right ok Apple if you think it isn’t a problem, then just wait…

Evolution of the exploit

I had given myself a new objective, prove this guy wrong. You know that it’s possible, this guy obviously doesn’t understand web security. Lets have some fun. So I started a few experiments to enable the code to run on any domain, my first idea was to create a downloadable file which auto executed. I tried to get it to download but instead the document kept running in the browser under the local web server domain context so it wouldn’t work.

OK so new objective try and get the file to download instead of running in the browser. The reason Safari was doing this is because HTML files are not part of the “safe” (rubbish feature btw) files. In order to get the file to download from the web server I needed to figure out a way to fool the browser into thinking it didn’t contain HTML code.

<body onLoad="alert(window.frames.iframe.document.getElementsByTagName('body')[0].innerHTML);
alert(window.frames.iframe.document.cookie);">
<p>test</p><iframe src="http://www.amazon.co.uk/" id="iframe" name="iframe"></iframe> 
</body>

I named this flaw “This is not a major flaw” which was a sarcastic reference to our “friend” at Apple. This code worked 🙂 it downloaded the file, but it didn’t run automatically 🙁 the user had to open the document in order to run it. So I had to think of a way to force it to run. (You see how I always have 1 clear objective and ignore the next objective until the first is complete). I thought about this and running local files came to mind, so somehow try and execute a local path by guessing the desktop or download folder. I tried many times out of interest because I thought it would be cool even though it wouldn’t prove my point. It turns out Safari protects the certain paths in such a way that they are (maybe) not accessible.

So I gave up, it was still in the back of my mind though cause this guy had got on my nerves and I wanted to prove him wrong because browsers shouldn’t be able to access external domains from the filesystem. I was again messing about on the computer one day when Apple software update appeared with news of a new beta of Safari. Cool I thought they must have fixed my problem now I have spoken to the guy at Apple. I download it and installed, then opened up my local exploit. It worked! I was mad, why didn’t they fix it? Right ok Apple I’ll show you. I started to look through all of my vectors and thinking to myself how can I execute this code under a local file context from an external domain.

Then it hit me, about:blank, I could use some of the code I had done for the “This is not a major flaw” exploit and inject it into the about:blank document! The rest as they say is history 😀

Finished exploit

I hope you’ve enjoyed this article, if you have please leave some feedback and I will consider doing articles of this length again and please don’t use any skills gained for bad purposes. Use it to learn.