Step 1: Exploit Overachievers

• Maximize value by using free tools
• OWASP (Open Web Application Security Project)
• WASC (Web Application Security Consortium)

Step 2: Learn

• Security is not an arcane art reserved for people with a special gift.  It’s campfire knowledge.
  • Assess your security posture regularly
  • Do not neglect any aspect of your security; bad guys don’t (Social Engineering, Internal Network, Firewall, Web Apps, etc)

Step 3: Chase Your Tail

• Remember where you started
  • Free tools can provide extreme amounts of value
    • OWASP (Eg: OWASP Testing Guide)
    • WASC
  • There is no magic to security

Tools Needed

• Web Developer Toolbar
  • POST to GET
  • Response headers
• NoScript or QuickJava

Estimating Vulnerabilities

• Site Age – Care & Feeding
  • “Copyright 2003”
  • Alexa
  • Archive.org
  • Whois
  • Last modified date
  • Old server + modules version #’s
• 2-3 years (2), 3-5 years (3), 5-10 years (4), 10+ (5)
• Programming Language
  • .cfm (1)
  • AJAX (1)
  • .do/.jsp (1)
  • .cgi/.pl/.shtml (2)
  • .asp (2)
  • .php (2)
  • .aspx/.jspx/.html (0)
  • Languages + Demographics theory
• Size of the Site Logic Complexity
  • Surf around manually
    • Sitemap
  • Google inurl: search
  • Spider (added download + added time)
  • Small (0), Medium – typical retailer (1), Large – Yahoo (3)
• Search
  • XSS tests (1)
    • “Company”
    • I <3 U
  • SQL injection (1)
    • O’Malley
  • DoS (.5)
    • a AND b AND c …
• Registration
  • Does it exist?  Yes (1)
  • Email validation and/or CAPTCHA (1-2)
  • Password complexity? (1)
  • Can you choose “admin” as a username? (1)
• Security Functions
  • Does change password enforce password complexity rules
  • Does change password require the existing password
  • Can you change email address without a password
  • Can emails be changed without validating them
  • Are secret questions “strong”
• Contact forms
  • Do they have an email address in a hidden field (1)
  • Submit a blank contact
    • Does it work without an error (1)
  • With and without JavaScript
    • Does it say “Thanks” without JS but errors when JS is turned on (1)
  • Can users contact other users on the site (Eg: Private message) (2)
• Login
  • Does it use SSL (1)
  • Does it allow auto complete (1)
  • Does it stop me from being able to type failed logins (3)
    • Horizontal, Vertical, & Diagonal Brute Force attacks
  • Can you switch POST to GET (1)
    • Session fixation
    • CSRF (1 per major site function, EG: change password, change secret question, change email address, etc)
  • Does it auto-logout (1)
  • javascript:alert(document.cookie) (1)
• Forgot password flow
  • Does it send the plaintext password (1)
  • Does it send a “small” key (1) – 20 bits or less
  • Does it tell you if your username is valid or not (.5)
• File Upload
  • Does it check file extensions (.5)
  • Does it check file types (.5)
  • Does it allow re-displaying of the file (1)
• HTML/JS/CSS Comments
  • Intranet IPs/addresses (.5)
  • Passwords (1)
  • Functionality comments (.5)
• URL Structure
  • function?path=/files/file.asp (1)
  • something?id=104 (1)
  • search?q=bob&charset=UTF-8 (1)
    • alternate charset
    • header injection
  • redir?url=http://www.cnn.com/ (.5)
  • chngpasswd?usr=bob&pass=1234 (2)
  • /images/ If it shows a directory (1)
• Obvious admin interfaces (2)
  • /admin/
  • /blog/wp-admin/
  • /administrator/
  • /adm/
  • admin.url.com
• Outdated Open Source or Commercial Programs
  • PHP nuke
  • WordPress
  • Drupal
  • 3/instance
  • +1 for every major revision out of date
• Other questions
  • Does it allow rich HTML user comments (1)
  • Does it have a send-to-friend function (1)
  • Virtual host? (MSN IP search) (1)

Things this doesn’t cover

• Timing attacks, buffer overflows, etc
• Network infrastructure flaws (including DNS)
• Predictable file locations (VCS trees, etc)
• Logic flaws
• Backup files/folders/CVS trees, etc
• Alternate paths of exploitation (email, FTP, APIs, etc)

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.

56% of organizations fail PCI section 6.  Poorly coded web applications leading to SQL injection vulnerabilities is one of hte top five reasons for a PCI audit failure.  Section 6 is becoming a bigger problem: #9 in 2006 reason for failure, #2 in 2007.

PCI Section 6 has to do with guidelines to "Develop and maintain secure systems and applications".  Section 6.6 reads "Ensure that all web-facing applications are protected against known attacks by either of the following methods: Having all custom application code reviwed for common vulnerabilities by an organization that specializes in web application secure" or by using a web application firewall.  Further clarifications say that automated tools are acceptable, web application penetration testing is allowed, and vulnerability assessments can be performed by an internal team.

