Jeremiah Grossman

TEDxMaui -- Hack Yourself First

2012-01-23T18:52:00.000-08:00

Ten years ago if you would have told me that I'd be back living in Hawaii, founder of a fast growing technology company, and a TED speaker -- I would've said, "What's a TED?" Preparing for TEDxMaui was extremely difficult. The presentation format is completely different than anything I’ve ever done before. It was limited to just 18 minutes as opposed to 50, and given to an audience of every day people eager to see something amazing, instead of security professionals and high-tech workers. The message had to be crystal clear. Since TEDxMaui videos won’t be published until late February, you’ll have to settle for my substandard textual description for now.

I wanted everyone, both the viewers in the audience and those who would eventually watch the video, to deeply appreciate the crucial importance of Internet security. I want everyone to know that to discuss Internet security is really to discuss our economic well-being and our national security, and I want everyone to know that both are under attack -- every single day. Most of all I wanted everyone to know that hacking, and people learning how to hack, is absolutely essential to defend ourselves. I labelled this concept Hack Yourself First, the title of the presentation. Hack Yourself First advocates building up our cyber-offense skills, and focusing these skills inward at ourselves, to find and fix security issues before the bad guys find and exploit them.

Before presenting Hack Yourself First I had to first imagine how the audience would respond. Most watching undoubtedly have only had negative experiences with the words “hacking” and “hackers.” All they likely knew of hacking is in relation to viruses infecting their computers, stealing money out of (their) bank accounts, TV interviews of shadowy characters wearing Guy Fawkes masks, salacious articles featuring cyber villains, and of course bad hollywood movies. Whether we like it or not, these are the ambassadors of hacking, so the idea of teaching cyber-offense skills might be considered akin to illegal activity. Just the same, there I was on stage revealing that, “Yes, I am a hacker -- but not like them.”

I don’t know what precisely it was that I said, but the message of Hack Yourself First undoubtedly resonated in a big way. No less than a hundred people introduced themselves to me afterwards excitedly asking, “How do I learn to hack myself first?” Perhaps I shouldn’t have been, but I was blown away. And not just the very young or student age, I’m talking about people 45 up to 70 years old with zero technology background. Maybe it was because I taught them a simple hacking trick, a simple hacking trick they could grasp, and even do, like those from my “Get Rich or Die Trying” presentation. Suddenly the fascinating subject of hacking, which they previously assumed was too complicated to learn, was suddenly approachable. I taught a TED audience how to hack! How cool is that!? :)

Many in the information security industry have been trying desperately and in vain to raise Internet security awareness among the masses. We repeatedly give people laundry lists of what not to do, and it isn’t helping. Better awareness, better overall Internet security, could be accomplished through Hack Yourself First. Teach anyone and everyone who wants to learn how to do the actual attacks the bad guys use against them, perhaps packaged up in a Capture-the-Flag format. That would be a lot of fun for everyone. When people know precisely how hacking works, they’ll be in a better position to spot attacks against them and be on their guard.

I came to TEDxMaui to share my ideas with a wider audience, but what I came away with was more ideas from them about where we can take Hack Yourself First.

Terrified

2011-12-29T13:42:00.000-08:00

Over my career I’ve given exactly 295 public presentations, to audiences as small as a table full and up to many thousands. Audience members have said countless times that they really enjoy my speeches. Conference organizers always invite me back, and my feedback scores are always amongst the highest. These are accomplishments I’m proud of and a level of success only achieved with the help of a lot of dedicated people. You might think that after all this experience that I’m extremely comfortable on stage. The reality is that you’d be wrong, very wrong. What most don’t know is that each and every time I’ve present, to this day, I suffer from extreme anxiety, commonly known as stage fright. In my case, terrified would be a more accurate description.

I’ve been known to physically shake, have shortness of breath and a strained voice, speak far too quickly, be statuesque on stage almost like I’m hiding, and feel just overall completely stressed out. Early on I decided that no matter how terrified I was, my message needed to get out there, and it was more important than letting fear stop me. I think my #1 skill as a public speaker is hiding my fear, my terror. My theory was the more experience I gained the faster I’d overcome it. In the meantime in order to cope I developed a pre-presentation ritual.

I’d prepare heavily for each event, pour over the content in every slide, and seek candid feedback from those I trusted. I’d also commonly ask event organizer for details on audience demographics to specifically tailor my comments. I’d then practice ahead of time for small private groups in order to get the timing and flow down. If something or all of it sucked, I’d throw it out. With the assistance of my wife, I’d even get a plan down for precisely what I was going to wear during at show day. Nothing was left to chance. Finally, I block out an hour before each presentation to check out the stage, be alone with time to center, prepare and calm myself down, and of course continue tweaking slides. Being prepared helped take the edge off my anxiety a lot.

The problem was, or is, that no matter how many times I presented, the anxiety, the fear, and terror never really lessened. That is until this last year. Something changed, but what!? Had I finally overcome? I’m not an introspective person so it wasn’t until very recently that I think I figured it out. In 2011 my public presentations weren’t pushing the envelope as much as in years past. The content was good to be sure, but it also focused on “safe” business level subjects and incrementally advancing work from previous years. In short, I really wasn’t putting myself out there as far as I’m used to. In my case, the feeling or fear and terror arises when pushing forth an idea or a concept and unsure if people will think its uncompelling or totally idiotic. A chance you take.

That’s about when I got a call from the TED offering a speaking slot in TEDxMaui. We got to talking about my work and discussing an idea worth spreading. It didn’t take long. Then all of a sudden I’m thrust right back into fear and terror mode, but now that I understand it, the feeling is almost comforting. It signals that I have an opportunity to take things in my industry, in our industry, to a new level --- or of course drive right off a cliff. Either way it’ll be a good show! :)

How I got my start -- in Brazilian Jiu-Jitsu

2011-06-21T16:28:00.000-07:00

I’ve been a UFC fan for years, even before it was acquired by Zuffa. I was fascinated by the anything goes, hand-to-hand form of combat. I suppose it reminded me of growing up in Hawaii. :) The UFC was also enjoyable because it helped answer the question, “What martial-art or fighting style was most effective?” Karate? Kickboxing? Boxing? Wrestling? Ninjutsu? What matters more, size or technique?

The UFC provided a forum, the octagon, to settle the long-standing fight-world debate. Everyone had a theory, but no one really knew for sure. What became crystal clear even today is that every fighter must have a background in Brazilian Jiu-Jitsu or they WILL lose. It’s just that simple. My background was mostly striking, so I wanted to try out this ground fighting stuff.

A co-worker, also interested in the UFC, and I found a local BJJ academy in San Jose taught by black belt instructor Tom Cissero. Tom has a passion for the martial arts and, more importantly, for his students, as he deeply feels that they are a direct reflection upon his life and value as a person. Yes, he takes his craft that seriously, and serious he is. Tom is abrasive, aggressive, and combative, attributes covering up a heart of gold. In the academy Tom will push you hard, harder than any place else, to make you good. Whether you like it or not, and he cares enough to do so. That’s why I stayed with him the better part of a decade.

Anyway, my 6’2” - 300lbs, and let’s face it, seriously fat and way out of shape frame walks in -- admittedly with a little bit of big man ego. I see Tom instantly trying to size me up. Of course he had me figured out in all of 5 seconds as you’ll read in a moment. After signing the waver, doing some drills, and learning a couple of submissions I began to familiarize myself with the basic rules and gym etiquette. Then came sparring time. Tom loves the sparring sessions more than anything else. Probably because it measures your progress in stamina and skill.

Tom pairs me up with, and I kid you not, a 150 lbs or less woman in her mid 40’s and says let’s see what you can do. She’s a purple belt with several years of BJJ experience, but I’m thinking to myself WTF!? She’s half my size! I’m going to squash her! Then of course the whole situation is running counter to my internal man moral code, never fight girls. Not being given a choice, but also not wanting to be disrespectful, I decided to go really easy as I didn’t want to hurt her or anything.

