One of the main problems with detecting cross site scripting (XSS) is that it is not an easy feat to traverse the document object model (DOM). Rendering engines are slow, and they are processor intensive. But let’s just suspend disbelief for a second and say that we could do exactly that. On every new submission to every form, let’s pretend we had enough processor time to execute each submission once and see the results before it was sent to the browser, looking for anything that might denote something malicious from a web application security perspective.

That would be great, in theory! I could suddenly remove obfuscation (the entire reason for the XSS Cheat Sheet) as an attack vector, because I could detect any possible variant, just by watching the DOM execute. Pretty slick, right? Well, no. Even setting aside for a second the problem mentioned above with processing power, there are other troubling issues with this.

The first is timed functions, or remote execution. The problem with JavaScript from a detection and parsing standpoint is that it is a full fledged language, that supports all sorts of interesting things. One of those interesting things is the ability to pull in remote information and do analysis on it. Let’s say I set up a JavaScript function specifically to pull in a remote image (from a server I have at least partial control over). If the image is over a certain height or width or the combination is just right, the JavaScript will execute malware. If you get really tricky you can use a combination of sized images as a decoding key for some enciphered peice of code. Here’s an example:

<SCRIPT>
image_1 = new Image();
image_1.src= "http://ha.ckers.org/images/kcpimp.jpg";
if (image_1.width > 1 ) {
// Execute malware
}
</SCRIPT>

Now, that pretty much puts to rest the notion that you could traverse the DOM and get the same results as the user will (once I switch the images out). So if I know you are going to scan my block of code prior to letting it get posted, I can simply allow it to stay put until that grace period is over. When I’m convinced that you won’t be scanning it any further, I’ll change the images out, and the code will execute for all future users, until I either change it back, or the code is removed.

There is still one other problem, which is that you have to pick a rendering engine to do this with. You’re now saying, “Well, of course you do! That’s a stupid thing to say!” Well which one would you pick? IE seems to have the most vectors that effect it and the highest penetration, so that would seem to be the obvious choice, but are you going to allow the Gecko (Firefox) only vectors to go through - thereby allowing double digit percentages to be infected by the malware? Tough choice, and certainly not bullet proof.

The remote execution issue is the biggest in my mind, though. Because the attack is now controlled by a remote device (an image or series of images) it is now out of the hands of the user to even decrypt if you so choose. Typically JavaScript is a very easy function to de-obfuscate, if you have the human eyes and time to do it, but in this case, if the images aren’t there or are different sizes, the decryption is meaningless. And even if you could scan every single input, you’d still be at the mercy of a timed function where the image changed after a certain point.

This could give a ceneral command and control aspect to XSS worms, where the central image controlled the timing function, as to keep the attack under wraps until the timing was right. This would be particularly effective in DoS attacks. The downside is that the single command and control is easy to remove - unlike self sufficient viral code which depends on nothing but itself and the machine for propogation and originating page for roots to continue growth.

id just sent me a link to Dark Reading talking about the controversial prospect of selling exploit code for cash.  It has been something I’ve talked about in the past, and actually I was alerted to it by OptikLenz as well.  The website is called Zero Day Initiative (it has been live for about a year now).  The black market is buying “weaponized” exploits that require little to no skill for up to 2-5 times the highest asking prices of these websites.

Call me crazy, but this is a huge market place now.  Considering that Phishing is a billion dollar industry, who cares if they have to spend $50k for a remote windows exploit to help them host phishing sites?  Or $10k for a new spamming technique.  It’s a small price to pay when the ultimate gain could be tremendous for the assailant.

And do you think 3Com or Tippingpoint are doing this for the good of humanity?  No, they are reselling it via their contracts with their customers to make more money off of the exploit code.  The economics of hacking are beginning to move into the free market economy and away from the socialist free-for-all of the last decade.

Well, perhaps Firefox was always grassroots, but I ran accross this link today that made me laugh a little.  Save the internet from bad browsing.  It’s national Firefox day!  Well, it was Firefox day but I guess Firefox day goes until September, so don’t worry, you’re not too late. I never saw much fan-fare about this, which is kinda too bad, because I think it’s a really interesting idea.  Who thought to make your browser viral or a meme.

One thing I would love to be able to do is package up all the things I normally do to Firefox and have a single downloadable executable that I could put up somewhere.  That way when I’m in a hurry, I don’t have to muddle around with settings and plugins, I can just download and go.   Anyway, cute link, and if you want your name to go down in infamy within some credits somewhere, you too can get someone to switch from an outdated browser.  Personally, I have every browser under the sun installed, so I won’t be getting my name in any credits anytime in the near future, unless I set up a VMware install or something… *sigh*  Just doesn’t seem worth the time.

The other day I was interviewing a guy for a position with our company and we got on the topic of phishing. Normally I pretty much avoid the topic, because I was way too intimately involved with it for too long, but he brought it up so we were talking about it. Then he proceeds to tell me his personal phishing story. Inside I was was shuddering because I’ve heard exactly 1 billion personal phishing stories now, and I really didn’t need to hear another one. But then he starts telling me a story I hadn’t heard yet. The story of someone who has had his website used as a phishing site.

