Trev built a test utility based off of the mhtml vulnerability the other day and I just got to thinking. It would be far more useful if this were built more as a framework instead of being just a stand alone file on a server somewhere. So, I went ahead and built one. You still need to call it from the server (not from a remote server) so to exploit this remotely you’d have to call an iframe to an html file (sample included) that instantiates the exploitation using the CGI script I included.

Clear as mud? Download it here. The CGI is pretty easy to read, the only trick is that it has to call itself three different times - once to get the JavaScript framework and twice more for the redirection. Using this makes exploitation of the MSIE mhtml vulnerability far easier. It still requires that you have CGI access on some site somewhere, and it also allows for a pretty serious redirection hole (I built optional restrictions into it if you like, but I turned it off by default).

For those of you who aren’t aware of what the mhtml bug is, it allows an attacker to force your browser to any other site (through redirection) and using the mhtml protocol with a redirection it allows the attacker to read the page as your browser would - complete cross domain leakage in MSIE 6.0 and 7.0 (due to a plugin with Outlook). Hopefully this is a good demonstration about how dangerous this bug is, because I think it’s been mostly conceptual up to this point. Thanks again to Trev for his demonstration - he definitely did the bulk of the work that this is based off of.

Today I was doing a little research and I happened across a site that displayed it’s phpinfo() function. I wasn’t even sure what I was looking at at first because it was just such an insane wealth of reconnaissance information on the server in question that I just couldn’t believe my eyes. It’s my new favorite amusing Google Dork: intitle:phpinfo() inurl:com

Let’s take an example, like ns7.webmasters.com. What can we derive out of looking at their phpinfo? Where should we start?

• Compile time configuration information. So if I wanted to know configuration options for PHP, I’ve pretty much got that at my disposal, not to mention path information. Bummer.
  
• Register_globals is apparently turned on - lucky for us.
  
• libcurl/7.15.1 OpenSSL 0.9.8a 11 Oct 2005 zlib/1.2.2 libidn/0.5.18 - lots of outdated software.
  
• Hashing engines - at least we don’t have to muddle around and guess how data is hashed too much once we do break in
  
• ImageMagick 5.5.7 - another outdated version, love it.
  
• pfpro.defaulthost test-payflow.verisign.com - could be interesting if we can compromise the DNS, but it’s only a test. This could be more interesting on a production machine.
  
• libTidy Release 1 September 2005 - more outdated software.
  
• Apache/1.3.34 Ben-SSL/1.57 (Unix) mod_gzip/1.3.26.1a mod_fastcgi/2.4.2 mod_throttle/3.1.2 Chili!Soft-ASP/3.6.2 FrontPage/5.0.2.2635 mod_perl/1.29 PHP/4.4.2 - hmmm… vulnerable to the expect XSS issue among other issues.

Why would you ever put something like this on your server, and more importantly why would you ever allow a search engine to spider it? These sorts of information disclosure issues can really hurt companies, and unfortunately it’s trivial to find them (less so on targeted servers, but for un-targeted worms this is great recon). Scary.

One of my very first programming assignments in one of my very first real jobs was to parse apart address information to shove into a database. Previously the address field had been textarea where the user could input whatever they felt like - there was no error checking of any kind. That seems bad but it’s actually worse for the user because they wouldn’t get paid if they didn’t put a valid address in there. So the problems were kept at a minimum. But when I mean minimum, I mean of the 10,000 addresses we had on file about 10% (1,000) of them had issues of some kind.

It might sound like a trivial task, but in reality it just wasn’t. First of all international addresses look nothing like US addresses, and in many countries (especially at that time) there was no online validation engine to validate that zipcodes (if the country even used them) were valid. Further, you had mis-spellings, incorrect formatting, and plain old typos where people entered nothing or completely erroneous data.

Think about an email address. It seems simple enough, but there are only two good ways to validate that it’s in the correct format - regex and emailing the user and seeing if they get it or not. Let’s look at what something as simple as an email address regex might look like:

