I saw a post this morning point to a fiction story over at Michael Daw’s website about how XSS can be used to steal national secrets. It’s based loosely off of the concepts that Jeremiah built and it references pdp (architect)’s paper on XSSing the Lan. Basically this is just a sensationalist outlook of what is possible, but it’s still an interesting narrative.

I’ve never been a fearmonger, but for the first time in my life I’ve found myself telling people, “I don’t know a company I couldn’t break into.” Every system I’ve found has vulnerabilities. There was something Bruce Schneier wrote a number of years back (and I’m paraphrasing here) that said that for every man hour it takes to build security it takes n+1 to break it. That is, if there are vibration mics in the ground it will take exactly n+1 the time it took to place them and test them and get them working properly as it would to break in.

On Mythbusters episode 59 the other night the crew cracked into several physical devices like fingerprint scanners, and walked past various versions of motion detection devices (with something as simple as a pane of glass). The point being here are always way around security, physical or otherwise. In the case of JavaScript port scanning it is similar to a Trojan horse. The idea is to sneak something otherwise normall and innocuous into an internal interface.

JavaScript seemed the most likely candidate, so we tackled that first. Yes, that means nearly every company on earth is vulnerable to that. Is that the only weapon in the arsenal? No way. Are there ways to fix it? We’re already working on them. Will that solve things? No way. It will just shift the problem elsewhere at best, and at worst, it will continue to be an esoteric attack vector that is only used by the few people who really get it’s consequences.

Last night a webmaster for a pretty large website mentioned that he was having problems with people doing password guessing against known user lists. This is a really common problem in the web application security world. It’s trivial to mount large scale password guessing attacks against websites, and there’s very little you can do about it. First, let me explain the three different types of password guessing brute force attacks:

Vertical Veritcal password guessing is where you start with a single known userid and you throw thousands of passwords at the script, testing each one in succession. These are by far the easiest to detect because the way databases are set up, it’s trivial to set up a counter for the number of times a userid has been tested. Once it reaches a limit you ask the user to do something special (unlock an account or otherwise).

Horizontal Horizontal password guessing attacks use the same password but request many different usernames. This is much harder to detect for a few reasons. First, the password is staying the same but generally people don’t have a database of attempted passwords, and passwords aren’t unique anyway, so that wouldn’t help. Secondly, a table of guessed passwords per username is irrellevant, as they are only guessing one username password pair at a time, and the username changes. Thirdly and most importantly, you cannot seperate the guessing by IP address because of companies like AOL who use massive super proxies and route thousands of people through the same account.

Diagonal Diagonal password guessing is by far the hardest. Not only does the attacker shift the username, but they also shift the password on each guess. There is relatively no way to stop this type of user except banning their IP address or asking them to remedy in some way or another, which is easy enough to defeat by simply changing IP addresses. And if they come through an AOL proxy, you’re out of luck because then you are asking all of your AOL users to remedy who came through that proxy (which could be upwards of 30k users or more). That may or may not be a big deal depending on what the remedy is and how many AOL users you have.

There are certain things I don’t recommend. For instance what PassMark did to Bank of America. You don’t want to block your users outright when their password fails. This just sets up a situation where competitors can deny service to all your users simply by enumerating through them in the most obvious ways to get you to block the accounts.

One common way to get around this is to ask a user for a CAPTCHA as a remedy. Of course, that represents problems for accessability, but that can be mitigated as I have discussed in previous posts. Another way is to ask the user to limit their account by IP addresses. Give them a few days to tell you all the IP address ranges that they’ll be logging into (optionally) and let them limit access to their account. That way outliers from those IP ranges will set off alerts, or at minimum you don’t have to allow access, so the attacker will waste time.

However, you end up doing it, it really won’t stop a determined attacker, but it will make it so difficult it may be easier to attack other targets. “I don’t have to run faster than the bear, I just have to run faster than you.”

One of my favorite stories about my courtship of my girlfriend is how I got XSS on her page. She had a really crappy tag-board thing that she had written in PHP. To this day she gloats that it took me 3 tries to get XSS on the page and that she had made it harder for me than most people had. Last night I finally told her the truth. It had, in fact, taken me four tries, not three. Let me start from scratch.

Her tag board was set up to take standard user input and echo it back to the page. From her perspective she saw a bunch of people tag her page, and then I started tagging her page. Being considerate, I didn’t immediately try to break her security. However after my first (benign) post I realized that there was a possibility for exploitation. From her perspective she saw me post three times total. From her perspective the first two attacks failed (she was escaping quotes and I tried single and double quotes) before moving on to a quote-less vector that worked.

But even though it took me three tries to break in, I was 99% sure it was vulnerable before I even started injecting vectors into her. How? It was actually a previous post I had made. Something utterly benign that had made it’s way on her board. Here’s what it looked like:

You’re hot!!! <3 <3 <3 -RSnake

The < in the "<3" was how I could tell that she was vulnerable, even before I had found the vector that would work. Simply by viewing source, I was able to see that it had not translated the open angle bracket to an HTML entity. The fact that I could inject an open angle bracket is 99% of the way to finding the vector that will fire. The only way it wouldn’t have worked is if I was limited in numbers of characters I could inject (which I knew from previous posts on the tag board I wouldn’t be) or if she had some super tricky method of knowing what was and wasn’t a valid HTML tag (I’ve only seen that type of security twice in all the years I’ve been working on XSS, so that’s pretty unlikely).

So from her perspective, she could see two failed attempts and one successful attempt. The beauty is, she didn’t even know about the one above all of that that had originally tipped me off as to the vulnerability. She was blissfully ignorant of that fact, even though it was staring her right in the face. Think about someone watching an automated IDS watching for anyone transmitting an open angle bracket (a very uncommon thing to see) and then upon closer review it’s someone saying “eye <3 u”. They would chalk it up to a false positive.

I’m sure now that you see what I did you can think of other ways to mask things like SQL injection and additional types of attacks that allow you to know if the site is vulnerable or not without setting off the alarm bells of anyone watching their logs.

And yes, even though it had taken me four tries - I got the girl. <3

This time it’s Yahoo’s turn to be used in propogation of phishing. This is the second time in just a few weeks that this has happened. The nay-sayers are awefully quiet these days, have you noticed? Interesting. Anyway, I’ll stop playing the “I told you so” game, and stick to the facts. The fact is Yahoo is currently hosting a redirection script used for tracking. That link can be modified to forward to any domain of the attacker’s choice. The attacker happened to chose a phishing page (big surprise):

http://rds.yahoo.com/_ylt=A0LaSV66fNtDg.kAUoJXNyoA;_ylu=X3oDMTE2ZHVuZ3E3BGNvbG8DdwRsA1dTMQRwb3MDMwRzZWMDc3IEdnRpZANGNjU1Xzc1/SIG=148vsd1jp/EXP=1138544186/**http%3a//65.102.124.244/usage/.us/link.php

This is a live phishing site at the time of this writing. I’m not sure what else has to happen before these companies start jumping on these to close them down. It’s bad for the consumers, and it’s bad for their trust brand. I understand better than just about anyone why it’s important to be able to track your users’ activities, but there are other ways, like onclick event handlers, etc… 98-99% of users have JavaScript turned on so that should be good enough to track as a percentage. Or use a whitelist. Or use an embedded checksum. There are alternatives to leaving yourself open to these forms of attack.

Maybe I’m preaching to the choir now.