It took a “few weeks” but better late than never. After a few weeks Google finally fixed the XSS hole that Watchfire found in Google Desktop. The flaw would enable attackers to read personal files from users who used Google Desktop. Apparently Google has now instituted additional layers of security to protect against their coding flaws. To quote the article:

“We’ve added an additional layer of security checks to prevent the types of attacks pointed out by Watchfire and future possible attacks through this vector as well,” [Schnitt] wrote.

Why am I not impressed by those words? Suffice it to say, neither is Watchfire:

“There’s a high potential for this to happen again,” Weider said.

Yup, but let’s finish Mike Weider’s sentence since it’s incomplete: There is a high potential of Google creating desktop products that endanger their users’ privacy again. Whenever you try to web-enable services, which Google is hyper interested in doing so they can track everything you do and integrate things more seamlessly, you are creating a huge hole.

Just because you add an additional layer of security does not make the concept secure. Of course no one will abandon this path only making the hole bigger and more complex with time. However, it is my opinion that it is only a matter of time until these types of exploits are being written into viruses. A “few weeks” is actually almost a month by my calendar (Jan 4th to Feb 1st) and that is just way too long to respond to a critical threat like this.

I got an email a few days ago from Moshe Ben-Abu talking about an XSS using UTF-7 in MediaWiki (version 1.9.2 LATEST). The advisory is available here. Here is his email:

A Cross-site scripting vulnerability has been found in MediaWiki 1.9.2 (latest version) in the experimental AJAX feature. Actually it’s the same one that they fixed on 9/1/07 (http://www.mediawiki.org/wiki/News) but UTF-7 encoded.

After doing some testing I was coming up empty handed - I couldn’t repeat it. Well it turns out it only works if Firefox is set up to view UTF-7 by default (which it next to never will be) and IE7.0 ignores it by outputting it’s default 400 page. So this would appear to work only in IE6.0 (which is not particularly useful). However, there’s an old trick in IE where you can force the output to show and get rid of that pesky default message. You just need to put in enough data. Here’s a demo that should work in IE7.0:

http://www.mediawiki.org/wiki/index.php?action=ajax&rs=%2B%41%44%77%2D%53%43%52%49%50%54%2B%41%44%34%2D%61%6C%65%72%74%28%27%58%53%53%27%29%3B%2B%41%44%77%2D%2F%53%43%52%49%50%54%2B%41%44%34%2Dasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf

So, yes, anyone using IE7.0 viewing MediaWiki is now vulnerable to the UTF-7 injection. This is a tricky one to solve, but could most easily be fixed by setting the charset to something rather than leaving it blank. Nice find, Moshe!

I’ve been toying with an idea for several months that I think I’ve finally got to the point that’s worth talking about. One thing that can be a big problem is mapping anyone behind a NAT. If there are a number of people using your site that use the same IP address it can be difficult to separate them into different users. Although this method is hardly fool proof it can help distinguish between users as long as they don’t close their browser regardless if they don’t use cookies, or allow any other form of session information to be written to disc.

So here’s the concept. The user connects to your DNS server, and gets an IP address with a very short TTL. The IP is unique for some period of time. The user will continue to use that IP address with the hostname given for the duration of their session, regardless of what they do. Other users who connect later will see a different IP. Of course, once the user shuts down their browser and restarts it they too will see a different IP, but that may be enough for certain applications. This would be most effectively used on a single static image or some sort of tracking mechanism so that you don’t have a high overhead. In general this is a pretty heavyweight solution, but it could be useful to some people out there.

ThePost sent me this link to Dr. Markus Jakobsson explaining how click fraud and phishing works for Google employees. At first this talk was a complete snoozer (if you already know this stuff, it won’t be an eye opener but if you aren’t familiar with it, it’s worth listening to the first half an hour). But the second half of it is where it gets interesting.

Firstly, one thing he mentioned during the speech was that you could create a robot to spider the net looking for bad things - well it turns out there is an easier way for Google to do this - their own spyware. Since Google Web Accelerator is spyware, they can see whatever they want that the user sees - making it a canary account. The counter attack for fraudsters is to create tactics to avoid exploiting users with web accelerator and it would make sense anyway. What’s worse, having Spyware on your machine or making a bad guy a few cents by subverting your clicks - tough choice. He also says, he’s not sure if Google has a way to tell where users have been before - again, Google’s spyware is pretty convenient here too.

I thought it odd that the Google engineers didn’t understand how the browser anti-phishing stuff works (it’s sorta their job to know this stuff, isn’t it?) and Dr. Markus Jakobsson did not mention the anti phishing built into Firefox and Netscape either, but at least he did talk about some of the heuristics and laid to rest their misunderstanding of why a programmatic solution to phishing detection cannot work completely.

Frankly, I’d rather see Dr. Markus Jakobsson doing more Q&A rather than his speech because he obviously knows what he’s talking about and was much more interesting when he was just answering questions. Anyway, interesting 40 minute speech if you have the time (it’s got subtitles if you don’t want to play it out loud at work).

I’ve been asking about this for years now, but I finally got my answer, yes, the US government is going to test the state of cyber-security in the event of a cyber war. The goal is to identify weaknesses and come up with solutions to a large scale network attack. I was bitching about this when I was a member of the IT-ISAC - there was no one working on this at the time, and it was scaring the crap out of me. Apparently someone was listening!

I have no idea how the test is going to play out, but to anyone who is involved, let me reiterate this issue - the attacks often come from within. It’s not only outside threats we are going to have to contend with (and furthermore once something is inside a network it’s hard to get out). So is the case with viruses, XSS worms, botnets, etc…. You may be able to kill the command and control but that relies on one critical assumption - that there is one. Anyway, I’ll be very interested to see the results of these tests if they are ever published.

You can’t make this stuff up - nEUrOO alerted me to an interesting XSS vector I hadn’t seen before. Yup, you can embed JavaScript in SVG - and you can embed SVG with an Embed tag using Base 64 encoding - and yes, that works in Firefox. Normally I’d blow something like this off, because if you can use Embed there are a lot of other worse things you can do - however this one is slightly different.

With Embed generally you have to already have the plugin installed to use it. In this case, in Firefox you don’t have to do anything - requiring no user interaction, unlike a Virus or something more malicious. That’s really the primary goal of the Cheat Sheet is to find ways to execute JavaScript without user interaction and this definitely fits that criteria in a pretty bizarre way. Carrying the payload with you is pretty sexy too, which means you can’t just shut down one command-and-control server to get the exploit to stop propogating (in the case of a worm). Interesting stuff, and nice find, nEUrOO!

Michal Zalewsky has been on a role lately - this time with overwriting cookies on other people’s domains in Firefox. Yup, Jordan Wiens sent this over to me and apparently a bug has already been filed by Mozilla to fix this but this has some interesting security implications.

The trick isn’t too complex, he is essentially using a null separator which confuses Firefox, but the implications mean that you can do session fixation across domains or invalidate cookies, etc. Further there may be other nasty things you can do since Firefox may not know where it is (allowing you unrestricted XMLHTTPRequests). Think of this as the mhtml bug for Firefox. Nasty. Great work Michal!

It’s pretty cool to have someone else write about you. There has been so many thing I’ve done over the last 12 years, it’s really hard to keep track of it all. Anurag did a pretty good job of getting a good chunk of my security background out of me. Pretty cool actually. I guess now that my name is out there people are getting to know me a little better (for good or bad, who’s to say?)

Things I didn’t mention in the interview - I’ve worked in banner advertising, I founded EHAP, and I helped invent some of almost everything that’s annoying and wrong with the internet (including spamming tools, delayed popups/popunders, and viral marketing). I’ve got a varied past, but these days I’m sticking with security and SEO - the two things that seem to evolve at the fastest pace on the Internet. Anyway, nothing new here, move along.

Update: Thank you to Zulfikar to pointing me to the real website where this was first discussed and indeed there was mention of Jeremiah’s work. Snarky comment now only applies to eWeek’s coverage, and my apologies to Zulfikar for my unfair comment - as it wasn’t him who said this.

I just got this link sent to me, and it is essentially a re-hash of the JavaScript intranet hacking stuff Jeremiah and I came up with last year. Essentially Zulfikar Ramzan of Symantec is saying that you can use the old technique (which he is calling a new technique) that we came up with to hack into routers. The only vaguely original thought in the article is that they are using it to change the DNS entries for use in pharming attacks. Of course there was no attribution - that would be silly because, of course, this is new. Except for… these little teeny weeny inconvenient tidbits:

Turning off security using CSRF - August 7th, 2006

JavaScript port scanners - August 2nd, 2006

Cross Site Scripting Talk at Blackhat - July 25th, 2006 (where I first mention attacking network devices)

XSS talk at BlackHat - July 1st, 2006 (where I first mention attacking other layers of the OSI model)

While not in any way at all new, it’s interesting to hear the statistics that 50% of home routers are vulnerable to this form of attack. Pharming is one of those things I have always scoffed at, because before this attack they primarily relied on DNS hacking (not of the home user’s DSL connection but of the DNS server they used). It’s a slightly different take on the same old hack, that has some interesting implications.

So, while not new, it’s another take on pharming, which I had pretty much thought was a dead topic. I guess we’re bringing it back, and calling it new. While we’re at it, I’m going to invent the Internet again. Al Gore will be pissed, but so what? /snarky

For those interested in scanners Shreeraj Shah posted a working ruby script for scanning for entry points in AJAX. It’s brief code, but it has a good point. There are obvious injection points in the code, that make for clear entry points to execution. I don’t know how well this deals with real life scenarios, like obfuscation or JavaScript that outputs JavaScript but the code is in his whitepaper.

I thought of similar ideas back when I was doing PERL auditing - looking for attack points by anything that used common libraries and commands that were often vulnerable to lack of input sanitation. The idea is sound - not bulletproof by any means, but in lots of cases it does tend to give favorable results. This said the man who shirks all scanners… but no, I think I give scanners a hard time because they aren’t bullet proof. Sometimes I think getting 80% of the issues still has value. Maybe it’s not bullet proof but maybe it will allow you to dodge said bullet.