Okay, I can bet I’m going to get a lot of flack for this post, so before I start, this is only my opinion and is not at all based on actual numbers. The only reason I’m putting a graph here is because I think it’s easier to visually explain. No numbers. Got it? Just opinion. Don’t get all excited here. Okay. Calm yet? Okay, now don’t start reading this post unless you intend to read the whole thing. Ready? Now you may continue reading the post.

The last post I made was describing just a small smattering of some of my personal Firefox woes around the add-ons that I use to personally secure myself from attacks that either I have helped create, or have seen in the wild. Now, truth be told, I use Firefox every day, due to the add-ons that it supports and the ease of testing webapps. And it’s with that that I’m disheartened by my sense of helplessness around updates.

So here’s what I feel is happening over time for security people (not for the regular every day casual web surfer, but indeed, hardcore security folks, like most of the people who read this site). Over time there are upgrades. Those upgrades fix a number holes, and introduce a few others. They also break the add-ons. Those add-ons help fix the broken browser security model. Therefore, for the likes of me and the vulns I actually am affected by, my security is reduced with each new major revision of the browser, making it look something like this:

Sure, the overall security is trending up with time, but there are major gaps in my perceived security while developers catch up to the new codebase. While the numbers and timelines may be way off, the concept (for me at least) is right. I don’t personally see any immediate major benefit from the browser changes - only negative. With time, sure, things get better, but I happen to be in a particularly bad security slump at the moment right there on the right hand side of the graph. The exploit code that I may have been at risk of, for the most part, is neutered by the add-ons, until they stop working. So which is it? Am I trusting the browser to evolve faster than the add-ons or vice versa?

Firefox’s model has always been, “Feel free to contribute, it’s open source!” While this is great in theory, a) My programming skills get me by and not much more - you don’t want my code in your browser holding the Internet together, trust me b) I don’t have access to all the security bugs - most of the worst of which are hidden from view on bugzilla for only a very small select few people to view and c) there are very few people who have the ability to commit code let alone to fix other people’s add-ons.

It’s tempting to get overwhelmed by the helplessness of it all, but then I just remember that none of these plugins fix things like CSRF which helps me ignore that particular issue. So then I just go home and cry myself to sleep. Okay, now rant away, but if you mis-quote me or fail to read everything before commenting, so help me, I’ll make fun of you senselessly.

Strangely enough there’s been a ton of things happening in the CSS history hacking world lately, and I thought I should recap some of the more important events of late. Firstly, Firefox 3.0 came out, and wow - it feels an awful lot like when Firefox 2.0 came out. A good chunk of my favorite plugins no longer work - Switch Proxy, Auto Copy, LocalRodeo (since ironically it doesn’t install over SSL - and btw, that was the only public tool protecting anyone from JS based intranet hacking that I am aware of) and, of course, Safe History. Why is that a problem? Well, if you were relying on it to protect your history, it’s no longer an option.

Now, if that’s not bad enough, Jeremiah Grossman pointed me to a page that attempts to calculate your gender based on a portion of your history. An interesting take on the usefulness of the old CSS history hack. How accurate it is is questionable, but realistically this is pretty good for a first generation tool that is virtually un-tuned.

Last but not least, I did a little looking into the ol’ about:config options in Firefox and landed on a few options that were noteworthy. Not the least of which is browser.visitedcolor which can be re-set to anything you’d like. That means if you are simply looking for the color of a typical viewed link, you may be deceived if this color has been modified. That is - unless, the attacker knows that the victim has visited something before (a previous page perhaps), and the attacker’s code verifies that against something they couldn’t have visited (a domain that isn’t up, for instance) to isolate what the real viewed color is. So that option, if you were considering it, wouldn’t work for a more advanced version of the code that checked for this kind of thing.

It’s a sad day for the old CSS history hacking security though. And please, please don’t tell me that you’ll just turn off JavaScript to protect yourself!

What do I have in common with Magnum PI? What does id have in common with Dog the Bounty Hunter? Well in the state of Texas we all need PI licenses. That’s right, if you want to help anyone recover from an incident, investigate computer theft, or engage in any sort of investigation relating to computers whatsoever, you need to become a private investigator in Texas. We can chalk this up to lawyers legislating something they completely fail to understand.

