I’m really sorry I haven’t posted in the last few days. Believe it or not, it’s for a good cause. I’ve been very busy writing a new domain scanner called Fierce. I was performing an audit a few weeks ago and I realized that it was taking me a long time to uncover hosts that I needed to perform audits on. I was using all sorts of tactics but it was still taking a long time (almost a day just to find 4 hosts that could have been interesting and only one of them turned out to be). The hosts were no where near each other physically or in terms of IP space, rendering tools like nmap and unicornscan nearly useless. That frustrating experience in web application security auditing forced me to write a perl scanner named Fierce.

Some of you will remember that I wrote a tool to uncover “internal.company.name” and “intranet.company.name” servers in the Alexa top 100. Well that was interesting, but it was only a precursor to Fierce. Fierce takes that same idea and magnifies it to over 300 requests. Further when it finds something on an IP it attempts to traverse up and down that IP range (within the class C) looking for other hosts that match your domain of interest using reverse DNS (or a supplemental pattern match that I added on top of it).

As a result, in just a few minutes of scanning you can uncover hundreds of hosts that are normally either not publically known or even route-able for that matter and that may be on completely separate networks. It’s actually very fast for a scanner, because it doesn’t actually try to connect to any of the machines in question, it only queries your DNS server and the DNS server of the target.

Click here to find out more about Fierce. There are a few other tools out there that attempt to do some things like this, but I wrote this because I found it to be far more effective at initial discovery (this is sort of a modern day version of host -l for those of you who were around in the early days when no one understood security). This is obviously a beta and will obviously miss stuff given how it works, but I plan on making it a lot more robust and I plan on adding a few more tests that I think will yield a lot more interesting results in the future. Questions and comments are welcome.

Happy new years, everyone!

Jeremiah sent me a link today about how the DoD has now completely banned the use of web-based email, like Outlook Web Access. Jeremiah asked the very scary question, “did we cause this?” Is our hubris out of control or are people listening. Unfortunately the wording was so vague it’s tough to tell for sure, but this quote is pretty telling:

“The JTF-GNO mandated use of plain text e-mail because HTML messages pose a threat to DOD because HTML text can be infected with spyware and, in some cases, executable code that could enable intruders to gain access to DOD networks, the JTF-GNO spokesman said. “

At first I thought that this could be just about anything, including spyware or some sort of Trojan that gives access to the internal network, but that is not specific to HTML emails. That means that the government has seen what we are doing and is now taking precautions to protect themselves from XSS malware. Good for them! It’s about time we start seeing people take this threat seriously. The impact is pretty massive for approximately 4300 troops who rely on web based email, but allowing your intranet to be compromised through JavaScript malware is completely unacceptable.

I for one am impressed! Not just that they took the precaution but that people are now really getting it. Clearly they know the value of security and take it seriously. This is a great gauge of how dangerous an issue DHTML malware really is.

If you don’t remember who Richard Stiennon is, think back to a few years ago and see if you can remember the words, “IDSs are dead”. Ring a bell? He is an analyst at Gartner focusing on security. I met him several years ago, although I’m sure he would have no idea who I am now, even though I accurately predicted the rise of the event correlation (SIM) services. Well, I found his blog almost by accident today and his most recent post actually turned out to be fairly interesting. He wrote about the top 10 threats for 2007. He was a little scattered in the topics he went into but most of them were pretty interesting to discuss. Here are some of my thoughts:

His second and third prediction is that DDoS in support of Phishing and fraud will become a big deal in 2007. I really don’t see this one happening. I get what he’s saying, but DDoS is noisy, and doesn’t actually aid in phishing. Plus if the bad guys have compromised servers why not use them for more phishing, which is far more lucrative than shutting down a server (except in the random cases of extortion - “pay me $10k and I’ll let your server come back up”). I just don’t believe this is happening all that often. They bad guys can make $10k per phishing incident. It’s way more scalable to stick to phishing. I only know of two cases where DDoS extortion has happened, and both of them were online casinos.

