After reading the thread on sla.ckers discussing how to detect which hashing algorithm is being used id and I had a pretty interesting idea. Let’s say you have a password and the hash, but you don’t know which hashing algorithm to run your password file against. That’s especially important before running any sort of time consuming cracking program (less so with time-memory trade off cracking programs like rainbow tables). Anyway, we decided to write a program to help solve this.

If you have the password and the hash, you can input it into hashmaster and get the algorithm used, which can help build a strategy for cracking the entire password file. All that we do is take the plaintext password, apply the various hashing algorithms and compare the results with the hash provided. If they’re the same you have a match. Pretty straight forward. Eventually, we may add optional salts, and many more hashing algorithms and make it more robust. Until then, be gentle.

Okay, whew, I finally got around to building out some demos of some of the things I’ve been talking about and thinking about. I’m not as crazy busy as Jeremiah but I am speaking at the APWG conference, an invite only Malware conference, a local Rotary meeting, the NJ OWASP conference, the SD ISSA conference and the big OWASP/WASC conference in San Jose. So yah, I’m swamped. Don’t expect much posting for a while. But in the mean-time here are two interesting proxy tidbits.

The first is something you may have seen in passing that Jeremiah and I mentioned at our Blackhat conference and our followup podcast. This code (it takes a several seconds to load) uses a piece of JavaScript to instantiate a Java socket call back to the origin site. In doing so it bypasses the proxy settings of the browser, allowing you to de-anonymize people using proxies. It works great for Tor or just about any HTTP proxy that I can think of. Cool stuff.

