This is a post I’ve been meaning to make for several years now, and I just now got around to doing it. Netscape is one of the few browsers out there that’s old enough to pre-date most of the security people who hack on browsers. It’s got a long trying history, with lots of problems and lots of successes and in a lot of ways it was one of the most influential browsers out there. I owe a lot to my understanding of the web to Netscape in the early days. There’s a lot to be said for the history. But we aren’t living in the past. Let’s talk about now.

Netscape’s new model is not as the role of a browser company, but more as a wrapper around IE and Firefox. Using versions of Firefox and IE, Netscape wraps them in certain ways depending on the user, to give the maximum browsing experience. Netscape has come a long way in terms of installers too, and their bookmarklets are very cool. However, there is a fundamental flaw in their design - they aren’t current.

Because they do not update as quickly as the other browser manufacturers that they wrap they are always behind the times in terms of vulnerabilities. That means any user who uses Netscape is vulnerable to old Firefox vulnerabilities for months longer than they would be if they used Mozilla. I haven’t seen a shift in that mentality in the nearly four years I’ve been meaning to write this and I don’t see it changing any time soon. If you are using Netscape you are wildly behind the security patching process. I’d love to see Netscape fix this and start updating in near-real-time along side their rivals who they wrap. I don’t see them as a serious competitor to Mozilla or IE, but still. I’d rather them not disappear completely from the planet - if only for nostalgia.

This weekend I stumbled upon a Achievo install on an Intranet environment and lo and behold - it had a security vulnerability in it. Actually it had other issues too, like open directories, misconfiguration that allowed attackers to read all the include files, etcetera. Not the most secure software in the world and seen fairly often on Intranet environments. It’s project management software for time tracking. From what I understand it’s free or they have a free version which makes it more attractive to SMBs that have professional services.

Click here for the live demo of the problem. The example on the Intranet environment that I saw was slightly different: http://ip/?auth_user=%22%3E%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E

It also looks like it may be vulnerable to SQL injections, although I didn’t press on this issue much, due to time constraints. Either way, if you are using this software, I’d recommend putting it behind a basic auth script or something to protect yourself from being automatically sent there by attackers, and if you run it on your external environment even more so.

A la Caezar’s Challenge, I wanted to create my own such challenge for the people who are able to attend Blackhat/DefCon and those who are unable alike. However, unlike Caezar’s challenge, this isn’t so much a better humanity type challenge - this is just a game for people looking to solve hard problems. The goal? Find the clues, solve the puzzle and win a ha.ckers/sla.ckers branded tee-shirt. If you aren’t coming to the con, no worries, we’ll ship you one. Here’s the ha.ckers.org challenge.

I must warn you - if you don’t know HTTP inside and out, there’s a good chance you won’t get past the first clue. It’s tough, very tough. I don’t expect anyone to solve it, although it can be solved in under ten minutes if you know what you’re doing. The rules are on the challenge. Good luck and see you in Vegas if you are coming!

Update: I’m going to cap it at 10 people. I’ll announce a list of winners that want their names to be mentioned along with how to solve the challenge once the answers come rolling in.

Update 2: We have our winners! In order of response :

WhiteAcid

Billy Rios

Shawn Lauriat

Tyler Reguly

Chris Soghoian

Ryan Platt

Wesley McGraw

Sid Stamm

Georgie

The spoiler is located here if you just want to know how it happened. Congrats to the winners. We had all of them in within just a few hours! Amazing! That definitely says something about the readership! This wasn’t an easy test. Maybe the next one will be harder.

David Byrne sent over an interesting proof of concept to use the same res:// attack I talked about that Billy Rios found the other day, but he put an interesting spin on it. The amount of CPU cycles (timing) it takes for the process to run depending on if the file is there or not are pretty significantly different. Click here to see the demo.

I’m not sure if this provides additional value over the original res:// attack, but certainly it shows that timing attacks are really very possible for this. The results on my machine were dramatic (over double the time for existing verses non-existing files). Your mileage may vary. Cool trick, nonetheless.

Billy Rios has a nice writeup on how you can enumerate files using the Internet Explorer res:// protocol. To see the demo, click here using Internet Explorer. I’ve been toying with this for a while, and used it to detect if you were using IE7.0 by looking at the included images that the anti-phishing image uses. But this is a new take on the same old idea.

This could be used to fingerprint a drive, enumerate users on a Windows platform, or detect which exploits to perform against a target. I’ve said a few times that the res:// protocol should be depreciated in the web context (cannot be called from the web) and I think there may be some movement in that direction in the future, but it probably won’t happen for a while. I’d love to see a hotfix to get rid of this one though, it just doesn’t need to be called from the web. In fact the only thing place I have seen res:// called from the web is in virus kits that attempt to fool people into thinking the page doesn’t exist by copying the IE file not found page, which includes links to res:// images. Time to kill that feature.

