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!

Two days ago I found myself reading something written by one of my readers about something I had written. Unfortunately, it not only completely missed the point of what I had talked about, but some dramatic and ultimately incorrect assumptions were drawn due to complete lack of technical understanding on this reader’s part. I’m not going to out this person, because I don’t think it’s productive. But it was pretty upsetting to me, because I do want people like this person to be able to learn from this site. This site is super tricky to run. On one hand I have some of the most technically competent people in the web security community visiting regularly. For them, some of the most complex topics I cover make perfect sense, and there is very little confusion. For the non-techies the technical posts are either misread or left unread. Either way, that’s not good for the sake of learning.

A huge chunk of why I started this site was for my own testing. I wanted to learn on a site that I controlled completely. That works great if you’re a guy like me, who’s already been in the web space for well over a decade. But for people who are either new, or are shifting their interests from some other area of security, the web space is highly complex and deep. So herein lies the second reason I started this site. I wanted a place where I could teach people what I know. Call it altruism, call it wanting a sanity check on my own thoughts, but here we are, 2 years and 20,000 visitors a day later and things have changed.

I’m ultimately troubled by the fact that there are so many people out there who are in every way smart but are only in web application security because they have fallen into it, for whatever reason, and now are trying to play catch up with guys like us. I feel like there is a huge gap of knowledge out there, and I feel like there is a lot that I could share with people given enough time. A one hour speech isn’t enough time. It’s barely enough time to gloss over a topic, let alone go down to any level of detail that would allow someone to think they are proficient in a topic. I really feel like I could share a lot more of what I know to a willing participant if we made it a week long course. So that’s what I did.

I’m going to be offering a week long course that I am dubbing The Austin Project. The goal of the project is to get a group of likeminded people who are interested in talking about and learning more about web application security from yours truly. Honestly, I just feel like there’s a lot more I can talk about in a week’s time than I could ever cover in a series of blog posts, especially because in an intimate class it is far easier to communicate.

So I will be inviting five people to fly in and stay for five days. No cell phones, no computers, no distractions - just talking webappsec. I attended an invite only conference of this format before and it worked great, where the only open computer was the one operating the projector. Being off the grid really helps people focus. Everyone will sign non disclosure agreements so people can talk freely about problems they are concerned with without having to worry about it getting out. There will be eventual outputs from the classes, but they will be discussed only with people who attend. Days will be spent talking about webappsec, nights will be spent with me in downtown Austin, visiting the local nightlife and probably talking about webappsec some more. My goal is not to make myself the grand leader of a group of five people who are webappsec gods, but rather, build a collaborative group of people who change their way of thinking and come out of it with the knowledge on how to fix their little slice of the Internet.

I’m just not scalable, and while the blog has been a great conduit for sharing some of my ideas, it’s clear to me that people just aren’t getting the value out of it that they could in another format (I guess you get what you pay for, as this site is free!). It turns out I just have a lot more to say than I put on this site. That became apparent today when I started chatting with someone about a specific web application flow. It took me ten minutes to explain some of the esoteric nuances to watch out for and I suddenly realized I had never talked about it before on the site, and I probably never would have because I ultimately consider a lot of that stuff to be “the basics” (even though apparently not a lot of people know about it). I usually try to skirt around the basics as to avoid alienating the experts who frequent this site. How would anyone know about the esoteric gotchas if I didn’t talk about it? Well, now is your chance to come ask me. Not that I will just be covering basics - oh no, why come to me for the basics? But this will be your chance to get me to slow down and explain things to you in a virtually one on one environment.

My goal isn’t to get the best of the best and put them in a room together (although if I wind up with a bunch of people who are experts I will build a class specifically for them). The main goal of The Austin Project is to get people who want to learn but are otherwise starved for information. I want to help those people and bring them to the next level, so that they go off and eventually help others and so on. I firmly believe education at this level will help our industry, help us start developing better applications, better strategies, and ultimately will make all our lives better.

This isn’t like most training. There will be no CPE credits (although I’m sure you could convince someone it should count), no class of 40 people, no canned demonstrations. This is just a chance for you to sit with me for a week and talk about whatever it is you want to talk about in an collaborative environment. I don’t want five people from the same company showing up. That’s not the goal here. The goal is for you to meet other people with other problems and work through them together as much as it is to hear from me. Why? Because other people have interesting problems that relate to our industry that you should think about too! I want to facilitate the correct thought process, which is so much more important than me just solving your problems for you. I want to make people into the big thinkers (not just technologists) that this industry needs. I want the participants to build relationships that they can use to better themselves and their careers. Big goals for such a little class!

