Web Admin Blog Real Web Admins. Real World Experience.

1Dec/150

The OWASP Board “Ivory Tower” Dilemma

I have been an active member of the OWASP community in some form since 2007.  I've been the OWASP Austin Chapter Leader, served as the Chair of the Global Chapters Committee, and, most recently, was elected (and re-elected) to the OWASP Board of Directors.  In the past, I have heard a number of people in our community compare the Board to an "Ivory Tower".  They would say that they were unapproachable and preferred to let others do the work while they pulled the strings of the Foundation from behind the scenes.  I think there may be some truth to that statement, but I told myself when I ran for the Board that I wouldn't be like that.  I want people to feel like I am out there actively trying to solve the problems of our community.  Case in point, in my 23 months on the OWASP Board, I have proposed more Bylaw changes and new policies than anybody else.

As I continue to try to be a man of action, I find that I am often one of the first Board members on the scene in times of crisis.  On multiple occasions I've shunned the historical "Ivory Tower" approach to managing the organization and dove head in to the situation at hand.  My assumption has been that I was elected because I have an opinion, not in spite of it.  In each case I've tried to present a clear and concise analysis of my view of the situation.  I've tried to offer up suggestions on next steps or provide data points that others may not have been aware of.  Being such a diverse community has many strengths, however, one weakness is that it is difficult to drive to a consensus on anything.  It really doesn't matter what side of the issue you are on, it always seems like some will agree with you and others will not.  Frequently, what begins as an intended friendly and spirited debate, ends with somebody feeling marginalized because a decision was made that they did not agree with.  It's sad when this happens, but is inevitable when you mix passionate people with issues that do not have binary answers.

This leads me back to the "Ivory Tower" dilemma.  If my desire is to actively be a part of the community, then I place myself directly in a position of potential conflict when I speak.  I'm not allowed to speak as Josh, the community member, because the perception is that I am always speaking with my Board member hat on.  And I have a strong feeling that this perception of Board members speaking authoritatively is what leads a person on the other side to feel marginalized.  Definitely not intended, at least on my part, but that's what I've started to gather from some of the feedback that I've received.  So if that's the case, then I begin to wonder if the situation would have been better off had I held my tongue and refrained from jumping into the discussion in order to let our community continue to fight it out or to let another Board member, our Executive Director, or somebody else communicate the Board's analysis and actions.  But, if I do that, aren't I now perpetuating the stereotype of the OWASP Board being an "Ivory Tower"?

I'm not sure that there is a right or wrong answer here and nobody said that being a Board member would be easy, but I can't say that I ever expected to need to give up my personal voice with the community (the one that likely got me elected to the Board in the first place) in order to serve the Board.  That said, it genuinely saddens me when an extremely valued OWASP volunteer feels the need to leave in order to make a point.  It is a huge loss for the OWASP Foundation and one that I, regrettably, played a role in provoking.  I don't apologize for my stance on the issue that was being debated.  I feel that we should all be allowed to have an opinion and I still support the actions of the Board thus far.  That said, if I could take back my words, crawl back into that "Ivory Tower", and let someone else do the talking in this particular situation, I'm sorry to say that I would.

Johanna, I'm sorry that it turned out this way.  You may not believe it, but I sincerely respect and appreciate what you have done for the OWASP Foundation more than words can express.  You have brought order where there was chaos and a dedication to the cause that was matched only by your intellect.  I feel that we don't have to always agree on a vision in order for me to appreciate your perspective.  I regret that I never conveyed that to you before now.  I'm sorry.

5Jun/1410

My First Six Months as an OWASP Board Member

When I first put my name in the hat for the OWASP elections in the fall of 2013, I thought I knew what I was signing up for.  I thought that my seven year history with the organization in a number of different roles (Chapter Leader, Chapter Committee Chair, AppSecUSA Chair) had me well prepared for the duties of an OWASP Board member.  I told my wife that it wouldn't be a big deal, mostly something that I could do in my spare time while at work, and that it would feel good to be able to make a difference on a bigger scale than I'd done to date.  I ran for the Board on a platform of wanting to support the growth of the OWASP chapters around the world and wanting to drive visibility, and ultimately buy-in, back to the community.  I told myself that as passionate as I was with these things as a community member, it was time to either put up or shut up.

