Paid Advertising
web application security lab

Archive for August, 2006

« Previous Entries
Next Entries »

Pirate Bay Uses Load Balancer Stealth

Wednesday, August 16th, 2006

If you were living in a cave for the last few months you may not have heard of the Pirate Bay’s legal woes. If you have been living in a cave for the last few years The Pirate Bay is a place for people to download and trade movies primarily that have been illegally reproduced/copied and put online via a peer to peer network (bittorrent). Anyway, they were shut down under supposed legal pressure by the US government backed by the MPAA and the RIAA which caused quite an uproard in Sweden where the Pirate Bay was primarily hosted. The swat arrived (approximately 50 people) to rip a few computers out of the wall, which was also considered highly contentious as the people of Sweden largely feel that their police officers should be solving violent crimes. It was and continues to be a big deal politically and may actually change the course of the upcoming elections. Now the Pirate Bay is fighting back by distributing the Pirate Bay behind a load balancer and hosting in multiple countries.

Natting has always been an interesting idea to combat denial of service issues, where you have many servers that can fail over if the primary one is ever taken offline (like squid for instance). But it’s particularly interesting when you are talking about physical denial of service (like removal of equipment or force majeure). I had a buddy who was working pretty closely with law enforcement on some case and the feds basically told him that any help he provided they couldn’t know about ahead of time because that would be circumventing the warrant process. That’s even more difficult when you are talking about routing through countries with no extradition treaties with one another. The same is true with any country. Pretty tricky. It may be helpfull to eventually create a 3D map of which countries you need to host in and hop through to have the maximum security from litigation - just a thought.

The Pirate Bay actually contains no pirated content, it is simply an aggregator of where the content is hosted so that people can connect with one another. None of this made any press in the United States, but it’s huge internationally. Their legal battles will continue, but for now it looks like this recent raid didn’t do much to stop their activities.

Posted in Random Security | No Comments »

Googlepath Module Released

Wednesday, August 16th, 2006

Matteo Cantoni sent me an email to his tool called Googlepath today. It’s a project written in PERL to find information from websites to automatically generate probable attack points for web applications. Granted, you already have to know what you are looking for, but it’s an interesting tool for blackhat SEO to find highly valuable .gov and .edu domains that are vulnerable, as well as for web application vulnerability assessments when you are trying to locate probable attack points.

I should caveat this because it is really more designed to be a wide scanner and not as much for a pinpoint target assessment, which strikes me as a very blackhat tool, rather than a whitehat app scanner, but it does have a -s flag which will allow you to scan a given site, which might save you time during vulnerability assessments. Thanks, Matteo!

Posted in Webappsec, SEO/SEM | 1 Comment »

OpenDNS Stops Some Phishing and has Some Issues

Wednesday, August 16th, 2006

I haven’t had a chance to play with OpenDNS yet, but I’ve been hearing about it a lot lately. One of the great things about it is that is attempts to fight phishing by locating domains that have phishing sites on them and blackholing them with this page. Pretty cool stuff, actually. One of these days I’m going to have to play with it.

I’m just going to go out on a limb here and pretend I know how it works. It probably uses a blacklist of domains. Unfortunately that means if my phishing site is on a hacked machine with other valid things on that machine it’s now inaccessable to users. That may or may not be a bad thing, but what about XSS? Everything is vulnerable to XSS. So any time I put up a phishing XSS site on any domain (Google, Yahoo, you name it) it gets blackholed? There’s got to be a better way to do that with more intelligence.

And then there is the XSS issue:

GET / HTTP/1.0
Host: <body onload=alert("XSS")>.com
User-Agent: blah blah
Accept: */*
Accept-Language: ru
Accept-Encoding: gzip,deflate
Accept-Charset: */*

Colons and slashes are not allowed in the Host: header, but pretty much everything else is, which allows you to run abitrary JavaScript on phish.opendns.org using the Flash header injection method. Which means, if my phishing site is on host “A”, I can XSS some other site “B” to do a simple redirect, with the flash injection have them forward to the real address of the phishing site “A” and even after I’m caught and the page where the server is being redirected to “A” is caught I can run XSS on the openwall server to continue my phishing phun. Beautiful.

I still think it’s an interesting idea, even with the flaws. I’d rather see this as a content filter proxy rather than a DNS server implementation because I think DNSs are too blind (as they don’t see paths). But it’s still probably better than nothing in the short term until the phishing community changes their tactics.

Posted in XSS, Webappsec, Phishing, Random Security | 9 Comments »

Social Networking Corporate Security Compromise

Tuesday, August 15th, 2006

