Netcraft’s marketing department wasn’t firing on all 6 cylindars when they came up with this plan. Yup, Netcraft will give an iPod to the person who finds the most phishing sites. And who is the most likely to have tons of phishing sites at their disposal? You guessed it, phishers!

So if you are a phisher and you are looking to get yourself a free iPod, you can go ahead and sign yourself up and report your own sites first. I love contests like this. So game-able. If an iPod were worth anything, I might just build them myself and not send anyone but Netcraft to them - it’s not like that’s part of the rules that anyone else has to see them.

p3rlhax posted about a vulnerability found in Blojsom today. The exploit itself breaks out of encapsulation and runs the vector. Here are the details. Along with it p3rlhax included a snort signature that is intended to catch his own vector. At first I thought that was pretty cool, but then I took a look at what it actually said. Here’s the signature:

alert tcp any any -> $HOME_NET $HTTP_PORTS (msg: “Blojsom Weblog XSS exploit”; flow:to_server; content:”POST”; depth:4; nocase;
pcre:”/(blog-category-description|blog-entry-title|rss-enclosure-url|technorati-tagsi|blog-category-name).*=.*%3cscript%3e.*%3c%2fscript%3e.*&/i”;
classtype:web-application-activity; sid:9999994; rev:1;)

The part that caught my eye was %3cscript%3e.*%3c%2fscript%3e. Can you spot the obvious mistakes here? The first is that it is not a requirement that I end the HTML tag immediately after the word “script”. I can put all sorts of junk in there. Secondly, there are oh, a hundred or so ways to bypass using script tags. Ouch.

This is exactly why I think network security is a dying creature. Sure, you still need it, but it’s completely commoditized and easy to circumvent now. It feels like 1998 all over again today. Rain Forrest Puppy proved most of the IDSs out there could be evaded, but the signatures themselves are just as easy to evade. Maybe Richard Steinnon was right. Maybe IDSs really are dead. Detection will always be a part of prevention, but regex just isn’t cutting it when you are talking about states that go well beyond the state of a packet or even a TCP/IP session.

I stumbled accros some CRYPTOCard promotion today and I really thought it was worth a quick post. The concept of single sign-in is a tough one. It really makes sense from a consumer point of view, but it’s bad from a security perspective, although most people don’t really get why. I have a long history with authentication systems so this one is one that is probably worth discussing.

When I attempted to launch a consumer product that enabled single sign-on at one point the first people we went to talk to were banks. It makes sense, the people who have the most to loose and are willing to sacrifice some usability for security are the people who have to insure your money. So we went and talked with them and they said that they were unwilling to enable single sign-on because they felt that someone would hack into the back end and steal whatever underlying technology required to get access to other accounts.

Right sentiment - wrong security hole.

The problem isn’t that the backend is insecure. Even though 70% of hacks are internal, I’m much more concerned about what can be done from the outside. You can mitigate internal risks by proper access controlls (the same kind the banks use with vaults with keys in them, blah blah). The problem is really on the front end.

Let’s say company-a.com has a website that you authenticate to. By virtue of single sign-on you are now authenticated to company-b.com. Now suddenly, CSRF via XSS in company-a.com that exploits company-b.com and would normally fail on company-b.com (becauuse previously I wasn’t logged in there) now functions. Worse yet, the article talks about giving access to intranet sites, etc… well that just makes our JavaScript intranet port scanning technique even more powerful because now I don’t even have to muck about with brute forcing authentication methods - I’m in without even trying.

The peril in single sign-on is that the least common denominator dictactes a large portion of the security for all members of the authentication network. Sure you can mitigate certain risks by using session tokens, but anything that would have been protected by a tiered authentication model now dissapears. Not a good situation to find yourself in if you are company-b.com.

A few days ago there was a post by 3APA3A about an exploit in PHPBB using poison null byte injection. For those of you who weren’t actively hacking in the 1990’s Rain Forrest Puppy came up with this technique in an article explaining common CGI exploitation techniques. RFP’s technique dealt with injecting a null byte at the end of a string, that was used for comparison. When the comparison failed (this will fail “root” == “root\0″) an operation is performed based on the input and since the null byte doesn’t do anything in other non comparison operations (like opening files for instance) it does so with higher privelages.

What 3APA3A disclosed on behalf of ShAnKaR is that PHP is also vulnerable to these same exploits. For some reason this strikes me as odd. One of the major lessons learned during the late 90’s during the PERL CGI script hay-days was that null byte injection must be detected and removed by stripping out erroneous null bytes from user input. It would have seemed safer to embed this sort of security into more functions without requring users to know anything about the form of exploitation.