Here I am, six months later, as an elected member of the OWASP Board of Directors and I can honestly say that no prior experience could have prepared me for this.  It's not a good thing or a bad thing, it's just very different than I expected.  As a community member, I remember being at the AppSecUSA conferences and struggling with how to introduce myself to these "famous" OWASP Board Members.  I was a just a chapter leader struggling to come up with ideas to engage the Austin security community while these guys were literally trying to change the world.  They were the figurative "Rock Stars" of my little security world.  Needless to say, I see things a bit differently now, but it's probably not what you think.

When I look at my fellow Board members, I do still see those "Rock Stars".  I can't even begin to tell you how much I look up to guys like Jim Manico for literally spending every day of his life trying to make the world more secure.  I constantly have to tell myself that even though I don't consider myself a security rock star, the community saw something in me and put me on the Board for a reason and I continue to hold myself responsible for executing on the platform that I laid out in my election materials.  But what I've come to realize now, that I didn't realize before my election, is that even though it feels the other way around, it's really the community, not the Board that holds the power in OWASP.

When I look back at the discussions that we've had as a Board over the past six months, other than setting strategic goals, the vast majority of our meetings have focused on operational and governance issues.  Through this process, I have come to the realization that while extremely important to keeping OWASP, as a non-profit organization, afloat, this isn't the kind of exciting world-wide impact stuff I thought I had signed up for.  As an example, my first two months as a Board member were spent in large part re-investigating a situation that a previous Board had closed the books on long ago.  In the process of trying to help the individual involved, I was twice accused by that individual (and acquitted) of violating OWASP's Code of Ethics.  Talk about gratitude.  Since then, it seems like it's been putting out one small fire after another.  More recently, I've spent many hours working with the Board and the Executive Director to grapple with an employee who resigned from the organization only to have members of our community question whether we, as an organization, did enough to keep them here, without knowing all of the details.  It blows my mind how the Board can have unanimous support for an item, feel confident that it's in the best interest of the organization, and still be called into question as to whether we are somehow being underhanded in our decisions.  It's like we sometimes forget that the Board is made up of seven people, from all over the world, with vastly different beliefs, desires, and even visions for OWASP.  If you can get that many people, that diverse, on the same page, then there's something to be said for that.

So, I guess in a nutshell what I'm saying is that while I feel that it's quite the privilege to be serving on the OWASP Board alongside some of the people I respect most in this industry, there is definitely a part of me that feels like the stuff that OWASP does that has the most profound impact on global security isn't what we do on the Board, but rather, what the community does in our Chapters and Projects.  The Board is there to support you, the community.  To create the policies to make you successful.  To provide the staff to make your lives easier so that you can spend your time doing things that accomplish OWASP's mission.  In addition, I want to dispel any notion that the Board is some sort of an Ivory Tower.  There should never be an "us vs them" mentality at OWASP because the Board is made up of people who have been, and in many cases still are, in the trenches right alongside the community.  The Board, to put it simply, is just a group of Chapter Leaders, Project Leaders, and other members of our community who, like me, decided that it was time to put up or shut up.  People who, for whatever reason, the community elected as our leaders to evangelize the OWASP mission and make the community that we hold near and dear to our hearts successful.  To think that anyone would volunteer to be a Board member only to destroy our community is absurd.  While I may not necessarily agree with everything my fellow Board members say or do, I have never questioned their loyalty to OWASP and I hope you don't either.