At one point or another I think I’ve been a part of almost every social networking site I’m even aware of. I really hate them, let me just tell you. Loath is a better word. Loath. Anyway. Here I am on LinkedIn loathing life, but one of my previous co-workers and I were making a game out of who could get the most contacts. Don’t ask me why, I really don’t know. At first I was playing fair, and then at one point that he started pulling ahead I resorted to adding my email address to the title so that people could add me at will. That’s not super interesting. But then it occured to me as I started getting requests from my co-workers, this is extremely game-able.

Personally, I’m not going to go messing around on LinkedIn, because most of the people I am networked to happen to actually know me and know it was me who was messing with them (and it’s not really my style anyway) but it’s a very real problem. You can send personalized requests to millions of users (spam).

“Yes, RSnake, but how?” Well, at one point I used to work for a company that was bought by a company and that company was bought by another company and that company was bought by another company. So it’s very difficult to figure out who you worked with because people left at various stages of the four companies, so you have to add yourself as having worked at all four companies to find everyone. But wait, why can’t I add… ANY company? I can!

So let’s say I want to make chummy chummy with a bunch of Google folks? It’s just a matter of saying I worked there at some point and adding enough people before people start adding you back. Free access to work email addresses of every major company! And the best part is I don’t have to say I continued to work there, I can then delete the fact that I pretended like I worked there and move on to the next company. Ouch.

This is clearly not LinkedIn’s idea behind this function. They don’t make money when you spam their users, and if you do, people will start abandoning the site right and left (meaning that would be one less site for me to visit every few weeks when I get one more peice of mail from someone adding me or asking me to get in contact with someone else - wouldn’t that be terrible)? So how would you detect something like this if you are architecting your own website? It’s a session variable that leaks too much information about it’s users that allows you to get in contact with them much easier than you would be able to normally.

I’m not aware of a web application scanner on earth that would find something so strange, but indeed, if you want to start spamming someone directly, or issuing targeted viruses/worms to mega companies, this is a perfect conduit for finding people in these huge companies, and targeting them directly. Remember our JavaScript scanner? “Hey, Joe, check out my new company, I just went to, I’d appreciate any feedback you could give since I know this is your area of expertise.” Even if they don’t know you, 9 out of 10 times they’ll click, and you’re in.

Social networking can lead to corporate security compromise. In the information age, social networking feels like one of the largest holes in online security.

Posted in Webappsec, spam | 3 Comments »

list-style-image XSS

Tuesday, August 15th, 2006

Again, boardering on the extreme esoteric of XSS examples, I ran into this element today that will allow JavaScript to render. It’s called the list-style-image CSS element. It’s so bizzare I’m not even sure how you could implement this effectively as it requires lots of HTML, and URL parameters inside style sheets. It works only in Internet Explorer rendering engine too. Ready for this one?

Now where would you use that? Well I guess I could come up with a theoretical example where you knew that there was a bullet on a page or could somehow insert it and you had some control over the styles on a page. Ugh. I have no idea, your guess is as good as mine, but it’s worth mentioning for anyone on the extreme edge. Good luck with this one!

Posted in General News, XSS, Webappsec | 4 Comments »

Circumventing DNS Pinning for XSS

Tuesday, August 15th, 2006

Martin Johns posted today about a technique for circumventing DNS pinning to enable cross site scripting against other domains (specifically against internal IP space). I too have looked into DNS pinning as an obstical but was unable to get around the browser pinning. For those of you who aren’t aware of this problem here’s a simple explination. If you go to www.whatever.com and that corresponds to an IP address, and then change the IP address in the DNS record and request it again in the same browser session the browser will not look it up. In this way, you cannot fool the browser into requesting a peice of JavaScript a few seconds later from a different domain to bypass same origin policies. It’s a pain, trust me.

What Martin was able to accomplish was to detect that if the server goes down, it will in fact make another request. That’s something I had never tried before personally and a great find! I had tried modifying hosts files, changing DNS records, and all sorts of things, short of ARP spoofing since I generally don’t have access to the switch in question. So the trick is, you change the DNS record and either shut down the webserver or add a firewall rule immediately afterwords to get the browser to drop it’s cached DNS entry for www.whatever.com and poof, you now can get the browser to request the same information from a different IP address without the same origin policies. Voila!

The only limitations he came up with were that it must be accessable at the IP address, and not at the virtual host level, because it will be requesting a host that does not exist (www.whatever.com) on the internal address. If you can get around that, you now have read/write on any internal host in JavaScript space! That’s an amazing extention of cross site scripting that was never possible before! Great find, Martin!