The bells sounds, I come slowly forward towards her, she quickly closes the distance, spider monkeys to my back, chokes me, and forces me to tap out inside of 10 seconds flat. I was shocked and a little upset. Here I am going light and she takes advantage of me. Clearly she’s not playing around. To hell with this, no way I’m going to let that happen again! No more Nr. Nice Guy.

We touch hands, signaling to begin again, but I go harder this time trying to put her back on the mat. She again somehow sneaks around under my arm, like an octopus, and chokes me with the same damn move! To my credit, I lasted a few more seconds that time. This scenario repeats for about 4 to 5 minutes in the session, and for the life of me, as big strong guy, I could not keep this tiny older woman off my back and robbing the oxygen from my brain. Oh, and all the while she is speaking to me in a calm instructive voice. Humiliation is the best word to describe.

At the end of class I’m thinking to myself, there is something to this Brazilian Jiu-Jitsu stuff. However, that wasn’t the most important thing to me at that particular moment. There was no way I could go on about my life happily knowing that a such a women could kick my butt so easily. Call it machoism if you like, I don’t care. It was clear to me that I had to keep training BJJ at least long enough to beat her. It only took three years. Fortunately for me by that time the motivation to simply get better and enjoy myself became my primary driver.

By the way, that woman is still training there. So if you are a big guy, and plan to drop by for a visit, don’t say I didn’t warn you. You could quickly find yourself on a journey to becoming a BJJ black belt.

Web security content moving to new WhiteHat Security corp blog

2011-05-16T10:41:00.000-07:00

Many of you have noticed I haven’t been blogging in several weeks. The truth is I have been blogging, just not here! For those that missed the announcement, WhiteHat Security recently launched a new corporate blog, featuring over a half dozen other WhiteHat bloggers in addition to myself. To support and intermingle with other exceptionally solid posts, I’ve been directing my Web security content over there. If you review the archives you'll find cool stuff on scaling CSRF identification, DOM-based XSS, Bypassing CSRF tokens with a Flash 0-day, etc.

Here are some of my most recent posts that you may have missed:

See! I have been blogging. :) Consider updating your RSS feeds.

I'll continue posting here, only at a much lower volume, and exclusively about personal things like my adventures in Brazilian Jiu-Jitsu.

Sentinel SecurityCheck

2011-03-15T17:28:00.001-07:00

Have you been hearing about WhiteHat Sentinel for a while, but never had the opportunity to try out the service for yourself? We'd like to change that and make Sentinel accessible to more people. We've recently announced a new promotion, for those who are interested and qualify, to receive the full customer experience for 30 days -- for FREE. This is way more than just finding vulnerabilities. If you like it, great sign-up! If not, which is extremely rare, you owe nothing. Follow the link below for additional details.

WhiteHat Security Announces No Cost Website Vulnerability Assessment Program
Sentinel SecurityCheck offers organizations 30 days of continuous assessment to identify all website vulnerabilities and mitigate leading risk for data breaches; Participating companies gain access to WhiteHat Security's verified vulnerability results and personalized guidance on website risk management

11th WhiteHat Website Security Statistic Report: Windows of Exposure

2011-03-11T11:07:00.000-08:00

WhiteHat Security's 11th Website Security Statistics Report, presents a statistical picture gleaned from over five years of vulnerability assessment results taken from over 3,000 websites across 400 organizations under WhiteHat Sentinel management. This represents the largest, most complete, and unique dataset of its kind. WhiteHat Security makes this report available specifically for organizations that aim to start or significantly improve their website security programs, prevent breaches, and data loss.

Top 3 Key Findings (Full list available in the report)

Most websites were exposed to at least one serious* vulnerability every day of 2010, or nearly so (9–12 months of the year). Only 16% of websites were vulnerable less than 30 days of the year overall.
During 2010, the average website had 230 serious* vulnerabilities.
In 2010, 64% of websites had at least one Information Leakage vulnerability, which overtook Cross-Site Scripting as the most prevalent vulnerability by a few tenths of a percent.

Window of Exposure is an organizational key performance indicator that measures the number of days a website has at least one serious vulnerability over a given period of time.

Download the Full Report...

Robert “RSnake” Hansen, age 34, has passed away, on Facebook

2011-03-10T10:33:00.000-08:00

Facebook encourages people to keep up with friends and family through those familiar little website reminders notices. In some cases the person suggested in the reminder has passed away, which would explain the account inactivity, and this might obviously be taken as offensive and emotionally distressing. Facebook recognizes this and offers a process where they allow accounts to be “Memorialized” on the recommendation of a “friend” by filling out the appropriate form.

“When a user passes away, we memorialize their account to protect their privacy. Memorializing an account sets the account privacy so that only confirmed friends can see the profile or locate it in search. The Wall remains, so friends and family can leave posts in remembrance. Memorializing an account also prevents anyone from logging into the account.”

As many readers might recall, a couple months ago Robert “RSnake” Hansen, best known for his contributions to Web security, bid his farewell in a final 1,000th blog post. Since RSnake has departed “the scene,” he is effectively dead in an online sense. As such some felt it only fitting that his Facebook persona follow a similar path and shake off its digital coil. To get RSnake’s page memorialized all that was required was finding a person who shared the same name, who had a recent obituary published somewhere online, lived in roughly the same area, and then fill out the necessary form. Not to long after...

If you are a Facebook friend of RSnake, you may still pay your last respects to him on his wall. Rest assured that while he can no longer reply himself, he is indeed smiling (or LHAO) down on us all from above.

Top Ten Web Hacking Techniques of 2011

2011-02-21T10:32:00.000-08:00

This post will serve to collect new attack techniques as they are published. If you think something should be added, please comment below and I'll add them.

"Every year the Web security community produces a stunning amount of new hacking techniques published in various white papers, blog posts, magazine articles, mailing list emails, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and so on. Beyond individual vulnerability instances with CVE numbers or system compromises, we're talking about actual new and creative methods of Web-based attack. The Top Ten Web Hacking Techniques list encourages information sharing, provides a centralized knowledge-base, and recognizes researchers who contribute excellent work."

Current 2011 List

Previous Winners
2010 - 'Padding Oracle' Crypto Attack
2009 - Creating a rogue CA certificate
2008 - GIFAR
2007 - XSS Vulnerabilities in Common Shockwave Flash Files
2006 - Web Browser Intranet Hacking / Port Scanning

BINGO! for Application Security

2011-02-03T07:55:00.000-08:00

In case you need something fun to do during an RSA 2011 or OWASP Summit 2011 presentation.

Web Browsers and Opt-In Security

2011-02-02T11:50:00.000-08:00

The last decade has taught us much about computer and information security. We’ve learned the importance of Secure-By-Default because people rarely harden their “security” settings as standard practice. We’re also painfully aware that security is often a trade-off between functionality and usability, which requires a balance be made. Ideally this balance is decided between what level of security a product claims and the customer’s expectations. Operating systems and Web servers have taken a strong supporting stance with regards to Secure-By-Default. Web browsers, well, I think there is much room for improvement.

Let’s look at recent outcomes shall we. According to CA Technologies, "Browser-based exploits accounted for 84% of the total actively exploited known vulnerabilities in the wild." Other industry reports support these findings including, "Of the top-attacked vulnerabilities that Symantec observed in 2009, four of the top five being exploited were client-side vulnerabilities that were frequently targeted by Web-based attacks." 2010 wasn’t much different. This is typically the result of a combination of imperfect software and not keeping browsers & plug-in patches up-to-date.

Even in this context the browser vendors (Google, Microsoft, and Mozilla) should still be given a lot credit for having been vastly improved the overall security of their software in the last two or so years. They have better development practices, publish regular and timely patches, included easy scheduled update mechanisms, added anti-malware/phishing features, sandboxes, and bounty programs. Collectively speaking anyway, but that's where it ends. All great benefits that users receive automatically and/or enabled by default. That is, Secure-By-Default. Memory handling issues aside, where these protections mainly focus, are still many extremely devastating attack classes where users have practically zero ability to defend themselves.