Unfortunately I didn’t get a lot of details out of him because I had other things to do, like make sure he was a worthwhile candidate, but I did manage to get an interesting story out of him. He had a crappy little Linux box (he didn’t say what flavor) sitting on an open network - no firewall, no nothing. He was using it to host some domains for some consulting work he did. One day he gets a call from AOL saying that he was hosting a phishing site. Sure enough, he looks at his website and indeed, he was.

He was non-technical so he called a friend of his who was vacationing in the south pacific at the time, and asked him to log in and find out what had happened. It was a pretty boring SQL injection attack that had gained them access. The hole was plugged, the site removed and everyone went back to their day jobs.

The next day, AOL calls him again, saying that he was indeed hosting a phishing site (again) and to please take it down post haste. Well he called up his friend (who I am imagining is getting a little tired of taking phone calls in the middle of the night while visiting Thailand - telling him to jump out of the saddle and nerd out). Anyway, he logs in and cannot see that anyone has logged in. He checks around and finds that there is a timed function to replace the phishing site each day if it happens to be gone.

He didn’t tell me if it was a “cron” job or an “at” job but that was a fairly effective tactic of re-owning a server, without actually exploiting any other holes in the security. Be warned, if you are hacked into, check your cron tasks!

I just booked my flight to DefCon, and I went through the normal checklist. Two beds, check. Smoking room, check. But wait, I’m guy traveling alone, and I don’t smoke (except for the occasional cigar). Vegas is known for it’s statistics. The statisics that go into making the casinos work, is truely amazing, but what does something like that mean to a Casino? Up until a year or two ago I was going to Vegas once every month and I always got a single queen sized bed, in a non smoking room with the exception of the first weekend of August when I always got two beds and a smoking room.

If I were sitting there, as a statistics weenie working at a Casino, I would be scratching my head. I mean, here is a clear anomaly, that clearly means something, but given the information they have on file for me, it’s meaningless information. Predictable, yes, meaningful, no. So how can a complex system that intends to predict user behavior handle something like that? Well clearly, it just simply must take it as a datapoint and continue to expect it. And if I’m in Vegas at all in the first weekend in August, I’ll be getting the same kind of room.

For anomaly detection, this is actually a useful peice of information. It’s predictable, it’s easy to detect if you extrapolate it out over a multiple year timeframe, and it can be used to target me as a unique individual. It’s really a gold mine of information if you look at it that way, but it also doesn’t mean anything to anyone but me. I asked my girlfriend who really should know, if anyone else in the whole world would, and even she had no idea why I would do that. Yet, year after year, I do the exact same thing. Two beds, in a smoking room (yet, I don’t smoke).

So, the answer is pretty boring, which is that lots of times hackers are down and out and need a place to crash, and I like to have an extra bed, just in case. The smoking part comes in to play because a lot of times I end up with hackers in my room and they smoke and I don’t want to get charged more for them messing up the room. So it has everything to do with an environmental variable that is not exposed through the Casino booking interface, which is that a particular convention is in town the first weekend of August. Tying that in with the other times I’m in Vegas wouldn’t work, but during those times I am getting a normal room.

In this particular scenario I’m actually an advocate for anomaly detection, where most of the time I think it’s really a psuedo science - in the same way I think certain dinosaur’s vision, which tracked only motion is only practical so long as your prey doesn’t stand completely still. All it would take is for my girlfriend to tag along once, and I would end up with a single bed, and a non-smoking room, which would throw them off even more. It’s a strange issue that anomaly detection helps identify, but not to diagnose.