Posted in XSS, Webappsec | 1 Comment »

Exploiting Cross Site Scripting Through POST

Monday, August 14th, 2006

I got an interesting question from Trixzster that I think is worth posting because it shows a common misunderstanding of how vulnerable POST is to cross site scripting:

I’ve noticed that its alot harder to exploit xss through post
variables, how would you go about doing this because its not as easy
as sending someone a link with xss attached to the end.

On the surface, it may seem that way, but really it is pretty trivial. Let’s take a simple XSS example where a variable called “abcd” is vulnerable to injection:

<body onload=”xss();”>
<form method=post name=f action=”http://www.example.com/whatever.php”>
<input name=”abcd” value=”<SCRIPT>alert(’XSS’)</SCRIPT>”>
<input type=”submit” class=”button” name=”s”>
</form>
<script>
function xss() {
document.f.s.click();
}
</script>
</body>

In this example once a user views this page they will be automatically redirected to the victim website in question with the correct POST variables to run the XSS exploit. So the matter is not getting the user to click on something on the website itself, but rather any website anywhere that you control. Remember our redirects we found in Google? Well using those the user cannot tell where they are going. If they click on them they land on a page that you control and instantly get redirected to the victim where the cross site scripting vector runs. Voila!

The only relatively difficult part of this is defining which variables are vulnerable. Stopping this exploit involves stopping cross site request forgeries (CSRF) in general. Session variables can help, as can building unique variables that are only outputted once. The mitigating factors for CSRF can be difficult to master, but they are possible. In general ending CSRF could actually hurt the usability of the entire Internet at large, so I don’t think this will end any time in the near future, although I could see browser companies putting a stop to automatic click generation.

Posted in XSS, Webappsec | 13 Comments »

SEO Security Contest Winners Announced

Monday, August 14th, 2006

Thanks to everyone who submitted their request to join the private SEO Security board. There will be another announcement in the next day or so for anyone else who wants to join (again I make nothing off this, so this isn’t an advertizement for anything I’m working on - I just think it’s super interesting). And the winners are *drumroll*:

Blwood and Perle!

Oh but wait, there’s one more, I talked it over with the owner of the board and he extended a personal invitation to one more person, because we got so many good people submitting. So a big congrats to SEO Hippy too, who got a free subscription! So congrats to you three!

The three winners were chosen specifically based on skill and willingness to devote code to the group (just because you weren’t chosen, doesn’t mean you aren’t good, we just had some tough competition). I’ll email the winners to explain how to get started. To the rest of you, I appreciate you writing in and I’ll send you a personal email as well shortly. It was a tough race.

Posted in SEO/SEM, Random Security | No Comments »

Flash Can Steal User Credentials

Monday, August 14th, 2006

Amit Klein has been coming out with some great stuff lately. First with his Flash header spoofing and expect vulnerability and more recently using the same header spoofing he can actually use Flash to steal user credentials. Holy crap!

Here’s the basic principle. If the user is sitting behind certain transparent proxies, if you send a Host: header through the Flash redirection the transparent proxy will send the request to whatever Host you specified. The browser is ignorant of that and will add the credentials as expected and your credentials will now be passed to another host.

Likewise if the machine you are interested in is sitting on a shared host you don’t need a transparent proxy. Just get an account on the same machine (same IP) and have the content forwarded to you instead of the correct virtual host. Gotta love it.

Add this onto RFC 1918 space JavaScript proxies and now you can steal internal user information and send it anywhere to be used by other users at a later date (assuming that user navigates away from the XSS proxy or otherwise closes the connection). But even without taking it that far, just casting a large enough net of users on a large enough application could lead to thousands of compromises on all sorts of different websites (as long as the user had authenticated with those websites recently). Great find, Amit!

Posted in XSS, Webappsec | No Comments »

JavaScript Port Scanner Code Released

Monday, August 14th, 2006

Jeremiah finally put up his speech and proof of concept code for his JavaScript port scanner malware. He also put the CSS history revealing code on his website if you want to see it in action (it’s non malicious, but very cool).

Lastly, he has some pictures up as well from Blackhat and DefCon. He mentions an awkward moment between me and Billy Hoffman, but it wasn’t really that bad, I swear. Someone told the SPI Dynamics guys that I took over a decade of martial arts and I think people were stressed that I might whip out a 55 gallon barrel of whoopass. But no, I have no desire to beat anyone up. That’s pretty much the last thing on my mind most of the time actually. Anyway, cool pictures and check out the proof of concept code if you want to get familiar with the concept.

Posted in XSS, Webappsec | No Comments »

« Previous Entries
Next Entries »