I'm talking about Intranet Hacking, DNS Rebinding, Clickjacking (UI Redressing), Cross-Site Scripting, Cross-Site Request Forgery, CSS History Leaks, and WiFi Man-in-the Middle. I see these as being the most pressing. They break the back of the Same-Origin-Policy, the very foundation of browser security, and there’s evidence that most of these have been used maliciously in the wild. A malicious website can easily detect what websites a visitor is logged-in to, what sites they’ve recently visited, take over their online bank/email/socialnetwork/etc accounts, hack into their DSL router or corporate intranet. Or maybe the attacker wants to get the victim in legal trouble by forcing them to attack other systems, post spam, download illegal content, and so on.

Sure, an individual user can defend themselves with add-ons like NoScript, Adblock Plus, LastPass, Better Privacy and so on, of which I’m a fan and user. To reiterate though, this is in no way a demonstration of Secure-by-Default! Users have to first be aware, download the application, install, and finally configure. The reality is most users don’t know these attackers are possible and even easy to perform. Only the readers of this blog and the browser vendors themselves do. So from a 10,000ft view of Web security, if a protection feature is not enabled by default then it doesn’t matter. Case in point...

To combat these issues, keep the security-minded elite mildly happy, and show that "something" is being done, there’s a mile long list of well intentioned security features that extremely few people outside of out tiny Web security sphere have heard of let alone implemented. HTTP Strict Transport Security, SECURE cookie flag, httpOnly cookies, X-FRAME-OPTIONS header, Origin header, Do-Not-Track header, disable form AutoComplete, iFrame security restriction, Content Security Policy, privacy modes, hidden configuration settings, delete browser data, cookie controls, LSO controls, etc. All of these are opt-in, invisible or buried several mouse-clicks deep in the GUI, and likely implemented differently. No wonder "The Need for Coherent Web Security Policy Framework(s)" was published.

There are lots of competing arguments about why these things haven't been or shouldn't be formally adopted. My intention here is not to rehash those, but instead remind us all about the bigger picture. I mean, it is simply amazing how much we are able to do online with just a browser. We can shop, bank, pay bills, file taxes, share photos, keep in touch with friends and family, watch movies, play games, and so much more. Browsers are the most important connection we have to the Internet. And the “we” is a stunning two billion people strong. Clearly browsers play a vital role in online security. Everyone needs a Web browser that is not only fast and stable, but secure as well. Only it is difficult to say that they are (or have been)... secure. That needs to change, somehow, someway, and preferably soon.

Remote participation for the 2011 OWASP Summit

2011-02-02T08:33:00.000-08:00

The OWASP 2011 Summit looks like it shaping up to be quite an event! From across the globe the top Web application security minds, practitioners, vendors, and influencers are showing up to help shape things to come. Check out the working sessions. As mentioned in an earlier post, I'm unable to attend due to a scheduling conflict. However, our own Arian Evans (VP, Operations) will be carrying the WhiteHat Security flag.

Fortunately for the rest of us, it looks they are organizing a professional video/audio feed for remote participation. Dinis Cruz is asking those interested to fill out a form to help accommodate the broadcast scheduling. I did just that.

Do-Not-Track (How about piggybacking on the User-Agent?)

2011-02-01T10:33:00.000-08:00

I think I’ve read just about every white paper, article, blog post, and tweet about Do-Not-Track (DNT), including the FTC’s recent 121 page preliminary staff report that thrust the concept into public consciousness. For those unfamiliar with what DNT is exactly, not to worry, it is really very simple.

The idea behind DNT is providing online consumers, those sitting behind a Web browser, an easy way to indicate to third-parties that they do not want to be "tracked" -- they opt-out. DNT would hopefully replace todays system of having to register with dozens of different provider websites to obtain “opt-out” cookies.

As the FTC pointed out, the out-out cookie approach proved unscalable and could never have been effective with the spirit of its intent, consumer privacy. Adding insult to injuring, anyone seeking to improve their privacy by deleting all their cookies would simultaneous delete their opt-out cookies too. They’d have to perform opt-out registration all over again. No wonder the advertisers and tracking companies support this model.

The FTC report gave no real technical guidance on how DNT should be implemented. Not that they should have. What you must first understand about DNT is that in all models, there is NO real technical privacy enforcement. Basically the consumer is asking (buried somewhere invisible in the HTTP protocol) anyone who is listening, “please do not track me.” It is then on the honor of the tracking companies across the Internet to support the DNT system and comply with the request when they have no legal obligation to do so. Which is not to say DNT is without value. It would be helpful to have a legal remedy available when all technical self protection mechanisms eventually breakdown.

Since DNT started making headlines Google, Microsoft, Mozilla, and various browser plug-in developers have been experimenting with different approaches to DNT in their respective Web browsers. The one seeming to get the most traction at the moment is adding a special 'DNT' header to each HTTP request. For example:

"DNT: 1" - The user opts out of third-party tracking.
"DNT: 0" - The user consents to third-party tracking.
[No Header] - The user has not expressed a preference about third-party tracking.

At first glance this does appear to be the logical and superior model over all others I’ve seen so far. Then I got to talking with Robert “RSnake” Hansen about this and we came to a slightly different conclusion to where DNT would best go. First remember that there are a lot of great big powerful corporate interests that really don’t like DNT and what it represents. If effective and widely adopted, business models are odds with consumer privacy choice would be seriously threatened. Opponents to DNT will seek to confuse, sabotage, derail, downplay, and stall progress at every opportunity. The final accepted protocol must be resilient to a large portion of the Internet hostile to its very existence.

DNT data must be able to traverse the Internet to its destination unaltered and be logged on the other end (the Web Server) for auditing / statistical purposes. If DNT ends up being a new HTTP request header, those headers like most others are rarely logged and never by default. It would be far too easy for a tracking company to ignore DNT headers and claim they never got them. Proving otherwise would be difficult for a plaintiff.

An alternative is piggybacking DNT onto an already well established header. A header one that no one in the connection stream would typically think of touching and that is already widely logged -- by default. The User-Agent header would make sure an ideal candidate. Imagine something like this with the DNT tacked onto the end:

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 DNT: 1

Simple. Easy. Logged.

Now if we can just encourage the browser vendors to enable it by default. :)

Travel the World, Meet new People, and Fight them

2011-01-31T15:14:00.000-08:00

I’ve been training Brazilian Jiu-Jitsu for a little over 5 years now, sprinkled in with a little Muay Thai and Boxing to complement the ground game. I’ve average a two hour class about 4 days a week, which has resulted in a loss of 60lbs (kept off) and a respectable brown belt. I’m currently working my butt off to earn black. While being a BJJ black belt would be unbelievably cool, honestly the belt color isn’t all that important to me. I’ll be training for as long as I’m physically about to for life regardless. The power of this martial art is simply amazing.

Right now I’d prefer to be training BJJ (MMA) twice a day 4-5 days a week, but between WhiteHat and family commitments there is just no way. When vacationing in Maui that’s pretty much what I do with all my down time, in between going to the beach of course. My BJJ game skyrockets to new levels super fast because guys out there are no joke. Everyone is in shape and train all the time. You’ll even find private MMA cages in people back yards that provide “something to do” when there’s no waves.

My job requires me to travel a lot. I’ve been to 5 continents, about two dozen countries, and 35 or so US states. Fortunately there has been an explosion in the number of BJJ academies thanks in large part to the UFC and MMA phenomenon. There’s at least one academy in every major US city I’ve been to and make a point to visit as many as I can. I always fly with my gi, rash guard, mouth guard, and fight short. Trained in about 20 academies across the US and abroad, including in Brazil where of course BJJ all began. I don't do this to try and prove how tough I am or anything, mostly just looking for a good workout (way better than the gym), learn a new move or two, and benchmark my progress. So if see me on stage with what looks like mascara, you’ll know why.

In 99% of the academies I’ve had lots of fun and amazing an experience. Got to meet some really cool people outside of the security industry and keep perspective on things. I’ve also learned a couple of important lessons on what NOT to do:

1) Don’t visit an unfamiliar academy as an out of town traveler unless you are a solid blue belt level or above, which equates to at least a year or more of hard training experience. Not everyone, instructor and students, are nice people so you must be able to truly protect yourself from serious injury in the rare case that someone is actually trying to hurt you. I’ve never had a problem in a strict BJJ (Gi) academy, but some “MMA” (No-Gi) places do have a level of “fighter” attitudes where some try to prove themselves outside of the cage. I’ve only had to deal with this kind of ego twice before. Both times it didn’t end up good for the other guy. They slept, I left.

2) As a sign of respect, call ahead and speak with the instructor. Introduce yourself and your training background. This lets the instructor know where to place you with their students skill wise and tell you if the place isn’t right for you for whatever the reason. Again, I’ve had two moderately bad experiences showing up to a martial arts academy unannounced. One was a primarily an Aikido place and the other Taekwondo, both advertising some BJJ classes on their site. Apparently the instructors in those disciplines also taught the BJJ class, but weren’t highly skilled. I asked if they do full speed sparring, to which they nodded. Once they found out my level, they wanted no part of me and asked that I leave. I think they were concerned that I might tear up their students or something and make the school look bad. Who knows, I complied.

3) NEVER tap anyone in an unfamiliar academy that is a higher belt than you. I hate this rule, but take my word for it. If you get a hold of a submission, let it go. Of course that doesn’t mean you go and let yourself get tapped out. Screw that! Fight to maintain control over your opponent, flow with the go, which demonstrates skill more than just about anything. While it shouldn’t be the case, I’ve a bad experiences when tapping the instructor. Things turn in Abu Dhabi night in an instant. I won’t be making this mistake again until I’m a black belt.

Remember the quote from The Matrix Reloaded, "…you don’t really know someone until you fight them." I’ve found this to be profoundly true, including in myself. A persons true mental disposition really shows when they are under physical duress. Chris Hoff (@beaker), cloud infosec icon, also trains BJJ while on the road. We’ve locked up in battle on the mat several times. His game reflects his personality. He's elusive and unassuming, but DO NOT underestimate him for one moment. He’ll catch you off guard the very moment you back off and not paying very close attention. For me its not who beats who, but having fun, bringing my best game, and see what happens. Learning where Chris is getting an edge on me or where I missed an opportunity.

BJJ Smackdown during RSA 2011
Feb 17, 7-9pm
Ralph Gracie's School
Everyone is welcome, but contact @jeremiahg or @beaker

Top Ten Web Hacking Techniques of 2010 (Official)

2011-01-17T10:05:00.000-08:00

Every year the Web security community produces a stunning amount of new hacking techniques published in various white papers, blog posts, magazine articles, mailing list emails, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and so on. Beyond individual vulnerability instances with CVE numbers or system compromises, we're talking about actual new and creative methods of Web-based attack. Now it its fifth year the Top Ten Web Hacking Techniques list encourages information sharing, provides a centralized knowledge-base, and recognizes researchers who contribute excellent work.

Since inception of the Top Ten Web Hacking Techniques list, the diversity, volume, and innovation of security research has always been impressive. 2010 produced 69 new attack techniques! This years point-position voting system worked well and the results showed exceptionally strong competition throughout all the entries. In fact, only two entries did not gain any points.

I’d like to take a moment again to thank everyone who took the time to fill out the voting surveys including those who were on this years expert panel. Ed Skoudis (InGuardians Founder & Senior Security Consultant), Giorgio Maone (Author of NoScript), Caleb Sima (CEO, Armorize), Chris Wysopal (Veracode Co-Founder & CTO), Jeff Willams (OWASP Chairman & CEO, Aspect Security), Charlie Miller (Consultant, Independent Security Evaluators), Dan Kaminsky (Director of Pen-Testing, IOActive), Steven Christey (Mitre), and Arian Evans (VP of Operations, WhiteHat Security). Also a big thanks to our sponsors BlackHat, OWASP, various Web security authors, and WhiteHat Security.

Today the polls are close, votes are in, and the official Top Ten Web Hacking Techniques of 2010 has been finalized! For any researcher simple the act of creating something unique enough to appear on the complete list is itself an achievement. To make it on to the top ten though, is well, another matter entirely. These researchers receive special praise amongst their peers who selected them and take their place amongst those highlighted in previous years (2006, 2007, 2008, 2009).

Top honors go to Juliano Rizzo and Thai Duong for their work on the “'Padding Oracle' Crypto Attack” They’ll receive a free pass to attend the BlackHat USA Briefings 2011! (sponsored by Black Hat) and a library of autographed Web security books.

In second place is Samy Kamkar for his work on “Evercookie.” He’ll receive a free pass to OWASP Conference Pass (sponsored by OWASP).

And finally, everyone appearing on the top ten will receive custom designed t-shirt (sponsored by WhiteHat Security).

Top Ten Web Hacking Techniques of 2010!

1) 'Padding Oracle' Crypto Attack (poet, Padbuster, demo, ASP.NET)
Juliano Rizzo (@julianor), Thai Duong (@thaidn)

2) Evercookie
Samy Kamkar (@samykamkar)

3) Hacking Auto-Complete (Safari v1, Safari v2 TabHack, Firefox, Internet Explorer)
Jeremiah Grossman (@jeremiahg)

4) Attacking HTTPS with Cache Injection (Bad Memories)
Elie Bursztein (@ELIE), Baptiste Gourdin (@bapt1ste), Dan Boneh

5) Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
Lavakumar Kuppan (@lavakumark)

6) Universal XSS in IE8 (CVE, White Paper)
Eduardo Vela (@sirdarckcat), David Lindsay (@thornmaker)

7) HTTP POST DoS
Wong Onn Chee, Tom Brennan (@brennantom)

8) JavaSnoop
Arshan Dabirsiaghi (@nahsra)

9) CSS History Hack In Firefox Without JavaScript for Intranet Portscanning
Robert "RSnake" Hansen (@rsnake)

10) Java Applet DNS Rebinding
Stefano Di Paola (@WisecWisec)

At IT-Defense 2011 (Feb.) it will be my great honor to introduce each of the top ten during my “Top Ten Web Hacking Techniques of the Year (2011)” presentations. Each technique will be described in technical detail for how they function, what they can do, to whom, and how best to defend against them. The audience will get an opportunity to better understand the newest Web-based attacks believed most likely to be used against us in the future.

The Complete List

How-to send HTML email, XSS testing WebMail systems

2011-01-11T15:55:00.000-08:00

If you come across a WebMail system that supports HTML email (no JavaScript) like GMail, Y! Mail, and Hotmail, then it's extremely helpful to know how exactly to send HTML email to test those anti-XSS filters. I don’t recall seeing a how-to on the subject anywhere in the webappsec circles. To send arbitrary HTML email, laced with filter evading JavaScript, requires only a specially crafted text file and a *unix command line. Copy / Paste the following into a plain text file (email.txt):

MIME-Version: 1.0
From: your.name
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: INSERT_SUBJECT

INSERT WHATEVER HTML/JAVASCRIPT CONTENT

.

The trailing dot is not a typo, it terminates the end of the message so make sure the file always ends with it. Second, leave the Content-Type, Content-Transfer-Encoding, and MIME-Version headers as they are. Beyond that, you are free to modify and insert your HTML/JavaScript injections wherever you’d like including the email subject and content body. You can also spoof the return email address and add arbitrary email headers using the same format. Once you got something to want to send, well email, type this Unix command:

> sendmail -t email_recipient@domain.com < email.txt

The -t flag is where you want to send the email to and redirect in whatever you named your email text file to sendmail. That’s it! Happy XSS hunting!

The Application Security Spending Conundrum

2011-01-11T12:38:00.000-08:00

Recently I needed to purchase automobile insurance. To obtain a quote, the online insurer asked my age, where I lived, how much I drive and where, the year, make, and model of my cars, about my driving record, and how much coverage I wanted. Behind the scenes, they likely took these data points, applied them to some vehicle claim actuarial data, and presented me with a rate based upon MY effective overall risk score. The process made sense, the price was fair, and I ended up buying.