He suggests in his fourth bullet that DNS will be a huge target over the coming year. Maybe. It’s hard to say, especially since it’s far easier to let it work for you in the case of XSS malware. I’m not sure I agree with this since there are easier ways to attack a target. But you never know. I also thought pharming would never be a big deal when everyone was hyping that one up and… er… no wait, it never was.

His seventh bullet talks about MySpace having to grow up and become more secure like the rest of their competitors. I don’t know that I agree that this is the 7th largest threat in 2007 (shutting down one community site) but I think the ramifications of why this is happening is easily within the top 10. He’s got a good point here. I think something that we have not spent enough time thinking about is the downstream impact of these types of issues to large businesses. Could a few XSS holes literally shut down a billion dollar company? That’s a big deal.

Number eight is also about XSS although Richard doesn’t mention the word. He talks about backdooring media files (pdp’s backdooring quicktime files and Mp3 files, no doubt) as well as spam advertising inside of the movie files. I would hardly call this the eight biggest threat on the Internet, because the files can be scanned for the backdoor and who cares if there is a little spam. It’s not a big threat to the Internet. So, unfortunately I think he’s way off on this one.

Number nine is about how the global network infrastructure is showing signs of strain under the new heavy weight content of the dynamic internet. I doubt this really will mean much to anyone other than more use of content delivery networks as well as additional money for the carriers who lay fiber (which was his comment).

His number ten threat is that Vista isn’t going to do anything in terms of Security. Well, that’s probably true, but that’s not a new threat, that’s just not an increase in security to match the increase in level of attacks against the new platform. But who wants to go after desktop machines when everyone is putting their information online anyway? That’s where the real money is. The only reason people go after home computers these days is to install keyloggers and turn them into spam/phishing machines. Also, the bigger issue is that everything is becoming web enabled. Alas, we’re going to see a lot more high profile information disclosures next year is my prediction. So I think he had the right idea, but he didn’t take it to the next obvious place.

I don’t mean to put Richard down here - he’s a very bright guy. Unfortunately, I think this year he spent too much time talking to a few people who didn’t have their pulse on the real issues. No doubt 2007 will be interesting though. I’m looking forward to it.

Despite all the damage that Jeremiah and some of the other web application security people and I have done to web security over the last year, there has been some good. Not a lot but some. We’ve already talked about the top 10 worst web application security hacks this year (and it was a huge pain to narrow it down to 10, let me tell you) but it’s hard to come up with even ten good things that have happened this year for web application security. Let me outline what I think are the best things that have happened. But instead of coming up with a contrived list of 10, I’m going to list everything I can think of that actually impressed me about web application security over the last year - which was only 7 things). Don’t fear, I’ll break every one of them along the way.

1) Internet Explorer 7.0 and Firefox 2.0 finally got anti-phishing installed on their browsers by default. This was a huge win for consumers because it finally gave them an out of the box tool. No more would they have to know enough to download some tool to protect themselves. Only problem is it doesn’t work very well. We’ve found many ways around each of these tools. But at least they’re trying! And with upwards of 90% of the market share collectively between the two browsers, that’s a big dent - even with the holes.

2) Internet Explorer 7.0 closed down the JavaScript directive inside of image tag cross site scripting issue. That was one of the most annoying vectors out there. Images should not be a place for JavaScript, they should be a place for images. Nevertheless, Internet Explorer has finally fixed this issue. They also fixed one of the more esoteric things like variable width encoding in US-ASCII and UTF-8, which can lead to people being able to run JavaScript while the application thinks they aren’t even inside of an HTML tag. However, we are a long ways from done patching XSS holes, but hey, huge props to MS for fixing those issues. It brings them to a far more level playing field in terms of XSS with the other browsers. There’s no clear winner in the XSS browser wars at this point.

3) Stanford released their Safehistory Firefox plugin. This was an answer to Jeremiah’s question about do you feel safe allowing anyone to see your history. I know I don’t, so I went ahead and installed it and it worked great. Yah, but it turns out you don’t need to use CSS in this way do steal someone’s history. Not to mention the obvious looking at the referrer and other simple hacks. But whatever, Stanford is trying their best.