/^\s*\d*\s+(([A-Z0-9]+[._]?){1,}[A-Z0-9]+\@(([A-Z0-9]+[-]?){1,}[A-Z0-9]+\.){1,}[A-Z]{2,4})\s*$/i

If something as complex as that regex is required to validate the informational structure of something as simple as an email address think about what it would take to look at the unstructured data of an address field, or something even more complex as a chunk of HTML. In the case of HTML it’s not necessarily just an exercise of identifying valid HTML but of identifying it’s intent. It just struck me in looking at the above regex, that people who try to protect against JavaScript injection while still allowing HTML in regex (especially people who can’t effectively read/write regex) are pretty doomed.

Alf sent me a very interesting link today that pretty much validates a lot of the fears I’ve had about the potential of XSS in the underground. This link is to an XSS clearinghouse. It’s in German, but you can probably get the idea. The users go to the site and get to see some XSS for free and others they have to contact the person who found the vulnerabilities. Not only that but it comes side by side with a Google Page Rank indicator to let you know how valuable the link is if you are into blackhat SEO.

This is probably nowhere near as dangerous as what it could be used for (redirecting a user or building a link farm out of high PR sites here or there is thankfully one of the least malicious things you could do). However the potential for using this for far more malicious purposes is highly likely in the not too distant future. I’ve already been asked about people trying to sell exploits so it’s not like we are years away from this or anything. Pretty scary.

A while ago I ran across someone who was claiming that if you enter your pin backwards in an ATM it will still allow you to withdraw money, however, it also calls the police. The theory is that if someone has a gun to my head it doesn’t look like I’m messing with the robber by allowing me to withdraw money but still alerts the police to the threat. I’m not sure if I believe that story is true (it would be a pain to be a dyslexic - or to have the numeric equivalent of a palindrome - IE: 4334). But it is an interesting story.

But it does bring up an interesting idea - why not allow consumers to enter a pin number/password to only be used in emergency situations? ATMs are not the only place where you could get robbed. It’s entirely possible that someone may break into my home and put a gun to my head telling me to do an online bank transfer. Having a safety number to type in would be pretty handy in that situation - to alert the police to my presence (my IP I suppose) or at minimum alert the bank that the transfer may be fraudulent.

Further, if you happen to be the type who writes their passwords on sticky notes, you could write one of the safety numbers down so that if anyone ever used it without my being there, I would be protected. Interesting idea anyway.

I was wondering how long it would take for someone to make the suggestion, and a few days ago it finally happened - someone made the suggestion that I write a book on XSS. The idea would be to write a book that anyone could pick up and use as a reference to understand and combat XSS attacks. Whelp, as it turns out, I’ve been doing just that for months now. Yup, the people on the forum outed us.

Several months ago Syngress Publishing asked a few people to help contribute to a book on XSS. The contributing authors are Jeremiah Grossman, Anton Rager, Seth Fogie and yours truly. We are still several months away from completing the book, but we are well on our way. Sorry I didn’t tell you all earlier, but I was just finally allowed to start talking about it.

I’ll let you all know as the date gets closer. But if I’m not super quick on the posts and answering email, that’s part of what’s going on - too many irons in the fire these days!

A month or so ago I was contracted to do a black box security assessment for a company. I was pretty crippled in the type of assessment I was allowed to do - no network scans, no DoS, no OS/router/switch/firewall hacking, etc… The company just wanted a straight black box web application security assessment. I began to find many security issues, but almost all of them were either low or medium severity. Finally the issues began to compound into an very serious opportunity to compromise the website.

This prompted me to write a case-study that I called Death by 1000 Cuts of how a series of what is normally considered minor (information disclosure issues) to medium level (things like XSS) security flaws turned into a nasty issue that was allowed me to gain a level of access that absolutely should not have been allowed.

