I keep hearing about this idea and every time I hear it I kind of cringe. In a recent blog post the folks at Internet Explorer talk about high assurance SSL certificates for Internet Explorer, Firefox, Opera, and Konqueror (I guess Netscape was left out?). The concept is pretty simple and I encourage you to read the IE blog for more details. Webmasters buy a high assurance SSL certificate which shows the public that they are trustworthy and for their troubles the browser community thanks them with a nice green URI field.

So I have to go out and buy updated SSL certs for every single SSL server I have so that we are actually trusted - because only phishers use that normal SSL stuff I guess. Now everyone has these high assurance SSL certs and only the chumps who are doing dev work or just can’t afford it have the snakeoil or non-assured SSL certs. And now there will have to be a lowered bar so that everyone can buy them (quickly too). And lastly you end up with SSL certs all over again, only this time you’re paying 10x more for them.

And let’s not forget our dear friend XSS which totally obviates the need for me building my own phishing site or buying my own SSL cert. Oh, and don’t forget that MOST phishers don’t use SSL enabled sites, since users don’t know the difference anyway.

Okay, I get it… they’re trying to build a whitelist and they can’t think of any “fair” way to do that. Using that whitelist they want to educate the users (I’d argue that that hasn’t worked super well in the past so I don’t know how this will help). There’s just got to be a better way to do it that doesn’t make us end up with the same thing we all started with in the first place.

This will seem like an odd post at first. Netvibes is vulnerable to XSS. “Wow” you’re saying, “Who cares? Practically every website is.” This one was a little different than most. What I noticed on a random blog site was the initial URL. What happened was that the URL itself was pretty tame. Just a redirection back to the homepage. In that redirection a cookie was set. Can you see where I’m going with this?

So upon redirection to the site there was no XSS in the URL string, it was, in fact Netvibes’ homepage. The problem is that Netvibe’s homepage is dynamically constructed and looks at those cookies. Those cookies contain our XSS script. They even try to take account XSS by escaping quotes. Alas, that’s pretty trivial to get out of.

So Netvibes takes the cookie and transforms it into JavaScript to do some tests on it. Meanwhile we have broken out of the JavaScript string and now control the webpage. Not just any web page, but the home page. This is what I’ve been talking about with muddying the waters. Instead of this being a simple HTML injection issue that would have been very cut and dry to fix, now they have to fix it in two places, both the JavaScript and perhaps the server side if it is expecting angle brackets to not be encoded. Additionally it also might require a change to the cookie writing code itself (although that probably wouldn’t stop me anyway, as I could forge my own cookies with Flash).

Netvibes is only interesting because of the sheer volume of users who could be phished and because it affects their homepage. It’s also interesting because I’ve heard of a few tools that might try to take into account the URL of the page you are on, and in this case unless it also counted redirections that protection would fail. I know I have a few Netvibes users, so unless you typed in the URL by hand, be careful!

Well, technically Firefox 2.0 has been ready for a while now, but tomorrow is really the big day that it gets pushed out. But Firefox 2.0 is available today for download. And download I did. Almost the first thing I noticed was the spell check in text areas. I almost didn’t notice it at first because it was so intuitive, but there it was. Very cool feature. Next I tried the anti-phishing filter:

Click to enlarge

Picked up the very first site I threw at it. So all of that appears to be great for the consumer and great from a security perspective. Now here’s the bad. Upon install it broke a number of installed plugins. Namely:

• Fasterfox (oh well, who needs speed)
  
• Switch Proxy (ugh! this is one of the most useful plugins I have for switching back and forth between burp suite)
  
• Server switcher (not particularly useful anyway - useful when switching back and forth between QA environments seamlessly but nothing really lost)
  
• Firefox View (never used it anyway so it’s okay)
  
• SEOopen (I don’t use it much anymore since I got Search Status so that’s okay too)
  
• Safe History (I guess the CSS history hack is back in force again)

So if you can handle that annoyance I’d say upgrade. It handles about the same, but only time will tell what major differences lay under the nice new exterior. Also, I was amazed that Firefox still hasn’t implemented HTTPOnly. I think it’s just getting ridiculous. I know it’s a Microsoft non-standard convention, but it’s a good idea, and I’m amazed that it’s still not implemented. Overall though I’m pretty happy except for the switch proxy plugin being broken. That one is going to hurt bad since that simple plugin is one of the major reasons I use Firefox for testing more than Internet Explorer. Oh well, back to doing things by hand.