This got me thinking. What if instead the insurer had said, “We’ll give you the same coverage as everyone else who applied, add some protection for a new, obscure, scary-sounding road hazard, and bill you 15% over last year.” Without taking anything about at all about ME into account, it would seem that there was no real risk management involved in their decision-making. As a consumer, I would reject this offer. Clearly this makes zero sense. Ridiculous as this scenario sounds, isn’t this fairly similar to the process of creating information security budgets?

Gunnar Peterson explains it best, “Security budgets are often based on a combination of last year's spending, this year's threat(s) du jour, and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s.”

I agree and I think this is precisely why we see so many organizations spending a larger percentage of their budgets protecting their networks and infrastructure, as opposed to their applications, where the largest chunk of IT dollars are invested. In Gunnar’s words, “...they are spending $10 to protect something worth $5, and in other cases they are spending a nickel to protect something worth $1,000. If you look at the numbers objectively, you see why it is out of control...” Worse still, this budget misallocation persists despite real-world data revealing where the real threats are (at the application layer, Verizon’s DBIR) and in stark contrast to the infosec pros’ own stated priorities.

A survey conducted by FishNet Security of IT pros and C-level executives from 450 Fortune 1000 companies found that: “45% say firewalls are their priority security purchase, followed by antivirus (39%), and authentication (31%) and anti-malware tools (31%)." The report goes on to say, "Nearly 70% [of those surveyed] say mobile computing is the biggest threat to security today, closely followed by social networks (68%), and cloud computing platforms (35%). Around 65% rank mobile computing the top threat in the next two years, and 62% say cloud computing will be the biggest threat, bumping social networks." This is pretty funny because Mobile, Social Networking, and Cloud attacks specifically bypass those firewall investments.

To resolve this spending conundrum, and begin closing the application security gap, I see two option:

1) Information security professionals must align their investments with business priorities, which is what Gunnar wisely advocates. He says, “the biggest line item in [non-security] spending should match the biggest line item in security.” In almost every enterprise, this would mean redirecting network security dollars to application security. Even if this approach makes perfect sense, there is no question budget re-allocation would meet fierce opposition. Nothing less than a paradigm shift in thinking, culture and regulatory design would allow this to come to pass. Unfortunately, I think it is nearly impossible for the masses.

2) Information security professionals would need to convince management to approve new additional budget dollars specifically for application security, without reducing other budgets. Ideally, these application security investments could be justified directly or indirectly to increased revenue or reduced costs. Ask yourself, how might application security investments contribute to new customer acquisition? Can the business increase its differentiation? Obviously this won’t solve the spending inefficiency conundrum, but we might be able to gain ground and close the gap using this approach. To do so we need more case studies and benchmarks to demonstrate how other organizations are investing.

Fortunately, from an industry perspective, these choices are NOT mutually exclusive. Each organization will of course have to find its own path. In a future post I'll list out ways I've seen organizations justify application security budgets. In the meantime, if you have ways that you've found successful, comment below!

Final Fifteen - Web Hacking Techniques

2011-01-10T10:01:00.000-08:00

Open community voting completed last week. From the ~67 Web hacking techniques, we’ve gotten down to the final fifteen (see below). Congratulations to all the researchers whose work made it. Also, thank you very much to all those who took the time to complete the survey. There were a total of 74 respondents, 63% of which were“Breakers” and the other 37% “Builders.” Good representation.

Now it’s time for the final phase where our panel of security experts vote on the list (same position point system) to determine the Top Ten Web Hacking Techniques of 2010. All those on the panel have substantial industry technical experience, domain knowledge in application security, and do not have entries on the list.

This year we’re very pleased to have:
Ed Skoudis (InGuardians Founder & Senior Security Consultant)
Giorgio Maone (Author of NoScript)
Caleb Sima (CEO, Armorize)
Chris Wysopal (Veracode Co-Founder & CTO)
Jeff Willams (OWASP Chairman & CEO, Aspect Security)
Charlie Miller (Consultant, Independent Security Evaluators)
Dan Kaminsky (Director of Pen-Testing, IOActive)
Steven Christey (Mitre)
Arian Evans (VP of Operations, WhiteHat Security)

Final Fifteen

Open letter to OWASP

2011-01-07T10:05:00.000-08:00

The OWASP Summit 2011 in Portugal is coming up soon! This is an opportunity for the community’s leaders and influencers to discuss the future of the organization and that of the application security industry. The working sessions are creative, diverse and forward-thinking, designed to direct standards, establish roadmaps, and improve organizational governance. Unfortunately I’ve a conflict in my schedule and unable to attend, but I am excited to be presenting at IT-Defense in Germany. Fortunately for me Jeff Williams (OWASP Chairman) put a call out for feedback on the Summit’s. Since I can’t be physically present, I’ve taken this as opportunity to share my thoughts for organizers and attendees to consider.

Before getting to the list, I’d like to remind everyone that I was personally present many years ago at the beginnings of OWASP. Since then I’ve contributed to many different projects where I prefer to spend my time. I’ve visited over a dozen local OWASP chapters, including several international conferences to present, where I met new people and shared ideas. Written blog posts and articles directing people to OWASP materials. Through sponsorship dollars from WhiteHat Security, we’ve financially supported the good work the organization does. So with this in mind, please take the following as purely constructive with a desire for OWASP and the industry at large to flourish.

1) Hold a Board of Directors Vote
To my knowledge, and I’m open to correction, OWASP has never had an official Board of Directors vote. At least not one where membership could participate. Is this covered in the by-laws? It should be. Update: Indeed I have been corrected. See Dan Cornell's comment below that nicely detail a 2009 membership vote that resulted in the addition of two new BoD seats. Embarrasing that I missed this. I'm told (via twitter) that after the summit there will be an plan laid out where half the current seats will go out for a vote. Progress!

OWASP is a community of volunteers and like any community it should be managed openly and democratically. I love the fact that the budget itself has been made transparent. Holding a BoD vote would increase confidence in the organization and establish personal ownership and accountability in OWASP’s future. A future where a someones individual contribution, commitment, and merit may be rewarded with a position of greater influence and responsibility.

I do not make this recommendation lightly as I know most of the current board members personally, whom I respect, who have given so much of themselves over the many years, and deserve our appreciation. They’ve done a remarkable job and this is in no way should be considered an indictment. I’m saying that for OWASP to continue to thrive, room must be made at the top most levels for new participants with fresh ideas.

2) It is time for an OWASP Chief Executive Officer
OWASP would be well-served by the creation of a President / CEO position just like Mozilla and other highly successful non-profits. A full-time person responsible for the day-to-day operational affairs and growing the organization. A go to person for global committee members, project leaders, members, sponsors, press, etc. who has the authority to make decisions and get stuff done expeditiously. OWASP generates enough revenue, with sufficient growth, and has enough stuff to easily justify such a position. No doubt others besides myself have experienced much internal confusion and disorganization within that stifles and frustrates those seeking to contribute. The right person could help clean all that up and make things much more efficient and productive.

Second, this person also must serve as an industry cheerleader. It is vital that someone representing OWASP is constantly out there raising awareness and sharing why its a good idea for every developer, security professional, and software generating organization to be involved. Someone who can meet personally with CEOs, CIOs, CTOs, and CSOs of organizations large and small to gain their support. Obviously this can’t happen on a part-time basis with people employed by for-profit “vendors.”

3) Less preaching to the choir, engage more with the outsiders
Everyone in the community recognizes the echo chamber issue. We know the vast majority of who we need to reach, those who do not voluntarily come to us, the application security industry. So of course they have no way of knowing why the work we do is important, how it affects the safety and privacy in their lives, and the viability of online business. Without addressing this issue, the summit runs the risk of perpetuation the problem. I’ve been as guilty as anyone. Therefore instead of continuing to expect people to come to us over the last several years I’ve been transitioning to going to where they are, and with much success! OWASP should do the same to spread the word and take itself to the next level.