The next demo is a tiny slice of HTML that simply tries to detect if you are using a HTTP proxy (as an example an Apache proxy using mod_proxy). It works by forceful browsing and then attempting to use the CSS history hack (without JS) to detect if you were able to surf there. By sending the browser to a place that doesn’t exist (http://test/) and creating an error using the %-- trick, I can detect that you were able to visit somewhere that normally can’t exist. Fun!

As a last point, id pointed out to me that we could easily import fierce’s hosts file and quickly enumerate all the possibilities (and probably more) with the JS CSS history hack and possibly get lots of internal address space of anyone who happened to surf intranet sites prior to visiting the hacker’s site. It’s less reliable than port scanning, obviously, but it’s also way less noisy.

That is all.

You know, normally I wouldn’t care less about finding yet another XSS in some retailer site, but in this case I think it’s worth mentioning. There’s a documentary crew doing something on hackers that came to Austin and interviewed several people (not sure when it’s coming out but I’ll probably mention it when it does). Anyway, during the interview I was asked to take a quick look at TJMaxx and sure enough within a few seconds I found this vuln:

Click here then click on the post forwarder as an example.

The ironies here are only obvious once you see TJMaxx’s page which has a huge customer alert on the top of the page. It’s a letter from the CEO of TJMaxx, Carol Meyrowitz:

We remain committed to providing our customers a safe shopping environment as you shop for great values, fashion and brands. TJX has been working diligently with some of the world’s best computer security firms to further enhance our computer security. We have also continued to work with law enforcement and government agencies and very much want to see that the sophisticated cyber criminals who attacked our computer systems are brought to justice.

I can’t comment on who is doing the audit work for TJMaxx as I have no idea, but I’d doubt if I’d call them the best in the world given the current state of the site. Anyhow, the real reason I mention this is I have no evidence whatsoever that TJMaxx has been actually hurt by this event. If you look at the TJMaxx 1 year stock chart not only did they recover from the huge security breach in Feb, but they’re actually up! Clearly, the consumers and the investment community has decided to overlook their issues. Strange.

So perhaps the cost of data security isn’t worth it. I can only count a few pieces of anecdotal evidence where people have said they’d never shop there as a result - then they said that they’d just never use their credit card. So in the end, that works out to be in TJMaxx’s benefit because they don’t have to pay the transaction fees that the credit card companies impose. I don’t have insight into their financials (I guess I could dig up their public earnings statements) but I have a feeling that although this was relatively bad, it was barely a bump in their earnings. Perhaps their settlement cost them a little, but is it really enough to make them fix their holes? Clearly they’re still vulnerable to some things - and without knowing who is doing their security it’s tough to say how good or bad they are. Does this set a bad precedence? Is it that any publicity is good publicity - even if it puts millions of consumers at risk? What a mess!

$30,000 and vulnerabilities to boot! Google’s search appliance appears to be vulnerable to another XSS vulnerability, according to Mustlive’s disclosure. It comes complete with a Google dork. Not good. Mustlive has contacted Google, who to my knowledge has not let their customers know that they are vulnerable - if I’m wrong, someone please correct me.

Here are a few examples: gsa.icann.org and search.york.ac.uk.

This obviously puts any site that uses Google’s search appliance with this particular vulnerability in it at risk (there are, as of this writing 186,000 listings on the Google dork). Time to patch up - once Google comes out with one, that is.

Searching through spam can be fun and annoying all at the same time. I found this beauty in my Wordpress moderation queue and thought it was worth a mention. Here’s a spam URL:

http://search.cnn.com/search?query=site%3Amultisquid.com%20-1995-mercury-outboard-serial-number

If you think about it, it’s a fairly ingenious tactic, using multiple sites to help your SEO. Firstly, they get me to link to a site (typically theirs, but in this case, it’s CNN, who is a trusted domain). Then CNN spits out the results (which would be there if Google hadn’t already nuked this site out of their index). The search engines follow their own results and give them link value. Very clever. No idea if it works or not, but it’s clever.

I was asked to take a look at ThreatSTOP the other day. Although it’s not very clear from the website after signing up I found out the basics. It’s essentially a lot like OpenDNS. In fact, it’s so much like OpenDNS that I actually confused id when I said what it was because he thought that’s what I was talking about. It’s not exactly like OpenDNS - there are a few differences.

First the similarities. They both rely on DNS to protect consumers (not websites) from contacting “bad” sites. They both require that you use their sites to perform the lookups on your behalf. They also share some of the same negatives - bad guys who use IP addresses are unaffected by this mitigation. It’s always reactionary - meaning it won’t block you from going there until it knows it’s bad. And if you’re paranoid, don’t forget that they both get to see every site you intend to contact.

Now for the differences. It appears that OpenDNS has quite a bit of added customization that you can put in front of it - allowing customized blocklists. OpenDNS also uses a block page, which theoretically could see the actual URLs you are going to (since it takes over the DNS for them - rather than simply blocking the request completely). Lastly, and the most import difference between the two: OpenDNS focuses on Phishing and ThreatSTOP focuses on malware infested websites.

Maybe one of the two companies should just buy the other? Not that I use this kind of stuff, but for those who do, it seems like you’d want to be protected from both threats as a consumer, not just one or the other.

If there are any people left who think social networking is a safe place to enter your information I think this is a pretty telling story. Times Online has an interesting article on the latest move by Facebook regarding information that previously was inaccessible to search engines. Guess what? They’re going to make it publically accessible. It’s like people never learn (remind anyone of the AOL search query fun?). Okay - to be fair they said it’s only going to include, “basic details, including names and photographs” available.

I’m not sure I agree that it makes ID theft easier as Keith Reed, of Trend Micro said in the article, but it may make recon easier. I’m not saying that that’s not bad - because it very well may be bad, but it’s not as bad as it definitely could have been. But it’s a slippery slope. This quote caught my eye regarding Chris Kelly, Facebook’s chief privacy officer:

He suggested that internet-users could no longer expect to remain anonymous online, but could control only the amount of information about them that is available on the web.

I’m not going to disagree with the reality of the situation, but is it really okay that a social network takes this stance? Shouldn’t they instead be saying something like, “While we cannot guarantee your privacy, we will do everything in our power to insure our consumers have the highest level of privacy we can provide”? Granted, in the end it’s all about the dollar signs. They need to find a better way to monetize their traffic, and a lot of that means they need more users, they need to use the data they have better, and they need the search engines to start sending them more search engine traffic.

Well it’s getting closer! My friend, PortSwigger (also known as Dafydd Stuttard - author of Burp Suite) is getting ever closer to completion of his new book The Web Application Hacker’s Handbook. He’s co-authoring it with Marcus Pinto. I’ve known about the book for a while now, and am really looking forward to reading it.

He’s also released a table of contents for the book so people can get a head’s up. It looks like a pretty thorough writeup on how to do manual and semi-manual security assessments. It’s going to look nice on my bookshelf - once I get my bookshelf looking nice that is.

Once upon a time the name of the game was buffer overflows. We spent countless hours banging on IDA Pro trying to get some debugger to give us the magical EIP as we smashed on our keyboards for hours. Life was a lot simpler back then - we banged on our own computers, trying to make them crash. We weren’t hurting anyone, and it made sense that we had a disclosure policy that matched that. Rain Forrest Puppy released an epic document called RFPolicy that was designed to solve the problem of responsible disclosure. It allowed the industry time to solve the challenges of patching, while still giving the researcher the credit for their work. The companies were forced to explain what happened when they released their patches, at which point it made sense to credit the researcher. Times have changed.

While RFPolicy is absolutely still practical and useful, even RFP admitted to me that it doesn’t cover the one area a lot of us now work in the most - web server vulns. Unlike hacking your own computer, when you hack a website it’s got all sorts of implications. But here’s the mostly likely worst cases: the owner may do nothing, they may fix it and not tell anyone, or they may decide it’s illegal for you to be finding the vulns and try to prosecute you. None of which are any good for the poor researcher looking to help the website and/or possibly trying to increase their own name brand in doing so.

Along comes RSPolicy (obviously incomplete). In the same vein as RFPolicy I wanted to create something that solved the unique problems that web researchers face, which is that they want either a) to be recognized b) to get the hole fixed or c) both. In any case, they still fear the worst cases as mentioned above. RSPolicy was both a tool and a policy designed to set timeframes within which exploits should reasonably, in a worst case, be fixed. Additionally, I was going to build a tool (essentially an anonymous one-directional webmail) to prevent the companies from knowing who was reporting the vuln as to prevent prosecution in the worst case.