With all of the above having been said, I feel that it's also important to say that being an OWASP Board member is also an amazing opportunity to be a catalyst for change.  Over the past six months the Board has stepped up to the task of driving visibility and control back to our community.  We've instituted a new polling system that the Board have used to take the pulse of the community on key issues.  Michael has taken on the responsibility of weekly calls with the community in order to keep them informed of key issues and allow them to provide feedback.  And we are currently working on bringing back the committees under a new structure that will encourage participation and empower our leaders to take action.  OWASP even won the SC Magazine Editor's Choice Award at this year's RSA Conference.  Regardless of how you've felt about OWASP in the past, I feel quite strongly that the future for OWASP is so bright we're going to need a good pair of shades.

So, I'll end this post very similar to how it began.  The OWASP Foundation is currently accepting nominations for the OWASP Board of Directors.  If you've ever felt passionate about Information Security or felt like you have big ideas to make OWASP a better community, then now is the perfect time to throw your hat into the ring as I did.  I can't promise that it'll make you a security rock star.  I can't even promise that the work is glamorous.  And my experience, thus far, has been that it's been countless hours of volunteer work with little appreciation for what gets done.  But, what I can promise, is that OWASP is making the world a better place and the Board plays a vital role in making that happen.  You, too, can be a catalyst for change.

13Nov/090

The OWASP Security Spending Benchmarks Project

This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project.  My notes are below:

It does cost more to produce a secure product than an insecure product.

Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.

Why do we spend on security?  How much should we be spending?

  • Security imposes extra costs on organizations
  • The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
  • No comparable data for development or web apps
  • Regualtions and contracts usually require "reasonable measures".  What does that mean?

OWASP Security Spending Benchmarks Project

  • 20 partner organizations, many contributors
  • Open process and participation
  • Raw data available to community

Reasons For Investing in Security

  • Contractual and Regulatory Compliance
  • Incident Prevention, Risk Mitigation
  • Cost of Entry
  • Competitive Advantage

Technical and Procedural Principles

  • Managed and Documented Systems
  • Business-need access
  • Minimization of sensitive data use
  • Security in Design and Development
  • Auditing and Monitoring
  • Defense in Depth

Specific Activities and Projects

  • Security Policy and Training
  • DLP-Type Systems
  • Internal Configurations Management
  • Credential Management
  • Security in Development
  • Locking down internal permissions
  • Secure Data Exchange
  • Network Security
  • Application Security Programs
13Nov/090

OWASP Top 10 – 2010

This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member.  My notes are below:

What's Changed?

  • It's about Risks, not just vulnerabilities
    • New title is: "The Top 10 Most Critical Web Application Security Risks"
  • OWASP Top 10 Risk Rating Methodology
    • Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
  • 2 Risks Added, 2 Dropped
    • Added: A6 - Security Misconfiguration
      • Was A10 in 2004 Top 10: Insecure Configuration Management
    • Added: A8 - Unvalidated Redirects and Forwards
      • Relatively common and VERY dangerous flaw that is not well know
    • Removed: A3 - Malicious File Execution
      • Primarily a PHP flaw that is dropping in prevalence
    • Removed: A6 - Information Leakage and Improper Error Handling
      • A very prevalent flaw, that does not introduce much risk (normally)
  1. A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
  2. A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser.  For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe.  (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
  3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
  4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
  5. A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application.  Vulnerability is caused by browsers automatically including user authentication data with each request.  (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
  6. A6 - Security Misconfiguration: All through the network and platform.  Don't forget the development environment.  Think of all the places your source code goes.  All credentials should change in production.
  7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
  8. A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL.  If they aren't validated, attacker can send victim to a site of their choice.
  9. A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely.  Failure to identify all sensitive data.  Failure to identify all the places that this sensitive data gets stored.  Failure to properly protect this data in every location.
  10. A10 - Insufficient Transport Layer Protection

OWASP Top 10 Risk Rating Methodology

  • Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
  • Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
  • Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy),  2 (Average), 3 (Difficult))
  • Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))

This is generic across the internet, not specific to any organization.

Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).

What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.

12Nov/090

OWASP Live CD: An open environment for Web Application Security