For example, OWASP representatives could attend, sponsor, and present at every possible non-security conference such as JavaOne, F8, Google I/O, any O'Reilly event, Star East/Web and so on where thousands of developers gather. In my experience at these events, when in their own element, developers are eager to learn about the state-of-the-art in application security, especially when presented in a way where they can derive value immediately when they get back to work. These attendees also represent a segment of developers who really care about their software. OWASP should proactively reach out to conference organizers with menu of official up-to-date topics and facilitate the CFP process on behalf of qualified representatives. Or, better still, offer to establish and manage an entire security track! Done right with a call to action, this alone would drive much needed membership.

4) Investment justification
Mountains of documentation on what organizations “should be doing,” are already available. Information security professionals are desperate for resources in how to justify to the business why an investment in application security is crucial. Effective application security programs aren’t easy or cheap to build. They require real organizational change and budget dollars to involve people, process, technology, and services. The justification cannot be because it’s “the right thing to do,” “PCI-DSS said so,” or “the APTs will get us!” That’s unconvincing and mind numbingly old. OWASP can help everyone do better.

One way is by capturing success stories from the OWASP corporate and individual membership. Real people, real companies, who are named, documented, and publicly highlighted. Ask them share how much OWASP materials helped them. What they did exactly and how it positively impacted the organization. Ask them to quantify some metrics in how much they are investing, how they are budgeting, all of which creates a watermark for others. These stories are key proof points their peers can use to follow the paths paved by early adopters.

5) Directly get involved with the PCI-DSS
PCI-DSS, despite whatever you think of it, does drive people to OWASP, but often under negative circumstances. Adoption of the OWASP Ten Top is not something e-commerce merchants necessarily want to do, but are forced to and no one likes to be forced to do “security.” As has been said privately to me, “What is OWASP except a bunch of crap I have to deal with for PCI?” This is the unfortunate net effect on attitudes. Merchants are incentivized to do the least application security they can get away with and NOT apply the Top Ten in the spirit of its intent. Either way, this makes OWASP look bad because the outcomes are indeed, bad. Of course PCI-DSS’s usage of the Top Ten in this manner was not something OWASP ever asked for, but here we are just the same.

Perhaps I’m not the first to say it, but this misuse has gone on long enough. If the PCI Council insists on using OWASP materials as an application security standard, which could be mutually beneficial, a good one must made available. Something clear, concise, and specifically designed for the risk tolerance of their credit card merchants. I believe this is what the OWASP PCI Project was meant to accomplish, but the status appears inactive. Fortunately there’s time to rekindle the effort as my understanding is the next revision to PCI-DSS is at least a year or two off. Done right, this could have a profound impact on a large segment of the Internet who currently get hacked all the time -- compliant or otherwise.

There you have it, my thoughts. I have more ideas, but I think that’s enough to chew on for now. :)

Vote Now! Top Ten Web Hacking Techniques of 2010

2011-01-03T10:12:00.000-08:00

Update: Open voting is now close. Thank you to all who participated!

The selection process for Top Ten Web Hacking Techniques of 2010 is a little different this time around. Last year the winners were selected by a panel of distinguished security experts. This year we'd like you, the Web security community, to have an opportunity to vote for your favorite research!

Here’s how it’ll work:

Phase 1: Open community voting
From of the field of 67 total entries received, each voter (open to everyone) ranks their fifteen favorite Web Hacking Techniques using a survey. Each entry (listed alphabetically) get a certain amount of points depending on how highly they are individually ranked in each ballot. For example, an each entry in position #1 will be given 15 points, position #2 will get 14 point, position #3 gets 13 points, and so on down to 1 point. At the end all points from all ballots will be tabulated to ascertain the top fifteen overall. And NO selecting the same attack multiple times! :) (they'll be deleted)

Voting will close at the end of the day this Friday, January 7.

The more people who vote, the better the results! Vote Now!

Phase 2: Panel of Security Experts

From the result of the open community voting, the top fifteen Web Hacking Techniques will be voted upon by panel of security experts (to be announced soon). Using the exact same voting process as phase 1, the judges will rank the final fifteen based of novelty, impact, and overall pervasiveness. Once tabulation is completed, we’ll have the Top Ten Web Hacking Techniques of 2010!

Voting will close at the end of the day on Friday, January 14.

Winners will be announced January 17!

Good luck everyone.

Which mountain would you rather climb?

2010-12-22T16:16:00.000-08:00

Some Web application vulnerability scanners, dynamic and static analysis, are designed for comprehensiveness over accuracy. For others, the exact opposite is true. The tradeoff is that as the number of "checks" a scanner attempts increases causes the amount of findings, false-positives, scan times, site impact, and required man-hour investment to grow exponentially. To allow users to choose their preferred spot between those two points, comprehensiveness and accuracy, most scanners offer a configuration dial typically referred to as a "policy." Policies essentially ask, "What do you want to check for?" Whichever direction the comprehensiveness dial is turned will have a profound effect on the workload to analyze the results. Only this subject isn't discussed much.

Before going further we need to define a few terms. A "finding" is something reported that’s of particular interest. It may be a vulnerability, the lack of a “best-practice” control, or perhaps just something weird warranting further investigation. Within those findings are sure to be "false-positives" (FP) and "duplicates" (DUP). A false-positive is a vulnerability that’s reported, but really isn’t one for any variety of potential reasons. Duplicates are when the same real vulnerability is reported multiple times. "False-negatives," (FN) which reside outside the findings pool, are real vulnerabilities with true organizational risk, that for whatever reason the scanner failed to identify.

Let’s say the website owner wants a "comprehensive" scan. A scan that will attempt to identify just about everything modern day automation is capable of checking for. In this use-case it is not uncommon for scanners to generate literally thousands, often tens or hundreds of thousands, of findings that need to be validated to isolate the ~10% of stuff that’s real (yes, a 90% FP/DUP rate). For some spending many many hours vetting is acceptable. For others, not so much. That’s why the larger product vendors all have substantial consulting divisions to handle deployment and integration post-purchase. Website owners can also opt for a more accurate (point-and-shoot) style of scan where comprehensiveness may be cut down by say half, but thousands of findings becomes a highly accurate hundreds or dozens thereby decreasing validation workload to something manageable.

At this point it is important to note, as illustrated in the diagram, even today’s top-of-the-line Web application vulnerability scanners can only reliably test for roughly half of the known Web application classes of attack. These are the technical vulnerability (aka syntax related) classes including SQL Injection, Cross-Site Scripting, Content-Spoofing, and so on. This holds true even when the scanner is well-configured (logged-in and forms filled out). Covering the other half, the business logic flaws (aka semantic related) such as Insufficient Authentication, Insufficient Authorization, Cross-Site Request Forgery, etc. require some level of human analysis.

With respect to scanner output, an organizations tolerance for false-negatives, false-positives, and personnel resources investment is what should dictate the type of product or scan configuration selected. The choice becomes a delicate balancing act. Dialing up scanner comprehensiveness too high, get buried in a tsunami of findings. What good is comprehensiveness if you can’t find the things that are truly important? On the other hand dialing down the noise too far reduces the number of vulnerabilities identified (and hopefully fixed) to the point where there's marginal risk reduction because the bad guys could easily find one that was missed. The answer is somewhere in the middle and one of risk management.

About 20 km west of Mount Everest (29,029 ft. ASL) is a peak called Cho Oyu (26,906 ft. ASL), the 6th highest mountain in the world. The difference being the two is only 2,000 ft. For some mountain climbers the physical difficulty, risk of incident, and monetary expense of that last 2,000 ft necessary to summit Everest is just not worth it. For others, it makes all the difference in the world. So, just like scanner selection, an individual decision must be made. Of course the vendor in me says just use WhiteHat Sentinel and we’ll give you a lift to the top of whichever mountain you’d like. :)

Vendors take Note: Historically, whenever I've discussed scanners and scanner performance the comments would typically be superficial marketing BS with no willingness to supply evidence to backup the claims. As always I encourage open discourse, but respectfully if you make claims about your product performance, and I sincerely hope you do, please be ready to do so with data. Without data, as Jack Daniel as concisely stated, we'll assume you are bluffing, guessing, or lying.

Bug Bounty Programs comes to Website Security: What do they mean?

2010-12-21T10:12:00.000-08:00

