Contraced Services Considerations

• Some Advantages:
  • Highly skilled
  • Established tools, processes, and standards
  • Unbiased
  • Available as needed
• Some Disadvantages:
  • Expensive, especially for an extended engagement
  • Less control and flexibility
  • Not familiar with company processes and culture
  • Rotating staff

Planning

• Considerations for establishing an internal team:
  • Time to staff and train the team
  • Overlap of external and internal teams
  • Development of processes and standards
  • Acquiring necessary tools

Service Model

• Define the services your team will provide.  This will be greatly influenced by:
  • The team's size and skills
  • The number of applications you have to support
  • The tools available
  • The level of executive support
  • The funding model
    • Who pays for your services
  • The team's role
    • Development support, pre-deployment testing or post deployment auditing and pen testing

Staffing the Team

• Decide how to staff your team and what skills you need.  Possible candidates include:
  • Experienced Application Testers
    • This is ideal from a skills standpoint, but people in this category may be harder to find, cost more, may not be familiar with your company and or fit its culture.
  • Experienced Developers
    • Developers will have a good understanding of the technologies, but may not understand security principles.  Their focus is on what an application is intended to do, not what it can be made to do.
  • Other IT Security Professionals
    • They have a good understanding of security principles, but may lack specific technical skills.  However, some skills may provide a useful overlap, like experienced OS or network testers.
  • Service and Project Managers
    • Building a new team, defining processes and standards, managing work flow and handling customer relations requires a set of skills as important, but distinct, from technical testing skills.

Selecting Tools

• There are a lot of options when it comes to tools.  What you choose depends on the services you want to provide, your team's skills and your budget.
  • Commercial vs. Free or Low Cost Tools
    • Commercial tools scale to support enterprise use, utilize a higher degree of automation and come with product support.  They also come with a big price tag.
    • Open source and low cost tools allow for more customization, and are free or inexpensive, usually have a supportive user community, but often require a higher degree of user knowledge and skill.
  • Types of Tools
    • Vulnerability Scanners
      • Commercial examples include IBM AppScan, HP WebInspect and Cenzic Hailstorm
    • Source Code Analysis
      • There are commercial options like Fortify or open source tools like the OWASP Yasca Project
    • Client Side Web Proxies
      • Options include WebScarab, Burp Suite and Charles Proxy
    • Other Tools
      • These include password crackers, hex editors, text extractors, browser plug-ins, integrated development environments, network mapping, network traffic analysis, and exploitation tools

What to Assess

• Measuring an application's risk:
  • The Types of Users
    • Privileged Users, employees, suppliers, customers or the general public
  • The Sensitivity of the Data
    • Intellectual Property, PII or other regulatory requirements
  • Availability and Integrity Requirements
    • The impact to the business if compromised
  • Technology and Environmental Consideration
    • What technologies are used, where is it deployed,...

Gather Necessary Information

• Before starting an assessment you will need to gather important information:
  • Application contacts
  • Server contacts
  • The process for getting accounts
  • A description of what the application does
  • The description or diagram of the system architecture

Assessment Planning Meeting

• Meet with the application development and support teams:
  • Get a demonstration of the application
  • Review the information gathered to support the assessment
  • Discuss the testing process and ground rules
    • No changes to the code during testing
    • Backups of the application servers and databases
    • How to address system crashes during testing
    • Database corruption issues
    • Emails generated by the application

Testing Notifications

• You should have a process to notify affected parties before the actual testing begins.
  • Key system contacts
  • Intrusion detection teams
  • Other assessors
• Information to include in the notification:
  • Source IP addresses
  • Target IP addresses, URL, system name
  • Testing schedule
  • Assessment team contacts

Conducting the Assessment

• If you are using automated scanning tools, beware of false positives and negatives
  • Pattern recognition has limitations
  • Combine various testing methods
    • Automated scanning
    • Code review
    • Manual testing
  • Learn what your tools do and do not do well
  • Validate every finding
  • Keep detailed notes