If you didn’t do much security auditing or penetration testing in the 90’s this might seem fairly obscure, but I’ve found the problem in dozens of applications. I think PHP’s major benefit is that it made database integration much easier than PERL did (requring the correct DBI libraries) which makes null byte injection fairly less useful, but it’s certainly not gone, as this advisory explains. I guess the major issue with black box penetration testing is that it is fairly difficult to find what you are attempting to exploit in the first place without significant recon and even then you may not find what you are looking for. In the case of PHP most applications are open sourced these days, so it is fairly trivial to find exploitable code, just by downloading the most current revision.

I’ll be curious to see if this starts a rash of new forms of PHP exploitation. If I had more time to be auditing, I’m sure I could find a few places that used this type of string comparison to perform security operations. Good stuff coming from Russia!

Jeremiah Grossman and I have been chatting a lot lately about ways to circumvent restrictions placed on exploitation by users who have turned off JavaScript. Welllll, as it turns out, we actually can still do significant recon without the use of JavaScript or Java or Flash. I think Jeremiah is going to wait until Blackhat Japan, so I’m not going to spill the beans, but from what I’ve seen it really adds another route to doing some of the things I’ve been posting about over the last few months.

But it got me thinking about other issues that I can talk about. For instance, I was visiting what was essentially a hacked site that had a redirection built into a Flash movie. Here I was, with Flash and JavaScript and Java turned off and yet I was still getting redirected. What’s the deal? Well, after doing a little research it turns out that Flashblock requires that JavaScript is turned on. So to turn off Flash, I have to have JavaScript turned on - how is that helping me?

Sure, there are other much more annoying ways to turn off JavaScript and Flash at the same time, but the point being, just when I thought I was safe from certain vectors, they were re-opened by conflicts with one another. This reminds me of a project I worked on once to supply anti-virus software to customers for free, but because of potential liability issues we opted not to because of conflicts with existing software.

The short answer is, no, you definitely aren’t safe by simply turning off JavaScript. Java, Flash, VBScript, ActiveX, and a host of other forms of dymanic content can cause exploitation. Things are pretty broken right now.

TOR is a pretty cool idea. It’s partially a rip off of a very old project that I helped out with in it’s inception with a bit of peer to peer built on top of it to help with anonymization. Anyway, very cool. Very slow, but very cool. From what I’ve been told it’s mostly for people looking for beastiality porn, but you get the idea. It’s got all kinds of applications. But it’s a little disconcerting that I don’t know if my users are hiding their origin IP addresses. Wouldn’t it be nice to be able to detect that?

So anyway, there I was, downloading the torbutton extention which requires Privoxy and TOR to be installed. Like a good little security guy I go and locate the current version of TOR which is thankfully bundled with Privoxy. I booted it up and after some wrestling I got it working. The first link I went to, however, was a tad puzzling. It was my own.

My own website has links to ads in it, which Privoxy so nicely kills with an error message letting me know why, and allowing me to go directly to the link. That link that allows me to bypass the Privoxy block was intriguing as it was just a modified URL (and a pretty easy one to reconstruct at that). So I threw up a little test script to detect privoxy and poof! I inserted a keyword that it blocks after a legitimate image with the modified URL. If it hits it, Privoxy is being used. If there’s an error because it’s not finding the correct image (because the modified URL doesn’t actually exist) you know they are safe. Now I can tell if users have it installed or not. This may be better than the chrome:// firefox extensions detection because I have a feeling that will get killed eventually.

I’ve been thinking a lot about my last post, and there are so many different paths to take this, it’s difficult to choose what to write about, but this is one thing that popped in my head this morning. One major issue with the naming convention of intranet applications is that they aren’t named only http://intranet/ they are also named http://intranet.company.name/ which is both good and bad. It’s good from a usability perspective and bad from a web application security perspective. If you know how the intranet is named, and you want to attack a particular user from a company, despite IP anonymization I can find out who the user is.

Let’s say I run a hacking site that is of particular interest to a bigsearchengine.com and I want to target an attack only to a particular users at bigsearchengine.com but that company uses things like redirectors and anonymizers to hide who they are. No problem. All I need to do is detect where they’ve been. So here is where I as a bad guy whip out Jeremiah’s CSS trick. But instead of point it to http://www.somerandomcompany.com/ I point it to http://intranet.bigsearchengine.com/ (hopefully you know the exact name of the intranet, so you can target better, but you get the point).

Now, regardless of anonymous proxies or hiding referring URLs or any other tricks, I now know exactly who the user is. They may or may not be allowed to connect back into their network if they are anonymizing their traffic, but I’m willing to bet most people are anonymizing at the network level, not at the client, meaning they can still access internal servers. This is the flag to allow me to start launching my highly targeted attack with my mapping (as you’ve seen below) of the company of choice.

