Well, the server is back up and running (big thanks to id - during our upgrade there was a drive failure causing us to have to switch machines), and to celebrate I didn’t want to come back with a boring post that would make you question why you read this site. So instead I decided to play around with some CSS tricks - bare with me for a minute. I don’t know why, but I really think CSS is going to get worse over time. Anyway, as I was poking around I happened across one of the missing pieces of the puzzle to solve a simple problem in using CSS to hack - the lack of conditional logic.

Jeremiah and I spent at least an hour on the phone several months back when he was coming up with browser port scanning without JavaScript. One of the key problems with that technique, which he later overcame, was that he was unable to find any good way to do conditional logic in CSS, so instead he leaned on a browser quirk that delays the rendering of images. Watching the timing differences can help an attacker derive which ports are open and which aren’t. While very cool, it’s caused some headaches and only solved one of our problems.

Before that Jeremiah also came up with the original CSS history hack as you may or may not remember. Later on pdp came up with another variant of the same issue using a very different technique (Firefox caching). Both of those techniques were cool, but both of them also required that you have JavaScript turned on. We all know there are still people out there who think turning off JavaScript protects them from everything.

Keeping this in mind it would be great if you could create a form of conditional logic in CSS. Well I finally figured out a way. Using a hybrid of a:visited and display: attribute you can detect that the user has visited a page and more importantly perform an action based on that fact. The actions are somewhat limited if you can’t use JavaScript, however, one action is enough. The reason being, when something is set to display:none it will actually cause the HTML tag that it references to not render. Setting the background: image attribute for the visible tag to use a URL of a logging CGI script allows you to send a request to a remote webserver based on the conditional logic as mentioned above.

Now, the only lacking part is the state management, and that can easily be tied together using a unique cookie, and/or an IP address in the QUERY_STRING or anything else you want to use to identify the user. In this way, the remote website can steal history information from the user without ever once using JavaScript, or any client side programming. Click here for a proof of concept of the CSS history theft without using JavaScript. This works nearly instantly, so it is far better than the JavaScript-less intranet hacking and pdp’s version of the JavaScript CSS history hack in terms of speed. The only latency is the time it takes your browser to request the images associated with each URL you’ve visited - which is nearly instant since I don’t return any data (and thanks to browser threading). The other nice thing about this is that it works beautifully in both Internet Explorer 7.0 and Firefox 2.0.0.2 (although it doesn’t work in Opera 9.22).

I haven’t experimented much with this yet, but I also believe this could be expanded to do another form of intranet port scanning as well. Using a series of iframes and forced browsing it may be possible to detect which pages the user can access. I’m not in love with this technique because the CSS will fire too quickly so you’d have to delay the CSS from loading or make it reload with a meta refresh or something equivalent, but I also haven’t put much thought into it yet.

The ramifications of the CSS history hacking stuff is that it allows the attacker to steal information about the client, which can be useful to identify a target, to find information about the user, for use in targeted attacks, to know trending information for use in targeted advertizements or other forms of private information theft.

So now we’ve eliminated the JavaScript pre-requisite from Intranet port scanning, cross site request forgeries, session riding and of course CSS history hacking. The only thing we can’t yet do without JavaScript is read cross domain (and I stress the word yet). What else is left? I don’t mean to sound ho-hum about this, but really, what else do we have to do? Are there any nay-sayers left?

To quote digi7al64 “With all the recent stuff surrounding google i thought i would check out how secure yahoo was in comparison… cause I have never really bothered to audit the domain so to speak. anyways within 5 minutes i had my first xss” and indeed he did:

Click here to see the XSS in yahoo for yourself. It’s true, I tend to talk about Google more than other sites primarily because of how much traffic they get through their search engine as a percentage. But yes, all major sites tend to be plagued by XSS among a plethora of other web application security issues. The greater the interdependencies between each application and the greater the complexity of the application the more likely it will have flaws.

I know we’ve all heard the statistics about how many vulnerabilities per line of code there is, but I don’t think this statistic is accurate and I don’t think it applies well to web applications in particular. It would be interesting to get the statistics of how many holes there tend to be in web applications per line of code. My bet is it would be higher than almost any other application due to the way people tend to build web apps. The web is only growing my friends.