Establish Standards

• Assessments performed by two different people or the same person over time, may result in the same finding being presented very differently
  • This may result in inconsistent descriptions of the vulnerability or different recommendations for remediation
  • Without standard findings you may also find it difficult to produce meaningful metrics about discovered vulnerabilities

Standard Findings

• Opinions about how to standardize software vulnerabilities are like noses, everyone has one.
• At Boeing we have categorized vulnerabilities into approximately 70 standard findings like:
  • SQL Injection
  • Path Traversal
  • Session Fixation
  • Excessive Authentication Attempts
  • Forced Browsing
  • System information Leakage

Data Elements for Standard Findings

• Each finding is made up of the following data elements:
  • Name
  • Control Classification
  • Severity (Likelihood + Impact)
  • Company Policy References
  • Industry References
  • Summary Description (one sentence)
  • Impact Statement (one sentence)
  • Detailed Description (basic introduction to vulnerability + detailed description of how it manifests within their application)
  • Recommendation (standard remediation recommendations tied into SDLC practices)

Control Classifications

• We group individual vulnerabilities into control classifications.  This helps us determine how effective we are at implementing control types.
• Our classifications:
  • Input and output controls
  • Authentication and password management
  • Authorization and access management
  • Sensitive information storage or transmission
  • System configuration and management
  • General coding errors

Reporting Findings

• Developing a standardized reporting template will allow you to deliver a consistent, branded message
  • Cover Page
    • Provides information necessary to identify the assessment, what was assessed and who the key people were
  • Executive Summary
  • Findings Summary
  • Detailed Findings
  • Conclusion
    • Summary of assessment results, discussion of next steps and links to additional resources
  • Appendixes
    • Information on how severity ratings are determined, description of control classifications
  • Attachments
    • Typically raw scan files

Managing Corrective Actions

• Once a report is issued you need a closed loop process to ensure serious issues are addressed.  Considerations include:
  • Tracking Findings:
    • Critical and high findings should be tracked to resolution
    • Medium findings are less straight forward
    • Low or informational findings may not be value added
  • Customer Responses to Findings:
    • Implement a technical fix to address the finding
    • Implement a process fix to address the finding
    • The business formally accepts the risk of not remediating

When to Re-Evaluate an Application

• Depending on the number of applications you support and the frequency with which they change you may need to establish re-evaluation guidelines.  Soem criteria to consider include:
  • Fixes to previously accepted risk
  • User population changes
  • Data sensitivity changes
  • Business's dependency on the application has increased
  • Authentication mechanism has changed
  • Authorization mechanism has changed

Application Assessment Process Flow Version

• Create a document that shows the process flow for both requested and targeted assessment (ask for document from presenter?)
• Formal closure process

Conclusion

• Building an assessment team from the ground up takes:
  • Executive Support
  • A lot of planning
  • Staffing
  • The right tools
  • Training
  • Standards
  • Supporting Processes

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.

"To measure is to know." - James Clerk Maxwell

"Measurement motivates." - John Kenneth Galbraith

Metrics do Matter

1. Metrics quantify the otherwise unquantifiable
2. Metrics can show trends and trends matter more than measurements do
3. Metrics can show if we are doing a good job or bad job
4. Metrics can show if you have no idea where you are
5. Metrics establish where "You are here" really is
6. Metrics build bridges to managers
7. Metrics allow cross sectional comparisons
8. Metrics set targets
9. Metrics benchmark yourself against the opposition
10. Metrics create curiosity

Metrics Don't Matter (Mike Rothman)

• It is too easy to count things for no purpose other than to count them
• You cannot measure security so stop
• This following is all that matters and you can't map security metrics to them:
  • Maintenance of availability
  • Preservation of wealth
  • Limitation on corporate liability
  • Compliance
  • Shepherding the corporate brand
• Cost of measurement not worth the benefit

Bad metrics are worse than no metrics

Security Metrics Can Drive Executive Decision Making

