Jungsonn has only been a member of the forums for one day and he hits big with IP encoding that evades Firefox’s anti-phishing filter. This isn’t the first time I’ve seen this sort of thing, but it’s the first time I’ve seen it in a commercial browser. What Firefox is doing is doing a direct compare against the URL. Using the IP obfuscation calculator you can create IP addresses that don’t match what is in the anti-phishing list. But it’s worse than Jungsonn reported even.

That’s right, go to any phishing site and add in a QUERY_STRING to the end of the URL and poof, no more popup. What a bummer. I was really hoping they would do something a little smarter with this. Unfortunately with this knowledge it is extremely easy to defeat the anti-phishing detection built into Firefox’s newest browser.

The QUERY_STRING issue is a tough one to solve, because where do you know to compare against? The IP address issue that Jungsonn came up with really bothers me. Why would you use the URI field to do comparisons instead of the IP address that it is normalized to? Is it an oversight? Oh well, I hope they fix this soon.

For the last few days I’ve really been trying to figure out what CSRF (Cross site request forgeries) are. I know that might seem like a pedantic or academic question but it’s really not. Here’s what I’m really concerned with. Without being able to define it we can’t even start talking about how to defend it. Stopping all cross site calls would break the internet and unfortunately wouldn’t solve a lot of the CSRF attacks out there anyway (since many are really SAME site request forgeries).

Here’s what I’m getting at. What if I can force someone to log out. In of itself that isn’t really much of an “attack.” If anything from a security perspective that is helpful because it reduces the overall risks for other CSRF attacks to be successful. However used in some strange DoS attack against the user might prove to be bad. So it’s not the CSRF that’s bad, it’s the DoS that the CSRF helps to create.

Calling a remote function might not be bad (lots of image servers are actually remote databases with an image output). Most would think calling an HTML file in an IMG tag is bad. Well, except if that HTML page is a benign 404 error telling us that the image isn’t hosted there anymore.

There are even more gray areas, like changing someone’s billing information. That would seem to be highly unscrupulous and bad, but if the attacker can’t do anything with it, it really ends up being only a mild inconvenience to the owner of the account when the company in question calls and warns them that their billing information doesn’t match their credit card on file. So while that definitely is a CSRF it’s certainly not an attack of any note. So what is an attack of note? Clearly changing passwords, secret questions or emails qualify. But who’s to say if adding a note to an calendar function or changing someone’s sex from male to female in the database or changing their default time zone is bad or not?

I’ve heard lots of definitions and all of them are skirting around the one major issue, which is what exactly makes the attack “bad” or worth thinking about. XSS seems more clear cut because it’s “bad” if you can get someone else to visit it and if the website is popular, etc… There are a few shades of gray in there but far fewer than with CSRF. If we as a web application security lab can’t define it, how can anyone reasonably expect to stop it?

Today Anurag Agarwal posted a link to the WASC list that demonstrates a conceptual manual AJAX worm. Actually that’s sort of a misnomer since this really is just using XMLHTTPRequest and not XML but you get the idea. The link is benign, but what it does show is a very slowed down and non malicious version of an XMLHTTPRequest worm that propagates via XMLHTTPRequest only (only on Anurag’s domain and only for the files he links to).

This is an interesting take on what we’ve been talking about. Of course it’s extremely slowed down because it’s not meant to overtake anything, and it’s all manual (you can see that the URL field does not change). This is kind of interesting when you can’t XSS the page your interested in but you are able to XSS at least one page that a user will end up clicking on.

The conceptual Warhol worms that I’ve worked on really have very few user requirements save that the user views a page that’s under the control of the worm and has the appropriate technologies installed. But breaking it down into it’s core components is definitely one step to understanding the most effective virulence methodologies. XMLHTTPRequest is definitely a technology worth thinking about though, especially combined with browser bugs like internet explorer’s mhtml: issue et al. Any way to move from one system to another makes the power of such a worm far more potent.

Enough acronyms in that title for you? Well I found this comic on securiteam’s blog and I nearly spit my drink out. It’s a little poke at our dear friend PHP and how many holes there tend to be in any kind of CMS written in it:

Click to enlarge

Just brightened my day a little and I hope it did for you too. Happy Sunday!

This is nearly a classic case of where understanding browser differences and the nuances of XSS is vital when you’re trying to stop attacks but still allow HTML. Yup, you guessed it, MySpace is still vulnerable to cross site scripting in the exact same way that they were vulnerable before, except now it only works in Internet Explorer.

You can read the forums to get the specifics, but basically by using a grave accent instead of single or double quote you can evade the filters that they put in place to stop Kuza55’s XSS fragmentation exploit that he disclosed earlier this week. Pretty nasty. Maluc also created a proof of concept that demonstrates the issue on the forums. It takes a few seconds to execute but it’s definitely still a valid exploit against the social networking platform.