Firstly, I highly doubt any of my customers would get any more value out of hiring Dog the Bounty Hunter to hunt through logs, or recover deleted data. Secondly, legislators are making broad statements like, “the computer industry needs cleaning up”. I’d like to make my own broad sweeping statement, “legislators who write ill-concieved laws need cleaning up.” I understand the reasoning, as poor as it might be. Proper handling of evidence, is always an important thing for convictions, but this is far more broad than that - even delving into the inner workings of private companies working to help other private companies do business.

I guess I better start waxing my chest and wearing dog tags, so I can start understanding how these darned computer thingies work.

Yup, it’s about that time again. Jeremiah has put up yet another webappsec professional survey. If you haven’t taken a look at his previous surveys you should - some of them are actually pretty interesting. Either way, it’s worth looking at the results, even if you don’t take part in the survey itself.

Also, I should note that the time is quickly approaching in which we’ll all be descending upon Blackhat and DefCon. I’ll be speaking at Blackhat on Xploiting Google Gadgets and an abrieviated version of the speech at DefCon as well. I’m also doing another speech at DefCon with Rich Mogul, David Mortman, Chris Hoff, Robert Graham, and David Maynor called All Your Sploits (and Servers) Are Belong To Us. So if you are planning on being there, drop on by and introduce yourself! I hope to see you all there.

Brian Krebs had an interesting report over at the Washington Post that cited a report from Indiana.edu about how redirects are in quite an abundance. Well, anyone who has worked in this field for any length of time should know that perfectly well, but it’s still interesting to get some validation from the researchers at Indiana.edu who specialize in anti-phishing research. Here’s the rub from Brian’s article:

Indeed, some of the Internet’s biggest Web sites — particularly Google — used to host large numbers of open redirects.

“Used to”? I know I’ve laid it on thick over the last few years, but I’m amazed people still think Google has somehow magically fixed problems that it never got around to fixing. Redirects are not fixed, XSS is not fixed. These issues still exist all over Google and Google’s web properties. But in case someone doesn’t believe me, here’s an example I whipped up in about 10 seconds that redirects to a random eBay auction from Google’s image server as a for instance (make sure you enable JS for the full effect).

It’s good to see people are finally understanding this in the main stream media, but let’s not give credit to companies that are clearly undeserving of it (both historically and currently). I’ll be the first one to stand up and give applause when we see these issues closed once and for all on Google even if it truly is just one company out of the vast untold wealth of sites out there that are vulnerable. But if it really is aiding phishers - and it is - the only way we are going to get ahead of it is by taking responsibility for our own sites. That’s especially true if we intend to be the be all end all of trustworthy advertising giants that Google aims to be.

So maluc and I went down the rabbit hole (again) looking for ways to screen scrape across domains using Java applets. You’d put a malicious Java applet on a page and an iframe to another domain that had sensitive information on it - then you’d use the Java applet to take a pixel by pixel screen shot and then log it for later analysis. Of course you can’t do it with Java, and for good reason, but you may be able to do it with Java Web Start. Of course there’s a security dialog but it’s pretty weakly worded and doesn’t look like it’s actually a security warning, so then I went down the path of looking at ways to force people to click on dialogs. The most obvious way is to float a whole bunch of JavaScript alerts in the same place right above where the “Yes” or “Always” buttons live hoping to trick them into clicking on the Java Web Start dialog.

But it got me thinking. People are fairly used to having to click on popups rather quickly to get rid of them and it it’s also fairly easy to change out the popups after a certain amount of clicks or if the rate of clicks reaches a certain threshold of clicks per minute. It’s also possible that those popups aren’t actually popups but rather DHTML that happen to look like popups and hover perfectly above where the more nefarious popup will come in once you are satisfied that the user is clicking quickly enough that they will inadvertently click on the Java Web Start dialog (or whatever type of dialog you are interested in getting them to click on).

Here’s what I came away with after this research: 1) users get frustrated easily, 2) they can’t tell the difference between good dialogs and bad dialogues when they are clicking quickly, 3) they will click on things if they think that by clicking on them they will get what they want (we already knew that from the porn movie codec malware guys) 4) because things like Java Web Start aren’t part of the chrome like the Information Bar or other chrome based notification, it’s easier to spoof, and 5) humans can’t tell the Z access of things in 2D objects so they can’t identify what is and isn’t a popup unless they have other issues during usability. It feels like there’s something exploitable here…