• How secure am I?
• Am I better off than this time last year?
• Am I spending the right about of money?
• How do I compare to my peers?
• What risk transfer options to I have?

Goals of Application Security Metrics

• Provide quantifiable information to support enterprise risk management and risk-based decision making
• Articulate progress towards goals and objectives
• Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
• Focus activities on risk mitigation in order of priority and exploitability
• Facilitate adoption and improvement of secure software design and development processes
• Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products

Use Enumerations

• Enumerations help identify specific software-related items that can be counted, aggregated, evaluated over time
• CVE - Common Vulnerabilities and Exposures
• CWE - Common Weakness Enumeration
• CAPEC - Common Attack Pattern Enumeration and Classification

Organizational Metrics

• Percentage of application inventory developed with SDLC (which version of SDLC?)
• Business criticality of each application in inventory
• Percentage of application inventory tested for security (what level of testing?)
• Percentage of application inventory remediated and meeting assurance requirements
• Roll up of testing results

Organizational Metrics

• Cost to fix defects at different points in the software lifecycle
• Cost of data breaches related to software vulnerabilities

Testing Metrics

• Number of threats identified in threat model
• Size of attack surface identified
• Percentage code coverage (static and dynamic)
• Coverage of defect categories (CWE)
• Coverage of attack pattern categories (CAPEC)

SANS Top 25 Mapped to Application Security Methods (CWE, Title, Education?, Manual Process?, Tools?, Threat Model?)

Weakness Class Prevalence based on 2008 CVE data (Mitre?)

Basic Metrics: Defect Counts

• Design and implementation defects
  • CWE identifier
  • CVSS score
  • Severity
  • Likelihood of exploit

Automated Code Analysis Techniques

• Static Analysis (White Box Testing)
• Dynamic Analysis (Black Box Testing)

Manual Analysis

• Manual Penetration Testing
• Manual Code Review
• Manual Design Review
• Threat Modeling

WASC Web Application Security Statistics Project 2008

• Goals
  • Identify the prevalence and probability of different vulnerability classes
  • Compare testing methodologies against what types of vulnerabilities they are likely to identify
• Summary
  • 12186 web applications with 97554 detected vulnerabilities
  • More than 13% of all reviewed sites can be compromised completely automatically
  • About 49% of web applications contain vulnerabilities of high risk level detected by scanning
  • Manual and automated assessment by white box method allows to detect these high risk level vulnerabilities with the probability up to 80-96%
  • 99% of web applications are not compliant with PCI DSS standard
• Compare to 2007 WASC Project
  • Number of sites with SQL Injection fell by 13%
  • Number of sites with Cross-site Scripting fell 20%
  • Number of sites with different types of Information Leakage rose by 24%
  • Probability to compromise a host automatically rose from 7 to 13%

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.

Why is AppSec so hard?

• AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
• Changing landscape
  • Increase skill and talen t pool of technically proficient individuals willing to break the law
  • Growing volume of financially valuable data online
  • Development of criminal markets (black markets) to facilitate conversion to money
• "Attackers now have effective skills, something to steal, and a place to sell it"

• Application Security is a complete one-sided game
• Need to become an enabler (not a barrier)
• Must inject application security earlier through Guidance, Education, and Tools
• Must understand the development and deployment process and integrate rather than mandate
• NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
• Solving the problem of the enterprise (Culture Change)
• Success factors
• Form a mission and strategy
• Develop policy (but not corporate "mandate")
• Gain executive buy-in (cost / benefit / risk)
• Understand the magnitude of problem (metrics)
• Asset inventory and vulnerability management
• Develop standards (what should I do and when?)
• Establish a formal program (strong leadership)
• Focus on education and training materials
• Develop in-house expertise, services and "COE"
• Continuous improvement, measurement, KPI
• Communicate!
• Drive a culture change (shared need, WIIFM)
• Communicate expectations with vendors
• Implement incentives (and penalties)
• Digitize after the process is solid (tools)
• AppSec program mission & structure
• AppSec program strategy
• Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve

Guidance

• "GE Application Security Working Group" (Talking to the businesses is critical!  Meet every 2 weeks.)
• Secure Coding Guidelines
• Vulnerability Remediation Guide
• Secure Deployment
• Quick Reference Card
• Contractual Language
• Desk Calendars
• Metrics: AppSec calendars helped increase visitors to key Guidance materials  (track hits to website docs when certain activities take place)

Education

• CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
• CBT2: GE Best Practices for Secure Coding (90 min)
• CBT3: Attack Profiles & Countermeasures (120 min for security people)
• Developer Awareness Assessment:
  • 100's of internally-developed questions
  • Randomized questions, timed completion
  • Vendors track their own resutls
  • Allows tailoring of training/awareness programs

Tools

• - COE AppSec assessment services
• Vendor framework & Metrics
• Compliance handbook
• Common objects repository
• GE Enterprise Application Security
• Scanning and Monitoring tools
• Automation is the way to go (but the tools are not quite there yet)

Metrics

• Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
• Is it making a difference (map avg of critical/high vulnerabilities per assessment)

Forming a Center of Excellence

• Combines the best available people, processes and tools
• Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
• COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
• Application Assessment Types (black/grey box vs white box)
• Application assessment process (map of the workflow with "swim lanes" of who does each step)
• Measure number of vulnerabilities and severities
• Measure customer satisfaction (overall, ease of engagement, responsiveness)

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.

What is a threat?

• An agent who attacks you?
• An attack?
• An attack's consequence?
• A risk?

What is a threat model?

• Depiction of the system's attack surface, threats who can attack the system, and assets threats may compromise.
• Some leverage risk management practices.  Estimate probability of attack.  Weigh impact of successful attack.

Elements of a threat model

• Structural view
• Threat actors
• Assets
• Attack vectors
• Privilege/"trust"

Threat

• Capability: Access to the system, able to reverse engineer binaries, able to sniff the network
• Skill Level: Experienced hacker, script kiddie, insiders
• Resources and Tools: Simple manual execution, distributed bot army, well-funded organization, access to private information
• Threats help encourage thorough throught about how intentions for misuse and determine "out of bounds" scenarios.

A Few Words on STRIDE

• A conceptual checklist backed by data flow diagrams

Attack Trees

• Aggregate attack possibilites
• Use OR, AND
• Allow for decoration (probability, cost, skills required, etc)

Threat Modeling as a Process

• Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.

Leading Up to Threat Modeling

• Identify threats
• Enumerate doomsday scenarios
• Document misuse/abuse
• Diagram structure, assets
• Annotate diagram with threats
• Enumerate attack vectors
• Iterate

Input: Goals, Doomsday Scenarios

Misuse/Abuse Cases (use case view and component view)

Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")

Anchor in Software Architecture

Consider where attacks occur:

• Top-down: enumerate business objects (sensitive data, privileged functionality)
• Bottom-Up: enumerate application

Output: Security Assessment & Test Design.  Threat models drive assessments, Test design.  Establish rules of engagement.  Prioritize areas of interest.  Manage a team in risk-based fashion.  Establish a single tie between vulnerability and control.

Application Structure: No "One Size Fits All"

Application Structure: Topology - Coloration shows authorization by role.  Arrows indicate resolution of principal/assertion propagation.  Use structure to separate privilege.

Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).

Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".

Assets: Flow - Assets exist not only in rest, but also flow through the system.  Use different types of flags to represent data flow of assets.

Use different colored arrows to represent each different attack vector.

Target Using Layered Attacks: Bootstrap later attacks with those that "deliver".  Use one layer to exploit another (net, app).  Combine attacks to reach desired target.

Take Homes

• Base threat model in software architecture
• When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
• Enumerate initial attack vectors.  Use common low hanging fruit.
• Elaborate more attacks.  Find opportunities for privilege escalation.  Layer attacks to target or "hop" to assets.  Fill in gaps by "inventing" attacks.
• Use threat modeling to drive security testing