I saw an interesting link today that reminded me a lot of the XSS Calculator. I wonder why. No, really I actually don’t wonder why - it’s practically the same thing. Spam-me-not is designed to allow people to use the mailto: functionality as they would today but obfuscating the URL using a mix of HTML and HEX characters. Cool in concept, but pretty trivial to beat. The cost to modern day robots is next to none to do the sort of backwards conversions required to get the real text.

I think the value in this is fairly limited. Spam is sort of a way of life these days. Email is really taking a back seat to other forms of internet communcation like instant messaging and oversees you’re beginning to see a lot of voice over IP traffic. It just makes more sense. Email has been around for 15 or 20 years now, and the spammers are always ahead of the anti-spammers. That’s not entirely true though. I’ve got a few account that get thousands of spam emails a day, and I see none of it. It’s pretty remarkable actually.

This form of obfuscation that spam-me-not provides is probably effective at the lowest common denominator of spam bots. And as more people use this form of obfuscation, developers will spend the 10 seconds necessary to write the code to decode it (they don’t even have to write it from scratch since it’s already out there). All of this reminds me of the DMCA problem. If you release software that has to be decoded at some point there is nothing you can do to stop that decoded information from being logged elsewhere. It’s the nature of software. Oh well, maybe some people will find some use for spam-me-not - while the rest use email forms.

I know there are quite a few people who read this site but don’t look at the forums, so to save you some time in combing through all the recent posts, I thought I’d highlight a few that were very noteworthy. The first is from Łukasz Pilorz. After doing quite a few tests against the most recent mhtml vulnerability in IE (which turned out to be a problem with interaction between outlook express and the browser) Łukasz found that there is one server side mitigating factor that makes this attack fail - and it’s something as simple as adding a few linebreaks to your code.

Next there has been a lot more attacks against MySpace on the forums as of late. I think increased awareness of how high profile a target has been the main impetus, but I’m speculating. Anyway, kuza55 found a rather interesting hole in Myspace using XSS Fragmentation which is a tricky way of saying he used two benign peices of code, injected into two different places on the same page to create a successful attack vector. It’s an interesting read and a terrific proof of concept about why doing blacklisting is prone to failure.

It’s also an interesting concept because it shows why you cannot look at the injection point alone and make a decision on it’s level of security. This is where a lot of application security scanners tend to fail - by looking at the singular output of a parameter rather than knowing the system as a whole.

This is right on the cusp of what I think is worth talking about since the volume is so low. It’s not particularly interesting that Nordea.se was phished (article in Swedish). The part that’s interesting is that a relatively small market segment is being attacked. This is common behavior for phishers, but in this case I think it’s more interesting than most for a few reasons. The bank is small compared to most of the more common attacked banks and it’s non-english.

Nordea.se is what I like to call a phishing probe. Phishers often attempt smaller regional banks to see if they can get a spike in returns. Either they buy spam lists of users or find other ways to attempt more targeted demographics but in the end the attack is the same. Phishers like to try these types of things because it costs them next to nothing to attempt, and it can be a huge return on investment.

The economics are pretty simple. Let’s say 100,000 emails were sent. For a pretty targeted list that might cost anywhere from $100 to $1000. It may cost $100 to get somoene to break into a server for you and throw up your PHP kit that you probably already had if you are a regular phisher. It might cost several hundred for the card blanks and the card writer for making the fake cards but that’s a one time cost. Setting up the email drop for the passwords is free. So once the card number has been stolen what can you get for it?

Typically you can only pull out $300 per card. It’s dangerous to try more than once. But it’s not unusual for phishers to sell the numbers after they’ve been used. They can get up to $75 for a card number with pin. So a max of $375 if they do all the work themselves. $375 x 100 users = $37,500. When you subtract expenses you’re still well above $30,000 for a single haul. That’s not a bad haul for someone who is probably living in a country where that is far higher than the annual average income.