Matt Cutts (the search engine guru at Google) just posted a few comments on this site and others that picked up the story that the redirection hole being used by phishers is now closed by adding a dialog warning you that you are being redirected (Click here for an example). That is good news because 1) clearly Google now can no longer deny it’s a hole - they themselves fixed it 2) some consumers may now be slightly safer, kinda. But as he himself said, this really isn’t a complete fix as this is only one of many known redirects in Google that have the potential of aiding phishing attacks.

There are 10 more redirects in Google that are still functional on this one URL alone. Google is riddled with these holes and they are incredibly easy to find. So while I applaud the fix, I am hardly impressed. It took over a year for this hole to get closed since I first announced it (you’ll notice the other three I mentioned in that post a year ago are still unfixed). There are at least 4 or 5 more that I’ve run across beyond that as well. It’s not even worth cataloging them at this point because there are so many left to fix.

So good job on fixing a small percent of the problem, but Google has got a very long road ahead of them before I’d trust clicking on any unscrutinized Google link I found on the web.

I’m sure this is old news to some people but it’s the first time I’ve seen it show up in my logs before. In the last twenty four hours three different hacked .edu domains have shown up in my logs. Stanford.edu, UCNE.edu and ISI.edu have all been at least somewhat compromised where the domains now host spam sites. Not so good.

Clearly the administrators of their domains have got some work to do to secure their sites. But it does cast some doubt on the “good” and “bad” domain concept. When a good domain goes bad, is it breakout (intentionally getting a good reputation and then converting to be bad) or is it spam? Either way, it’s clearly bad, but what to do about it? Do you blacklist the pages or the whole domain? That’s gotta make life a little harder for the search engines that try to stay away from spammy domains. Perhaps reputation and link popularity is a bad model afterall.

If you look at the latest security advisory by Mozilla you can see a number of big changes have been made to reduce the prospect of cross site scripting attacks. I talked with Daniel Veditz at Mozilla and he warned me that some changes were coming with the next version and he wasn’t lying. Where shall we start:

First of all the non-alpha-non-digit attack vector will now be closed. This is the same one that has been causing MySpace so much pain over the last few months. This is a good fix, as there really was no practical use for it anyway. Bravo!

Secondly was a fix for inheritance of charset by pages that don’t set their own. The child webpages accept the charset of the parent. More info posted by Stefan Esser, here. This can make the attacker control the charset to something that would normally not work like the UTF-7 vector. Again, bravo!

Third, Firefox password manager has finally been updated to look not only at the source of the website that it auto-populates password but also the destination. This is in response to an old post on automatic password theft that spawned WhiteAcid’s scripts and then a post on Slashdot. So yah, this is good, but unfortunately it doesn’t actually stop the attacker from reading the text in JavaScript. While good, I’m still staying away from password managers (not to mention all the other broken password managers that are still out there).

Last, but not least, the Adobe Universal XSS vuln has been fixed! Hurray! It was already fixed by Adobe, but not that many people update Adobe reader anyway, so this is a stop gap for those users.

So wow, that’s a powerful set of fixes! Each and every one of those could be very nasty, so I’m glad the changes were made. Now, back to work!

pdp has a really interesting demo code that steals Firefox history using the about-cache directive in Firefox. This is a different method than we’ve seen before, and is quite a bit slower in his demo than Jeremiah’s version but it’s equally clever. If you read his post he describes how this is different than the looking at link color, but you get the idea.

He does it by checking the cache of the images on certain sites you’ve been on. So this actually may be better than the URL checking that Jeremiah built in that it can see if you’ve been on a site where the image was vulnerable before you do the fine grain URL checking. So it can uncover large swaths of a site in a single request since images are often used on many different pages. Pretty clever actually. Nice work pdp!

Come one, come all, how much do you want for this 2.5mbit hacked machine? We all know it’s out there - the underground market for hacked machines. There’s an interesting thread brewing on sla.ckers.org about this topic - one that I find kinda disturbing. Yes, if you ever wondered if those stories everyone told about a black market for hacked machines was true, rest assured, it is.

The prices are interesting, especially given the number of vulnerable services out there. Also, the fact that eGold is the currency of choice confirms what I’ve been told as well. That doesn’t really surprise me, there’s very few good way to transfer money safely internationally (and mostly anonymously). Interesting and scary read, if you aren’t already familiar with this stuff.