Long term I’ll probably turn this into a talk, but adding a lot of other elements about how this could go much further, given other issues upon further review, including intranet scanning. But for now I thought I’d share it so everyone can see how it occurred. This is a good lesson to companies who balk at lower level security issues and could prove to be a useful tool to help them recognize why they must close as many security issues as possible, no matter how small.

I spent the better part of my free time for today putting together a rather sophisticated search engine result page arbitrage tool. No, I won’t release this one. Partly because it sucks, partly because it requires that I allow other companies to run JavaScript on my domain, partly because it requires redirection, and partly because it’s easy enough that anyone with enough skill could do it themselves anyway. The point is I did it as a demonstration for a potential client, and there are some lessons learned. This is pretty nasty tool for blackhat SEO/SEM types.

If you don’t know what I’m talking about, it was an old trick I talked about revisiting, which is making the back button on browsers change functionality (popups or redirection to other sites). Only my version actually mimics the search engine the user came from.

1) The arbitrager must understand that the user is coming from a search engine. There is more than one search engine. So they must code for each one that they want to steal traffic from. This alone can be a bit of a nightmare.

2) The traffic arbitrager must detect which links the user has already been to so to make sure that if they are to click on those links again they end up on the page they meant to go to. This will make it fare less likely that the user will notice the trick. This is harder than it sounds because each site has a different style for the a:visited tag. And btw, case matters if there are any letters in the color (EG: 4e4e4e is different than 4E4E4E4E).

3) The site must take into account crazy JavaScript and Style sheets that all the search engines SERPs add to each of their pages. That can really mess things up (and definitely change the layout slightly). I defaulted to the no JS view that looks close enough - less likely to cause errors.

4) The first time the user visits you need to redirect them to the original page they meant to go to in question. If the cookie (state) exists where they have already been there, when they hit back they see the fake SERP.

Ultimately I think this is a pretty powerful tool for malicious arbitragers. Pretty nasty, actually.

I ran across this article today at Wired about how MySpace shut down SecLists.org by contacting Godaddy. Apparently MySpace was annoyed that someone had posted to one of the lists a bunch of MySpace passwords from one of the successful phishing attacks a while back. Instead of contacting Fyodor, who I’m sure would have reacted appropriately, they went right to the Registrar (Godaddy).

The site was down at some point, but is back online now. But it does make me scratch my head a little knowing how close his site and our sites really are. Are we at risk for ToS, because it’s objectionable materials? Even if it’s totally defensible is Godaddy simply going to nuke our sites because some company issues a cease and desist? Did Godaddy even verify the nasty content? What if someone else uploaded malicious content to the site (XSS, SQL Injection, or straight old hacking into the machine). It’s troubling to say the least.

I know I’m a tad bit of a cynic but when id sent me the link to the Stolen Id Search page, my red flags popped up. Of course, this site is probably totally legitimate and takes all sorts of precautions and has security in mind at all costs - but let’s just pretend for a moment that I manufactured a fake site to have the exact same user interface. Except my interface is a lot more likely to steal your credentials than report them back to you.

Simple scenario: Enter your credential - oops, your account looks like it’s been stolen. Please enter your name, address, credit card number and pin as verification so that we can be sure it’s you. Thank you, we have contacted your bank on your behalf, rest assured, your account is now disabled.

I just don’t trust applications like this. Who knows if the site suffers from other sorts of data leakage as well - SQL injection or system vulnerabilities in general. There’s no way for me to verify that that site is safe, and if my identity is stolen, there’s no way for me to verify that they are keeping my information safe from the rest of the people who are interested in stealing it. Maybe they use encrypted databases. Maybe the site is hardened. Maybe they only store a hash of the credentials that are stolen. Of course the site does have this page saying they use SSL, encrypt the data to the “highest” standards and don’t store anything you type (my site would say the same thing incidentally). But it strikes me as odd that the TrustE logo and the TrustedID logos are both for other websites. That also sounds and awful lot like something I’d do for my proposed fake website, doesn’t it?