I’ve been thinking a lot about how the Jikto code was leaked over the last few days. At first I thought it was a really easy problem to solve, then I thought it was a really hard problem to solve, and now I’ve come around full circle but not in the way I originally thought I would. The problem is that Jikto needs to be on the public internet to work (because Google needs to be able to pull the content at some point, and maybe some other reasons). Okay, given that requirement, that makes things like session tokens (cookies) or browser certificates out of the question. Bummer, because that really is the best answer. Then you have stuff like HTAccess, but unfortunately rather than popping up a 401 basic auth dialog it just gives you the standard 401 error. So that’s out the window too.

So then I started thinking this is a really hard problem. You can’t block based on IP because anyone can use the translation service. You can’t do it via time, because someone could type it in and hit enter at exactly the same second (and it would suck if you missed your window). Maybe it’s not possible after all, I think to myself.

Then I recall a conversation I had with beNi about how he was in the process of writing a worm that only allowed you to pull the worm code once based on your IP address. While that’s not a new concept, and it wouldn’t apply here (the thief could use another IP address to pull the code and maybe the translation service uses more than one IP to pull the content) there is some merit to this concept. Note: using only a single IP address is often a bad idea in worms due to proxies like AOL, and Tor, where you can actually reduce the transmission effectiveness.

What if you were to create a counter that said that you could only pull this content one time total (not based on IP). That way the code is pulled, and cached. You don’t need to ever pull it again, as long as the proxy doesn’t re-pull it it’s fine. Or better yet it can send back the unmodified headers if Google requests it again, so it doesn’t need to re-send the data.

In this way, the data is used only once, and available only once (so you had better make sure you are the first person to type that URL in since it is only protected by the fact that you are the first to grab it). You’ve effectively hidden the content in plain view, and allowed the attacker (or data theif or whatever) to know the exact location of the script, without ever giving it to them. The point being, I think there are techniques to hide information in plain sight without giving it to anyone else.

I like to report on these about once a month because they keep popping up and people keep selling them like they are the be-all end-all to privacy. Non parsed header CGI proxies are not secure from a privacy perspective. They just aren’t. Not only because they are vulnerable to XSS, but because they can leak your information to the party you are trying to avoid having your information leaked to. In the case of IPHide.com it’s no different. IPHide is vulnerable to the UTF-7 XSS vector. That means that any page you go to using IPHide and authenticate to is vulnerable to having your information stolen, which is kinda bad, I guess, but more importantly, your information can be transferred over the wire to locate your real IP.

Like I said in an earlier post, if you are relying on this to not get kicked out of school or busted by your office, you had better think twice. Unlike a normal proxy it relies heavily on two things 1) being able to strip out any content that could possibly leak where you are really intending to go and 2) the content filter not using patterns that could be used to pick up the fact that you are in fact surfing for porn or hacking or whatever it is you’re doing that you shouldn’t be. Although I must say it is ridiculously easy to get around content filters if you control both the client and the server, it’s much harder to properly filter out all forms of active content.

Now onto the second part of this, none of the links on the bottom of the page (FAQ, Privacy Policy, Terms of Service, or About us) are valid links. So either this is just a terribly sloppy page, or it is a way for people to steal information from you (login credentials). Sort of like phishing, only you are knowingly using a proxy. Kinda clever if it is being used as that. I don’t assume to say one way or another, it just struck me as an amusing way to abuse people’s paranoia to get information from them.

I won’t spend a lot of time writing about this one, but I found this link (I never read the news which is why I am probably the only person who missed this) but John McCain came out on the side of gay marriage or at least that’s what his MySpace page said. Deep linking happens all the time. Sometimes it’s replaced by a goatse or tub girl, sometimes it’s targeted.

In some cases if it’s made subtle enough, it can go completely undetected, and it really mess up your site. You can force a redirection and use it to force the users to perform a CSRF attack. At the very least it causes you to have another point of failure if the resource is down. Whatever the case, it’s bad. Nuff said.

I’ve been thinking a lot about referring URLs over the last few days - mainly as a security measure. I’ve had a long standing internal battle about whether I think referring URLs have value or not as a security mechanism. Most of the time I think it’s not particularly useful since it can be spoofed, but really, let’s think about this for a second. When you look at traffic hitting your website, some fragment of it is spoofed (referrer spam) some of it is someone lying to hide their tracks and sometimes it’s just plain not there for some reason. It’s actually this third scenario that I’m most interested in and I’ll share why in a minute. First let’s look at when it isn’t there the majority of the time:

META Refresh: Whenever someone uses a meta refresh (in headers or in HTML) it strips out the referring URL. This is often used when you are building sites that have quickly changing content, or to redirect people to another page after some amount of time (sorta a backup for JavaScript redirection these days).

JavaScript: There are a number of cases where JavaScript will strip out referring URLs. Although there are lots of scenarios where this is true, it’s not particularly useful to strip it out in most cases.

Local addresses: If a local URL makes a request to a remote site it will strip out the referring URL. This is to protect people from having their information stolen (drive information). There are bugs in this, but those are rare and for the most part this works as designed. Note that this does not apply to localhost type URLs, just HTML pages on the system itself.

Security tools: There are a number of desktop security tools that sanitize URLs. They also mess with other headers too, so in a way they are easy to detect, but I’m not going to get into that.

Those are the vast majority of cases where a referring URL won’t be there. So let’s talk about why you’d want to see a referring URL. You may want it to make a decision about whether to perform a function or not - probably a bad idea given that it can be spoofed. You may want to see where your traffic is coming from - a decent idea if you don’t make decisions based on it given that people can spoof it (referral spam). Lastly, if you want to see where a bulk of your traffic is coming from in the case of mass exploitation you may want to see a referring URL. Therein lies the single reason I think it may be worthwhile to start sending referring URLs on each request.

Now mind you, I know for a fact that there will be browsers and software that will always cleanse the referring URL. But if you change meta referesh, and JavaScript to always send referring URLs, (not the other two scenarios mentioned above) you make it impossible for an attacker to cleanse their attack origin. Currently today, attackers have a conduit to sending as much traffic as they like without letting the victim know where the traffic started. For privacy advocates they can create an interim redirection that changes the referring URL. So rather than have no referring URL it will be a referring URL to a page that has no value to an attacker attempting to derive information from the user.

Yes, referring URLs are for amusement purposes only in a lot of ways, but I think making those two changes could really yield a lot more security benefits with only a minor hit to website development.

With all this anti-DNS pinning stuff going on, Martin Johns published an interesting tool called LocalRodeo that does a really nice job at preventing JavaScript malware that tries to connect to intranets by circumventing DNS pinning as well as anything that connects to RFC1918 address space (and localhost/loopback as well). Really, it’s a very cool tool and I feel bad finding an issue with it, because this sort of research is critical to stoping some of the issues we’ve been talking about.

However it is pretty trivial to detect LocalRodeo by actually trying to connect to localhost. Because LocalRodeo won’t let the connection take place, neither an onload nor an onerror event handler will fire. However the DOM is not modified so you can’t just iterate over the images and see if the source still points to the correct location. But the first part is enough to detect if LocalRodeo is installed or not (example requires JavaScript). Still, it’s a great tool and I encourage people to try it out and give feedback to help improve it.

About once a month I get someone asking me why knowing what users are running is useful. People don’t seem to think reconnaissance is worth doing these days. I’ve heard people say things like, “Just try the attack and see if it works.” While sometimes it is totally worth just trying the attack in un-targeted attacks there are circumstances where that’s just not true. The first circumstance is where the attack takes a prohibitively large amount of resources. The second is where the attack leaves a big signature when it runs and you want to minimize that signature. The last, however, is the most interesting. The last is where I want to hack a single user, and I want to make it work the first time without fail. This is where recon is useful.

So I decided to pick a user out of the tens of thousands of people who have visited my site. As you all probably know by now, I’ve never been on super great terms with Google - it’s a long story that I’ll rant about over beers to almost anyone who asks. The point being I represent what we like to call a determined attacker. Not so much that I want to hack Google directly - that’s easy enough, but calling out their unofficial technology spokes person while making a point about how important recon is to web application security is the best of both worlds. So I picked Matt Cutts who runs the web-spam group at Google and who happens to be the person that SEO Blackhats most love to hate.

This case study has taken me a few months to put together, and I was thinking about releasing it at a conference at some point but why wait? I think it’s worthwhile to release it now before the noise of Bluehat, Blackhat and DefCon is upon us. In this case study that I’ve entitled Death by 1000 Cutts (as a jab at my own original case study entitled Death by 1000 Cuts) I take a series of extremely minor information disclosures in various ways to mount a really nasty attack where I steal files directly from his machine using anti-anti-anti DNS pinning against Google Desktop. Rather than type the whole thing out again, I encourage you to read it for yourself. I hope this at least partially puts to rest people’s resistance against recon and proves why recon is a powerful tool in a determined attacker’s arsenal.