Anyway, if we wind up with way more than five people who are interested, we can separate the classes into groups, but I have no idea how many people will be interested. I don’t want to go over five people and I don’t want it smaller than that or it would defeat the goal of building a team, so I may actually turn people away if we don’t hit a critical mass. This is just as much an experiment for me as it is for anyone who would attend. I also may turn people away if I think they couldn’t benefit from this - which is why I’ll be asking for a resume from each of the people who are interested. If you have no experience, this isn’t the class for you. If you have been doing this longer than I have, this isn’t the class for you. If you just want to come to the class to heckle me, well, it’s an expensive prank, but it’s your money. So if you are at all interested, check out The Austin Project web-page for the specifics and send your contact information through the form.

There’s an interesting article over on PC World about an auto-update that Microsoft is pushing on Feb 12th. This update will be an automatic update of IE6.0 to IE7.0. That’s right, folks… all you people who were writing exploits against IE6.0 will have little to no market share left. Here comes IE7.0. IE7.0 has a few significant improvements for XSS but probably the most notable change beyond the user interface is the anti-phishing technology.

I can completely see why Microsoft is taking this approach - although I think people who aren’t used to IE7.0 will revolt until they get used to it. But if you think about it from their biggest customer’s perspective - they want their users to stop getting exploited. It’s bad for business, it’s bad for security and it’s bad for public relations. So for all of you who had come to know and love IE6.0, you might as well go download it now and beat the curve. Resistance is futile! Although there are instructions on how to stop the upgrade if you really need swim upstream.

One of the things I love to talk about when I’m ranting about the improper use of the same origin policy to dictate how we as security professionals are auditing a website is the use of APIs. Hackers don’t care that your browser sees them as different domains. If they can attack the API and that API has access to the same data that the main website does, but without the controls in place to lock it down, that much the better. Anyway, all of this and much much more will be covered in the OWASP preso that I’m doing in Minnesota on Feb 11th, for those of you who live nearby. But let me return to my rant for a second.

I’ve seen lots of examples of this in the wild, but for various reasons I haven’t been able to talk about them specifically until now. Rosario Valotta found an XSS in MySpace using the mobile API. MySpace being plagued with XSS vulns is really nothing new, but this is actually pretty interesting to me because it’s the first time I can publically point to a place where the API is the conduit for the attack. Where you’d normally be unable to enter JavaScript, on the mobile API the filters don’t exist. Good for bad guys, bad for consumers.

As Rosario pointed out, although this does end up on MySpace it wouldn’t make for a good worm, as the mobile platform doesn’t use the same credential as the website, so it would be impossible to propagate unless someone happened to be logged into the mobile platform when they visited an attacker’s malicious profile. Yes, folks, APIs need to be secured in the same way the website is. You are only as strong as the weakest link, and if you aren’t auditing those APIs you aren’t finding all your holes. Nice work by Rosario!

I saw this article today and I just thought it was just too amazing. So it turns out that in North Dakota one very technologically impaired judge felt that running a zone transfer, among other things, is illegal. David Ritz was attempting to shut down a spammer, using the normal tactics to find out who was running the server that you’d expect, like looking at whois info, traceroute etc…. Oh no, not in North Dakota you don’t! He’s facing possible jail time for attempting to fight spam. Now there’s a twist for you! Isn’t there some sort of oversight for technically challenged judges? Or maybe a “I don’t know anything about this stuff, perhaps you should talk to Judge Bob about this instead, since he does” type system?

While Cynthia Rothe-Seeger (the district judge on this case) opinions are obviously technically questionable given that many of these tools are written specifically to find public information (that means available for anyone, including anti-spam organizations) this could set a legal precedent that enables spammers to operate with near legal impunity out of North Dakota. Great. So if you or someone you are investigating is based out of North Dakota - I’d watch this lawsuit until this is settled. Talk about taking one giant leap backwards for mankind. So fierce is off limits to you North Dakotans!

So I got a new smart phone, which has been highly entertaining when I’m stuck in airports, or waiting for meetings or whatever. It’s a Moto-Q9. Boy is it sexy - lots of features, fairly fast. It kinda reminds me of what Windows95 used to be - usable but not fast. It has the new version of Microsoft’s mobile operating system on there with direct push on there (similar to Blackberry which saves battery life, I’m sure, for real time email), a 2mega pixel camera, etc… etc… Fun little toy. So id and I were driving around town and I was messing with my phone as he drove and it suddenly occurred to me, I had never really toyed with the browser. So I start messing around with the settings, and of course turn off JavaScript. But then I realized, I had never tested it with JavaScript turned on. That’s when I went to Mr. T. What did Mr. T do to the Moto Q9 (which is running Opera, by the way)? It crashed it immediately.

So then I start messing around with it, and I narrow it down to one of the things that’s more legacy than anything, the now fixed, MS mhtml bug. Uh oh. Yup, the mhtml bug appears to crash mobile Opera instantly. So back to keeping JS turned off, I guess (I haven’t tested if there is another way to cause the crash using a redirection or an iframe, but it takes a long time to test, so I’ll leave that to another day).