Comparing Apples, Oranges, and Watermelons

• Setup: Source code analysis (+2) is good because it works on existing hardware, but must live where your source code lives.  Penetration testing (+3) is good because you only need one to assess everything and works on existing hardware, but needs to talk to a running program.  Application firewall (+1)is good because it lives on the network, but you must model program behavior.
• Optimization: Source code analysis (+2) is good because you can specify generic antipatterns in code, but you must understand vulnerability in detail.  Penetration testing (+2) is good because tests are attacks, but you must successfully attack your application.  Application firewalls (+1) are good because they share configuration across programs, but must differentiate good from bad.
• Performance: Source code analysis (+3) is good because it simulates all application states and is non-production, but scales with build time and not the number of tests.  Penetration testing (+2) is good because you get incremental results and is non-production, but you must exercise each application state.  Application firewall (+1) is good because it's a stand-alone device and scales with $$$, but impacts production performance and scales with $$$.
• Human resources: Source code analysis (+1) is good because it enables security in development and reports a root cause, but makes auditors better and does not replace them.  Penetration testing (+2) is good because it is highly automatable, but reports symptoms and not the root cause.  Application firewall (+2) is good because once it's configured it functions largely unattended, but requires extensive and ongoing configuration.
• Security know-how: Source code analysis (+3) is good because it gives code-level details to an auditor, but you must understand security-relevant behavior of APIs.  Penetration testing (+1) is good because it automates hacks, but a hacker is required to measure success and optimize.  Application firewall (+2) is good because it identifies common attacks out of the box and is a community effort, but a hacker is required to measure success and customize.
• Development expertise: Source code analysis (+1) is good because it focuses attention on relevant code, but you must understand code-level program behavior.  Penetration testing (+2) is good because basic attacks ignore internals, but advanced attacks require internal knowledge.  Application firewalls (+2) are good because they live on the network, but you must understand the program to tell good from bad.
• False positives: Source code analysis (+1) is good because it gives auditors details to verify issues, but reports impossible application states.  Penetration testing (+2) is good because results come with reproduction steps, but it is difficult to oracle some bugs.  Application firewalls (+1) are good because it is attacks instead of vulnerabilities, but there is an evolving definition of valid behavior.
• False negatives: Source code analysis (+3) is good because it simulates all program states and models the full program, but it must be told what to look for.  Penetration testing (+1) is good because it is good at finding what hackers find, but is difficult to oracle some bugs and has missed coverage.  Application firewalls (+1) are good because it uses attacks instead of vulnerabilities, but there is an evolving attack landscape.
• Technology support: Source code analysis (+2) is good because parsing is separable from the analysis and is interface-neutral, but it must adapt to new program paradigms.  Penetration testing (+2) is good because it is independent from program paradigms, but is tied to protocols and is limited to network interfaces.  Application firewalls (+2) are good because they are independent from program paradigms, but are tied to protocols and are limited to network interfaces.

Working Towards a Solution

• Assessment: Proving the problem or meeting the regulatory requirement.  Recurring cost that does not "fix" anything
• Remediation: Fixing security issues found during assessments.  Lowering business risk at a single point in time.
• Prevention: Get security right hte first time.  Minimizing business risk systematically.

Do your own comparison and fill out the scorecard yourself (presenters ratings are noted in parentheses above).

Taylor did interviews with three companies to get their experiences deploying each (source code analysis, penetration testing, and application firewall) and had them evaluate based on the nine criteria both before and after buying.  Not going to list each company's results in the blog, but it was just a basic table with each criteria and a number rating for both before purchase and after deployment.  To sum it up, Source Code Analysis was a 14 rating before purchase and a 17 rating after deployment.  Penetration testing was a 21 rating before purchase and a 21 rating after deployment.  Application firewalls were a 21 rating before purchase and a 16 rating after deployment.  It seems like the first organization had a large amount of developers and that factored into their decision to purchase a source code analysis tool.  The second organization had a far fewer number of developers and was more of an IT shop and chose the penetration testing tool.  The last organization was a smaller shop in general (still fairly large) and went with the WAF because they wanted something they could just put in place and manage.

Analysis: All three solutions required more effort than expected.  All three solutions produce reasonably accurate results.  Varying levels of expertise needed.

How do you demonstrate that your application is protected against known attacks?

• Verification that the application was analyzed

• A report showing no critical security issues identified

• Document showing how the tool fits into your architecture

How do you show that the user is appropriately trained?

• Document explaining prior experience or an informal interview

How do you show that you have configured the tool appropriately?

• Document explaining how the tool was configured and what new rules had to be added.

Summary: PCI section 6 is evolving to become increasingly precise.  Compare technologies in your environment along nine criteria.  Demonstrating compliance is an art, not a science.