General Goals Going Forward

  • Showcase great OWASP projects
  • Provide the best, freely distributable application security tools/documents
  • Ensure that the tools provided are easy to use as possible
  • Continue to document how to use the tools and how the modules were created
  • Align the tools with the OWASP Testing Guide v3 to provide maximum coverage
  • Awesome training environment

330,081 total downloads as of 10/5/2009

~5,094 GB of bandwidth since launch (7/2008)

Most downloads in 1 month = 81,607 (3/2009)

Available Tools: 26 "Significant"

  • Web Scarab
  • Web Goat
  • CAL9000
  • JBroFuzz
  • WSFuzzer
  • Wapiti
  • Burp Suite
  • Paro
  • Spike Proxy
  • Rat Proxy
  • w3af
  • Grendel Scan
  • Nikto
  • nmap
  • Zenmap
  • sqlmap
  • SQL Brute
  • Metasploit
  • ....

OWASP Documents

  • Testing Guide v2 & v3
  • CLASP
  • Top 10 for 2007
  • Top 10 for Java Enterprise Edition
  • AppSec FAQ
  • Books (CLASP, Top 10 2007, Top 10 + Testing + Legal, WebGoat and Web Scarab, Guide 2.0, Code Review)
  • WASC Threat Classification
  • OSTTMM

Where are we going?

  • Project Tindy (Live CD installed to a virtual hard drive, persistence, VMware, VirtualBox, and Paralles)
  • Project Aqua Dog (OWASP Live CD on a USB drive, VM install + VM engine + USB drive = mobile app sec platform, currently testing, Qemu is the current VM engine)
  • Much easier URL - AppSecLive.org
  • Community site around OWASP Live CD
  • Online Tool DB (331+ tools)
  • New release will be based on Ubuntu instead of SLAX
  • Create .deb packages for every tool
  • Create a repository for packages
  • Add dependency info to packages
  • Brings the 26,000+ existing packages to the Live CD
  • More fun cool stuff like Wubi (install Ubuntu onto an existing windows desktop to be able to dual-boot without repartitioning windows)

Design Goals

  • Easy for users to keep updated
  • Easy for project lead to keep updated
  • Easy to produce releases (every 6 months)
    • Crank out new .debs when new tool releases
    • Continually updating repository
  • Focused on just application security - not general pen testing
    • Both dynamic and static tools
    • Developer tools also

OWASP Education Project

  • Natural ties between these projects
    • Already being used for training classes
    • Need to coordinate efforts to make sure critical pieces aren't missing form the OWASP Live CD
    • Training environment could be customized for a particular class thanks to the individual modules
      • Student gets to take the environment home
    • As more modules come online, even more potential for cross pollination
    • Builder tools/docs only expand its reach
    • Kiosk mode?

Crazy Pie in the Sky Idea

  • .deb package + auto update + categories = CD profiles
  • Allows someone to customize the OWASP Live CD to their needs
  • Example Profiles:
    • Whitebox testing
    • Blackbox testing
    • Static analysis
    • Targe specific (Java, .Net)

What have you done for me lately?

  • For Testers/QA testers
    • Wide array of tools, preconfigured and ready to go
    • Nice "jump kit" to keep in your laptop bag
    • Great platform to test or learn the tools
  • For App Sec Professionals
    • Both dynamic and static tool coverage
    • Ability to customize the job your on
  • For Trainers
    • Ready to go environment for students
    • Ability to customize for the class

Get Involved

  • Join the mailing list
  • Post on hte AppSecLive.org forums
  • Download an ISO or VM
    • Complain or praise, suggest improvements
    • Submit a bug to the Google Code site
  • Create a deb package of a tool
    • How I create the debs will be documented, command by command and I'll answer questions gladly
  • Suggest missing tools, docs, or links
  • Do a screencast of one of the tools being used on the OWASP Live CD