Even though Nordea.se is a small bank in comparison, the yield is still high enough to make the economics worthwhile. These probing techniques are not just worthwhile from an experimentation perspective but even if the yield is remarkably low (0.1% of users really is not much) the potential revenue is dramatic.

Okay, it’s be a tough day for new holes. This one affects nearly as many sites as the last IE hole, if you can believe that. Stefan Esser today released an issue with Flash where cross domain policy files can be embedded in almost anything. This isn’t the kind of thing you like to hear. Typically these sorts of things are dealt with by XML readers and not just looking for where the XML begins and ends. As a result this could be a pretty big deal.

Any website that lets you host images, or lets you do redirection (thanks to the Internet Exprlorer mhtml issue) or has a blacklist of HTML tags is now vulnerable to complete cross domain access via Flash. That’s really bad, folks. Although Stefan says that response splitting and XSS aren’t issues since you have XSS access, this isn’t completely true. I’ve seen a few situations where I could inject information but it wouldn’t render as HTML. Things set as text/plain are now vulnerable too. Like I said, this is not a small problem, and it will affect many many websites out there that are otherwise free from compromise.

This is some of the worst ownage I’ve seen in a long time. Secunia announced a really nasty cross domain leak for Internet Explorer. This allows anyone with control over a webserver to control anything you do with any page you can connect to. It’s interesting that Secunia marked it as a “less critical” threat, as this pretty much gives any attacker read access to any domain anywhere as long as you are using Internet Explorer 6.0 or 7.0.

The only saving grace here is that it does require access to a server where you can write HTTP headers (or somewhere that you can do header injection/redirection) as you need to force the browser to go to a certain URL which then redirects to another URL. Here’s what the header’s look like:

telnet secunia.com 80
Trying 213.150.41.226…
Connected to secunia.com.
Escape character is ‘^]’.
GET /ie_redir_test_1/1234 HTTP/1.0

HTTP/1.1 302 Found
Date: Thu, 19 Oct 2006 15:38:46 GMT
Server: Apache
Location: mhtml:http://secunia.com/ie_redir_test_2
Connection: close
Content-Type: text/html

telnet secunia.com 80
Trying 213.150.41.226…
Connected to secunia.com.
Escape character is ‘^]’.
GET /ie_redir_test_2 HTTP/1.0

HTTP/1.1 302 Found
Date: Thu, 19 Oct 2006 15:39:00 GMT
Server: Apache
Location: http://news.google.com/
Connection: close
Content-Type: text/html

At this point the client is redirected to the server as you (with your credentials) and it is returned as a cachable mhtml file that can be read via XMLHttpRequest since it “appears” to your browser to be located on the machine that did the redirection. Pretty clever. I’ve played around with these sorts of things before but was never successful (obviously I never tried mhtml). It seems to me that someone was saving this one.

And remember our nonces we were using to protect against CSRF? Well forget it, they’re readable by the cross domain leakage now. I don’t know why anyone would say this is a less critical risk as this is complete ownage of the entire internet for users of Internet Explorer. Hopefully Microsoft will patch this one quickly.

Just a quick note to any recruiters out there, or anyone looking for a job, I’ve thrown up a web application security/network security job board on the sla.ckers.org forums. Since the people who frequent this site tend to be more hardcore web application security and network security I thought it would be good to open up a job board since I get tons of calls from recruiters.

So I’ll post the job offers as I get them or if you hear of anything or know of a position that needs filling feel free to throw it on that section of the forums. I’m sure we are all interested in finding good work at some point or another, so this should be a useful resource to all of you. That is all.

Normally I skoff at user conferences and now I know why. Sylvan von Stuppe had a pretty funny writeup on the first day of SPICON. For those of you who aren’t in the know, SPICON is a SPI Dynamics user conference. That’s not unusual for big companies so that they can do lunch and learns or otherwise help their consumers to better understand the new product offerings as well as get feedback. In fact, if you are working with a vendor that doesn’t offer at least a beta program, run!

Anyway, it’s a fairly embarrassing read. Maybe there are a lot of beginners in the audience but most of the topics covered thus far are pretty cut and dry, however if you are looking for a primer on how to set up training on basic web application security principles for development this is pretty much right on. Anyway, interesting read!