This is a pretty thorough writeup from Chinesed about how his site was vulnerable to XSS. His writeup explains how the attacker injected XSS through a referrer field and affected his admins nearly a day later. I’ve personally seen this exact issue a number of time, and in fact, I used to surf around with a benign XSS exploit payload in my referrer field for exactly this reason.

The reason I stopped was primarily because I knew that the majority of the time the only place these issues arise is in administration consoles, and it’s not particularly useful as an attack vector if I can’t see the results. That’s good news because it’s hard to test for, but it’s bad news because it affects your administrators who watch your logs. In some cases it can be hours, days or even weeks later.

The scary part about this is that the payload was designed to get the attention of the administrator by popping up an alert box. It could have easily gone unnoticed had it not popped up an alert box. That’s even more scary to think about, as it can covertly allow attackers access to your most sensitive administration consoles and there’s really no good way to detect it. Anyway, it’s a pretty good writeup on how Chinesed isolated the issue.

I found this in my spam today, a free trial of AppScan. Pretty cool, actually. I like to see companies putting their products on the line for peer review. Of course it’s to get business - I would assume the majority of IT people who get that spam are interested in fixing their machines rather than finding issues with vulnerability assessment and security theory in general.

Still, good to know that companies are doing this. What would be even better though is to get some real statistics on how good each of these scanners are and what they are good and bad at. How hard is something to hack once it’s been tested by these various tools? Isn’t that the real statistic? Not how many vulnerabilities it finds, but rather how hard is it to break into your site after having been scanned.

Whiteacid built a pretty remarkable XSS Greasemonkey assistant script. It’s got a few kinks left to work out as we’ve been discussing but on the whole this is feeling like a possible right approach to by-hand penetration testing for XSS vulnerability assessment. I still think something like this should be built into burp suite but Whiteacid’s approach is pretty slick.

After installation and going to Tools->Greasemonkey->User Script Commands->Start XSS Forms you see an icon that looks like this:

When clicked that button allows you to run all the commands that the XSS cheatsheet XML file has in them against all form elements. Interesting tool that helps diagnose some of the problems out there. It’s really no substitute to doing it the old fashioned way, but it’s a nice crutch when you’re in a hurry.

Once again, the blind are at it - wanting equality and accessibility. Those pesky blind people! No but seriously, this is really pretty important and although I am pretty anti-litigious I think the National Federation of the Blind is making a statement by suing Target. Yes I know I’ve mentioned this before, but I started thinking about this some more in the wake of this recent MSNBC article. Blind people cannot use the Internet in the same way people with vision can. They cannot “see” the page layout. One thing I haven’t talked much about is semantic relationships in HTML. It’s a very simple concept that eludes most people who claim to know HTML (at least they put it on their resume).

One of the major problems I see with the way HTML is constructed is tables. Tables are one of the most useful constructs in HTML. You put things in columns and rows, and it makes sense. The problem is that it’s not accessible. The way tables are constructed you read down the column instead of across the row. It’s easier to dump the contents of a select statement in SQL than put it into a multi dimensional array and output one row element at a time in order. Thus it is no longer semantically correct.

Let’s say I have a simple table that has this sort of data in it:

Name Age Sex
Alice 32 Female
Bob 53 Male
Cathy 38 Female

A person who is blind heard that as follows: “Name Alice Bob Cathy Age 32 53 38 Sex Female Male Female.” That’s not terrible with such a small list but when the table grows to many columns with many rows in it, it’s nearly impossible for the person to understand which person you are now talking about. If the table were re-constructed to be in semantic order it would make more sense, “Name Age Sex Alice 32 Female Bob 53 Male Cathy 38 Female.” I understand CSS has come to the rescue but with completely different look and feels and bugs depending on what browser you are using. My question is, why haven’t we invented a new table structure in HTML that is semantically correct? It’s not radical thinking, it’s a simple solution to giving accessibility and still allowing an easy standard way to display data in HTML.

Anyway, sorry, that was probably a tangent. The real reason I’m writing this post is to drive home the fact that the CAPTCHAs people have been using on their enterprise websites are going to get them sued unless they have an alternative. We’ve talked about this before, and I’ve been given the impression that people just aren’t sensitive to this issue by the very same people who built those CAPTCHAs. I wonder what it will take for people to realize it’s just not a good idea from a security perspective (porn proxies completely circumvent the value since you can trick people in any context to type in those CAPTCHAs for you) and from a legal perspective. Hell, it doesn’t even have to be a porn site that relays the CAPTCHAs to unsuspecting users, it could be a blog… a web application security blog. Hmmm…

Coming quick on the heels of my last post comes an advisory from Secunia around address bar spoofing in Internet Explorer 7.0. This is pretty straight forward, just adding some %0A’s (hex for linebreaks) as padding in the URL in a popup window. It should be pretty trivial to fix, but I can never figure out why browsers allow the URL field to be removed at all. Suppression of URL fields should never be allowed unless the user permits it as a power user function.

That’s a few big holes in just a few days for the newest version of Internet Explorer. The score card isn’t looking so hot at this point. Anyone keeping score?