Monday, September 29, 2008
New CSRF paper with vulnerability disclosure
Ed Felten and Bill Zeller recently released a very well-written paper about Cross-Site Request Forgery (CSRF), including some real-world vulnerability examples from ING Direct, YouTube, MetaFilter, and The New York Times. As you all know so well, CSRF vulnerabilities are easy find when you just decide to look on basically any website. Don't expect any ground breaking research per-say, but the papers content is really helpful to those unfamiliar with CSRF (and that's still a lot people - especially developers). Ed and Bill also did some work on a potential client-side solution, like LocalRodeo I think, which I hope to find time to investigate further. We need as many smart people as we can trying to solve this problem in creative ways. CSRF certainly isn't going to go away anytime soon.
Insecure Magazine Issue #18
Issue #18 of my favorite online magazine, (IN)SECURE, is now available for download. The magazine is consistently content rich, high quality, and best of all - free! ;) This issue has several articles on Web security, one of which was written by yours truly, "Browser Security: Bolt it on, then build it in." Obviously with software security this is the opposite of what you want things to work, but when you consider the business objectives of Web browser security this is the way it tends to work. Here’s an excerpt of the premise..."Some vendors attempt an über secure design - Opus Palladianum as an example, but few use it. Others opt for usability over security, such as Internet Explorer 6, which almost everyone used and was exploited as a result. Then, somewhere in the middle, is fan-favorite Firefox. The bottom line is that any highly necessary and desirable security feature that inhibits market adoption likely won't go into a release candidate of a major vendor. Better to be insecure and adopted instead of secure and obscure."
Other compelling web security articles:
- Web application security: risky business?
- Secure web application development
- Enterprise application security: how to balance the use of code reviews and web application firewalls from PCI compliance.
Thursday, September 18, 2008
I used to know what you watched, on YouTube
In doing some crossdomain.xml Flash research I noticed that YouTube’s policy file trusted *.google.com. They quickly removed it after I privately disclosed the following security flaw to Google.
My idea was if an attacker could upload an arbitrary Flash movie (SWF) anywhere on the google.com domain they could leverage that trust. So if an authenticated YouTube user visited an attacker-controlled page anywhere on the Web, the attacker could SRC in the google.com hosted SWF, and use it compromise the victims YouTube username, email address, first/last name, viewing history, and even comment or post/delete videos.
Billy Rios blogged in the past about being able to upload arbitrary files to google.com, but the only place I could locate that allowed SWFs when I checked was Gmail. Maybe others?
Anyway, I emailed a SWF attachment to a Gmail account and located the download URL. Perfect, but the next problem was even with the correct URL the victim is not authorized to view the file unless they are authenticated on THAT particular Gmail account. This is where the login-CSRF / identity misbinding trick the Stanford guys wrote up came in quite handy.
Here’s the step by step.
1) Attacker emails a special SWF to a Gmail account they control and locates the attachment download URL on google.com.
2) Logged-in YouTube user visits an attacker controlled page
3) Attacker forces their victim to authenticate to the attackers Gmail account (identify misbinding / CSRF).
4) Attacker embeds SWF from the Gmail account into the web page
5) Attacker now has read write access on YouTube.com as the victim's account.
Video:
Clever eh? :) I’m sure the Google/YouTube aren’t the only places where this particular scenario is still possible.
Many thanks to Rich Cannings and Chris Evans from the Google Security team who sheparded this along!
My idea was if an attacker could upload an arbitrary Flash movie (SWF) anywhere on the google.com domain they could leverage that trust. So if an authenticated YouTube user visited an attacker-controlled page anywhere on the Web, the attacker could SRC in the google.com hosted SWF, and use it compromise the victims YouTube username, email address, first/last name, viewing history, and even comment or post/delete videos.
Billy Rios blogged in the past about being able to upload arbitrary files to google.com, but the only place I could locate that allowed SWFs when I checked was Gmail. Maybe others?
Anyway, I emailed a SWF attachment to a Gmail account and located the download URL. Perfect, but the next problem was even with the correct URL the victim is not authorized to view the file unless they are authenticated on THAT particular Gmail account. This is where the login-CSRF / identity misbinding trick the Stanford guys wrote up came in quite handy.
Here’s the step by step.
1) Attacker emails a special SWF to a Gmail account they control and locates the attachment download URL on google.com.
2) Logged-in YouTube user visits an attacker controlled page
3) Attacker forces their victim to authenticate to the attackers Gmail account (identify misbinding / CSRF).
4) Attacker embeds SWF from the Gmail account into the web page
5) Attacker now has read write access on YouTube.com as the victim's account.
Video:
Clever eh? :) I’m sure the Google/YouTube aren’t the only places where this particular scenario is still possible.
Many thanks to Rich Cannings and Chris Evans from the Google Security team who sheparded this along!
What’s important, Palin’s Yahoo Mail account hacked
That’s right, Alaska Governor and republican Vice-presidential candidate Sarah Palin's quasi-personal Yahoo Mail (gov.palin@yahoo.com) account was hacked into by the infamous group called “Anonymous”. While there are conflicting news reports on the incident’s authenticity - emails, screen shots, and family photos have been posted to Wikileaks as proof. If we assume the incident is real, there are so many ways a free WebMail account could be compromised – some more likely than others:
1) Password guessing / brute force attacks
2) Password recovery system flaw or website vulnerability
3) Network sniffers
4) Phishing scams
5) Insider (rouge customer service representation or software backdoor)
6) Operating System Malware/Spyware
7) Stolen hardware
8) Lost backup tape (hah, as if free WebMail providers have backups!)
9) Use of a public computer
etc. maybe more I’m not thinking of.
For myself and the rest of the InfoSec industry the “how” is interesting, but its unimportant for everyday users like our friends, family, coworkers, politicians, etc. What they need to know is WebMail compromises could happen to anyone - even if they do everything “right” because security is largely out of their hands or impossible to behave perfectly all the time. Mistakes happen and the more high profile of a person you are the higher the likelihood you will be targeted.
Bottom line: DO NOT receive or store anything you don’t want read or made public on these “free” WebMail systems. They are NOT private. They are NOT secure. They are NOT safe. The same goes for Google Docs, social network private messages, online backup solutions, whatever. What they are is FREE and CONVEINIENT. The businesses that support them are not accountable for your privacy, security, or lack thereof. Read their EULA or ToS if you don’t want to take my word for it.
1) Password guessing / brute force attacks
2) Password recovery system flaw or website vulnerability
3) Network sniffers
4) Phishing scams
5) Insider (rouge customer service representation or software backdoor)
6) Operating System Malware/Spyware
7) Stolen hardware
8) Lost backup tape (hah, as if free WebMail providers have backups!)
9) Use of a public computer
etc. maybe more I’m not thinking of.
For myself and the rest of the InfoSec industry the “how” is interesting, but its unimportant for everyday users like our friends, family, coworkers, politicians, etc. What they need to know is WebMail compromises could happen to anyone - even if they do everything “right” because security is largely out of their hands or impossible to behave perfectly all the time. Mistakes happen and the more high profile of a person you are the higher the likelihood you will be targeted.
Bottom line: DO NOT receive or store anything you don’t want read or made public on these “free” WebMail systems. They are NOT private. They are NOT secure. They are NOT safe. The same goes for Google Docs, social network private messages, online backup solutions, whatever. What they are is FREE and CONVEINIENT. The businesses that support them are not accountable for your privacy, security, or lack thereof. Read their EULA or ToS if you don’t want to take my word for it.
Monday, September 15, 2008
Let's talk Software Serviceability
Financial Times graciously invited me to write an opinion piece for their publication entitled "Learn from today’s software flaws to protect corporations tomorrow", where I discuss a bit about Software Serviceability. In the wake of Dan K's vulnerability announcement (and others like it), I couldn't shake the notion that no matter how hard to try to write perfectly secure code, given a long enough time line we'll always fall short. We will miss a bug, there will be a new attack technique, hackers will exploit our systems. To me this says our important systems must have speedy and adaptive security measures to identify threats as they happen and the ability to quickly service our deployed software (preferably within days or hours). Some systems have this capability, but it's too few and far between.
"So in the case of the issues found by Dan, Tony, and Alex it is hard to put a top-end market value on them, but consider that other less severe issues have sold for five and six figure sums. Would seven figures be out of the question? Will the next security researcher be influenced by the potential financial reward instead of giving it away for free? We know for sure that there will be a next time, because software is imperfect. Vulnerabilities will be found and long standing encrypting algorithms will be broken or at least weakened. And it’s difficult, if not impossible, to future-proof our code against attack techniques that don’t yet exist."
"So in the case of the issues found by Dan, Tony, and Alex it is hard to put a top-end market value on them, but consider that other less severe issues have sold for five and six figure sums. Would seven figures be out of the question? Will the next security researcher be influenced by the potential financial reward instead of giving it away for free? We know for sure that there will be a next time, because software is imperfect. Vulnerabilities will be found and long standing encrypting algorithms will be broken or at least weakened. And it’s difficult, if not impossible, to future-proof our code against attack techniques that don’t yet exist."
(Cancelled) / Clickjacking - OWASP AppSec Talk
“Clickjacking,” the presentation Robert “RSnake” Hansen and I had planned for OWASP AppSec NY 2008, has been postponed due to vendor request.
The premise of Clickjacking is that we know a lot about what JavaScript malware is capable of once a user comes in contact with an attacker-controlled webpage (or a page with their code on it) such as history stealing, intranet hacking, phishing with superbait, Web worms, browser exploit, and so on, but comparably little about what can be done with a captured “click”. Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable. What could they possibly do then?
With Clickjacking attackers can do quite a lot. Some things that could be pretty spooky. Things also performed, with a fair amount of ingenuity, quite easily. Over the past couple of weeks/months RSnake and I have been completing our PoC examples to demonstrate the potential attacks and sharing the results privately with a few industry colleagues to obtain a third-party opinion. At the time, we believed our discoveries were more in line with generic Web browsers behavior, not traditional “exploits,” and that guarding against Clickjacking was largely the browser vendors' responsibility. Clickjacking is a well-known issue, but severely underappreciated and largely undefended, and we hope to begin changing that perception.
One Clickjacking PoC utilized an Adobe product with an attack technique they considered to be a critical issue, we just hadn’t realized it, so we narrowly avoided 0-day’ing them! Considering the short notice, Adobe requested additional time in case the browser vendors do nothing to prevent Clickjacking. High severity issue #2 in Internet Explorer 8 would have potentially given the aforementioned issue persistent qualities. There was/is a third issue with websites in general, which would have required all website owners to make an update, but that would obviously be impossible to do so. Again, better fixed by the browser vendors. With much of our technical details taken off the table waiting for patches and/or new safeguards we weren’t left with much to convey the true power of Clickjacking other than what’s already known.
Postponing our OWASP talk wasn’t an easy decision to make as we put a lot of time and effort into the presentation. We apologize to the attendees and had every intention of releasing mind-blowing stuff. At this time just about everyone out there using the latest versions of Internet Explorer (including version 8) and Firefox 3 is affected. Please be assured that as soon as we’re able to expose the information we will do so. In the meantime, the only fix is to disable browser scripting and plugins. We realize this doesn’t give people much technical detail to go on, but it’s the best we can do right now.
Adobe PSIRT (psirt@adobe.com)
More to come.
The premise of Clickjacking is that we know a lot about what JavaScript malware is capable of once a user comes in contact with an attacker-controlled webpage (or a page with their code on it) such as history stealing, intranet hacking, phishing with superbait, Web worms, browser exploit, and so on, but comparably little about what can be done with a captured “click”. Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable. What could they possibly do then?
With Clickjacking attackers can do quite a lot. Some things that could be pretty spooky. Things also performed, with a fair amount of ingenuity, quite easily. Over the past couple of weeks/months RSnake and I have been completing our PoC examples to demonstrate the potential attacks and sharing the results privately with a few industry colleagues to obtain a third-party opinion. At the time, we believed our discoveries were more in line with generic Web browsers behavior, not traditional “exploits,” and that guarding against Clickjacking was largely the browser vendors' responsibility. Clickjacking is a well-known issue, but severely underappreciated and largely undefended, and we hope to begin changing that perception.
One Clickjacking PoC utilized an Adobe product with an attack technique they considered to be a critical issue, we just hadn’t realized it, so we narrowly avoided 0-day’ing them! Considering the short notice, Adobe requested additional time in case the browser vendors do nothing to prevent Clickjacking. High severity issue #2 in Internet Explorer 8 would have potentially given the aforementioned issue persistent qualities. There was/is a third issue with websites in general, which would have required all website owners to make an update, but that would obviously be impossible to do so. Again, better fixed by the browser vendors. With much of our technical details taken off the table waiting for patches and/or new safeguards we weren’t left with much to convey the true power of Clickjacking other than what’s already known.
Postponing our OWASP talk wasn’t an easy decision to make as we put a lot of time and effort into the presentation. We apologize to the attendees and had every intention of releasing mind-blowing stuff. At this time just about everyone out there using the latest versions of Internet Explorer (including version 8) and Firefox 3 is affected. Please be assured that as soon as we’re able to expose the information we will do so. In the meantime, the only fix is to disable browser scripting and plugins. We realize this doesn’t give people much technical detail to go on, but it’s the best we can do right now.
Adobe PSIRT (psirt@adobe.com)
More to come.
Thursday, September 11, 2008
My Picks for OWASP NY AppSec 2008
OWASP NY AppSec 2008 is only week away and is going to be big, really big, bigger than anyone expected I think. So big in fact that Tom Brennan, conference organizer, had to find a larger venue this week to accommodate all the attendees. The Park Central Hotel - 870 Seventh Avenue at 56th if you hadn’t already seen the updated page. What Tom and Co. also did was create a jam-packed line-up of sweet looking presentations. So much so that everyone will probably miss something they wanted see because of dueling talk. Oh well, that’s what video is for! While the schedule still seems to be in a bit of flux, I thought I’d list the stuff I’m most interested in and get my personal schedule going.
Disclaimer: If I don’t pick your talk it doesn’t mean I don’t like you or the material. :) It might be that I’ve already seen it and/or familiar with the content.
Day 1
Web Application Security Road Map - Joe White
Because its initiatives like this one that will eventually serve as a template for other organizations to follow.
Http Bot Research - Andre M. DiMino - ShadowServer Foundation
I have a soft spot for bots, seemed interesting, and wanted to see what data they have.
Get Rich or Die Trying - Making Money on The Web, The Black Hat Way - Trey Ford, Tom Brennan, Jeremiah Grossman
Well, you know, I sorta have to be there. :)
New Exploit Techniques - Jeremiah Grossman & Robert "RSnake" Hansen
One of those presentations exposing what Web attacks in the next 12-18 month will look like. We’ve purposely kept really quiet about what we plan to demonstrate, but its certainly going to make people a little nervous. :)
Industry Outlook Panel
Curious about what these folks have on their mind.
Multidisciplinary Bank Attacks - Gunter Ollmann
Good speaker and I enjoy hacking backs. :)
Case Studies: Exploiting application testing tool deficiencies via "out of band" injection
I have no idea, though appeared to be an interesting topic
w3af - A Framework to own the web - Andres Riancho
Coding Secure w/PHP - Hans Zaunere
Want to see more about how this is done. It can be right?
Day 2
Best Practices Guide: Web Application Firewalls - Alexander Meisel
A big toss up between this one and Pen Testing VS. Source Code Analysis, but had to go with the WAFs. Wanted to see what their point of view is and the guidance they're suggesting.
APPSEC Red/Tiger Team Projects - Chris Nickerson
Sounded cool, that’s about it.
Industry Analyst with Forrester Research - Chenxi Wang
It’s always good to know how the certain enterprises will be influenced
Security in Agile Development - Dave Wichers
As before, is this possible? And if so, how!? TELL ME!
Next Generation Cross Site Scripting Worms - Arshan Dabirsiaghi
cmon Arshan, no holding back. Give me the next NEXT generation XSS worms! :)
NIST SAMATE Static Analysis Tool Exposition (SATE) - Vadim Okun
Tools lined-up side-by-side and tested always interested me.
Practical Advanced Threat Modeling - John Steven
It's been a while since I attended a threat modeling talk, especially one targeted towards webappsec, which I hope this is.
Off-shoring Application Development? Security is Still Your Problem - Rohyt Belani
Flash Parameter Injection (FPI) - Ayal Yogev & Adi Sharabani
Flash security is HUGE! HUGE I SAY!
Most of these speakers I've never seen present before, which I find refreshing. New talent, new ideas, and shows an emerging industry. Good luck everyone!
Disclaimer: If I don’t pick your talk it doesn’t mean I don’t like you or the material. :) It might be that I’ve already seen it and/or familiar with the content.
Day 1
Web Application Security Road Map - Joe White
Because its initiatives like this one that will eventually serve as a template for other organizations to follow.
Http Bot Research - Andre M. DiMino - ShadowServer Foundation
I have a soft spot for bots, seemed interesting, and wanted to see what data they have.
Get Rich or Die Trying - Making Money on The Web, The Black Hat Way - Trey Ford, Tom Brennan, Jeremiah Grossman
Well, you know, I sorta have to be there. :)
New Exploit Techniques - Jeremiah Grossman & Robert "RSnake" Hansen
One of those presentations exposing what Web attacks in the next 12-18 month will look like. We’ve purposely kept really quiet about what we plan to demonstrate, but its certainly going to make people a little nervous. :)
Industry Outlook Panel
Curious about what these folks have on their mind.
Multidisciplinary Bank Attacks - Gunter Ollmann
Good speaker and I enjoy hacking backs. :)
Case Studies: Exploiting application testing tool deficiencies via "out of band" injection
I have no idea, though appeared to be an interesting topic
w3af - A Framework to own the web - Andres Riancho
I'd like to see this tool demonstrated and understand what it can really do.
Coding Secure w/PHP - Hans Zaunere
Want to see more about how this is done. It can be right?
Day 2
Best Practices Guide: Web Application Firewalls - Alexander Meisel
A big toss up between this one and Pen Testing VS. Source Code Analysis, but had to go with the WAFs. Wanted to see what their point of view is and the guidance they're suggesting.
APPSEC Red/Tiger Team Projects - Chris Nickerson
Sounded cool, that’s about it.
Industry Analyst with Forrester Research - Chenxi Wang
It’s always good to know how the certain enterprises will be influenced
Security in Agile Development - Dave Wichers
As before, is this possible? And if so, how!? TELL ME!
Next Generation Cross Site Scripting Worms - Arshan Dabirsiaghi
cmon Arshan, no holding back. Give me the next NEXT generation XSS worms! :)
NIST SAMATE Static Analysis Tool Exposition (SATE) - Vadim Okun
Tools lined-up side-by-side and tested always interested me.
Practical Advanced Threat Modeling - John Steven
It's been a while since I attended a threat modeling talk, especially one targeted towards webappsec, which I hope this is.
Off-shoring Application Development? Security is Still Your Problem - Rohyt Belani
Uh yap it is, but what to do about it is the question. Hopefully Rohyt will answer that one.
Flash Parameter Injection (FPI) - Ayal Yogev & Adi Sharabani
Flash security is HUGE! HUGE I SAY!
Most of these speakers I've never seen present before, which I find refreshing. New talent, new ideas, and shows an emerging industry. Good luck everyone!
Monday, September 08, 2008
WASC Web Application Security Statistics 2007
For those hungry for more web application security vulnerability data, WASC has released its Web Application Security Statistics report for 2007. Under the leadership of Sergey Gordeychik and the broad participation by Booz Allen Hamilton, BT, Cenzic, dblogic.it, HP, Positive Technologies, Veracode, and WhiteHat Security – we’ve combined custom web application vulnerability data from roughly 32,000 websites totaling 70,000 vulnerabilities. Methodologies include white box and black box, automated and manual, all reported using the Web Security Threat Classification as a baseline. Excellent stuff.
Vulnerability frequency by types
The most prevalent vulnerabilities (BlackBox & WhiteBox)
Sergey did a masterful job coordinating all the vendors (whom we thank), compiling the data, and generating a report in a nicely readable format. I’d like to caution those who may read too deeply into the data and draw unfounded conclusions. It’s best to view reports such as these, where the true number and type of vulnerabilities is an unknown, as the best-case scenario. There are certainly inaccuracies, such as with CSRF, but at the very least this gives us something to go on. Future reports will certainly become more complete and representative of the whole as additional sources of vulnerability data come onboard.
Vulnerability frequency by types
The most prevalent vulnerabilities (BlackBox & WhiteBox)
Sergey did a masterful job coordinating all the vendors (whom we thank), compiling the data, and generating a report in a nicely readable format. I’d like to caution those who may read too deeply into the data and draw unfounded conclusions. It’s best to view reports such as these, where the true number and type of vulnerabilities is an unknown, as the best-case scenario. There are certainly inaccuracies, such as with CSRF, but at the very least this gives us something to go on. Future reports will certainly become more complete and representative of the whole as additional sources of vulnerability data come onboard.
Wednesday, August 27, 2008
Download the 5th Website Security Statistics Report
Whew, what a mountain of work! I’m ecstatic the complete 5th installment of our Website Security Statistics Report report (all 13-pages) is finally published and available for everyone to see – and comment. I’m also extremely proud that we’re able to capture a measurable improvement in overall website security. Good news from inside InfoSec!? I know, weird huh!? We still have a long way to go, but these statistics show we’re on the right path and doing the right things:
- Find and prioritize all websites
- Find and fix website vulnerabilities
- Implement a secure software development process
- Utilize a defense-in-depth website security strategy
Today’s webinar went extremely well, slides are available for those interested. And some quick numbers:
Total Websites: 687
Identified vulnerabilities: 11,234
Unresolved vulnerabilities: 3,541 (66% resolved)
Websites HAVING HAD at least one serious issue: 82%
Websites CURRENTLY WITH at least one serious issue: 61%
Average vulnerabilities per website: 5
The shiny new WhiteHat Top Ten
Yes! CSRF finally make the list!
Also covered is:
- Collection methodology
- Time-to-fix and remediation metrics
- Industry vertical comparisons
- Best practices & lessons learned
Feedback on what other numbers people would like us to report on in the future is very welcome.
Monday, August 25, 2008
5th Website Security Statistics Report
For the last month I’ve been compiling our third quarter 2008 Website Security Statistics Report, which contains a comprehensive vulnerability analysis of over 600 real live websites. We’re talking 11,000 verified vulnerabilities collected from typically weekly assessments. This type of data is not available from reports by Symantec, Mitre (CVE), IBM X-Force, SANS, or anywhere else and we're excited to be able to share it.
We put a ton of work into this report and there is a massive amount of data. Highlights include a revised Top Ten list of vulnerabilities, updated Time-to-Fix metrics, vulnerability remediation percentages showing progress, vertical market comparison, and so on. The information is really valuable because it provides visibility into the future trends, trouble spots, and what action items should be considered.
On Wednesday, August 27th, 11:00 AM PDT I’ll be hosting an hour-long webinar to go over the results. Attendees will be given the opportunity to be the first to see the results and ask questions. Registration is free, but space is limited. If you are interested in attending, now is the time to register.
Back at my Desk
I’m finally home from a 3-city in 3 days tour covering Atlanta, New York, and Chicago. Beyond the excellent turn out for the WH/F5 lunch and learn presentations, I’m always fond of the extracurricular activity. Since I’m still injured, visiting new BJJ academies was out of the question, so instead I substituted the time with food. Fortunately I was able to do so with meals that fit within my high protein low-carb diet (208 lbs is the goal). 30lbs to go!
In Atlanta there was Fogo de Chão, a stellar upscale all-you-can-eat Brazilian BBQ restaurant, that served 15 types of fire-roasted meats brought to your table sizzling on skewers. Now that’s hard to beat. In New York we stopped by my all-time favorite steak place, Smith & Wollensky, for a Colorado bone-in ribeye. The waiter said it was the most flavorful meat in the world, I’m thinking he was right.
Chicago, I left the venue selection to the OWASP Chicago Chapter locals. But before that Cory Scott and Jason Witty invited me deliver an encore performance of “Get Rich or Die Trying” at the recommendation of Ed Bellis (Thank you). The cool thing about that particular talk is afterwards people always clue me into other business logic flaws they’ve encountered. It’s really good content to add, especially if it involves money. For me I was excited to see the presentations by Mike Zussman and Nate McFeters since I didn’t get to see either talk at Black Hat.
Wednesday, August 20, 2008
Can you identify the white ninja?
During BlackHat USA, there were sightings of a mysterious white ninja. Witness reports claim he spoke with an english accent at 300 words per minute, raved on about sandboxing code, and plotted to take over the Web with a worm to wake people up (but just for a day). Anyone know who this phantom figure is?Bonus points for posting the best photo caption. I’m thinking “practice safe output encoding”.
Tuesday, August 12, 2008
Application Security Vendors Counting their Millions
Software security sage Gary McGraw (CTO, Cigital) published his market research on what he believes are the 2007 revenue numbers for application security vendors. Speaking for myself, I can neither confirm nor deny the accuracy of this data, certainly when it comes to WhiteHat.
Fortify: $29.2 million
Coverity: $27.2 million
Klockwork: $26 million
Watchfire (IBM): $24.1 million
SPI Dynamics (HP): $22.3 million
Cenzic + Codenomicon + WhiteHat: $12.5 million
Ounce Labs: $9.5 million
$150.8 million total for the tools / SaaS market
“The source code analysis space is now larger than the black box testing tools space….”
Sort of, but more on that in a moment.
“Tools don't run themselves”
Ain’t that the truth.
“The hard-to-track software security services space checks in around $100-140 million in 2007, with growth just shy of 20% over 2006. Services can be divided into three tracks: training (around $7 million), risk assessment ($45-60 million) and penetration testing ($50-75 million).”
I’m not sure about the risk assessment number, but I’m thinking the estimates for training and penetration testing is probably orders of magnitude lower than they should be. The rates for larger players including IBM Global Services, Verizon, Symantec, Ernst & Young, PwC, and KPMG aren’t cheap. And to some extent neither are the smaller players such as Matasano, SecTheory, iSec, Leviathan, Denim Group, Foundstone, Gotham, NGSS, FishNet, Aspect, SANS, IOActive, Immunity, NTO, NGS, BlueInfy, Net-Square and dozens of other regional players. No wonder the overall market totals are tough to track, but each takes their piece of the pie.
I believe when it comes to the black-box testing of web applications, services are likely 5x larger than the tools industry – especially if you consider that few organizations these days haven’t had a professional vulnerability assessment (and its tough to capture international sales as well). The opposite is true for white-box testing where tool purchases a way more common due to the costs of a line-by-line source code review by a consultant. Then we have WAF sales driven by VA sales, which makes sense because an organization typically must identify a need before they can justify the fix. The same was true of network firewalls, patch management, and A/V markets.
All in the all trajectory for the entire web application security segment is going up, and fast. PCI-DSS 6.6 is certainly one stimulant, but so is all the web hacking going on these days. Great numbers Gary, thanks for sharing!
Fortify: $29.2 million
Coverity: $27.2 million
Klockwork: $26 million
Watchfire (IBM): $24.1 million
SPI Dynamics (HP): $22.3 million
Cenzic + Codenomicon + WhiteHat: $12.5 million
Ounce Labs: $9.5 million
$150.8 million total for the tools / SaaS market
“The source code analysis space is now larger than the black box testing tools space….”
Sort of, but more on that in a moment.
“Tools don't run themselves”
Ain’t that the truth.
“The hard-to-track software security services space checks in around $100-140 million in 2007, with growth just shy of 20% over 2006. Services can be divided into three tracks: training (around $7 million), risk assessment ($45-60 million) and penetration testing ($50-75 million).”
I’m not sure about the risk assessment number, but I’m thinking the estimates for training and penetration testing is probably orders of magnitude lower than they should be. The rates for larger players including IBM Global Services, Verizon, Symantec, Ernst & Young, PwC, and KPMG aren’t cheap. And to some extent neither are the smaller players such as Matasano, SecTheory, iSec, Leviathan, Denim Group, Foundstone, Gotham, NGSS, FishNet, Aspect, SANS, IOActive, Immunity, NTO, NGS, BlueInfy, Net-Square and dozens of other regional players. No wonder the overall market totals are tough to track, but each takes their piece of the pie.
I believe when it comes to the black-box testing of web applications, services are likely 5x larger than the tools industry – especially if you consider that few organizations these days haven’t had a professional vulnerability assessment (and its tough to capture international sales as well). The opposite is true for white-box testing where tool purchases a way more common due to the costs of a line-by-line source code review by a consultant. Then we have WAF sales driven by VA sales, which makes sense because an organization typically must identify a need before they can justify the fix. The same was true of network firewalls, patch management, and A/V markets.
All in the all trajectory for the entire web application security segment is going up, and fast. PCI-DSS 6.6 is certainly one stimulant, but so is all the web hacking going on these days. Great numbers Gary, thanks for sharing!
Monday, August 11, 2008
BlackHat encore - Chicago OWASP next week
Chapter leaders Cory Scott or Jason Witty were gracious enough to invite me to present at this months OWASP Chicago meeting. It's always fun to visit a new chapter. I've been to about a dozen so far, and meeting like minded webappsec people from various parts of the country/world. This is also a good opportunity for those who missed Black Hat to see one of the presentations live rather than relying solely on the information in the slides.
August 21 - OWASP Chicago Chapter (6:00pm – 8:30pm)
6:00 Refreshments and Networking
6:15 Bad Cocktail: Spear Phishing + Application Hacks - Rohyt Belani, Managing Partner, Intrepidus Group
7:15 Get Rich or Die Trying - Making Money on The Web, The Black Hat Way - Jeremiah Grossman, Founder & CTO of Whitehat Security
Bank of America Plaza
540 W. Madison, Downtown Chicago, 23rd floor.
*Please RSVP to jason{AT}wittys.com by 8/19/2008 if you plan to attend. Your name will need to be entered into the building's security system in order to gain access to the meeting.*
August 21 - OWASP Chicago Chapter (6:00pm – 8:30pm)
6:00 Refreshments and Networking
6:15 Bad Cocktail: Spear Phishing + Application Hacks - Rohyt Belani, Managing Partner, Intrepidus Group
7:15 Get Rich or Die Trying - Making Money on The Web, The Black Hat Way - Jeremiah Grossman, Founder & CTO of Whitehat Security
Bank of America Plaza
540 W. Madison, Downtown Chicago, 23rd floor.
*Please RSVP to jason{AT}wittys.com by 8/19/2008 if you plan to attend. Your name will need to be entered into the building's security system in order to gain access to the meeting.*
Road Show - 3 Cities in 3 Days
For those interested in learning more about the WhiteHat Sentinel / F5 ASM integration we have a road show scheduled (If not, go ahead and stop reading now). We’re visiting Atlanta, New York, and Chicago next week. In each city presenting will be our CEO Stephanie Fohn sharing insights on the latest website vulnerability statistics, a guest customer from a financial institution sharing their experiences on “The Challenge of Managing Application Security in Today's Environment”, and myself paired with an F5 engineer performing live VA+WAF demos. A really nice lunch will be served on us and registration is free, space is limited though. Hope to see many of you there!
August 19 (Atlanta @ 11:30am – 1:30pm)
The Four Seasons Hotel
75 Fourteenth Street Atlanta, GA 30309
Guest Speaker: Allen Stone, Senior Security Specialist, E*TRADE Financial
August 20 (New York @ 11:30am – 1:30pm)
The Tribeca Grand Hotel
2 Avenue of the Americas
New York, NY 10013
Guest Speaker: Jim Routh, Chief Information Security Officer, DTCC
August 21 (Chicago @ 11:30am – 1:30pm)
The Peninsula Chicago Hotel
108 East Superior Street
Chicago, IL 60611
(312) 337-2888
Guest Speaker: Anna Sherony, Privacy and Information Protection Officer, Sammons Financial
August 19 (Atlanta @ 11:30am – 1:30pm)
The Four Seasons Hotel
75 Fourteenth Street Atlanta, GA 30309
Guest Speaker: Allen Stone, Senior Security Specialist, E*TRADE Financial
August 20 (New York @ 11:30am – 1:30pm)
The Tribeca Grand Hotel
2 Avenue of the Americas
New York, NY 10013
Guest Speaker: Jim Routh, Chief Information Security Officer, DTCC
August 21 (Chicago @ 11:30am – 1:30pm)
The Peninsula Chicago Hotel
108 East Superior Street
Chicago, IL 60611
(312) 337-2888
Guest Speaker: Anna Sherony, Privacy and Information Protection Officer, Sammons Financial
Get Rich or Die Trying (BlackHat USA 2008)
Update 08.11.2008: Added a video interview of Trey and myself to the bottom of the post.Our speaking slot was informally dubbed the “power hour” due to the number of stellar presentations all booked at the same time - many of which I would have loved to attend personally. Nate McFeters & Co. unveiled the details on their GIFAR research, Microsoft announced they’ll be revealing vulnerability details to certain vendors prior to public disclosure, Joanna Rutkowska on Xen Hypervisor, etc. And making matters just a little bit more interesting, we were generously given a larger ballroom. This was scary because with a speaking time near the end of the last day combined with top-notch competition, a sparsely attended room would have been entirely likely. So when the room filled to capacity, I’m guessing of around 1,000 people (standing room only) Trey Ford and I were extremely ecstatic! Which reminds me, Trey Ford (Director of Solutions Architecture) pinched hit for Arian Evans (Director of Operations) so he could focus more time on his presentation, “Encoded, Layered and Transcoded Syntax Attacks.”
The premise for the “Get Rich or Die Trying” presentation was looking forward at the next 3-5 years considering that we’re probably going to see less fertile ground for XSS/SQLi/CSRF to be taken advantage of – that is if the good guys do their job well. So the bad guys will likely focus more attention on business logic flaws, which QA overlooks, scanners can’t identify, IDS/IPS can’t defend, and more importantly issues potentially generating 4, 5, 6 or even figures a month in illicit revenue. In many ways though this is sort of like predicting the present since just about every example we gave was grounded with a real-world public reference and backed by statistics. We also wanted this presentation was very different than what most are used to at BlackHat that tend to be deeply technical, hard to follow, and often dry. And while everyone in webappsec is transfixed on JavaScript malware issues, we chose another direction.
We designed a presentation meant to be a lot of fun, that taught things anyone could do, and perhaps by the end might have people questioning their ethics. Judging from much of the feedback I think we might have succeeded on the last point. :) RSnake was also a good sport when we ribbed him a little bit. For those interested in the slides, I quickly uploaded them to slideshare. The quality is decent (hard to see the references) and you can download the PDF. I’m working on slenderizing it now, so when I have it I’ll upload that as well, including the video when we get it.Lastly thank you very much to everyone who came and supported us, it meant a lot.
Thursday, July 31, 2008
My Picks for BlackHat USA 2008
Loads of awesome looking presentations this year! So hard to choose from. I really hope I’ll have time to see most of them and not stuck 24x7 in little rooms answering questions with people holding microphones. :) I hear the conference attendance is PACKED and suggest if you want to get in to see a popular speaker/talk, get there early. Oh, the same goes for the OWASP/WASC Party, get the Breach booth early.
Day 1: 10:00 to 11:00
Bad Sushi: Beating Phishers at Their Own Game
Nitesh Dhanjani, Senior Manager
Billy Rios, Microsoft
I saw this talk at Blue Hat is Seattle a couple months back. Not only is the data they present extremely compelling, but their humor and speaking style really put it over the top. With so many dry talks in our industry, when speakers are actively engaging it really makes a difference.
Day 1: 11:15 to 12:30
DNS Goodness
Dan Kaminsky
The vulnerability itself and disclosure drama aside, I have it on good authority that Dan will provide some important lessons learned as a result of the fiasco with regards to software serviceability. I’m really interested in hearing what he has to say about how we can improve our situation so we can adapt better to a similar scenario down the road.
Day 1: 13:45 to 15:00
Iron Chef: Fuzzing Challenge
This event was a lot of fun last year when I participated as a “celebrity judge”. Just don’t be under the impression that this is a scientific experiment or any kind. Instead simple enjoy the “show” where you can participate if you'd like. You get some code, find vulnerabilities however you want, and share your results. Simple! We should give them RSnake’s blog software. :)
Day 1: 15:15 to 16:30
Xploiting Google Gadgets: Gmalware and Beyond
Tom Stracener
Robert Hansen
My man RSnake accompanied by Tom Stracener delivering Google zero-days and JavaScript malware PoC abound. Who could miss that! Keep your eyes peeled for Googlers in the front row feverishly taking notes and radioing live information back to the Googleplex. This talk might also renew our sense of paranoia about browser security, if there is such a thing.
Day 1: 16:45 to 18:00
FLEX, AMF 3 and BlazeDS: An Assessment
Jacob Carlson
Kevin Stadmeyer
Don’t know much about the speakers or the talk itself, but the subject matter looks compelling and particularly timely. I’ve been doing a lot of my own research in Flash/Flex are well and there is a lot of unexplored territory within. XSS and CSRF malware payloads can and will get a lot worse with this stuff.
Day 2: 10:00 to 11:00
Encoded, Layered and Transcoded Syntax Attacks: Threading the Needle Past Web Application Security
Arian Evans
Going only because I have to speak alongside Arian. :) This presentation is the result of a large amount of experimentation on live websites using seriously obfuscated attack techniques. Some of the methods we’re still not exactly sure why they work, only that they do in extreme edge cases. What we’re also learning is that there is A LOT of web application vulnerability edge cases out there.
Day 2: 11:15 to 12:30
No More Signatures: Defending Web Applications from 0-Day Attacks with ModProfiler Using Traffic Profiling
Ivan Ristic
Ofar Shezaf
A serious toss up between this one and Threats to the 2008 Presidential Election, which I’m sure is also going to be a stellar. For me, I need to stay as up-to-date as I can in WAF technology evolution and Ivan is THE MAN in the open source space.
Day 2: 13:45 to 15:00
REST for the Wicked
Bryan Sullivan
Love the talk title and really interested in learning about any new attack techniques on SOAP and surrounding technologies. This area also continues to be a struggle for automated testing.
Day 2: 15:15 to 16:30
Get Rich or Die Trying – Making Money on the Web, the Black Hat Way
Jeremiah Grossman
Arian Evans
Again, only because I HAVE to be there. :) I’ve been wanting to do a presentation like this for quite some time and have finally been able to pull together enough data and public examples to make it possible. The idea is to demonstrate how to make serious money illicitly using the most simplistic of web attack techniques, all of which have already been used in the real world, and then speculate a little on other possibilities. All story driven, not meant to be grown breaking attack wise, just really thought provoking and fun.
Day 2: 16:45 to 18:00
Pushing the Camel Through the Eye of a Needle
SensePost
Only because the Sensepost guys are super l33t, always have exceptional material, and I’ve never been to a bad presentation yet. Didn’t even bother to read the description, I know it’ll be worthwhile. Hopefully I can make it over there after my presentation.
Day 1: 10:00 to 11:00
Bad Sushi: Beating Phishers at Their Own Game
Nitesh Dhanjani, Senior Manager
Billy Rios, Microsoft
I saw this talk at Blue Hat is Seattle a couple months back. Not only is the data they present extremely compelling, but their humor and speaking style really put it over the top. With so many dry talks in our industry, when speakers are actively engaging it really makes a difference.
Day 1: 11:15 to 12:30
DNS Goodness
Dan Kaminsky
The vulnerability itself and disclosure drama aside, I have it on good authority that Dan will provide some important lessons learned as a result of the fiasco with regards to software serviceability. I’m really interested in hearing what he has to say about how we can improve our situation so we can adapt better to a similar scenario down the road.
Day 1: 13:45 to 15:00
Iron Chef: Fuzzing Challenge
This event was a lot of fun last year when I participated as a “celebrity judge”. Just don’t be under the impression that this is a scientific experiment or any kind. Instead simple enjoy the “show” where you can participate if you'd like. You get some code, find vulnerabilities however you want, and share your results. Simple! We should give them RSnake’s blog software. :)
Day 1: 15:15 to 16:30
Xploiting Google Gadgets: Gmalware and Beyond
Tom Stracener
Robert Hansen
My man RSnake accompanied by Tom Stracener delivering Google zero-days and JavaScript malware PoC abound. Who could miss that! Keep your eyes peeled for Googlers in the front row feverishly taking notes and radioing live information back to the Googleplex. This talk might also renew our sense of paranoia about browser security, if there is such a thing.
Day 1: 16:45 to 18:00
FLEX, AMF 3 and BlazeDS: An Assessment
Jacob Carlson
Kevin Stadmeyer
Don’t know much about the speakers or the talk itself, but the subject matter looks compelling and particularly timely. I’ve been doing a lot of my own research in Flash/Flex are well and there is a lot of unexplored territory within. XSS and CSRF malware payloads can and will get a lot worse with this stuff.
Day 2: 10:00 to 11:00
Encoded, Layered and Transcoded Syntax Attacks: Threading the Needle Past Web Application Security
Arian Evans
Going only because I have to speak alongside Arian. :) This presentation is the result of a large amount of experimentation on live websites using seriously obfuscated attack techniques. Some of the methods we’re still not exactly sure why they work, only that they do in extreme edge cases. What we’re also learning is that there is A LOT of web application vulnerability edge cases out there.
Day 2: 11:15 to 12:30
No More Signatures: Defending Web Applications from 0-Day Attacks with ModProfiler Using Traffic Profiling
Ivan Ristic
Ofar Shezaf
A serious toss up between this one and Threats to the 2008 Presidential Election, which I’m sure is also going to be a stellar. For me, I need to stay as up-to-date as I can in WAF technology evolution and Ivan is THE MAN in the open source space.
Day 2: 13:45 to 15:00
REST for the Wicked
Bryan Sullivan
Love the talk title and really interested in learning about any new attack techniques on SOAP and surrounding technologies. This area also continues to be a struggle for automated testing.
Day 2: 15:15 to 16:30
Get Rich or Die Trying – Making Money on the Web, the Black Hat Way
Jeremiah Grossman
Arian Evans
Again, only because I HAVE to be there. :) I’ve been wanting to do a presentation like this for quite some time and have finally been able to pull together enough data and public examples to make it possible. The idea is to demonstrate how to make serious money illicitly using the most simplistic of web attack techniques, all of which have already been used in the real world, and then speculate a little on other possibilities. All story driven, not meant to be grown breaking attack wise, just really thought provoking and fun.
Day 2: 16:45 to 18:00
Pushing the Camel Through the Eye of a Needle
SensePost
Only because the Sensepost guys are super l33t, always have exceptional material, and I’ve never been to a bad presentation yet. Didn’t even bother to read the description, I know it’ll be worthwhile. Hopefully I can make it over there after my presentation.
Friday, July 25, 2008
Results: Web Application Security Professionals Survey (July 2008)
The survey concluded this morning with a simply amazing turn out! A total of 340 respondents -- well over double the previous. Thank you to everyone who helped get the word and of course to those taking the time to fill out the form. This information is invaluable. Since there were so many responses, and hence comments, I’m only able to post the report graphs below. The full report containing all the comments, probably the best part, is available for download (xls). The upside of so much data is I was also able to run reports on people classifying themselves as “Security vendor / consultant”, “Enterprise security professional”, and “Developers” individually to see how they differed, if at all. If you want to the entire package of reports, here ya go. Big hat tip to Robert “RSnake” Hansen for the bandwidth.
And now for my interpretation of the results…
Question #1 – 3
Shows that we have a nicely diverse set of individuals with varying backgrounds and years of experience. It looks like I should have had more granular answer options for Q2 though, note for next time.
Question #4
In the matter of browser security I figured just about everyone is using something above and beyond a default install, which is just plain crazy now days and the results confirmed. What astonished me though is the percentage of people across the range using virtualization, roughly 25%! Think about this. 1 in 4 web security people assume their browser and/or OS has a high likelihood of getting owned. Military intelligence, congressional ethics, browser security.
Question #5
In retrospect I should have asked a better PCI-DSS related question, the answers were unsurprising. People in the certain business sectors were influenced by PCI-DSS when it applied to them and they weren’t when it didn’t. What I really want to know is what ARE the driving factors behind why organizations are investing in web application security. I’ll try to figure out a better way to get to that answer set.
Question #6
These answers I found to be really interesting because they were split roughly down the middle and the comments were all over the map. Clearly there is no widely accepted view of what security means in the Web 2.0 software development era. We’re still trying to figure things out and convince ourselves that we have the right answer. Or that someone does. I think there is a lot still to be learned in this particular area and I plan to ask more questions on the topic going forward. This also might be an area where we should bring individual experts and practitioners to together to discuss the various issues.
Question #7
I purposely kept the term “vulnerability scanner” vague to see how they performed as an entire category. It doesn’t appear that vulnerability scanners have improved much or at least peoples impressions of them since the last survey. They performed dismally in Web 2.0 technologies including Ajax, Flash, and Web services. What surprised me is how well the scanners performed in the persistent XSS category, on par with the non-persistent. I can’t say I agree, but it is what it is. Could be an artifact that people don’t understand the difference and figure if the tool didn’t find it that its not there. The other interesting thing is that developers have a better opinion of scanners than security vendors and enterprise professionals.
I plan on digging into this area even more in the future and separate out scanner types, asking for product names, and overall impressions.
Question #8
I was fairly impressed with these results. 1/3 of the respondents said they’d either recommend a WAF, already have a WAF, or had a WAF on the road map. Then half of everyone said they were “Skeptical, but open minded” as compared to a sparse 15% expressing a level of negativity. This should be a huge market indicator for WAF vendors, industry analysts, VARs, and systems integrators. That 50% category represents a huge opportunity to demonstrate a WAFs value and long-term viability. In the next year we’ll know which way the trend is heading.
Question #9
Cmon, I had to poke a little fun at RSnake. I mean you gotta know web security is becoming mainstream when you can’t automatically win an online Chihuahua beauty contest poll in Austin without getting out haxored at the last second. ;)
Question #10
OK, that settles it. Web security people have little to no respect for McAfee’s HackerSafe brand and even that’s putting it mildly if you read the comments. I was confused on what the large “other” responses wanted for an option though. There is also a quite unnerving statistic with developers as their answers were split in thirds. Could it be that 1/3 of developers believe HackerSafe means security?
Question #11
And there we have it, web security people don’t trust Google, roughly 75% of them anyway. The kicker is most still use them in some way or form anyway. Maybe in many ways we are just like the average user. We’ll tend to sacrifice security for convenience just like they do.
Question #12
Some like the idea, some hate it, and others have a love-hate relationship. Either way it appears there’s enough people interested in a certification that its time for someone to do it and do it well. Sooner or later there will be 1 or perhaps 2 industry acceptable certifications. Who will it be!? Probably the first one to do it right will.
Question #13
The answers were all over the map and I don’t think I asked this question in the best way. Still the majority of C-level executives are at least giving the web security problem a good look. What I’d really like to know, similar to question #5, is what exactly is causing people to care and dedicate more resources. Maybe it’s an incident, industry regulation, keeping up with the jones, who knows! I aim to find out.
Question #14
80% of us figured the industry noise was tolerable or we’ve become number to it. The rest, well, they are not long for the industry anyway. You must get used to it or you’ll go crazy, maybe some of us already have.
Question #15
Who’s winning? Few think it’s the good guys. What more can we say here but that this is really sad and we have our work cut out for us.
Question #16
The forced ranked list. Some were close in the center, but this is what we got. Awareness is still a HUGE issue and I tend to agree.
1) General awareness and education
2) Implementation of an security inside the SDLC
3) Source code analysis
4) Black-box vulnerability assessment / pen-testing
5) Web application firewalls
6) Enforcing industry regulation
Question #17
Read the comments, it’s worth it. :)
And now for my interpretation of the results…
Question #1 – 3
Shows that we have a nicely diverse set of individuals with varying backgrounds and years of experience. It looks like I should have had more granular answer options for Q2 though, note for next time.
Question #4
In the matter of browser security I figured just about everyone is using something above and beyond a default install, which is just plain crazy now days and the results confirmed. What astonished me though is the percentage of people across the range using virtualization, roughly 25%! Think about this. 1 in 4 web security people assume their browser and/or OS has a high likelihood of getting owned. Military intelligence, congressional ethics, browser security.
Question #5
In retrospect I should have asked a better PCI-DSS related question, the answers were unsurprising. People in the certain business sectors were influenced by PCI-DSS when it applied to them and they weren’t when it didn’t. What I really want to know is what ARE the driving factors behind why organizations are investing in web application security. I’ll try to figure out a better way to get to that answer set.
Question #6
These answers I found to be really interesting because they were split roughly down the middle and the comments were all over the map. Clearly there is no widely accepted view of what security means in the Web 2.0 software development era. We’re still trying to figure things out and convince ourselves that we have the right answer. Or that someone does. I think there is a lot still to be learned in this particular area and I plan to ask more questions on the topic going forward. This also might be an area where we should bring individual experts and practitioners to together to discuss the various issues.
Question #7
I purposely kept the term “vulnerability scanner” vague to see how they performed as an entire category. It doesn’t appear that vulnerability scanners have improved much or at least peoples impressions of them since the last survey. They performed dismally in Web 2.0 technologies including Ajax, Flash, and Web services. What surprised me is how well the scanners performed in the persistent XSS category, on par with the non-persistent. I can’t say I agree, but it is what it is. Could be an artifact that people don’t understand the difference and figure if the tool didn’t find it that its not there. The other interesting thing is that developers have a better opinion of scanners than security vendors and enterprise professionals.
I plan on digging into this area even more in the future and separate out scanner types, asking for product names, and overall impressions.
Question #8
I was fairly impressed with these results. 1/3 of the respondents said they’d either recommend a WAF, already have a WAF, or had a WAF on the road map. Then half of everyone said they were “Skeptical, but open minded” as compared to a sparse 15% expressing a level of negativity. This should be a huge market indicator for WAF vendors, industry analysts, VARs, and systems integrators. That 50% category represents a huge opportunity to demonstrate a WAFs value and long-term viability. In the next year we’ll know which way the trend is heading.
Question #9
Cmon, I had to poke a little fun at RSnake. I mean you gotta know web security is becoming mainstream when you can’t automatically win an online Chihuahua beauty contest poll in Austin without getting out haxored at the last second. ;)
Question #10
OK, that settles it. Web security people have little to no respect for McAfee’s HackerSafe brand and even that’s putting it mildly if you read the comments. I was confused on what the large “other” responses wanted for an option though. There is also a quite unnerving statistic with developers as their answers were split in thirds. Could it be that 1/3 of developers believe HackerSafe means security?
Question #11
And there we have it, web security people don’t trust Google, roughly 75% of them anyway. The kicker is most still use them in some way or form anyway. Maybe in many ways we are just like the average user. We’ll tend to sacrifice security for convenience just like they do.
Question #12
Some like the idea, some hate it, and others have a love-hate relationship. Either way it appears there’s enough people interested in a certification that its time for someone to do it and do it well. Sooner or later there will be 1 or perhaps 2 industry acceptable certifications. Who will it be!? Probably the first one to do it right will.
Question #13
The answers were all over the map and I don’t think I asked this question in the best way. Still the majority of C-level executives are at least giving the web security problem a good look. What I’d really like to know, similar to question #5, is what exactly is causing people to care and dedicate more resources. Maybe it’s an incident, industry regulation, keeping up with the jones, who knows! I aim to find out.
Question #14
80% of us figured the industry noise was tolerable or we’ve become number to it. The rest, well, they are not long for the industry anyway. You must get used to it or you’ll go crazy, maybe some of us already have.
Question #15
Who’s winning? Few think it’s the good guys. What more can we say here but that this is really sad and we have our work cut out for us.
Question #16
The forced ranked list. Some were close in the center, but this is what we got. Awareness is still a HUGE issue and I tend to agree.
1) General awareness and education
2) Implementation of an security inside the SDLC
3) Source code analysis
4) Black-box vulnerability assessment / pen-testing
5) Web application firewalls
6) Enforcing industry regulation
Question #17
Read the comments, it’s worth it. :)
Friday, July 18, 2008
Web Application Security Professionals Survey (July 2008)
It’s been a long while since I posted a webappsec survey, Oct 2007. So leading up to BlackHat seemed like an opportune time to hear from the community what they think about the hot button topics of the day. The questions are designed to expose various aspects of web application security industry we previously didn't know, understand, or fully appreciate – and maybe learn a thing or two about our peers in the process. As always the more people who submit data, the more representative it will be, and that means please share the link. All the past surveys have been quite revealing.
TAKE THE SURVEY
Guidelines
- Open to anyone working in, around, or near the web application security field.
- If a question doesn’t apply to you or you don’t want to answer, leave it blank.
- Comments in relation to any question are welcome. All data will be published.
- Submissions must be received by July 25, 2008 (1 week), results posted shortly thereafter.
Publishing & Privacy Policy
- Results based on aggregate data collected will be published.
- Absolutely no names or contact information will be released to anyone, though feel free to self publish your answers anywhere.
TAKE THE SURVEY
Guidelines
- Open to anyone working in, around, or near the web application security field.
- If a question doesn’t apply to you or you don’t want to answer, leave it blank.
- Comments in relation to any question are welcome. All data will be published.
- Submissions must be received by July 25, 2008 (1 week), results posted shortly thereafter.
Publishing & Privacy Policy
- Results based on aggregate data collected will be published.
- Absolutely no names or contact information will be released to anyone, though feel free to self publish your answers anywhere.
Tuesday, July 15, 2008
0wN3d by 5 characters
RSnake: My number one problem with WAFs is they don't protect against _all_ the vulns.
Jeremiah: Sure, but secure code doesn't fix all the vulns eitehr
RSnake: Depends on _how_ secure! I could easily create a peice of code that was 100% secure. You wouldn't find it fun to interact with, but it would be secure.
Jeremiah: while (1) { exit; }
RSnake: Sure, if you want to get crazy. I was thinking: exit;
Jeremiah: dammit, 5 characters.
RSnake: I rule
Jeremiah: Sure, but secure code doesn't fix all the vulns eitehr
RSnake: Depends on _how_ secure! I could easily create a peice of code that was 100% secure. You wouldn't find it fun to interact with, but it would be secure.
Jeremiah: while (1) { exit; }
RSnake: Sure, if you want to get crazy. I was thinking: exit;
Jeremiah: dammit, 5 characters.
RSnake: I rule
Sunday, July 13, 2008
Roxer - still the easiest way to make a web page
Jer Blog Roxer:
It’s been several months since I’ve written about Roxer. Currently Lex does all the coding since I’m investing just about every waking moment at WhiteHat. Primarily I help on Roxer strategy and solve extremely difficult JavaScript problems. Since the beginning we’ve been completely enthralled in the types of pages users build and the features they ask for. Iterative development is a lot of fun as is prioritizing enhancements into buckets that draw a crowd, improving the user experience, and keep people coming back. Astonishingly we’re up over 13,000 users, not bad for near-zero marketing, and that’s if you count my single blog post. :)
Its really cool seeing people from all over the world using something you’ve built. Actually we think over half of our users are outside the U.S. Teachers are posting classroom curriculum. Students are making online book reports. Bands are creating their online presence. Gamers are creating fan pages. And of course there is some other stuff in there we have to remove from time to time that’s’ not PG-13 rated. :) A lot is being published and its become impossible for even us to track.
Our next challenge is trying figure out a business model that makes sense. Fortunately though since everything is so darn cheap to run on the Amazon cloud platform we haven’t really felt pressured to do so, focused more on product and kept the service free. Premium subscription pricing seems to be the way we’ll go, much more attractive than advertising, but we’ll probably try that to. Maybe I’ll post again when we hit 50K users, that’ll be something!
It’s been several months since I’ve written about Roxer. Currently Lex does all the coding since I’m investing just about every waking moment at WhiteHat. Primarily I help on Roxer strategy and solve extremely difficult JavaScript problems. Since the beginning we’ve been completely enthralled in the types of pages users build and the features they ask for. Iterative development is a lot of fun as is prioritizing enhancements into buckets that draw a crowd, improving the user experience, and keep people coming back. Astonishingly we’re up over 13,000 users, not bad for near-zero marketing, and that’s if you count my single blog post. :)
Its really cool seeing people from all over the world using something you’ve built. Actually we think over half of our users are outside the U.S. Teachers are posting classroom curriculum. Students are making online book reports. Bands are creating their online presence. Gamers are creating fan pages. And of course there is some other stuff in there we have to remove from time to time that’s’ not PG-13 rated. :) A lot is being published and its become impossible for even us to track.
Our next challenge is trying figure out a business model that makes sense. Fortunately though since everything is so darn cheap to run on the Amazon cloud platform we haven’t really felt pressured to do so, focused more on product and kept the service free. Premium subscription pricing seems to be the way we’ll go, much more attractive than advertising, but we’ll probably try that to. Maybe I’ll post again when we hit 50K users, that’ll be something!
Monday, July 07, 2008
Some unanswered questions
Some thoughts from over the holiday weekend.
1) Is time (adding or taking away) the only defense against web application timing attacks?
2) What good is using SSL to encrypt usernames/passwords when all other sensitive data is not?
3) Who is getting fined for how much due to lack of PCI-DSS compliance?
4) If automated vulnerability scanning of an application is a test of the tools intelligence, is manual testing a test of the human's intelligence?
5) When oh when will the TCv2 finally be finished!? :)
1) Is time (adding or taking away) the only defense against web application timing attacks?
2) What good is using SSL to encrypt usernames/passwords when all other sensitive data is not?
3) Who is getting fined for how much due to lack of PCI-DSS compliance?
4) If automated vulnerability scanning of an application is a test of the tools intelligence, is manual testing a test of the human's intelligence?
5) When oh when will the TCv2 finally be finished!? :)
Web Security Specialist ~ Tenacious Hunter Needed
We're hiring, especially those want to hack into websites for a living. That's right, paid to hack. If you don't know how, that's OK because we're ready to train. If you or someone you know might be interested in the opportunity, fill out the form on the job listing page. Note: you must reside in the S.F. Bay Area or willing to relocate.
"WhiteHat Security has an amazing opportunity for the creative person itching to take a crack at poking holes in websites while on the prowl for gaping security vulnerabilities. In this role you will have access to thousands – yes, thousands – of well-known websites. Your job will be to actively root through them looking for all the ways a blackhat might use to break into a site. In this role you will master the basics of web application security and secure software engineering and learn what it takes to become a skilled hacker--an incredible launching pad for your career in the web application security industry."
"WhiteHat Security has an amazing opportunity for the creative person itching to take a crack at poking holes in websites while on the prowl for gaping security vulnerabilities. In this role you will have access to thousands – yes, thousands – of well-known websites. Your job will be to actively root through them looking for all the ways a blackhat might use to break into a site. In this role you will master the basics of web application security and secure software engineering and learn what it takes to become a skilled hacker--an incredible launching pad for your career in the web application security industry."
Thursday, July 03, 2008
Whitepaper: Vulnerability Assessment Plus Web Application Firewall (VA+WAF)
For those interested we’ve released a whitepaper on how Vulnerability Assessment Plus and Web Application Firewall (VA+WAF) function independently and collectively. We spend a few pages describing the technical fundamentals of both which many should find educational – especially on the WAF side with industry material in painfully short supply. Very few people really understand the nitty gritty details of how WAF work and deployed in the real-world. I've learned a great deal in the last couple months talking with those who have. There is a little F5 ASM marketing in the paper so beware! :) Enjoy, snippets:
“WAFs at their core are designed to separate safe Web traffic from malicious traffic before it’s received by the website. And, if an attack does find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network. To get a better understanding of how the technology works, it’s helpful to view a WAF’s functionality as three discrete components - policies, policy generation, and policy enforcement. Depending on the particular WAF in use, they may go about implementing each component in a number of different ways. No one particular way has proven to be the right way, as each has its pros and cons.”
“Every effective vulnerability assessment program requires a cohesive combination of people, process, and technology. Qualified people are necessary to carry out day-to-day tasks, manage the technology, and interpret the results to make them meaningful to the business. Process is required for coordinated efforts between executive management, IT Security, and software development groups to share information, prioritize vulnerability fixes, and enable organizational improvements. The right technology is essential for consistency, efficiency, and comprehensiveness. Whether an organization chooses to perform vulnerability assessments with internal resources, a consultancy, or a Software-as-a-Services vendor, the overall vulnerability program must always account for people, process, and technology. If not, the effort will cost more in time and dollars than it should. Or worse, simply not work.”
“WAFs at their core are designed to separate safe Web traffic from malicious traffic before it’s received by the website. And, if an attack does find a way to sneak past a WAF, it still has the ability to prevent sensitive information from leaving the trusted network. To get a better understanding of how the technology works, it’s helpful to view a WAF’s functionality as three discrete components - policies, policy generation, and policy enforcement. Depending on the particular WAF in use, they may go about implementing each component in a number of different ways. No one particular way has proven to be the right way, as each has its pros and cons.”
“Every effective vulnerability assessment program requires a cohesive combination of people, process, and technology. Qualified people are necessary to carry out day-to-day tasks, manage the technology, and interpret the results to make them meaningful to the business. Process is required for coordinated efforts between executive management, IT Security, and software development groups to share information, prioritize vulnerability fixes, and enable organizational improvements. The right technology is essential for consistency, efficiency, and comprehensiveness. Whether an organization chooses to perform vulnerability assessments with internal resources, a consultancy, or a Software-as-a-Services vendor, the overall vulnerability program must always account for people, process, and technology. If not, the effort will cost more in time and dollars than it should. Or worse, simply not work.”
Wednesday, July 02, 2008
PCI-DSS references the outdated OWASP Top Ten
I’m sure other people have noticed this, at least I hope so, but never mentioned it publicly. If you read PCI-DSS 1.1 section 6.5, the part that covers “Cover prevention of common coding vulnerabilities in software development processes”, you’ll notice the list is identical to that of the OWASP Top Ten 2004 while the latest version is 2007:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance. :)
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance. :)
Web Application Security Today - Are We All Insane?
CSO magazine was kind enough to publish an opinion piece where I present a top-down view of the current state of web application security. I nervously expect a “spirited” flow of blog comments because it questions the value of certain best-practices and deeply held personal philosophies. Fortunately though our general public discourse has advanced a great deal recently and the community at large is a lot more informed of the challenges at hand. I pulled out a snippet to give a feel.
"It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at $50 billion and e-crime losses at $100 billion. We're losing two dollars for every dollar spent."
Enjoy!
"It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at $50 billion and e-crime losses at $100 billion. We're losing two dollars for every dollar spent."
Enjoy!
Thursday, June 26, 2008
Can WAFs protect against business logic flaws?
“Web Application Firewalls (WAF) are a total waste of time/money because they can’t protect against business logic flaws!,” a common theme among the few, but vocal, seriously anti-WAF zealots out there. While there is some truth it’s also like saying car door locks are useless because criminals can break in by smashing the windows. Or car alarms are a waste because they don’t protect against carjacking. And steering wheel locks are lousy because the car is at risk to thieves with tow trucks. You see where I’m going with this. Every security measure has a particular purpose, limitation, and overall value to the owner considering what it is they’re protecting.
Sure, WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors. A/V products don’t red flag every piece of malware. Anti-spam misses some junk mail. Yet we still utilize these solutions anyway because their value outweighs their limitations. And of course WAFs don’t replace vulnerability assessment (VA) or secure coding practices just as Nessus doesn’t compete with network firewalls or good segmentation practices. Therefore I recommend we ignore rash criticisms and keep an open mind into what WAFs can/can’t do, the value they may provide today, and consider how they made be improved – including being aided by VA intelligence (VA+WAF).
I’m going to keep my comments vendor agnostic. Perhaps some of the features described below are already included in some of the available WAF products. In fact I know they are and claim no novelty of any of these ideas (probably printed elsewhere), but I’ll leave it to the vendors to comment on their specific products capabilities. I think the readers here might be pleasantly surprised. My intent here is to explore a few of the more common business logic flaw examples we’ve all seen, assume we know where their location (VA), and attempt to hypothesize defense measures.
Business Logic Flaw examples
1) Rotating numbers in URLs, the classic case of Insufficient Authentication, Insufficient Authorization and Insufficient Process Validation where an attacker can gain access to data or functionality their user-level should not have. We’ve seen these issues countless times in order tracking systems, bank account screens, and even in online vote registration. I see at least two possible ways to prevent these types of business logic flaws with a WAF.
URL encryption
The WAF inspects outbound Web page content, dynamically encrypts and replaces every URL directed to the website, and by extension decrypts them on the way back in – completely transparent to the web server or application. For example:
<* a href=”http://website/app.cgi?foo=bar”>action<* /a>
becomes…
<* a href=”http://website/06ad47d8e64bd28de537…”>action<* /a>
or
<* a href=”http://website/app.cgi?foo=bar&t=1fad47d…”>action<* /a>
URL encryption is powerful as it prevents URL parameter tampering and by extension protects against a wide range of attacks (XSS, SQLi, CSRF, etc.). No parameter tampering, no number rotation, no business logic flaw. Implementation is really tricky though because the HTML parser has to be perfect otherwise requests will be blocked when links are missed. Bookmarks and search engine indexing is also potentially disrupted. However, websites where most functionality is behind a login screen, such as banking sites, might not mind. Its also possible these side effects could be reduced by only focusing on the URLs known to be vulnerable (VA) instead of pursuing global enforcement. There is no need to encrypt URLs that aren’t vulnerable.
Session-State tracking
Users can be tracked from one page to the next so it’s technically possible for a WAF to know where they are in a particular flow and where they should be able to get to, or not. If an attacker were to rotate a number in a URL the WAF could be capable of determining if they should have been able to get it (UI-wise) from where they are. If they shouldn’t be able to, deny! Or perhaps a more forgiving threshold is in order so the may try 1, 2, or even 10 illegal URLs, but not more because that would surely be abnormal behavior. Scalability is biggest drawback here as increasingly large state tables are required for tracking. However, if you know a particular URL or parameter name has a problem with number rotation, WAFs can again be configured to focus and enforce controls only there.
2) Session hijacking by way of cookie tampering is another old school hack that has implications for Credential/Session Prediction, Insufficient Session Expiration, and Session Fixation. This issue doesn’t show up as much as it once did because most developers are using the native session handling APIs in their development frameworks as opposed to rolling their own. A very good thing.
Just like the previous example we can utilize some good ol’ on-the-fly cookie encryption/decryption that can be easily performed with a WAF. If an attacker is unable to modify their cookie to a valid value, and the WAF would know cryptographically, then session handling issues go away. You could even add some httpOnly, secure, and non-persistent flags if you want. You’d still probably have issues with Insufficient Session Expiration or Session Fixation, but we’re getting somewhere. The only drawback I can think of is if JavaScript or some other client-side language needed to read/write the original cookies values.
3) WAFs could also potentially be used to stop login brute force attacks or Insufficient Anti-Automation by including CAPTCHAs on-the-fly at various choke points. Again, thresholds would be neat. We could explore other examples, but I think you get the idea and this post is long enough. Well at least I don't want to write anymore. :)
Its important to understand that we’re at the very beginning of WAFs (or website VA for that matter), their deployments, which is also why there is so little field experience posted anywhere. We need an open community dialog so we can see where this technology can go and how it can be improved. - independent of the PCI 6.6 mandate. My point is I don’t think WAFs will be able to solve all of our web application security problems, or even all business logic flaws, and I don’t know of anyone who does. It certainly would be nice though to see what WAFs can do or be made to do. We won’t know unless we keep and open mind and try.
"Any fool can criticize, condemn, and complain, and most fools do."
Benjamin Franklin
Sure, WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors. A/V products don’t red flag every piece of malware. Anti-spam misses some junk mail. Yet we still utilize these solutions anyway because their value outweighs their limitations. And of course WAFs don’t replace vulnerability assessment (VA) or secure coding practices just as Nessus doesn’t compete with network firewalls or good segmentation practices. Therefore I recommend we ignore rash criticisms and keep an open mind into what WAFs can/can’t do, the value they may provide today, and consider how they made be improved – including being aided by VA intelligence (VA+WAF).
I’m going to keep my comments vendor agnostic. Perhaps some of the features described below are already included in some of the available WAF products. In fact I know they are and claim no novelty of any of these ideas (probably printed elsewhere), but I’ll leave it to the vendors to comment on their specific products capabilities. I think the readers here might be pleasantly surprised. My intent here is to explore a few of the more common business logic flaw examples we’ve all seen, assume we know where their location (VA), and attempt to hypothesize defense measures.
Business Logic Flaw examples
1) Rotating numbers in URLs, the classic case of Insufficient Authentication, Insufficient Authorization and Insufficient Process Validation where an attacker can gain access to data or functionality their user-level should not have. We’ve seen these issues countless times in order tracking systems, bank account screens, and even in online vote registration. I see at least two possible ways to prevent these types of business logic flaws with a WAF.
URL encryption
The WAF inspects outbound Web page content, dynamically encrypts and replaces every URL directed to the website, and by extension decrypts them on the way back in – completely transparent to the web server or application. For example:
<* a href=”http://website/app.cgi?foo=bar”>action<* /a>
becomes…
<* a href=”http://website/06ad47d8e64bd28de537…”>action<* /a>
or
<* a href=”http://website/app.cgi?foo=bar&t=1fad47d…”>action<* /a>
URL encryption is powerful as it prevents URL parameter tampering and by extension protects against a wide range of attacks (XSS, SQLi, CSRF, etc.). No parameter tampering, no number rotation, no business logic flaw. Implementation is really tricky though because the HTML parser has to be perfect otherwise requests will be blocked when links are missed. Bookmarks and search engine indexing is also potentially disrupted. However, websites where most functionality is behind a login screen, such as banking sites, might not mind. Its also possible these side effects could be reduced by only focusing on the URLs known to be vulnerable (VA) instead of pursuing global enforcement. There is no need to encrypt URLs that aren’t vulnerable.
Session-State tracking
Users can be tracked from one page to the next so it’s technically possible for a WAF to know where they are in a particular flow and where they should be able to get to, or not. If an attacker were to rotate a number in a URL the WAF could be capable of determining if they should have been able to get it (UI-wise) from where they are. If they shouldn’t be able to, deny! Or perhaps a more forgiving threshold is in order so the may try 1, 2, or even 10 illegal URLs, but not more because that would surely be abnormal behavior. Scalability is biggest drawback here as increasingly large state tables are required for tracking. However, if you know a particular URL or parameter name has a problem with number rotation, WAFs can again be configured to focus and enforce controls only there.
2) Session hijacking by way of cookie tampering is another old school hack that has implications for Credential/Session Prediction, Insufficient Session Expiration, and Session Fixation. This issue doesn’t show up as much as it once did because most developers are using the native session handling APIs in their development frameworks as opposed to rolling their own. A very good thing.
Just like the previous example we can utilize some good ol’ on-the-fly cookie encryption/decryption that can be easily performed with a WAF. If an attacker is unable to modify their cookie to a valid value, and the WAF would know cryptographically, then session handling issues go away. You could even add some httpOnly, secure, and non-persistent flags if you want. You’d still probably have issues with Insufficient Session Expiration or Session Fixation, but we’re getting somewhere. The only drawback I can think of is if JavaScript or some other client-side language needed to read/write the original cookies values.
3) WAFs could also potentially be used to stop login brute force attacks or Insufficient Anti-Automation by including CAPTCHAs on-the-fly at various choke points. Again, thresholds would be neat. We could explore other examples, but I think you get the idea and this post is long enough. Well at least I don't want to write anymore. :)
Its important to understand that we’re at the very beginning of WAFs (or website VA for that matter), their deployments, which is also why there is so little field experience posted anywhere. We need an open community dialog so we can see where this technology can go and how it can be improved. - independent of the PCI 6.6 mandate. My point is I don’t think WAFs will be able to solve all of our web application security problems, or even all business logic flaws, and I don’t know of anyone who does. It certainly would be nice though to see what WAFs can do or be made to do. We won’t know unless we keep and open mind and try.
"Any fool can criticize, condemn, and complain, and most fools do."
Benjamin Franklin
Tuesday, June 24, 2008
Microsoft announces Black Box, White Box, and WAF
Apparently the mass SQL Injection attacks have really woken people up and they’re probably flooding the MS blogs and inboxes with pleas for assistance. No doubt a lot of them use Twitter. :) Site owners are desperate to protect their old legacy ASP classic code. To help the situation Microsoft has just announced 3 free new toys specifically targeted at SQLi.
1) The Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool that identifies SQL Injection vulnerabilities in ASP code. In order to run MSCASI you will need source code access and MSCASI will output areas vulnerable to SQL injection (i.e. the root cause and vulnerable path is identified).
Cool. If anyone wants to provide feedback on effectiveness, I'd really like to know!
2) Microsoft worked with the HP Web Security Research group to release the Scrawlr tool. The tool will crawl a website, simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities.
This is nice of HP to offer, but the product limitations seem somewhat onerous to me...
* Will only crawls up to 1500 pages
* Does not support sites requiring authentication
* Does not perform Blind SQL injection
* Cannot retrieve database contents
* Does not support JavaScript or flash parsing
Will not test forms for SQL Injection (POST Parameters)
Hmm, if used MSCASI and Scrawlr are used at the same time, can we call this Hybrid Analysis? :)
3) In order to block and mitigate SQL injection attacks (while the root cause is being fixed), you can also deploy SQL filters using a new release of URLScan 3.0. This tool restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from being executed on the server. It uses a set of keywords to block certain requests. If a bad request is detected, the filter will drop the request and it will not be processed by SQL.
IIS's equivalent to ModSecurity on Apache. Cool stuff, first used it a LOONG time ago and no doubt solid improvements have been made. From the description it appears to still be using a black list negative security model approach to protection. How about that!? :) Looks like the only thing they left out is some kind of DB or system clean up for those who have already suffered an incident. I’m hearing that the hacked count is up to 2 million sites now. Ouch.
1) The Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool that identifies SQL Injection vulnerabilities in ASP code. In order to run MSCASI you will need source code access and MSCASI will output areas vulnerable to SQL injection (i.e. the root cause and vulnerable path is identified).
Cool. If anyone wants to provide feedback on effectiveness, I'd really like to know!
2) Microsoft worked with the HP Web Security Research group to release the Scrawlr tool. The tool will crawl a website, simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities.
This is nice of HP to offer, but the product limitations seem somewhat onerous to me...
* Will only crawls up to 1500 pages
* Does not support sites requiring authentication
* Does not perform Blind SQL injection
* Cannot retrieve database contents
* Does not support JavaScript or flash parsing
Will not test forms for SQL Injection (POST Parameters)
Hmm, if used MSCASI and Scrawlr are used at the same time, can we call this Hybrid Analysis? :)
3) In order to block and mitigate SQL injection attacks (while the root cause is being fixed), you can also deploy SQL filters using a new release of URLScan 3.0. This tool restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from being executed on the server. It uses a set of keywords to block certain requests. If a bad request is detected, the filter will drop the request and it will not be processed by SQL.
IIS's equivalent to ModSecurity on Apache. Cool stuff, first used it a LOONG time ago and no doubt solid improvements have been made. From the description it appears to still be using a black list negative security model approach to protection. How about that!? :) Looks like the only thing they left out is some kind of DB or system clean up for those who have already suffered an incident. I’m hearing that the hacked count is up to 2 million sites now. Ouch.
Twitters users angry about SQL Injection hacks on their websites
The mass SQL injection attacks have impacted the lives of a lot of Twitter users out there. I did a search for “SQL Injection” and the results are page after page of misery, time wasted cleaning things up, and cursing up a storm. You can really feel their pain and the worst is probably not yet over. Still gotta fix all that legacy code. Here are some of my favorites tweets…
shartley: Cleaning yet another SQL injection attack. I'm F'n sick of cleaning up after lazy programming that took place during my year away.
jamesTWIT: To the hacker who designed the SQL injection bot. I hope you die and not a fast death...something slow and painful. Like caught in a fire!
chadmonahan: Dearest SQL Injection people, I don't like you. Yours, CM
programwitch: F'n SQL injection hacks.
Anirask: Damnit. Our main website is down cause of SQL Injection attacks. You figure devs would sanitize their inputs against this shit..
shartley: Cleaning yet another SQL injection attack. I'm F'n sick of cleaning up after lazy programming that took place during my year away.
jamesTWIT: To the hacker who designed the SQL injection bot. I hope you die and not a fast death...something slow and painful. Like caught in a fire!
chadmonahan: Dearest SQL Injection people, I don't like you. Yours, CM
programwitch: F'n SQL injection hacks.
Anirask: Damnit. Our main website is down cause of SQL Injection attacks. You figure devs would sanitize their inputs against this shit..
Sunday, June 22, 2008
Made purple belt in brazilian jiu jitsu
This weekend is one to be remembered. Out of the blue (no pun intended) I make purple belt in BJJ (white - blue - purple - brown - black) and our GGAFL nationals footy team wins a regional qualifier for 2008 USAFL National tournament (we’re trying to make Division 1). Woot! I love both these sports.
I’ve been training BJJ seriously hard over the last year and a half since receiving my blue, typically 4 days a week when not traveling and visiting local academies across the national when I am. Sprinkle in some running, weights, and footy and my stamina/skill is somewhat reasonable. Now if I could just be more disciplined about my diet, 221 lbs should be in reach within the next 6-8 weeks for competition.
A dislocated shoulder about a month ago set things back and is taking forever to heal. Ugh! It’s extremely painful to push or pull when my arm is extended so I have to keep it bent and use my elbow for everything. I also have to make sure no one grabs onto it otherwise its tap city. And I hate tapping, the thing I failed to do and the cause of the injury (stupid). I’ve also noticed that when injured my technical game comes up a lot faster than it would have otherwise.
You see if you can’t use any much of any strength you are forced to rely more on technique and strategy. Speed, strength, and technique are basically the three ways to beat someone. At my size speed is unreliable :). For me if I stop training altogether to heal or get frustrated my game and stamina goes down fast. For those in BJJ they know nursing minor injuries is just part of the sport.
While I really hadn’t realized it over the past couple of weeks, I’ve been taping everyone in the academy (blues and purples) one after the other. I guess it looked weird for me to NOT have a purple belt, even if I’m early, so here I am. A whole new level, the realm of leg locks, and pursuing journey to the brown.
Hoff, we’re gonna have some fun at Black Hat. :)
I’ve been training BJJ seriously hard over the last year and a half since receiving my blue, typically 4 days a week when not traveling and visiting local academies across the national when I am. Sprinkle in some running, weights, and footy and my stamina/skill is somewhat reasonable. Now if I could just be more disciplined about my diet, 221 lbs should be in reach within the next 6-8 weeks for competition.
A dislocated shoulder about a month ago set things back and is taking forever to heal. Ugh! It’s extremely painful to push or pull when my arm is extended so I have to keep it bent and use my elbow for everything. I also have to make sure no one grabs onto it otherwise its tap city. And I hate tapping, the thing I failed to do and the cause of the injury (stupid). I’ve also noticed that when injured my technical game comes up a lot faster than it would have otherwise.
You see if you can’t use any much of any strength you are forced to rely more on technique and strategy. Speed, strength, and technique are basically the three ways to beat someone. At my size speed is unreliable :). For me if I stop training altogether to heal or get frustrated my game and stamina goes down fast. For those in BJJ they know nursing minor injuries is just part of the sport.
While I really hadn’t realized it over the past couple of weeks, I’ve been taping everyone in the academy (blues and purples) one after the other. I guess it looked weird for me to NOT have a purple belt, even if I’m early, so here I am. A whole new level, the realm of leg locks, and pursuing journey to the brown.
Hoff, we’re gonna have some fun at Black Hat. :)
Friday, June 20, 2008
Day 1: Starting at the beginning
You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites.
What is the very first thing do on day 1?
The idea here is to collect wisdom from the crowd (avoiding multiple choice), see if we can find reoccurring themes, order them accordingly, and then move onto the next step. And please don’t say pour a cup of coffee. :)
What is the very first thing do on day 1?
The idea here is to collect wisdom from the crowd (avoiding multiple choice), see if we can find reoccurring themes, order them accordingly, and then move onto the next step. And please don’t say pour a cup of coffee. :)
Top 5 questions to get webappsec threads spinning out of control
1. Should all Web traffic be SSL'ed or only username/passwords?
2. Black box vs. white box testing, which is better?
3. Ask anything about a WAF.
4. What are the best-practices for conducting password recovery?
5. Which certification should I get? CISSP?
2. Black box vs. white box testing, which is better?
3. Ask anything about a WAF.
4. What are the best-practices for conducting password recovery?
5. Which certification should I get? CISSP?
Thursday, June 19, 2008
Ultimate Scanner Accuracy Test
Imperva issued a press release and a pair of blog posts describing their new SecureSphere (WAF) API functionality (OpenSphere). Cool stuff. Clearly from the text they’re excited by the VA+WAF concept, which is the same technology integration path WhiteHat Security completed with F5’s ASM and Breach’s open source ModSecurty. We’ve been getting email asking when we plan to integrate Sentinel with Imperva (and we likely will) because we’re only VA scanning vendor not listed (Cenzic, HP, IBM, NTO) in their announcement, but I’ll get to that in a moment.
There is something else deep underneath that VA+WAF brings to the surface, something everyone finds important, and that is true scanner accuracy. For VA+WAF to work (block) in a production environment scanner results MUST be EXTREMELY accurate. We’re talking sub 1% false positive and duplicate rates or things will fail (badly). And even then you still want to test virtual patches in alert mode first. Scanners cannot fudge these results, use noncommittal “potential vulnerability” reporting, or use clever marketing spin. You got the good or you don’t and probably an interesting new way to review scanners.
For example Kavado (defunct) attempted the VA+WAF in 2002-2003; and other vendors tried again in 2003-2004 using AVDL. Ultimately, all VA+WAF attempts proved unsuccessful because the scanning products dumped hundreds or even thousands of false positives and duplicate vulnerabilities (still the case?) into the WAFs. Early implementations labored WAF performance or rendered the entire website inaccessible. We feel at WhiteHat Security we’ve overcome the accuracy challenge and statistically gathered enough proof points to feel comfortable bringing the solution to market.
As far as integration our plans go and why we’re not listed, WhiteHat Sentinel features are almost entirely customer demand driven and WAF integration is no different. Many enterprises are considering their options (Cisco, Citrix, WebDefend, etc.) and then let us know which product they liked best. Then we get the product in the lab, integrate the technology, test, test, test, and test again, then show it off to a several people. If feedback is positive, then we announce. Perhaps other scanning vendors do it differently and don’t mind marketing vapor-ware. We prefer offering solutions that work first and that might explain why we’re not on the list. :)
There is something else deep underneath that VA+WAF brings to the surface, something everyone finds important, and that is true scanner accuracy. For VA+WAF to work (block) in a production environment scanner results MUST be EXTREMELY accurate. We’re talking sub 1% false positive and duplicate rates or things will fail (badly). And even then you still want to test virtual patches in alert mode first. Scanners cannot fudge these results, use noncommittal “potential vulnerability” reporting, or use clever marketing spin. You got the good or you don’t and probably an interesting new way to review scanners.
For example Kavado (defunct) attempted the VA+WAF in 2002-2003; and other vendors tried again in 2003-2004 using AVDL. Ultimately, all VA+WAF attempts proved unsuccessful because the scanning products dumped hundreds or even thousands of false positives and duplicate vulnerabilities (still the case?) into the WAFs. Early implementations labored WAF performance or rendered the entire website inaccessible. We feel at WhiteHat Security we’ve overcome the accuracy challenge and statistically gathered enough proof points to feel comfortable bringing the solution to market.
As far as integration our plans go and why we’re not listed, WhiteHat Sentinel features are almost entirely customer demand driven and WAF integration is no different. Many enterprises are considering their options (Cisco, Citrix, WebDefend, etc.) and then let us know which product they liked best. Then we get the product in the lab, integrate the technology, test, test, test, and test again, then show it off to a several people. If feedback is positive, then we announce. Perhaps other scanning vendors do it differently and don’t mind marketing vapor-ware. We prefer offering solutions that work first and that might explain why we’re not on the list. :)
Wednesday, June 18, 2008
I've joined the Twitter-sphere
Don't know exactly why yet, but people say it's cool and worth a look. Seems like speed blogging to me, or maybe like a big chatroom. jeremiahg is the name if you care to follow.
OWASP/WASC Party - Black Hat 2008
Last year hundreds showed up to the OWASP/WASC Black Hat (2007) party (sponsored by Breach Security) for the free booze, food, and chance to geek out on webappsec. The 2008 party is going to just as awesome, who knows, may be even better. If that's possible. :) Due to the overly massive attendance last year (and long line), there will be no email RSVP list. You MUST show up to get a wristband at the Breach booth. My advice, don't wait till the last moment. They'll definitely run out because the Shadow Bar can only hold so many people. See you all there!
When: Wednesday, August 6, 7:30 PM – 9:30 PM
Where: Shadow Bar, Caesar's Palace, Las Vegas
When: Wednesday, August 6, 7:30 PM – 9:30 PM
Where: Shadow Bar, Caesar's Palace, Las Vegas
Monday, June 16, 2008
Why most WAFs do not block
I found the reason elegantly described in “Economics and Strategies of Data Security", by Dr. Dan Geer.
“When you know nothing, permit-all is the only option. When you know something, default-permit is what you can and should do. When you know everything, default-deny becomes possible, and only then.”
To implement default-deny Web Application Firewalls (WAF) must know everything about a website at all times, even when they change. That’s programmatically documenting every expected request method, URL, parameter name/value pair, cookie, process flow, etc making default-permit deployments the rule rather than the exception. Some WAF policies though, like HTTP protocol validation, can run in default-deny mode - the rest well, not so much. Which is why putting in point rules (virtual patches) to defend against known vulnerabilities tends to work well in lieu of pure positive security models.
“When you know nothing, permit-all is the only option. When you know something, default-permit is what you can and should do. When you know everything, default-deny becomes possible, and only then.”
To implement default-deny Web Application Firewalls (WAF) must know everything about a website at all times, even when they change. That’s programmatically documenting every expected request method, URL, parameter name/value pair, cookie, process flow, etc making default-permit deployments the rule rather than the exception. Some WAF policies though, like HTTP protocol validation, can run in default-deny mode - the rest well, not so much. Which is why putting in point rules (virtual patches) to defend against known vulnerabilities tends to work well in lieu of pure positive security models.
Developers don’t go to security conferences
RSnake and I were talking about this the other day as one of the problems in the webappsec industry. Over the years I’ve spoken at well over 100 events including ISSA, ISACA, Black Hat, AppSec, InfoSec, SANS, CSI, and probably more OWASP chapters than anyone. Saying 10% of infosec conference audiences are developers would be a generous estimate. The vast majority is part of IT Security in one form or another. For some reason though IT Security people expect developers to come to us and be shown the light, perhaps it should be the other way around. In fact, I’m sure of it.
Back in May Joe Walker and I co-presented at JavaOne (as we did the year before at the Ajax Experience). He’s plays the part of the well-known developer bringing in the well-known infosec guy. Over 1,000 people maxed out the ballroom, so clearly “security” is a draw at developer conferences. We covered XSS, CSRF, SQL Injection, and offered some live demos. We showed what an attacker could do to their beloved code should some basic precautions not be taken and discussed the value of security inside the SDLC. Judging from the feedback - they loved it. Demos rule, no question. I think I reached more developers and made a more positive impact on that group that day than in all the shows since the Ajax Experience.
Here’s what I’ve learned: Tailor your subject matter and talking points to your audience. OK, you already knew that. From my experience IT Security is most interested in learning about the latest and greatest threats, statistical trends, and what they’re peers did to solve a particular problem. So that's what I focus on during those events. Preaching security in the SDLC is just “OK”, but not terribly sexy to this audience. This is why you hardly see any code security talks at the infosec conferences, much the dismay of Andrew van der Stock. Developers and developer conferences are much interested in “application security”, but it has to be presented in the proper context to keep it interesting. Getting a handle on the right flow, format, and level of sophistication is the hard part. Seems they want to cover more browser extension and Google Gears related stuff now.
Back in May Joe Walker and I co-presented at JavaOne (as we did the year before at the Ajax Experience). He’s plays the part of the well-known developer bringing in the well-known infosec guy. Over 1,000 people maxed out the ballroom, so clearly “security” is a draw at developer conferences. We covered XSS, CSRF, SQL Injection, and offered some live demos. We showed what an attacker could do to their beloved code should some basic precautions not be taken and discussed the value of security inside the SDLC. Judging from the feedback - they loved it. Demos rule, no question. I think I reached more developers and made a more positive impact on that group that day than in all the shows since the Ajax Experience.
Here’s what I’ve learned: Tailor your subject matter and talking points to your audience. OK, you already knew that. From my experience IT Security is most interested in learning about the latest and greatest threats, statistical trends, and what they’re peers did to solve a particular problem. So that's what I focus on during those events. Preaching security in the SDLC is just “OK”, but not terribly sexy to this audience. This is why you hardly see any code security talks at the infosec conferences, much the dismay of Andrew van der Stock. Developers and developer conferences are much interested in “application security”, but it has to be presented in the proper context to keep it interesting. Getting a handle on the right flow, format, and level of sophistication is the hard part. Seems they want to cover more browser extension and Google Gears related stuff now.
Subscribe to:
Posts (Atom)