Moritz Naumann Just published a cross site scripting vulnerability in WebScarab today. The details are pretty obvious, and I’m surprised it took this long to find it (I don’t personally use WebScarab as Burp Proxy is far more useful in my opinion (even though I do have to have Java installed which can be a pain if I’m in a pinch).

But this is an interesting trend I picked up on last year at DefCon. There were a handful of talks about how you could exploit one security service or another and get access to some device. I have mixed feelings about that. Yes, security people should code secure systems. But are security products ubiquitous enough to make for a valid attack vector? I mean how many people do you see roaming around with WebScarab installed and running? If I were to put that exploit on this page, I’d probably have one of the highest hit ratios for that vulnerability working, given the users who visit it. I bet you it’s still less than .1% of users who visit this site are actively using WebScarab while they read this blog too.

So perhaps that’s not worth mentioning. Another common security XSS vulnerability I’ve seen is where the admin must input the XSS himself and then another admin can be hit by it. Sure, there is some grey area here, where I could see a rogue admin who knows he’s going to get fired who wants to keep access to the machines, but that’s one of a thousand ways to do that as an insider. So maybe that’s not particularly valid either. But what about things like breaking into IDS boxes and gaining access to poorly set up networks? Sure, there I can see that being a valid exploit. Taking it further, what about getting remote access to machines running an anti-virus product? Well since a huge percentage of users have it installed these days, I’d say that qualifies as a valid attack vector that needs to be dealt with.

I guess my point is, most of these exploits in security systems are interesting in academia only, not as a valid attack vector. Although I think what Moritz found is impressive, it would be very difficult to exploit efficiently - although one could argue the people who have it installed are harder to exploit than most people, so perhaps it is somehow worth more to target them directly. IE: someone who has WebScarab installed probably has access to a number of other sites that would make him a valuable target to penetrate. Interesting theory anyway.

Isulong SEOPH just published an amusing comic I thought I’d share with all of you. It’s regarding the content theft that happened last week. It was pretty funny, so I thought you might get a kick out of it.

(Click to enlarge)

Attackers can use Cross site scripting (XSS) as a proxy to perform website security auditing. Jeremiah Grossman and I have been toying with this idea for a while now, but it occured to me much later, that we never got into the basics of how this could work. The basic premise is that by using Cross Site Request Forgeries (CSRF), I can get users to perform systematic security penetration tests against web application targets of my design.

Typically XSS works in this way: You have a site that you want to attack, and by injecting HTML into it the users who go to that URL are then fooled into entering their credentials, or the information that is sent via the browser (like cookies) are logged off host. It’s a very direct path, that doesn’t leave much room for obfuscation. The other problem is that testing the application to find the vulnerable cross site scripting holes can take a lot of poking, and all the while you are leaving signatures all over the host.

You may get around that by using a proxy, but here’s an idea. Why not use existing users as your proxy? All it takes is one compromised host, or another site that is frequented that you can inject HTML into. So I have random site “A” that is not the ultimate target, and the victim site “B” that you are interested in. I inject HTML into site “A” and the visitors of that site stumble accross the injected XSS. That XSS tells their machine to connect to site “B” and test for a simple exploit (say another XSS hole - just to make this easy).

The first XSS vulnerability in site “A” runs a series of attacks against known potential holes, like in PHP nuke, or whatever. Those attacks attempt to inject HTML and JavaScript. That JavaScript contains a script to post cookies (or anything really) and the exploit that worked to a remote machine somewhere named “C” (this could be a bullitin board or anything - it doesn’t matter, as long as it accepts incoming anonymous requests and logs them in a way that you can view later). The script will continue to run until the user navigates away from the page on site “A”. When site “B” is found to be vulnerable, the user automatically sends their own cookies to site “C” along with the vulnerable URL and string that worked.

Now the bad guy simply needs to go to site “C” and look for any string that might have worked. Voila! Now what did the victim host “B” see? They saw an IP address connect to their machine and perform a series of XSS attacks. They may see one succeed, but either way they can no doubt see where the information was intended to be logged on site “C”. You can remove site “A” from the logs by using a series of META refreshes so it doesn’t show up in the referring URL (as META refreshes remove the referring URL). The important part here is that the real attacker’s IP address never shows up in the log files of the victim, site “B” and it is highly unlikely that the user who’s machine is being used as an attack relay probably won’t have any idea about what is going on.

Here’s a diagram that should help explain it:

Click to enlarge

Cross site scripting is probably the most important initial vulnerability to find, because that will then open the doors to remove the browser cross domain policy issues so you can perform more interesting attacks, like SQL injection and code injection. Once those attacks are performed they will need an XML RPC call (requiring cross site scripting) to send the data that is outputted to a logging remote host (site “C” or otherwise).

In this way you can use XSS to completely proxy all of your web attacks so that the victim in question (site “B”) will never see the originating IP address. This does rely on having two other cross site scripting vulnerable machines at your disposal, but those are a dime a dozen. This concept really falls into the category of XSS malware (a term coined by Jeremiah) where XSS goes beyond a simple way to inject HTML, but actually can be used as a launch pad by which to initiate much more destructive attacks.

I know I’ve been batting around a lot of the accessability issues with CAPTCHAs and turing tests in general when used to discriminate against robotic activity and how that relates to the blind.  Sometimes what I talk about is theoretical and sometimes it’s not.  Here’s a case in point.  Target had a class action suit filed against it by the National Federation of the Blind (NFB).

My general feeling on this matter is it is always better to allow alternate applications to visual CAPTCHAs.  Audio versions are one example.  Email is another example.  Out of bound methodologies can provide reliable alternatives to visual CAPTCHAs and can still allow users to proceed through the flows in question.

Quadszilla ran a story regarding another giant MySpace worm traveling over the XSS riddled social networking site.  This time it hit the embedded shockwave files, which has long known to allow JavaScript to be embedded in it.  The details of the hack can be found here, and the details of the actual exploit can be found here.

I should note that this is using two seperate vectors.  The first, as I mentioned as the shockwave that MySpace allows in their system.  The second is a JavaScript directive that is split up by a newline and a carriage return (both of which only work in Internet Explorer, Netscape 8.0 in the IE rendering engine mode and Opera.  This exploit is probably confusing to some people who attempt to test it in Firefox, but it definitly works.  All the good stuff happens when I’m gone for a few days!  Geez!