Lotus Notes/Domino History

Lotus Notes is client and Domino is the server.  Supports multiple protocols with one interface (HTTP, LDAP, SMTP/POP/IMAP, file sharing).  Strong on workflow application and collaborative application.  Used by .gov, .edu, .com.  Google search shows 66 million notes databases facing the internet.  People use it because it's easy to develop and deploy a simple application, granular access control, good logging method, and it integrates well with e-mails.

Notes Databases

Notes databse is building block of Domino application (.nsf or .ntf).  Notes Database is a container for data (document, message, web page), design elements (form, page, view, folder, navigator, agent, frameset, outline).

Two components in Domino server architecture.  There is an HTTP Server and a Domino Engine (URL Parser, Command Handler, and Database).

Web Access Syntax

• http://host/data/base/NotesObject?Action&Arguments
• Database = Notes Database
• NotesObject  = the web accessible design element
• Action = the action on NotesObject
• Arguments = the qualifiers for the action (optional)

Notes Database Access Control List (ACL)

• Define users and groups access privileges on the database
• Seven access levels (manager, designer, editor, author, reader, depositor, and no access)
• Eight access options for each level (create/delete documents, create/delete folders/views, create/delete agents, create/delete public documents)
• Anonymous and -Default-
• Maximum internet and password access: only works for name-password authentication but not for certificate authentication.  A web user cannot get the access greater than the "Maximum" access even if the access explicitly given is higher
• Further restriction can be done by conjunction with reader field, author field, and access list of documents for granular read and write access control

Notes Web Authentication

• Anonymous user - who does not have Person documents in DOmino Directory (names.nsf)
• Authentication occurs if anonymous access is disabled on server configuration document and Notes objects
• Name-password authentication: user/pass are authenticated to Person document and internet password in Domino directory (names.nsf).  Basic authentication and session-based authentication.  Internet password lockout function (Notes 8 only)
• SSL client certificate authentication

Common Security Mistakes in Development

1. Unauthorized Access: Anonymous access.  Anonymous privilege is assigned to Default access level if there is no anonymous group explicitly set.  Default access level is Designer and Maximum Internet and Password Access is Editor of most built-in templates.  Forceful browsing.  Solutions are to setup anonymous group and assign it "no access".  Review the ACLs of all databases and confidential documents.
2. Using Default Objects (Databases):  Default databases are statrep.nsf, schema.nsf, reports.nsf, names.nsf, log.nsf, events.nsf, doladmin.nsf, dbdirman.nsf certsrv.nsf, certlog.nsf, admin4.nsf, ...  Anonymous users should not be allowed to access these databases.
3. Default Objects (view): $DefautlView?OpenView, $DefaultNav?OpenNav, $DefaultForm?OpenForm, help?OpenHelp, $about?OpenAbout, $searchform?searchdomain, $searchform?searchsite, $searchform?searchview, $Icon?OpenIcon, $first, $file.  Solutions are to use the URL redirection and mapping on server document, customize the default pages, and apply the appropriate access control.
4. SQL Injection: Places to process User Input (@Commands, WebQueryOpen, WebQuerySave, WebQueryClose, @URLQueryString, OpenAgent, RunAgent).  Solutions is input validation in fields by formula or lotus scripts
5. Cross Site Scripting: Most cross site scripting vulnerabilities are persistent.  Solutions are to use input validaton or to HTMLencode.
6. Session Management: By default uses basic authentication.  Username and password are sent in clear-text in teh packet of every request.  Solution is to configure the server document to use session-based authentication.  Do not append sensitive data to Querystring.
7. Information Leakage: Hard coding username and password.  Solutions are to remove the sensitive information from the source code and log and customize the error message.
8. Operating System Interaction: LotusScript has system commands such as Shell, OSLoadProgram, OSLoadLibrary, FileCopy, Open, Kill, Get, Input, Close.  Solution is to hardcode the path and validate the filename input.

Testing security is challenging but it can be done:

• Lotus Notes Designer (Design Synopsis)
• Grep
• A good text editor
• Paros

References

• Secure Domino Application
• Lotus Security Handbook

Is an XSS worm really a worm?

5 components of a worm:

• Reconnaissance - "[the worm] has to hunt out other network nodes to infect"
• Attack - "[components] used to launch an attack against an identified target system"
• Communication - "nodes in the network can talk to each other"
• Command - "nodes in the worm network can be issued operation commands"
• Intelligence - "the worm network needs to know the location of the nodes as well as characteristics about them"

Short answer: 3/5 - probably

How are XSS worms different from traditional?

1. Infection model - Current model requires user interaction, worm strictly contained within web application, passive and localized, no Warhol worms (15 mins of fame).
2. Payload capability - Perform any application function (money transfer, close account).  XSSProxy/Attack API.  Malware (yikes)
3. Target shift - Internet worms can own everything both in front of and behind a firewall (island hopping).
4. Penetration - Need to trick the user into spreading between sites using a 3rd party proxy.

Traits of Current XSS Worms

• Static payloads
• Passive infection strategy
• Staty on the same domain (don't say nduja)
• Uncontrolled growth
• No command and control

Current Incident Response Options

• Fix the vulnerability
• Manual purging - can only be done by experts and doesn't scale
• Database snapshot restore - effectively removes all worm data from tained columns, but forces loss of other application data
• Search & Destory - works now.  Tricky in the future, but possible.

Next Gen XSS Worm Reconnaissance: A reconnaissance component will be added to the client side to find more web applications to infect.  Nodes can use HTML5 Workers/Google Gears WorkerPool/<insert tomorrow's new RIA technology>.  What about SOP?  Old and busted: utilize 3rd party proxy (a la jikto ~2007).  What attackers should be doing now: malware - no SOP!  Next gen hotness: cross-site XHR, XDR, postMessage.  Allows cross-site bidirectional communication.  Servers must opt in, like Flash, so absolutely no security issues there (kidding)

Cross-site communication in HTML5

• postMessage(): Cross-domain communication based on strings.  What do developers do with strings?    JSON/eval()  SiteA + JSON + SiteB = Shared Security

Staniford, Paxson & Weaver's Reconnaisance Techniques

• "hit list scanning"
• Permutation Scanning
• Topological Scanning (not without malware, cross-site XHR)

Next Gen XSS Worm Attack: An attack component will be added to the client side.  New client side piece delivered with reconnaissance piece to attack other off-domain web apps.  85% of websites have XSS (how much is reflected vs stored?)  How likely is it to fnd a stored XSS in another web app

Polymorphic Javascript: javascript can be highly mutated

Next Gen XSS Worm Communication: A communication component will never occur in a XSS worm.  Can't communicate directly from victim browser to another victim browser.  "centralization" in worms is just another word for weakness.

Next Gen XSS Worm Command: A command component will be added to the worm payload.  Communicationw ith operator necessary for command-and-control structure, data delivery (new target info, soruce updates, etc)

1. Attacker quietly posts signed payloads
2. Victim creates token
3. Victim queries Google form token using JSON
4. Victim finds a signed result
5. Executes the signed payload

Next Gen XSS Worm Intelligence: An intelligence component will be used after initial worm stages, it can't be trusted (adversaries can poison).  XSS worms probably don't need this, they typically follow a pattern where the first 24 hours it reaches massive infections through epic growth rate.  After that, gone and never seen again.

Ways to Prevent Next Gen XSS Worms

• search+destroying polymorphed javascript
• on demand exploit egress filters: popular sites need agile response techniques
• OWASP AntiSamy - safe rich input validation.  Uses a positive security model for rich input validation.  High assurance mechanism for stopping XSS (and phishing) attacks
• utilizing cross-domain workflows: letting the browser SOP protection prevent cookie disclosure + sensitive application information
• browser content restrictions: Doesn't make sense in a DOM.  Requires parsers to honor end tag attributes.