4) Another plugin was released to emulate Microsoft’s HTTPOnly inside Firefox. Great idea, Microsoft! I just wish Firefox would make this standard. But never fear, it’s breakable anyway, via XMLHttpRequest - but we knew that years ago when I believe Thor Larholm originally discussed this. Hey, at least it will slow the bad guys down a little.

5) There have been several tools released for developers including Microsoft’s .NET security framework. I took a look at it and wow, it works! I wonder how many people will go back and fix all their applications to use it. And furthermore I wonder how many developers use .NET. Hmm… this one might take a while to take affect.

6) Let’s also not forget HTML Purifier. It’s some of the best code I’ve seen to date to stop XSS. Unfortunately, it can’t protect you against server level hacks, like the Expect vulnerability, or DOM based XSS, or anti-DNS Pinning, the unpatched mhtml issue or other crazy XSS issues. But we have to start somewhere right?

7) Apache closed the Expect vulnerability. Yes, I know I just mentioned it in #6, but that was a big win. Previously all new installs of Apache would be vulnerable to the Expect vulnerability. No more. All future installs should be safe. But that does leave several million old and vulnerable installs out there…

So although I wouldn’t call this year a stunning success in terms of the security community making leaps and bounds over their adversaries, there was some good that came out of this year. Don’t let anyone tell you otherwise. But no, seriously, we did a lot more damage this year than I think has ever been done to internet security (at least within the last 4-5 years). Hopefully there will be some new tools and tactics over the coming year to close down some of the more dangerous emerging security issues out there.

I’ve been toying with Intranet hacking for a few years now, and I’ve always though there were more creative ways to do that. One of which was by using JavaScript. Another that is less sexy but no doubt dangerous is direct brute force. One of the major issues with Intranets is that companies don’t realize they need both an internal and an external DNS resolver. One for the public and one to hide the true IP address of their intranet applications. The obvious Intranet application that most companies have is an Intranet page. Usually it links the user to all the other wonderful applications that the company hosts.

Okay, well that’s great, so it would seem that the Intranet isn’t that interesting if it’s only got a bunch of links. Well that’s probably true except that knowing the links and knowing that the DNS resolver works for internal applications as well as external means that once you know the name you can start finding a lot more interesting websites on the internal site. Okay, so where do we find some vulnerable sites? Easy enough, let the Internet do some work for you. Let’s start with a big list of sites (the Alexa 500 will do). Now let’s scrape them and do a DNS lookup on each one looking for a few common key words “intranet” and “internal”. Now let’s do a reverse lookup and see what their IP address is. And here’s our list:

10.0.1.10 intranet.godaddy.com
10.1.119.43 intranet.dyndns.org
10.210.136.22 internal.iask.com
10.25.0.31 intranet.joyo.com
10.30.100.238 intranet.shopping.com
10.50.11.131 intranet.monster.com
125.206.202.66 internal.hatena.ne.jp
125.206.202.66 intranet.hatena.ne.jp
192.168.11.6 internal.zhaopin.com
192.168.11.6 intranet.zhaopin.com
194.60.206.60 internal.facebox.com
194.60.206.60 intranet.facebox.com
200.225.157.127 intranet.ig.com.br
200.5.80.58 intranet.terra.com.ar
202.106.185.73 internal.126.com
202.106.185.73 intranet.126.com
202.108.253.57 internal.soufun.com
202.108.253.57 intranet.soufun.com
202.45.130.127 intranet.jobsdb.com
202.84.5.80 intranet.china.com
202.99.16.9 intranet.homeway.com.cn
204.9.178.60 internal.typepad.com
204.9.178.60 intranet.typepad.com
207.106.239.74 internal.aweber.com
207.106.239.74 intranet.aweber.com
207.46.78.170 internal.msn.co.jp
207.46.78.170 internal.msn.com.cn
207.46.78.170 internal.msn.com.tw
207.46.78.170 intranet.msn.co.jp
207.46.78.170 intranet.msn.com.cn
207.46.78.170 intranet.msn.com.tw
207.7.149.50 internal.bebo.com
207.7.149.50 intranet.bebo.com
208.66.64.173 intranet.technorati.com
209.183.200.52 intranet.freewebs.com
209.202.226.100 internal.tripod.com
209.202.226.100 intranet.tripod.com
209.8.50.54 internal.yousendit.com
209.8.50.54 intranet.yousendit.com
210.150.29.30 internal.exblog.jp
210.150.29.30 intranet.exblog.jp
211.100.6.30 internal.readnovel.com
211.100.6.30 intranet.readnovel.com
211.147.3.81 internal.it168.com
211.147.3.81 intranet.it168.com
211.151.252.189 internal.chinahr.com
211.151.252.189 intranet.chinahr.com
211.72.254.4 internal.yam.com
211.72.254.4 intranet.yam.com
212.126.20.1 internal.o2.pl
212.126.20.1 intranet.o2.pl
212.129.63.216 intranet.skyblog.com
212.129.63.231 internal.skyblog.com
212.31.2.5 intranet.hurriyet.com.tr
213.13.145.10 internal.sapo.pt
213.13.145.10 intranet.sapo.pt
213.136.52.34 intranet.mysql.com
213.180.193.24 internal.yandex.ru
213.180.193.24 intranet.yandex.ru
213.180.199.20 internal.narod.ru
213.180.199.61 intranet.narod.ru
213.54.164.169 internal.dyndns.org
216.128.27.100 internal.w3schools.com
216.128.27.100 intranet.w3schools.com
216.234.234.222 intranet.theplanet.com
217.148.176.63 internal.usercash.com
217.148.176.63 intranet.usercash.com
217.74.65.234 intranet.dev.interia.pl
218.244.111.214 internal.ctrip.com
218.30.64.121 internal.vnet.cn
218.30.64.121 intranet.vnet.cn
218.77.130.71 internal.tianya.cn
218.77.130.71 intranet.tianya.cn
218.93.205.59 internal.onlinedown.net
218.93.205.59 intranet.onlinedown.net
219.239.88.110 internal.yesky.com
219.239.88.110 intranet.yesky.com
219.239.94.46 internal.it.com.cn
219.239.94.46 intranet.it.com.cn
220.170.88.225 internal.mofile.com
220.170.88.225 intranet.mofile.com
222.185.229.78 internal.skycn.com
222.185.229.78 intranet.skycn.com
222.88.88.133 internal.51.la
222.88.88.133 intranet.51.la
38.118.213.25 intranet.filefront.com
59.106.28.143 intranet.seesaa.net
59.106.28.144 internal.seesaa.net
59.151.40.9 internal.wangyou.com
59.151.40.9 intranet.wangyou.com
59.188.4.76 internal.uwants.com
59.188.4.76 intranet.uwants.com
60.190.31.51 internal.51.com
60.190.31.51 intranet.51.com
60.191.254.47 internal.blogchina.com
60.191.254.49 intranet.blogchina.com
60.191.72.130 internal.5show.com
60.191.72.130 intranet.5show.com
61.129.48.152 internal.51job.com
61.135.134.206 intranet.focus.cn
61.135.134.216 internal.focus.cn
61.137.93.45 internal.5460.net
61.137.93.45 intranet.5460.net
61.151.243.133 internal.china.com
61.152.249.35 internal.1ting.com
61.152.249.35 intranet.1ting.com
61.31.193.111 internal.webs-tv.net
61.61.133.2 internal.twbbs.net.tw
61.61.133.2 intranet.twbbs.net.tw
62.129.129.27 internal.payserve.com
62.129.129.27 intranet.payserve.com
63.166.3.19 internal.wenxuecity.com
63.166.3.19 intranet.wenxuecity.com
63.236.2.233 internal.89.com
63.236.2.233 intranet.89.com
63.245.209.41 dyna-intranet.nslb.sj.mozilla.com
64.124.63.70 internal.piczo.com
64.124.63.70 intranet.piczo.com
64.255.170.250 internal.wannawatch.com
64.255.170.250 intranet.wannawatch.com
64.56.205.72 internal.adultfriendfinder.com
64.56.205.72 intranet.adultfriendfinder.com
64.72.113.224 intranet.badongo.com
64.72.113.227 internal.badongo.com
65.64.83.190 internal.warriorforum.com
65.64.83.190 intranet.warriorforum.com
66.11.50.5 intranet.photobucket.com
66.11.54.5 internal.photobucket.com
66.152.91.81 internal.pornaccess.com
66.152.91.81 intranet.pornaccess.com
66.230.171.162 internal.xnxx.com
66.230.171.162 intranet.xnxx.com
66.246.179.201 intranet.multiply.com
66.246.179.202 internal.multiply.com
66.28.245.123 intranet.hi5.com
66.35.250.151 internal.slashdot.org
66.35.250.151 intranet.slashdot.org
69.20.16.232 internal.sitepoint.com
69.20.16.232 intranet.sitepoint.com
69.28.181.43 internal.deviantart.com
69.28.181.43 intranet.deviantart.com
69.36.233.10 internal.stumbleupon.com
69.36.233.10 intranet.stumbleupon.com
69.5.88.75 internal.megarotic.com
69.5.88.75 internal.megaupload.com
69.5.88.75 internal.sexuploader.com
69.5.88.75 intranet.megarotic.com
69.5.88.75 intranet.megaupload.com
69.5.88.75 intranet.sexuploader.com
69.59.144.138 internal.kooora.com
69.59.144.138 intranet.kooora.com
72.232.170.2 internal.4shared.com
72.232.170.2 intranet.4shared.com
72.232.72.218 internal.minijuegos.com
72.232.72.218 intranet.minijuegos.com
72.32.5.117 internal.break.com
72.32.5.117 intranet.break.com
8.10.160.60 internal.met-art.com
8.10.160.60 intranet.met-art.com
81.19.66.173 intranet.rambler.ru
88.212.196.65 internal.liveinternet.ru
88.212.196.65 intranet.liveinternet.ru