Learn More

  • Google "OWASP Live CD"
  • Download & Community Site (http://AppSecLive.org)

Everything is stored in /opt/owasp

Tagged as: , , , No Comments
12Nov/090

The ESAPI Web Application Firewall

This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project.  My notes are below:

WAF Fallacies (at least in regards to OWASP ESAPI WAF)

  • WAFs add attack surface
  • WAFs can create culture problems
  • WAFs can't fix business logic vulnerabilities
  • WAFs are way too expensive
  • WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

  • Changing in ESAPI WAF is just a text file
  • Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

  • Performance - Only your rules are checked, plus state is already managed by the app server
  • Capability - being closer to the app lets us do more
  • Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

  • Add anti-clickjacking header
  • Set uniform content-type
  • Add HttpOnly flag
  • Add secure flag
  • Detect outbound information
  • Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

  • Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
  • Unchecked Redirect
  • Add HttpOnly
  • Add anti-clickjacking header
  • Privilege escalation

3 Different WAF Modes

  • Log
  • Block
  • Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.

12Nov/090

Software Assurance Maturity Model (SAMM)

This presentation on the OWASP Software Assurance Maturity Model (SAMM) was by Pravir Chandra, the project lead.  I was actually really excited in seeing this topic on the schedule as SAMM is something that I've been toying with for my organization for a while.  It's actually a very simple and intuitive approach to how to assess where your organization is at as far as software maturity, where you want to get to, and how to get there.  My notes on this presentation are below:

By the end of the presentation should be able to....

  • Evaluate an organizations existing software security practices
  • Build a balanced software security assurance program in well-defined iterations
  • Demonstrate concrete improvements to a security assessment program
  • Define and measure security-related activities throughout the organization

Lessons Learned

  • Microsoft SDL
    • Heavyweight, good for large ISVs
  • Touchpoints
    • High-level, not enough details to execute against
  • CLASP
    • Large collection of activities, but no priority ordering
  • ALL: Good for experts to use as a guide, but hard for non-security folkds to use off the shelf

Drivers for a Maturity Model

  • An organization's behavior changes slowly over time
    • Changes must be iterative while working toward long-term goals
  • There is no single recipe that works for all organizations
    • A solution must enable risk-based choices tailored to the organization
  • Guidance related to security activities must be prescriptive
    • A solution must provide enough details for non-security-people
  • Overall, must be simple, well-defined, and measurable

Therefore, a viable model must...

  • Define building blocks for an assurance program
    • Delineate all functions within an organization that could be improved over time
  • Define how building blocks should be combined
    • Make creating change in iterations a no-brainer

SAMM Business Functions (4 in total)

  • Start with the core activities tied to any organization performing software development
  • Named generically, but should resonate with any developer or manager
  • Governance, Construction, Verification, Deployment

SAMM Security Practices (12 in total)

  • From each of the Business Functions, 3 Security Practices are defined
  • The Security Practices cover all areas relevant to software security assurance
  • Each one is a 'silo' for improvement
  • Governance: Strategy & Metrics, Education & Guidance, Policy & Compliance
  • Construction: Threat Assessment, Security Requirements, Secure Architecture
  • Verification: Design Review, Code Review, Security Testing
  • Deployment: Vulnerability Management, Environment Hardening, Operational Enablement

What is "software"?

  • Lots of different aspects of what software is
  • Could be a tarball of source code, UML and specifications, or a server running the code

Under each Security Practice

  • Three successive Objectives under each Practice define how it can be improved over time
  • Level 1, Level 2, and Level 3
  • "Going from crawling to walking to running"
  • 72 different actives all about the size of a bread box

Per Level, SAMM defines...

  • Objectives
  • Activites
  • Results
  • Success Metrics (2-4 metrics for each objective)
  • Costs (training, content, license, or buildout)
  • Personnel (overhead on different roles because operating at this level)

Conducting Assessments

  • SAMM includes assessment worksheets for each Security Practice

Assessment Process

  • Supports both lightweight and detailed assessments
  • Organizations may fall in between levels (+)

Creating Scorecards

  • Gap Analysis
    • Capturing scores from detailed assessments versus expected performance levels
  • Demonstrating Improvement
    • Capturing scores from before and after an iteration of assurance program buld-out
  • Ongoing Measurement
    • Capturing scores over consistent tiem frames for an assurance program that is already in place

Roadmap Templates

  • To make the "building blocks" usable, SAMM defines Roadmaps templates for typical kinds of organizations
    • Independent SW Vendors
    • Online Service Providers
    • Financial Services Organizations
    • Government Organizations
  • Organization types chose because
    • They represent common use-cases
    • Each organization has variations in typical software-induced risk
    • Optimal creation of an assurance program is different for each

Expert Contributions

  • Build based on collected experiences with 100's of organizations
    • Including security experts, developers, architects, development managers, IT managers

Industry Support

  • Several case studies already
  • Several more case studies underway

The OpenSAMM Project

  • http://www.opensamm.org
  • Dedicated to defining, improving, and testing the SAMM framework
  • Always vendor-neutral, but lots of industry participation
  • Targeting new releases every ~18 months
  • Change management process

Future Plans

  • Mappings to existing standards and regulations
  • Additional roadmaps where need is identified
  • Additional case studies
12Nov/090

All About OWASP

The second presentation of the morning was various members of the OWASP board speaking about the goals of OWASP for the upcoming year.  My summary is below.

Jeff Williams

  • Cross Site Scripting is an epidemic
  • We need to view insecure software as a disgrace
  • Everything OWASP is free and void of commercialism
  • "When information comes with an agenda, people discount it"

Tom Brenan

Global Membership Committe 2010 Focus

  • Global expansion
  • 7x increase (2008)
  • Vote your board members

Global Industry Committee 2010 Focus

  • Building industry special interest groups
  • Continuing to impact regulation (NIST, government, organizations, EU)

Dave Wichers

Global Conferences Committee 2010 Focus

  • Support four global AppSec Conferences per year
  • Support OWASP regional and local events worldwide

Sebastian Deleersnyder

Global Education Committee 2010 Focus

  • Academic outreach
  • OWASP bootcamp
  • Roll out college OWASP education kits

Global Chapter Committee 2010 Focus

  • Identify and reactive inactive chapters
  • Actively support chapters with mentors and speakers
  • College OWASP education kits

Dinis Cruz

Global Projects Committee 2010 Focus

  • Apply assessment criteria version 2 to all projects
  • Unified dashboard for OWASP projects
  • Launch and manage 2010 season of code
Tagged as: , , , No Comments
31Oct/081

Using Proxies to Secure Applications and More

I've been really surprised that for as long as I've been active with OWASP, I've never seen a proxy presentation.  After all, they are hugely beneficial in doing web application penetration testing and they're really not that difficult to use.  Take TamperData for example.  It's just a firefox plugin, but it does header, cookie, get, and post manipulation just as well as WebScarab.  Or Google Ratproxy, which works in the background while you browse around QA'ing your web site and gives you a nice actionable report when you're done.  I decided it was time to educate my peers on the awesomeness of proxies.

This past Tuesday I presented to a crowd of about 35 people at the Austin OWASP Meeting.  The title of my presentation was "Using Proxies to Secure Applications and More".  Since so many people came up to me afterward telling me what a great presentation it was and how they learned something they can take back to the office, I decided (with a little insistance from Ernest) that it was worth putting up on SlideShare and posting to the Web Admin Blog.

The presentation starts off with a brief description of what a proxy is.  Then, I talked about the different types of proxies.  Then, the bulk of the presentation was just me giving examples and demonstrating the various proxies.  I included anonymizing proxies, reverse proxies, and intercepting proxies.  While my slides can't substitue for the actual demo, I did try to include in them what tool I used for the demo.  If you have any specific questions, please let me know.  All that said, here's the presentation.

25Sep/080

Cryptography for Penetration Testers – OWASP AppSec NYC 2008

This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.

The Premise

How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.

Goals

  • Learn basic techniques for identifying and analyzing cryptographic data
  • Learn black-box heauristics for recorgnizing weak crypto implementation
  • Apply techniques

The Crypto that Matters in 6 Short Slides

Types of Ciphers

  • Block Ciphers: Operates on fixed-length groups of bits, called blocks.  Block sizes vary depending on the algorithm.  Several different modes of operation for encrypting messages longer than the basic block size.  Example ciphers include DES, 3DES, Blowfish, AES
  • Stream Ciphers: Operates on plaintext one bit at a time

Block Ciphers: Electronic Code Book (ECB) Mode

  • Fixed-size blocks of plaintext are encrypted independently
  • Each plaintext block is substituted with ciphertext block, like a codebook
  • Weaknesses: Structure in plaintext is reflected in ciphertext.  Ciphertext blocks can be modified without detection.

Bliock Ciphers: Cipher Block Chaining (CBC) Mode

  • Each block of plaintext is XORed with the previous ciphertext block before being encrypted
  • Change of message affects all following ciphertext blocks
  • Initialization Vector (IV) is used to encrypt first block

Stream Ciphers

  • Plaintext message is processed byte by byte (as a stream)
  • Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
  • Encrypt by XORing plaintext with the generated keystream

Common Crypto Mistakes

  • Insecure cipher mode (usually ECB)
  • Inappropriate key reuse
  • Poor key selection
  • Insufficient key length
  • Insecure random number generation
  • Proprietary or home-grown encryption algorithms (Don't do this ever!)

Analysis Techniques

Dealing with Gibberish Data

What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?

  • Cookies
  • Hidden fields
  • Query string parameters
  • POST parameters

How random is it?

  • Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
  • Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc

Observe Characteristics

Is the length a multiple of a common block size?

  • Indicates that the application may be using a block cipher

Is the length the same as a known hash algorithm?

  • For example, MD5 is usually represented as 32 hex characters
  • May also indicate the presence of an HMAC
  • Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used

Stimulus, Response

Does the length of the token change based on the length of some value that you can supply?

For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)

How does the token change in response to user-supplied data?

  • Figure out how changing different parts of the input affects the output
  • Is more than one block affected by a single character change in the input?

Deeper Block Cipher Inspection

Are there any blocks of data that seem to repeat in the same token or over multiple tokens?

  • Possibly ECB mode, this doesn't just happen by coincidence

EXAMPLE

Context:  A public-facing web portal for a large ISP.  Used an encrypted cookie to authenticate identity.  A new cookie is issued on each request.  Base64 decoded EE cookies.  Divided by 8 and found 8 byte blocks.  Noticed some repetition in the same position.  The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism).  Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.

'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"

The token is longer, meaning the username is probably stored in the cookie.  Still noticed repition in same position.  Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step.  Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32.  Reason is padding.  The username doesn't align perfectly with the block offset.  Want to figure out what position in the cookie the usernaem is located.  Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block.  Now you know where the username is in the ciphertext.

Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext.  The root cause was the insecure cipher mode and the lack of a verification mechanism.  ECB mode shoul dnot be used (use CBC instead).

EXAMPLE

Token values observed in URLs.  Changed every time we logged on to the application.  Never the same for any two sessions or any two users.  Base64 decoded values for several different "stmt" tokens.  Statement numbers were displayed in the browser.  Looked for correlations between statement number and cipher-text.  Conclusion: It looks like a stream cipher.  Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number).  Now try the same things against one of the other collected tokens, such as the one called "Ctxt".  Get ASCII text that allows you to infer what it would say.  Expand it out more and more to get the keystream.  Repeat over and over until you have enough of the key to figure out anything in the application.

Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter).  Can replace the statement number with another valid statement number and view the contents.

Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext.  They were using RC4 with a unique key generated for each user session.  Root cause of the vulnerability is the re-use of the keystream.