Well the month of PHP bugs is fast approaching. If you haven’t been following Stefan Esser’s blog and you run PHP, read this now. Over a 31 day period, starting next Thursday (March 1st), Stefan plans to release one or more vulnerabilities each day in PHP (not particular applications but the underlying language itself). He didn’t comment on if he would give demonstration code or exploit particular applications directly. That’s the bad news.

The good news is that apparently PHP 5.2.1 fixes some of the issues that Stefan will be disclosing. Further, Stefan is the same guy who wrote Suhosin which is a patch for PHP to secure it. My gut tells me Stefan will keep Suhosin up to date, but I have no proof of this. My gut tells me if you run PHP, and if you haven’t updated PHP lately and you don’t run Suhosin, you are in for a rough month. Time to patch up!

It suddenly hit me this morning. Google’s entire security model is based on not finding a single XSS hole in Google’s domain. The amazingly poorly thought out link between Google desktop and Google’s website creates one of the worst security holes I’ve seen. After reading Watchfire’s paper on “Overtaking Google Desktop” yesterday I too took a look at Google Desktop. For those of you who aren’t aware of how it works, it basically looks for certain strings in the Google domain and replaces them with a link to itself. It does this using a browser shim (not a network shim). This simple design decision is one of the few things that’s saving them from having a second vulnerability right now.

The link itself is to Google Desktop and it includes a nonce (a one time token). That one time token is the second reason that Google Desktop is briefly saved from exploitation. This one actually is a good design decision (not the integration with the website, but forcing the nonce to be there and validating it on each request). The nonce changes with each request, so knowing it once doesn’t mean knowing it for other requests. However, here is where things start falling apart pretty quickly.

Google Desktop is pretty much completely susceptible to a mixture of Anti-DNS pinning and header forging (also known as anti-anti-anti DNS Pinning) (and even that is only to make sure the Host: header reads “127.0.0.1:4664″). Okay, but what about the nonce? Doesn’t that make Google’s Desktop super uber secure? Hardly. Now all we need to do is find one XSS hole in allllll of Google where Google’s Desktop reads the header and overwrites it with its nonce. The XSS hole reads the nonce, pops an iframe with the data needed for the anti-DNS pinning, spoofs the header and voila, read/write access to Google Desktop.

You are may now be asking, “But if you have an XSS hole on Google there is a lot of other things you can do.” Maybe, but remember, Gmail is on another cname (mail.google.com). So if you can’t read their gmail, why not just read the files from their cache instead (which Google happily keeps for you)? Normally cache would be unavailable to your browser, but luckily for the attacker Google’s Desktop makes that matter rather trivial. “But that seems like a lot of work. I mean, why tip your hand if you aren’t even sure if they have Google Desktop installed?” Oh, I don’t know, why don’t we just detect if they have it installed just to save us some hassle? So I wrote a little detection mechanism to pull an image from Google Desktop (I guess the Google engineers got lazy and decided not to add nonces to their images). If it’s there, they have it installed and turned on, if not, don’t bother running your exploit.

Again, the heavy integration between web based and client based software is not a good thing. There are far too many unknowns and far too many holes out there right now. Just ask yourself this. If the security of every file on your computer rested in the hands of Google’s engineers never inadvertently creating a single input validation hole would that make you very comfortable knowing their history (1, 2, 3, 4, 5)?

I’ve always loved CGI proxies because they have to deal with all the same problems that every other application has to deal with plus they have to try to force anything and everything that connects back to the remote machine into their pipe to proxy it. Alas, it’s just not that easy. HideMyBrowsing.com is designed to protect users from being seen by content filters. Firstly, how long will it take for content filters to block them? But even if you put that aside, and the obvious using their services to do malicious PHP injection, etc… they are still vulnerable.

The very first thing I tried was the UTF-16 vector. Normally they strip out JavaScript, and they do a fairly good job of it, but like all systems this complex they don’t anticipate everything, and as a result they are vulnerable to XSS. Normally that’s bad enough in of itself, but this time it’s worse. If the website uses UTF-16 they can force the user’s browser to connect back to the machine in question. Thereby de-anonymizing the user, making their viewing visible to content filters and running JavaScript on hidemybrowsing.com. Bad bad bad.

I’m sure it’s vulnerable to other vectors as well, that was just the first one I tried. So while interesting and vaguely clever usage of CGI, I wouldn’t use this if you could get fired for looking at porn at work.