Then I start messing with the other options, like the “Identify as” function. With it turned to “handheld device” the user agent reads, “MOT-Q9/01.04.35R Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; Smartphone; 320×240) Opera 8.65 UP.Link/6.3.1.17.0″. Eesh! It gives my actual device type! So then I turn the setting to “desktop computer” it turns to “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0″. Okay, fair enough, that appears to be the more secure setting as at least it doesn’t say the revision and model number of the phone.

That is, of course, until you look at the rest of the headers:

HTTP_ACCEPT = application/xhtml+xml, application/vnd.wap.xhtml+xml, text/html, text/vnd.wap.wml, application/vnd.wap.wmlc, */*,text/x-hdml,image/mng,image/x-mng,video/mng,video/x-mng,image/bmp,text/html
HTTP_ACCEPT_CHARSET = iso-8859-1, utf-8, utf-16, *;q=0.1,*
HTTP_ACCEPT_ENCODING = deflate, gzip
HTTP_ACCEPT_LANGUAGE = en
HTTP_CACHE_CONTROL = no-cache
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0
HTTP_VIA = 1.1 alnmagr1fe09WAP2-mbl
HTTP_X_UP_DEVCAP_ACCEPT_LANGUAGE = en
HTTP_X_UP_DEVCAP_CHARSET = utf-8,ISO-8859-1,US-ASCII,UTF-16,GB2312,BIG5
HTTP_X_UP_DEVCAP_ISCOLOR = 1
HTTP_X_UP_DEVCAP_NUMSOFTKEYS = 2
HTTP_X_UP_DEVCAP_SCREENDEPTH = 16
HTTP_X_UP_DEVCAP_SCREENPIXELS = 320,240
HTTP_X_UP_DEVCAP_SMARTDIALING = 1
HTTP_X_UP_SUBNO = ppu_105cb54061e_vmag.mycingular.net
HTTP_X_WAP_PROFILE = “http://uaprof.motorola.com/phoneconfig/q-umts/Profile/mot-q9.rdf

Okay, so now we know my provider how big my screen is, that it’s a mobile device of course (the reference to wap), but more importantly we get the actual profile of the phone in the RDF file with all the settings, so you know exactly what may or may not work against the phone! Geez! Talk about giving up too much info! I hardly consider myself a cell phone hacker (for that you’ll need to talk with the Flexilis guys) but in 5 minutes I found all that - that’s not a good start. Whelp, so much for surfing from my phone!

You may have already read about this on Jeremiah’s site but the rumors about me being in a documentary are true. It’s a short one (only 20 something minutes, I think) but nevertheless. You can see a preview of it here. It’s trying to describe how serious the dangers of internet insecurity is to global economy. I thought it was really well done actually.

One thing I thought was hilariously ironic was a quote by Howard Schmitt (ex cyber security czar for the United States, who replaced Richard Clarke), “We should never ever ever be so arrogant to think that we’re not a potential victim or our data has not been compromised or that there’s not some adversary out there that’s just as smart if not smarter than we are who won’t be able to compromise that data.” Then the camera flashes back to me as he’s finishing his sentence. The irony being that I’ve actually briefly worked with Howard before. This industry is just too small sometimes! So there’s some funny editing work in there to point to me as the bad guy, but I’m not offended. Someone has to be the antagonist. Fortify is showing the documentary in three places around the world (SF, NY and London). It was fun!

While the fun is over, there is a lot to talk about in the wrap-up. So much so that I think it will take longer to deal with the output of the contest than the contest itself took. First of all, a huge congrats to both Giorgio Maone and Sirdarckcat for winning the contest with an incredibly small 161 byte worm. They tied because they both had nearly the same vector and it worked equally well. It was a tough battle and there were a lot of close calls, but various rules, cross browser compatibility and interoperability with Apache caused the pool of potential winners to be relatively small when the scoring was complete. However, that’s not to diminish everyone’s work - everyone did amazingly and I was very impressed when it all came together.

But now that leaves us to the aftermath. After looking at the contest for the first four days we may have figured out a way to potentially stop worm propagation. Unlike tracking this method actually may help companies devise plans on how to reduce the likelihood of worm propagation across their websites. This should put to rest the nay sayers who thought nothing good could come of this contest. The paper is not for everyone - it’s pretty complex (as worms tend to be), but I think the people who have the problem will understand how to use it in their own environments.

That said, there is at least two or three more potential outputs of this contest - including papers on propagation analytics, worm tracking technology, and potentially other things that I’m not privy to. Was it worth it? Absolutely. I couldn’t have been happier with the results. Thanks again to everyone who made it such a success. It was a lot of work, but it was the first step towards large scale worm defense. Again, a huge congrats to Giorgio Maone and Sirdarckcat!