I was sort of bored and listless this evening and I decided to type in a phrase into a search engine just to see what I’d find, “JavaScript Protection” seemed like a good enough candidate. The first link I found in Yahoo was a link to the JavaScript Protection script collection on internet.com. I spent a good hour looking over all of the scripts and I have to say, it’s a pretty impressive collection of oddities.

There are a few things on there that have no obvious flaws, like the JavaScript password creator. However, almost all of the others suffer from the same obvious problem. They rely on the fact that the user doesn’t view source to see the “encrypted” or otherwise obviously plaintext passwords in the source. There was one version of the script that I thought was vaguely clever and also incredibly scary in that it sends users to their password plus the .html extension. Nothing like keeping your password in plaintext on publicly accessible internet websites! There’s nothing new here, other than the fact that there is such an amazing collection of badly written code snippets in such a small space. Ugly!

Update: Just to be clear this was not intentionally leaked. The source was in fact stolen by one of the audience participants. See the comments for details.

Well, I’m back! No, all that mess yesterday was not for real - I did not get an offer from Google, and I did not sell my site to a 13 year old girl. It might come to a surprise to some of you, but I do like to have fun once in a while. Anyway, back to the webappsec stuff. This weekend the source of Jikto was officially leaked. How long did that take? Anyone time it? So much for this statement: “Although I will not be releasing the source code of Jikto….” There are a few things to note, although I haven’t gotten through all of it.

Firstly, it is only made up of a test HTML page, a single .JS file and a command and control file. Secondly, by the time I had received it, it had already been modified at least a few times, perhaps to test it, but nevertheless it is no longer the original function. Here’s a few snippets from the modification (cleaned up, for readability if you can believe that):

var GUIURL = rot13(”uggc://jjj.cragrfg.vg/wvxgb/pbageby.gkg”); //http://www.pentest.it/jikto/control.txt //http://localhost/JiktoControl/Collect.aspx?type= // uggc://ybpnyubfg/WvxgbPbageby/Pbyyrpg.nfck?glcr=

And…

//var startUrlString = rot13(”uggc://mreb.jronccfrphevgl.pbz/”);
var startUrlString = rot13(”uggc://oynpxung-sbehzf.pbz/cucOO2/vaqrk.cuc”); //http://blackhat-forums.com/phpBB2/index.php uggc://oynpxung-sbehzf.pbz/cucOO2/vaqrk.cuc

If you don’t know what rot13 is, it’s just a really simple shifting cipher that rotates letters 13 places in the alphabet. Anyway, I’m not quite sure why the system uses rot13 at all, since that doesn’t actually stop anyone who can read even basic JavaScript from knowing what URLs it uses, and it just slows down the transmission of the code, but anyway, I am nowhere near combing through the code. The point being it’s on the loose. Oops!

my name is emily nice to meet u all this guy came up to me and aksed if i wanted a site so i said sure an he aksed how old i waz and i said 13 lol!!! and he aksed how much i had an i said 5 dolarz an he said sure lol! so i guess i run this site so i should start doing stuff u can see the colorz hav changed cuz those old colorz are so yesterday rofl!!!

so it is nice to own the site an expect to see some changes around here lol!!! ill take some pictures of my poniez an put them online so u can all see them lollll!!! xoxoxox

I’m sorry to say this but this will be my last post at ha.ckers.org. Why you ask? Because Google has hired me! What about my company? Well, I was always waiting for a good offer to buy me out, so Google decided to pay that thing off and hire me directly. id is shit out of luck, but I’m going to be living in a nice luxury house in Palo Alto. Last I heard id was going to start a biker bar somewhere - he’s not talking to me anymore. How did this all come to be?

Google send me a few emails asking me about anti-anti-anti DNS pinning. Finally they just came out and said, “You know, we find all this whole anti-anti-anti DNS pinning stuff very confusing and distracting, after looking into it, we can’t figure out how to stop it, and rather than fixing it, we’d prefer if you could just stop talking about it.”

Most of the details of the deal are secret, but there are two terms that I feel you should all know about. Firstly, they said they can’t hire anyone who doesn’t have a degree from Stanford, so they granted me a degree since they are so in bed with the people who run the school. So, cool, I now have a degree in liberal arts. Secondly, Google said that I’d have to sell or get rid of my site. They don’t want anyone talking about their holes anymore. So I’ve decided to sell it to the first person I find who wants it. So consider this my last post on ha.ckers.org. It’s been a great ride, but I’m off to sell some banner ads! Caio!