I saw a few different people mention over the last few days that httpOnly has been added to Firefox 2.0.0.5. Very exciting stuff - as this has long been missing for over two years. There are some major pros and cons when using httpOnly on cookies. The pros are that httpOnly cookies aren’t visible in JavaScript space using document.cookie and that makes XSS much more difficult when using it in context of credential theft. The cons are that it doesn’t work in all browsers and in some browsers, like WebTV and IE5.5 on Mac it can actually cause the page to fail to load. Granted the user base on those browsers is pretty minimal but that may be a show stopper for some people.

The only problem I see with using this as protection against credential theft is that the cookies are still visible using XMLHTTPRequest. If you look at Alex’s example, it looks secure because the cookie is not visible. But if you look at this example you can see that using XMLHTTPRequest you can still get access to the cookie by looking at the headers. This has been one of those long standing problems with httpOnly, but it does raise the barrier by shutting down the most obvious way of getting at the cookies, using document.cookie.

I got an email from Ryan N today describing a huge privacy leak in Photobucket - allowing anyone to look at anyone else’s private photos. Photobucket protects photos normally by password protecting them. However, as Ryan found, a username/password is not the only way to access the photos:

Here’s a random livejournal user’s “bucket”
http://img.photobucket.com/albums/v462/glass0rthodoxy/
as you can see it requires a login.
replace the subdomain with ‘pb5′ voila, you’re in:
http://pb5.photobucket.com/albums/v462/glass0rthodoxy/

As you can see, simply by looking at the exact same directory on another hostname allows you complete access to the user’s private photos. Allowing indexing is not always a bad thing - sometimes it’s a huge convenience. Other times it’s a huge privacy leak that can cause people a lot of trouble and pain. Who knows what private photos people store there? This is a great example of why you can’t think about applications the same way browsers do (same domain policy). Other servers can provide equal or better opportunity for exploitation and data leakage if they are somehow tied together. It’s best to explore all options when doing penetration testing. Nice find, Ryan!

Kuza55 and I have been trading emails over the last few days around a new technique he has been working on that he posted a few days ago regarding spoofing user agents. There are a lot of systems that use user agents to do operations. Typically that’s not a problem because the only person you can hurt is yourself. However, if you can force someone else to change their user agent, you can get them to exploit themselves.

So the problem is that Flash allows you to submit “User_Agent” instead of “User-Agent” and in some programming languages “User_Agent” gets changed to “HTTP_USER_AGENT” (in the case of PERL for instance). There are a number of vulnerable programming languages. The easiest fix would probably be for Flash to disallow injection of User_Agent and the other headers that may be used on the web in unsafe ways.

Very nice work by Kuza55. It took a while to get a demo that we could both use but click click here for an example of changing your user agent. I don’t allow the attack to render (for obvious reasons) but you can at least see the demo. Very nasty.

Jason Wood alerted me to this one. Apparently Ferruh Mavituna posted about a new tool he’s created to do XSS tunneling. At first blush it looks a lot like what Jeremiah Grossman built and what Billy Hoffman later re-created for Jikto, except Ferruh’s is in .NET instead of server side scripts. “So what” you say? Well there is one aspect of this that actually is interesting and caught my eye.

He built his tool to be a proxy, so that you could write other third party scanning tools that interface with it. So let’s say you’ve got Nikto, but you want your target to do the work for you. You can plug Nikto into this, use it like a proxy, and poof, the client is now under Nikto’s control, by way of XSS Tunneling, by way of JavaScript running on their browser. Crazy, but cool. Ferruh’s also got a nice writeup and video to go along with it. Very cool stuff!

Over the last several days, Portswigger and I have been going back and forth around something he’s been working on - circumventing proxies using anti-DNS pinning. A lot of users sit behind proxy servers at work. The uses are varied but can be things like content caching or content filtering. The problem is that the client (which does a fairly good job, albeit not great) of preventing anti-DNS pinning attacks is not in control of the DNS in the case of a proxy - the proxy is.

Now you can take a huge leap and guess that the proxy is vulnerable to anti-DNS pinning attacks, and you’d be right. The bad news is, the people who are most vulnerable to this are corporations trying to protect their Intranet! While the host header is still not spoofable, the rest falls into place nicely because proxies often pay attention to the TTL packets instead of restricting it to a user/session (because what does that mean to a proxy anyway)? Portswigger wrote up a nice paper on the topic, and even talked about a few proxies that are vulnerable (the most notable is squid).

He also mentions a few mitigation techniques in the proxy server, or how proxies could even help this issue in some ways (not fix, but help) by caching the TTL for longer than what the DNS server claims it should be. That could cause other problems, of course, but it’s an interesting theory. I have a feeling there is more to come here.