Recently I tweeted a passing thought, "I wonder if the final stage of maturity for website vulnerability management is offering a bug bounty program." This was stimulated by the news that Mozilla became the second company, following Google, to provide monetary rewards for security researches who find and privately report website vulnerabilities. Only last year this idea would have been considered crazy. Sure, other organizations including Microsoft, Facebook, and PayPal already gladly accept third-party vulnerability disclosures without threatening legal action, but it’s the financial compensation part that sets Google and Mozilla apart.

I’m sure others like myself in the community are asking if website vulnerability bug bounty programs a good idea to begin with and if such programs an anomaly or the start of a 2011 trend?

If we posed the first question to bug hunting masters Charlie Miller, Alex Sotirov, and Dino Dai Zovi there is no question how they’d answer. "No More Free Bugs." Not that all researchers must ascribe to this philosophy, it’s a personal choice, but there certainly shouldn’t be a stigma attached to those who do. The thing is the bugs these gentlemen generally focus on reside in desktop-based software developed by large ISVs. Software that can be readily tested in the safe confines of ones own computer where permission is not strictly required. Website vulnerabilities are in a word, different.

Website vulnerabilities reside in the midst of a live online business, on someone else’s network, where penetration-testing without permission is illegal and the results of which may cause degraded performance and downtime. Not that legalities ever really got in the way of a free pen-test. See the thousands of public cross-site scripting disclosures on XSSed.com. Still, I’d personally agree that while bug bounty programs can indeed be a good idea for a certain class of website owner, I think everyone would recommend thoughtful consideration before opening up the hack-me-for-cash flood gates.

What’s most interesting to me is understanding why Google and Mozilla themselves believe they need a bug bounty program the first place. It’s not like Google and Mozilla don’t invest in application security or would depend on such an initiative. In fact, from my personal interactions their level of application security awareness is top notch and practices represent among the most mature across the Web. They invest in source code reviews, security QA testing, penetrating tests / scans conducted by insiders and third-parties, developer training, standardized development constructs, threat modeling, and a collection of other Software Security Assurance (SSA) related activities. Activities most organization are still coming up to speed on.

So Google and Mozilla have already done essentially all our industry "recommends." Yet, as the multitude of negative headlines and unpaid vulnerabilities disclosures historically show, issues are still found by outsiders with annoying regularity. Personally I think that’s where the motivation for a bug bounty program comes from.

Google and Mozilla probably view their bounty programs as a way to remove additional missed bugs from the vulnerabilities pool, remediate them in a manageable way, foster community good will, and for the low low price of few hundred to a few thousand bucks. Check it out. In the first two months of Google’s program, it looks like they’ve paid out a few 10s of thousands of dollars to three dozen or so researchers. Said another way, the PR benefit is perhaps three dozen user confidence shaking news stories DIDN'T get published. All in all for that price, suddenly the idea of paying "the hackers" doesn’t sound as crazy.

It should be made crystal-clear that bug bounty programs are in no way a replacement for any part of an SSA or an SDL program, rather they are complementary and an opportunity to facilitate improvement. Also, bug bounty programs are not for everybody, and probably not even for most. Only those organizations that truly have their application security act together should even consider offering such a program.

For example, the organization should already have reasonably bug free websites or they won't offering attractively priced bounties for long. Budgets would run out fast and they’ll be forced to suspend the program, which would be quite embarrassing. The organization must also have a strong process in place to receive, validate, respond, act upon, and pay out for submissions. Next as Mike Bailey, a self proclaimed Narcissistic Vulnerability Pimp elegantly stated, "bounty program also involves an implicit commitment to fix bugs quickly." That’s right, no sitting on bugs for a "reasonable" amount of time -- like months to a year or more. Finally the organization will require a super-stable infrastructure capable of enduring sustained attack by hundred or perhaps thousands of entities.

In my humble opinion if an organization has all of this in place, then I’m confident in saying there is a correlation between bug bounty programs and website vulnerability management / SSA maturity. Gunnar Peterson for the graphic>

Jeff Moss, the man behind Black Hat and Defcon, recently encouraged Microsoft, a firm long opposed paying for bugs, to offer a bounty program. "I think it is time Microsoft seriously consider a bug bounty program. They advanced the SDL, it is time for them to advance bounties." I’ve suggested the very same to Microsoft in person on more than one occasion. Veracode has that as a 2011 infosec prediction. Everyone I know of has received a response similar to the following:

"We do not believe that offering compensation for vulnerability information is the best way we can help protect our customers." - Dave Forstrom, group manager of Microsoft Trustworthy Computing.

And there you have it. Is the website vulnerability bounty program phenomena the start of a trend? Who can really say? Only time will tell.

Sandboxing: Welcome to the Dawn of the Two-Exploit Era

2010-12-20T13:27:00.000-08:00

Exploitation of just ONE software vulnerability is typically all that separates the bad guys from compromising an entire machine. The more complicated the code, the larger the attack surface, and the popularity of the product increases the likelihood of that outcome. Operating systems, document readers, Web browsers and their plug-ins are on today’s front lines. Visit a single infected Web page, open a malicious PDF or Word document, and bang -- game over. Too close for comfort if you ask me. Firewalls, IDS, anti-malware, and other products aren’t much help. Fortunately, after two decades, I think the answer is finally upon us.

First, let’s have a look at the visionary of software security practicality that is Michael Howard as he characterizes the goal of Microsoft’s SDL, "Reduce the number of vulnerabilities and reduce the severity of the bugs you miss." Therein lies the rub. Perfectly secure code is a fantasy. We all know this, but we also know that what is missed is the problem we deal with most often, unpatched vulnerabilities and zero-days. Even welcome innovations such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) only seem to slow the inevitable, making exploitation somewhat harder, but not stopping it entirely. Unless the battlefield itself is changed, no matter what is tried, getting hacked will always come down to just one application vulnerability. ONE. That’s where sandboxes come in.

A sandbox is an isolated zone designed to run applications in a confined execution area where sensitive functions can be tightly controlled, if not outright prohibited. Any installation, modification, or deletion of files and/or system information is restricted. The Unix crowd will be familiar with chroot jails. This is the same basic concept. From a software security standpoint, sandboxes provide a much smaller code base to get right. Better yet, realizing the security benefits of sandboxes requires no decision-making on the user’s behalf. The protections are invisible.

Suppose you are tasked with securing a long-established and widely-used application with millions of lines of insanely complicated code that’s deployed in a hostile environment. You know, like an operating system, document reader, Web browser or a plug-in. Any of these applications contain a complex supply chain of software, cross-pollinated code, and legacy components created long before security was a business requirement or anyone knew of today’s class of attacks. Explicitly or intuitively you know vulnerabilities exist and the development team is doing its best to eliminate them, but time and resources are scarce. In the meantime, the product must ship. What then do you do? Place the application in a sandbox to protect it when and if it comes under attack.

That’s precisely what Google did with Chrome, and recently again with the Flash plugin, and what Adobe did with their PDF Reader. The idea is the attacker would first need to exploit the application itself, bypass whatever anti-exploitation defenses would be in place, then escape the sandbox. That’s at least two bugs to exploit rather than just one. The second bug, to exploit the sandbox, obviously being much harder than the first. In the case of Chrome, you must pop the WebKit HTML renderer or some other core browser component and then escape the encapsulating sandbox. The same with Adobe PDF reader. Pop the parser, then escape the sandbox. Again, two bugs, not just one. To reiterate, this is this not say breaking out of a sandbox environment is impossible as elegantly illustrated by Immunity's Cloudburst video demo.

I can easily see Microsoft and Mozilla following suit with their respective browsers and other desktop software. It would be very nice to see the sandboxing trend continue throughout 2011. Unfortunately though, sandboxing doesn’t do much to defend against SQL Injection, Cross-Site Scripting, Cross-Site Request Forgery, Clickjacking, and so on. But maybe if we get the desktop exploitation attacks off the table, perhaps then we can start to focus attention on the in-the-browser-walls attacks.

Why Speed & Frequency of Software Security Testing Matter, A LOT

2010-12-16T14:48:00.000-08:00

