A few weeks ago at RSACon I sat down with Amit Klein and asked him one question that I’ve wanted to ask for a long time. I wanted to know if there was one defining moment in his past that suddenly opened his eyes. More specifically, some event that made him realize that he had stumbled upon knowledge that would lead him down a path that only a very select few would ever travel. I wanted to know that one cathartic event that made him realize the web was extremely vulnerable. I wanted to know this because I wanted to know if there was a common thread between him and some of the other experts in the field.

Amit took his sweet time thinking of a good answer, of course telling me all the while that there was no single defining moment and that the question was harder than it sounds. Yes, yes, Amit, but out with it! He finally began to tell me the first time he messed with a binary. He went in with an editor and changed one word. Expecting it not to work, he ran it, and sure enough it did. To him that was totally amazing that it would work, and suddenly, he realized that there were probably a lot of exploitable things out there similar to that. He also told another story about how he had read the HTTP spec and realized you could put a newline in front of the first line of the HTTP request, which in the future would eventually lead to exploitation.

So then I asked the same question of Dinis Cruz:

I can probably point to three key moments:

- the first was when I was a CTO of an university and one of campus’ IT guys showed me how he was able to access (over the internet) another campus internal network (via a remote shell delivered via one of the earlier IIS exploits)
- the 2nd was when I read back to back the first Hacking Exposed book and really got an understanding of network and application exploitation
- the 3rd was when I realized that my programming background (ZX Spectrum generation, Assembly programming on Amiga/x86, etc..) really allowed me to ‘understand’ Application security (vs network security) AND to write exploits

Jeremiah Grossman also gave his story:

For myself it started almost immediately when I began developing web applications many years ago. I read all the books, walk through the examples, and built websites. Being the natural prankster that I am I immediately saw how others could potentially screw around with the way my application worked, post offense stuff, and just generally cause a poor user experience. At the time I didn’t know to even to call it "security", it was just something that could be done to a webapp. The AHA moment came when I got the feeling that my code was no better or worse than anyone elses.

As I just passed my 800 blog post mark, I realized I had never talked about my moment either, and what better way to talk about it than to talk about other people’s moments as well. Mine was a very vivid point in time in my memory. I had read the HTTP spec and knew the basic principles of how it worked, but one day I followed some guide and telnetted to port 80 for the first time and started typing in commands. The first time I saw a flood of headers fly by my screen was like getting hit in the face with a brick. I just couldn’t deny how powerful that knowledge was and how broken everything must be if it was that simple. I know most people look at HTTP and kinda shrug their shoulders, but for me it was an awakening that made me realize that there is almost no end to the potential and danger that it allows.

I don’t know that I can point to any one particular thread between these experts, but I do know that the net effect was the same. The realization that everything is vulnerable is a pretty profound concept. So? What’s your story?

Okay, I waited long enough to tell this story, but it’s funny enough that it’s worth it. At SOURCE Boston, Jeremiah, Mark Kranack and I were sitting around talking and apparently at one point long ago he had started a religion. The religion was simple, all you had to do was accept Mark as your god and that’s that. No fees, no prayers, no nothing, just accept him as your god. You don’t even have to do it on purpose, one guy joined by accident as a matter of fact by inadvertantly saying that Mark was his god as he described it. There’s no way to get kicked out of his religion and nothing really special about it in any way beyond the religious leader, of course. You can still find a reference to it on the internet archive.

Then we got to talking and laughing and ultimately came up with a CSRF joke of all time. We could get tens of thousands, maybe hundreds of thousands, or even millions of people to join through CSRF via images to forms on MySpace, or what have you. You see, there is a bit of a bug in the acceptance program of Kraynackism. You don’t have to necessarily “say” that Mark is your God it turns out, you just have to somehow indicate it to him, either intentionally or inadvertantly as we saw with his friend. We could turn Kraynackism into the fastest growing religion the world has ever seen! You could be a member right now and you wouldn’t even know it!

It’s funny but it’s less funny when you talk about getting people arrested in China as we talked about a long time ago or of course going to jail for child porn, etc… Funny and scary all at the same time.

I was having our weekly cigar meeting with the local security guys when we stumbled across a pretty funny thought. There’s a pretty good paper put out by Cybersource about trends for 2008 in which it had a graph showing that as a percentage of online transactions fraud was dropping. Whoah! That’s not what I expected to hear. But then in closer examination that’s a red herring, because total fraud is still increasing at the same rate it always has. Not so good after-all, it just means consumer spending is out pacing the bad guys. That makes it worth being in the business of online retailing, but spending will eventually taper off with population growth.

The funny part of the story is what if all the consumers finally hit a tipping point where they just decided to go home and stop using the Internet completely? What if we just had bad guys trying to phish bad guys, and spammers just trying to spam other spammers? What would the Internet be when every page was a scam and every person on it was desperate for money because all the people who they wanted to scam went outside to go play in the grass? A funny thought! Hey, we were having cigars, sue us for getting a little off topic!

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’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.

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.

There’s a very interesting report out on the fact that IP addresses are now potentially considered personally identifiable information in the EU. Whoah! I’m sure people can think of their own reasons this might be a big deal, but here is just a small smattering of stuff that I came up with:

Advertising: banner ads are almost always pulled from a third party. That third party gets things like referrers and, what else, IP addresses! Sorry, say goodbye to third party ad revenue! Yes, that means you, Adsense and Overture! People can no longer leak that information to you as it’s PII!

Tracking Pixels: tracking pixels are used by companies all over the world because it’s often easier than dealing with their own logs and buying and configuring their own log analysis software (especially if they get a lot of traffic). So Omniture and Google’s Urchin could be hard hit here.

Embedded content: There are tons of bulletin boards, message boards, blogs, etc… out there that allow images to be posted off host. People like it because it doesn’t force them to have to build upload scripts, and maintain them. Sorry, no more embedded content, and that includes things like Youtube because that would leak the people’s IP addresses to third parties. Also, things like Gmodules which often pull in content from other domains would be a big no no without some changes. Same with Google cache, translation services, etc… etc…!

There’s dozens of issues out there, but you’ll notice that this particular issue would wreak havoc on Google’s business model if it’s ever fully enforced. It’ll be interesting to see how this plays out and if there is any other tricky way people can use to get around this (like hashing the IP or stripping off the last bits - which is mentioned in the last part of the article but probably isn’t much actual protection since that only makes it 255 times harder to guess at best). This is one to watch folks!