The goal was to get companies to agree to the RSPolicy, and throw up a page, explaining at a high level who found the hole, what it was, and potentially dates that it was found and closed. It all seemed like a lofty goal. Now I needed to get a few big companies to agree to timeframes. Here’s where it got ugly.

In order to protect the companies I picked I’m not going to use their names here, but trust me, you’ve heard of the companies. I picked them because they were huge, and they have these problems all the time. That means that they aren’t quick on their feet, which is perfect since I was really looking for a worst case anyway. Alas, one of the companies was unwilling to put limits on anything - fearing reprisal or even lawsuits from their customers. Another company felt the impact of this would be pretty massive to their ability to be able to fix flaws (in a good way) but never bought off on verbiage and also never put a line in the sand. Then I started talking to people in the industry.

I spoke with RFP, of course, and I didn’t get the feeling he felt it was providing enough of a mechanism. I spoke with a few others who felt that people wouldn’t adopt the tool portion (which I don’t care about but it’s a good point). And when it came down to it the major beef I heard was that it actually wasn’t a policy, so much as a moving line in the sand that was ill defined. I agree. And henceforth I have given up on the project. While a noble goal, I think I’m just exhausted by the concept. The companies have all completely dropped the ball at this point, despite the fact all three have had vulnerabilities found in their sites within the last month that I am personally aware of. So despite the ball dropping the problem hasn’t gone away.

I’m not looking for the community to pick up where I left off - that’s not my goal. My goal at this point is just to let everyone know that perhaps there is an alternative out there, and there is no reason you cannot make up your own policy at any time that makes sense for whatever application you need it for. I chose RSPolicy because I thought it fit a need. Perhaps it will for some, but I’m not going to build the tool, host it, or work on RSPolicy anymore, which is why it is in the state is (incomplete). The companies mentioned who read this (and they all do) all continue to have the opportunity to work with the community however they see fit - I’m just not going to facilitate.

Mike sent over an interesting blog post by David Ross pointing to a new paper he and some colleagues at Microsoft wrote about a new concept they call Script Accenting. This is a concept designed to stop a lot of new browser exploits (the type that Michal Zalewski, mikx and http-equiv for those of you who remember those names used to find). While all or most of the known attacks have been fixed there are probably untold left to find and that is what this is intending to fix (not XSS though, for those who are curious).

It’s an interesting concept but being the hacker type the first thing that struck me was this paragraph on how the accent is generated:

XOR-based randomizations are frequently used in security defenses. Our current implementation also uses XOR as the primitive operation for accenting: we generate a 32-bit random number (four-bytes) as the accent key for each domain. The primitive operation to accent a text string is to XOR every 32-bit word in the string with the accent key. When there are one, two or three bytes remaining in the tail of the string, we mask the accent key to the same length, and apply the XOR operation. This accenting operation has two clear advantages: (1) it guarantees that the accented script or any portion of the script is illegible to other domains, regardless of how the script travels; (2) the operation does not increase the length of the script, so the existing browser code can correctly handle the accented script without the possibility of buffer overflow. This is important for the transparency of our mechanism.

Okay, so all we need to do is guess a four byte word, look for some errors and poof, we’re good, right? Well, not so fast, they too have thought of that problem!

Although the above probing attack seems plausible at the first glance, it is not effective for two reasons. First, we observe that scripts in IE are always represented using wide-characters, which means the string “//” is already four-byte long. It requires 256^4 attempts to guess. More fundamentally, even for a browser not using the wide-character representation, the attack still lacks an important prerequisite – there is no way for the attacker frame to detect a syntax error in the victim frame, because the two frames are in different domains. In other words, for the probing attack to succeed, the attacker frame already needs the capability to communicate with the victim frame (e.g., through the onerror method of the victim frame), but such a prerequisite is exactly the domain-isolation violation that the attacker tries to achieve. This is a cyclical cause-and-effect situation. Therefore, the XOR-probing is not a real concern of the accenting mechanism.

I’m not sure I agree with this statement actually. Sure, that’s one way to do it, but generating 256^4 scripts isn’t impossible either (especially if you create and destroy them). Oh, sure, it might take a year, but you can do it. Once they succeed you know it and get the results back and poof, you’re good. Also, In some cases you can actually get data back from other domains (in Firefox at least). Look at the Firefox login checker for instance. While yes, that’s against Firefox only, these bugs tend to happen a lot, and there are countless interesting ways to get at least some amount of data back from other domains through history, the status bar, referers, timing attacks, onload event handlers, etc….

I’m not saying it’s broken, or that the techniques to break it are easy or even possible given current computational boundies, but it feels like the lightweight nature of that is to it’s own detriment, when a longer key might actually solve it in any way that would be computationally possible with modern computing (save turning the Storm worm’s 50MM hacked machines into the largest script accent breaking machine known to man - just before it becomes self aware and kills us all). Breaking a 10 char string is way harder computationally than a 4 char for instance. Perhaps there are more performance concerns though. But for once I don’t see really any major gotchas. It looks like a pretty clean way to solve lots of the browser cross domain hacking issues out there. Sure there will still be vulns, but they’ll have to obey yet another rule. Now, onto XSS!