(Note: you aren’t seeing redundant listings, they actually have different names “internal” and “intranet” even though they point to the same IP). Wow… I thought I’d find one or two, but 162 examples in the Alexa 500 alone! The ones with non-routable IP space like the 10.* and 192.168.* ones may still be interesting for anti-DNS pinning but let’s ignore them for this conversation.

Now what are the chances all of those sites have secured their Intranets? Specifically how many do you think would shut down access to brute force attempts? We already know the usernames for those accounts, because they are almost always the NT domain usernames. Where would we find NT usernames out on the Internet? Well thankfully search engines have done the work for us here as they are almost always the same names as any public email addresses from those companies. IE: username@company.com is almost always the same as the NTDomain. Using this we can now brute force the Intranet website, with relative ease.

A few days ago Kanatoko found a vulnerability in the DNS pinning used withing modern web browsers that can be exploited by simply shutting down an open port. This is far easier than the previous technique of closing the connection using a firewall. Very tricky. Kanatoko also pointed to another issue disclosed on bugzilla as well regarding another anti DNS pinning technique.

To paraphrase the user connects to my machine which has an IP address of 123.123.123.123. I use a Dynamic DNS server that tells the world that mydomain.dyndns.com is located at 123.123.123.123. When my DHCP lease expires I move to another IP, dyndns.com points to it and the rest of the world can now find me. The one poor sap that was on my page already and has DNS pinned my IP address will now submit their content to whomever takes over my IP address next, assuming they do so before the user is finished submitting the form (otherwise their DNS cache will flush and they’ll move on).

This is a tricky way for DynDNS users and other dynamic DNS users to compromise information from other servers. Of course it relies on the person who had your DNS entry before you a) having a webserver with forms and b) having traffic you’d want to compromise (since this is blind there’s no way to know ahead of time if you are interested in that traffic). Normally this wouldn’t be a problem for most websites because they don’t use this sort of DNS hacking, but it does point to some major flaws in how DNS is implemented and not necessarily just another browser flaw, as Kanatoko pointed out. Great find!

I laughed out loud when I read this. Kuza55 found another issue in MySpace again today using the exact same exploit that we have been trying to get them to close FOUR separate times now. Click here to read about the XSS hole last time if you don’t recall what I’m talking about.