So my lovely gfnd’s co-worker enrolled her pet Chihuahua into a contest to rate the dog against others of the same breed in the local area. Vaguely amused, I took a look at the web application and sure enough, it pretty much sucked. The developers had used a client side code in Flash to make it so that you couldn’t submit twice, but in re-loading the app you could (and that’s how the newbs in her office were cheating). I, however, looked at what data it was sending and sure enough I could send votes by bypassing the client side app entirely. I took the cheating to a whole new level.

So I gave the dog 100 votes just for good measure. My gfnd and her office mates were amused and asked me to up it to 1000. Sure, no sweat. The next closest Chihuahua was in the 50-60 range, which I found by writing a quick scanner to dump all the results for all the other dogs. So I figured we pretty much had this whole thing sewn up. With the 700 votes all of her co-workers had managed to generate, plus my 1000, we were an order of magnitude higher than the next competitor. I could see it already - my gfnd’s co-worker’s Chihuahua would be named Chihuahua supreme, there would be dancing in the streets, songs would be written…. The whole nine yards.

Little did I know how fierce this whole Chihuahua community is, and right before midnight on the night that the contest closed some other hacker did the exact same thing - but took the number one spot above my pick. Alas, had I checked the scores leading up to the closing moments of the contest my Chihuahua could have easily won that contest. I guess if I cared more about Chihuahua contests, I might have put more thought into it. But in the end it’s just another amusing story. Props go to whomever managed to out haXor my Chihuahua contest haXoring!

I think we all can see how similar high profile and more important contests (or elections) could be tampered with. Maybe Chihuahua contests don’t rank high on your visibility scale, nor mine typically, but despite the silly consequences of tampering with Chihuahua contests, it’s a small window into a much more dangerous issue. I hope everyone had a good 4th and Canada day!

You may have already seen the news about the new XSSFilter in IE8.0 but I wanted to echo it here as well, because it’s a pretty major new release. It does a great job of preventing most of the reflected XSS attacks out there for default users of the browser when it hits production. Very cool stuff. By the way, the second link above also has a sneak peek as to another security feature in IE8.0 if you look closely.

Think of XSSFilter like noscript in Firefox, but without the turning off JS portion of the functionality, and unlike noscript, it’s default in the browser, so it will impact a lot more people. David Ross (the guy who came up with the term Cross Site Scripting in the first place, btw) wrote this tool to start tackling a problem he’s been thinking about for 8 or more years since that paper was first authored. It’s not perfect, don’t get me wrong, but it’s a huge leap forward in the right direction, and I was hugely honored to be a part of it, since I think it will have a great positive impact on consumer security while us security knuckle draggers figure out a way to get websites to start securing themselves.

Next on my wish list? Content restrictions!

I got forwarded this link today from businesswire about how Google and Yahoo are now going to be armed with the information necessary to look at and extract information out of SWF files. Ho-boy, here we go. The link was sent to me with the “bad juju” caveat, and I’m pretty sure I agree.

The problem is, like anything, if the search engines start pulling down rich applications that actually interact with the web application, there is untold issues that could arise. For instance, Flash applications have quite a bit of rich features in them, and some of that could be dangerous if they interact with back end applications. Also, if the word “test” appears in a Flash movie, does that mean it should get indexed? Or is it a frame that’s not visible, or off the side of the page, or whatever? What if it takes ten minutes to find that particular line of text or dozens of sub-menus? Are people really going to sit for that?

Do people really want to load a Flash movie when they query for things? I know I sure don’t! I’m already annoyed when I get linked to PDF files or .docx files. I think this just takes searching to a new level where people don’t actually want to go. Instead of crawling deeper and refining their search, the search engines are going to new mediums to stave off the people (like myself) who have argued that Flash isn’t a good medium for accessibility, usability and SEO. SEO is going to be off the table soon enough, leaving accessibility and usability.

But seriously, what’s next? Are the search engines going to decompile Java applets looking for text? As a side note, this should, at least in the short term, lead to a new round of Flash hacking, once it goes live. I’ll give a tee-shirt to the first person who writes a Google dork for internal Flash text that leads to exploitation.