Now you’re saying, “But what if they clear their history?” Well, it’s easy enough to force their browser to the intranet site too. If they can successfully connect to the intranet site in question they now have it in their history, and boom, you’re detection is on again. .htaccess basic auth dialogues throw a wrench into the mix, but I’m not sure how many intranet sites are protected in that way. Anyway, sucks to be bigsearchengine.com right about now, doesn’t it?

Amit Klein just published a rather interesting article on how anti-anti-DNS pinning techniques can be circumvented (counter counter measures). Namely how you can get around Host: header restrictions by using XmlHttpRequest or by forging headers with Flash. Coupled with Martin Johns’ DNS pinning circumvention technique this marks a sad day for web application security for Intranet applications.

Now from any website in the world that I control, I can read your internal interfaces of your web applications and actually return the entire website. Of course this doesn’t reveal credentials, but it certainly will tell you everything you need to know from an unauthenticated state about what every Intranet page looks like. Ouch.

Amit explains that the common technique of looking for the Host: header on the server will not work against DNS pinning evasion. Previously this wasn’t that big of a deal because you can just go to any website that you want and from an unauthenticated state you can see the webpage. That’s not particularly interesting unless you can’t get to the website (in the case of RFC 1918 non routable address space). Combining these two techniques gives you the ability to read internal addresses. This might not seem easy to exploit because how do you know what a company names it’s internal machines? There are a few ways. First, you can do web searches for logs that may contain referring URLs from intranets. For instance, here are just few intranet servers I found out there:

Google: http://pfe-staging-gfe.prodz.google.com/

Google: http://gwstest.prodz.google.com:8882/

Google: http://lighthouse.prodz.google.com/

Google: http://c4.corp.google.com/

Google: http://merchantdb.corp.google.com/

Google: http://trakken.corp.google.com/

Google: http://gtools.corp.google.com/

Google: http://gweb.corp.google.com/

Google: http://www.corp.google.com/ (add a ~username/ to see specific users)

Google: http://gnome.corp.google.com/

Google: http://epqa71.corp.google.com:19900/

Google: http://newsapps.corp.google.com/

Google: http://adtools.corp.google.com/

Google: http://bugs.corp.google.com/

Google: http://mailman.corp.google.com/

Google: http://alligator.corp.google.com:3128/

Google: http://dogfood.corp.google.com:10000

Google: http://newsapps.corp.google.com/

Google: http://peregrine.corp.google.com/

Google: http://fuzzy.corp.google.com:8000/

Google: http://reactor.corp.google.com/

Google: http://gueda-g2.corp.google.com/

Google: http://columbus.corp.google.com:443/

Microsoft: http://team/

Hi5: http://intranet.hi5.com/

The one that I think is the most interesting is actually Hi5 (even though this is also visible from the Internet-despite it’s name), because I think this is really sestemic of the issue. There are a few very common names for intranet applications that can help you get started in your recon. The first is “intranet” as Hi5 shows us. Being able to read the intranet website can help you locate lots of other servers because intranet applications are designed to be hubs where users go to locate other servers. There are tons of other common names, but I think you are best off finding the intranet application and spidering from there.

So, in review: Locating that the site is there in the first place using Jeremiah’s JavaScript intranet port scanner and then using the DNS pinning attack to read the page itself pretty much seals the deal.

Tim Tucker posted an interesting solution to some of the CAPTCHA solving stuff going around. He posted that to comment on his blog you must enter any data, as long as it’s incorrect. So as long as you don’t type in whatever you see and it is six characters long, it will be solved.

As the posted noted, this isn’t particularly good security, as a) it can be broken by anyone who views the site and knows that rule (therefore it’s not good against targeted attacks), and b) if it ever gains popularity it will become standard in splogging software. Still, it’s an interesting take on the same old problem of blog spam.

pdp has an interesting article about how to embed JavaScript into quicktime movies. Pretty cool stuff actually. I’ve actually seen this before (in the wild) in other video formats where upon execution it attempts to connect to the web in some form or another generally creating popups, etc. This is an interesting problem though, because it’s pretty difficult to detect. It’s not just a matter of scanning a network shim and looking for JavaScript, you now have to scan everything.

That’s actually partially what this thread on sla.ckers.org is about. As more forms of media become web enabled, this problem will mutate. It will be interesting to see the future of these attacks as they grow, because they will grow as quickly as the technology evolves. More and more people want to have web enabled software, and this only paves the way for more forms of attack.