Anyway, this is the exact same non-alpha-non-digit issue that they have faced numerous times before. Only this time they got exploited through a different issue they caused for themselves. Remember how I’ve said a number of times don’t strip content unless you really know what you’re doing? Well they don’t really know what they are doing (if you aren’t using a while loop you are already in trouble). In this case, they stripped out moz-binding (the Firefox CSS issue) and replaced it with “..”. Wellll if you make your vector look like onloadmoz-binding= and it gets replaced with “..” you get onload..= which still works in Firefox.

Kuza55 said it best… you really have to wonder what these MySpace developers are thinking right about now. Anyway, this is why you should never ever strip or change HTML input unless you know how HTML works in different browsers, lest you get hit with the same issue 4 times. Nice job Kuza55!

The site is down now, but I got yet another phishing email using Google redirection to hide the real address that the user is being forwarded to. Sorry for the super long line (had to break it up): http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5Q-
fXBJGSiQLU0eDSAueHkArnhtWZAu-FmQWgjlkQAxgFKAg4AEDKEUiFOVD-
4r2f-P____8BoAGyqor_A8gBAZUCCapCCqkCxU7NLQH0sz4&num=
5&adurl=http://211.240.79.30:2006/www.paypal.com/webscrr/index.php

Google has been notoriously bad about fixing these issues, even after admitting a few times that it was an issue. As a matter of fact I don’t know of a single example of where they really have fixed these issues at all, other than blocking a single URL. Not a great track record. The reason being it’s far too difficult to fix them than to leave them there, even if it hurts their consumers, and their own brand in the process. Anything for a buck, I guess.

Whelp, we sorta missed this one, because, well, it wasn’t announced to us… but it turns out that Firefox had a lot of issues that were kept tight lipped until they could release a patch. Probably the most interesting to me was CVE-2006-6503 which still has the details hidden from view on bugzilla and the name of the person who reported it is masked as “moz_bug_r_a4″.

From what I can gather from the various sites apparently if you have an image inside of an iframe you can change the img.src attribute to be a javascript: directive thereby bypassing their internal XSS filters. Interesting. Of course I always try to keep an out of date version of a browser around for a few days, so if anyone can think of how this exploit worked, I’d be curious to know how, just from a research perspective.

I’ve got to tell you, I’m not thrilled by their non full-disclosure policy. I thought open source was supposed to be just that. One of the major advantages of an open sourced browser is that I know everything that’s going on with it. Telling me to “turn of JavaScript” is not enough information for me personally. So there went one of the major advantages for me. I’d be curious to hear other people’s thoughts.

This link probably won’t work in another week or so, but according to their website the open relay database is shutting down. This is an interesting turn of events. Their reasoning is that people who are running it have found other things to do and that the spammers have changed tactics. There may be some logic fallacy here, let’s think about this for a second.

First of all one of the reasons spammers changed tactics was because it was no longer as effective as it was before. That was due in large part to companies getting on blacklists because they had open relays that they didn’t even know about. So the problem was sort of fixing itself, leaving the spammers with fewer and fewer relays. That did, in fact, make the spammers change tactics. That doesn’t mean that the problem will stay fixed though. Let’s think about how companies use ORDB: when a mail is sent the server does a DNS lookup against relays.ordb.org with the IP prepended to it, if it comes back as a positive, it means the host is a relay and it shouldn’t send the email.

Now that the open relay database is gone, there are a few funky things that could happen. 1) You could see a delay in processing time with a lot of mail servers that rely on the ORDB domain being up to check their blacklist. Since the server is no longer up, and the DNS entries are going away the lookup will have to fail before it works. Postmasters, it’s time to upgrade. 2) You may start seeing a sharp rise in the amount of relays out in the world, allowing the spammers to move back to their old tactics. 3) The ORDB guys “recommend a combination involving greylisting and content-based analysis (such as the dspam project, bmf or Spam Assassin).” Until that happens you may also see an increase in spam while the postmasters upgrade their systems.

Yes, the ORDB was sort of outdated technology, but that doesn’t mean it wasn’t needed. However, only time will tell what the full impact will be.