The length of time between when a developer writes a vulnerable piece of code and when the issue is reported by a software security testing process is vitally important. The more time in between, the more effort the development group must expend to fix the code. Therefore the speed and frequency of the testing process whether going with dynamic scanning, binary analysis, pen-testing, static analysis, line-by-line source code review, etc. matters a great deal.

WhiteHat Sentinel is frequently deployed in the Software Development Life-cyle, mostly during QA or User Acceptance Testing phases. From that experience we’ve noticed three distinct time intervals (1 week, 1 month, and 1 year), from when code is written to vulnerability identification, where the effort to fix is highly distinct. Below is what we are seeing.

The following focuses solely on syntax vulnerabilities such as SQL Injection, Cross-Site Scripting, HTTP Response Splitting, and so on. Semantic issues, also known as Business Logic Flaws, cause a different environmental impact.

When vulnerability details are communicated within ______ of the code being written:

1 Week (Less than 1 hour fix)
The same developer who introduced the vulnerability is the same developer who fixes the issue. Typically the effort required ranges from just minutes to an hour because the code is still fresh in the developers mind and they are probably still working on that particular project. The code change impact on QA and regression is minimal given how new the code is to the overall system.

1 Month - (1 - 3 hour fix)
The original developer who introduced the vulnerability may have moved onto another project. Peeling them off their current task enacts an opportunity cost. While remediation effort might be only 1 - 3 hours of development time, usually an entire day of their productivity is lost as they must reset their environment, re-familiarize themselves with the code, find the location of the issue, and fix the flaw. The same effort would be necessary if another developer was tasked to patch. If the vulnerability is serious a production hot-fix might be necessary requiring additional QA & regression resources.

1 Year (More than 10 hour fix)
The original developer who introduced the vulnerability is at least several projects away by now or completely unavailable. The codebase may have transferred to a software maintenance group, who have less skills and less time to dedicate to “security.” Being unfamiliar with the code another developer will have to spend a lot of time hunting for the exact location, figure out the preferred way fix it, that is if any exists. 10 or more developer hours is common. Then a significant amount of QA & regress will be necessary. Then depending on the release cycle deployment of said fix might have to wait until the next schedule release, whenever that may be.

What’s interesting is that the time and effort required to fix a vulnerability is not only subject to the class of attack itself, but how long ago the piece of code was introduced. Seems logical that it would be, just a subject not usually discussed. Another observation is that the longer the vulnerability lay undiscovered the more helpful it becomes to pinpoint the problematic line of code for the developer. Especially true in the 1 year zone. Again terribly logical.

Clearly then during SDL it’s preferable to get software security test results back into the developer hands as fast as possible. So much so that testing comprehensiveness will be happily sacrificed if necessary to increase the speed and frequency of testing. Comprehensiveness is less attractive within the SDL when results only become available once per year as in the annual consultant assessment model. Of course it’d be nice have it all (speed, frequency and comprehensiveness), but it’ll cost you (Good, Fast, or Cheap - Pick Two). Accuracy is the real wild card though. Without it the entire point of saving developers time has been lost.

I also wanted to briefly touch on the differences between act of "writing secure code" and "testing the security of code." I don’t recall when or where, but Dinis Cruz, OWASP Board Member and visionary behind the 02 Platform, said something a while back that stuck with me. Dinis said developers need to be provided exactly the right security knowledge at exactly the time they need it. Asking developers to read and recall veritable mountains of defensive programming do’s and don’ts as they carry out their day job isn’t effective or scalable.

For example, it would be much better if when a developer is interacting with database they are automatically reminded to use parameterized SQL statements. When handling user-supplied input, pop-ups immediately point to the proper data validation routines. Or, how about printing to screen? Warn the developer about the mandatory use of the context aware output filtering method. This type of just-in-time guidance needs to be baked into their IDE, which is one of the OWASP O2 Platform’s design objectives. "Writing secure code” using this approach would seem to be the future.

When it comes to testing as you might imagine WhiteHat constantly strives to improve the speed of our testing processes. You can see the trade-offs we make for speed, comprehensiveness, and cost as demonstrated by the different flavors of Sentinel offered. The edge we have on the competition by nature of the SaaS model is we know precisely, which of our tests are the most effective or likely to hit on certain types of systems. Efficiency = Speed. We’ve been privately testing new service line prototypes with some customers to better meet their needs. Exciting announcement are on the horizon.

DO NOT Poke the Bear

2010-12-15T07:35:00.000-08:00

ThreatPost was kind enough to allow me to guest post on their blog about some thoughts on the Gawker hack. A snippet is below, click through for the rest.

Lessons Learned From the Gawker Hack
"Everyone sounded the alarms at the Gawker Media attack, which included a security breach of websites such as Gizmodo, Lifehacker, Kotaku, io9, and others. The numbers were impressive: 1.3 million user accounts exposed, 405 megabytes of source code lost, and perhaps more important to some, the identity of those leaving anonymous comments potentially revealed. For Gawker, there is a loss of trust that will be difficult to regain. Users are already clamoring for the ability to delete their accounts. And, on the technical side, all Gawker’s systems will need to painstakingly audited or rebuilt entirely from scratch to prevent the same thing from happening again. Happy Holidays indeed.So, what is to be learned from this perfect storm of bluster and bravado? Many lessons, most of them demonstrating what not to do.

1. First and foremost, DO NOT poke the bear. By taunting the hacker community, especially the vigilante types, Gawker made itself a target unnecessarily. Never claim to be “unhackable.” The hackers outnumber you by several orders of magnitude, and they have more free time. Respect their capabilities. Not to mention the odds are always stacked against defenders. The attackers only have to find one little crack in wall to bring the castle crumbling down."

....

Spoofing Google search history with CSRF

2010-12-10T17:12:00.000-08:00

Let’s assume, dear Web surfer, that I can get you to visit a Web page I control. Just like the page on my blog you’re reading right now. Once you do, by nature of the way the Web works, near complete control of your Web browser is transferred to me as long as you are here. I can invisibly force your browser to initiate online bank wire transfers, post offensive message board comments, vote Jullian Assange as Times Person of the Year, upload illegal material, hack other websites and essentially whatever else I can think up. Worse still, on the receiving end, all the logs will point back to you. Not me.

If you don’t believe me keep reading. I already made you search Google for something a little embarrassing. And no, this is not something anti-virus scanners can do anything about.

The technical term for this type of attack is Cross-Site Request Forgery (CSRF) and years back I called it the sleeping giant. If you happen to be one of the legions of Web developers who have never heard of CSRF then chances are every feature of every website you’ve ever built is vulnerable. Millions of other websites out there are suffering the same problem. With same technology (HTML and JavaScript) that Web pages use to include images, audio, video, banners, trackers, counters etc from all over the internet, any website owner can instruct a victim’s browser to send arbitrary HTTP requests to any website of their choosing.

Generally, Web browsers generate two different types of HTTP requests, GET and POST. For the sake of demonstration here we’ll be focusing only on GET. POSTs require a tiny bit more code. To have someones browser send a particular GET request, like a Google Search for example, is extremely simple.

1) Search Google something like “Justin Bieber fan club” and copy the URL in the location bar.

2) Paste the Google search URL into an HTML IMG tag and zero out the height, width, and border to make it invisible.

<* IMG SRC="http://www.google.com/search?hl=en&q=Justin+Bieber+fan+club&btnG=Search&aq=f&aqi=&aql=&oq=&gs_rfai=" WIDTH="0" HEIGHT="0" BORDER="0" *>

3) Load this code into a Web page, like this one, and voila! When the a Web surfer arrives their browser will execute the code and perform the exact same search (see HTTP request screen shot).

Obviously then any website owner can make your browser search for anything on Google, anything at all. Keep in mind that if the victim is logged-in, their session cookies will be automatically be sent as well. This is a key point about CSRF attacks. Forged HTTP requests are authenticated if the user had previously logged-in to the target website.

If you happen to be logged-in to Google right now, go check your Web search history. Maybe you’ll see something in there you didn’t search for. It might look something like this... :)