Agenda

1. Introduction to XML/Web Services Threats
2. Techniques for Defending XML Threats
3. XML Attack Examples and Classification
4. Review sample attacks

Introduction to XML Threats

• Explicit Attacks
  • Forced Disruption
  • Information Theft
  • Vendor Discovery
• Implicit Vulnerability
  • Perimeter Breach (embeeded virus, malware)
  • Infrastructure Malfunction (parser and data processing failures)

New Attack Vectors

• Protocol Firewalls are blind to XML
• Malware and virus delivered via SOAP attachments
• WSDL exposes schema and message structure
• Injection attacks exposed via XML parameters
• Data replay attacks

Security Testing - Base Requirements

• Security Framework
  • Sign, ENcrypt, Decrypt, SSL
• Identity Framework
  • Basic auth, SSL auth, WS-Security token auth
• Parameter Injection
  • Database or file driven
  • Permutations for security, identity, and SOAP/XML
• Concurrent Client Simultaneous Loading
  • Denial of Service Testing
• SOAP with Attachments
  • Malware and Virus testing
• Dynamic XSD Mutation
  • Derive SOAP vulnerability profile from WSDL schema

XML Security Gateway - Base Requirements

• Certified PKI Infrastructure (DOD PKI)
  • X509 Path validation
  • Sign/verify, SSL initiation, SSL termination
• Certified Security Architecture (FIPS)
  • Key management and storage
  • Physical security device
• Transaction Privacy
  • Encryption, decryption, SSL
• Transaction Integrity
  • Digital signature, signature verification, schema validation
• Transaction Accountability
  • Archiving, logging, reporting, and monitoring
• Transaction Threat Mitigation
  • Intrusion detection and prevention
  • Rate-based rules, size-based rules, anti-virus detection, pattern recognition
  • Structural integrity, protocol adherence, athorization attempts

XML Attack Examples and Classification

1. SQL Injection Attack
2. Denial of Service Attack
3. XSD Mutation Attack

XML Web Services SQL Injection Attack Example

• How to Attack
  • Construct SQL escape sequences
  • Construct SQL 1=1 query
  • Inject into XML node values
• Discovered Exposure
  • Sensitive data loss
  • Database corruption
• Used "SOAPSonar" tool to load WSDL and send responses

SQL Injection - XML Gateway Secured

• How to Defend
  • Deploy XML Gateway
  • Enable pattern scanning IDP rules
  • Configure response message size and complexity limits
• Advantages
  • Prevent Data Loss
  • Alert and Quarantine Attempted Breaches

XML Web Services based Denial of Service Attack

• How to Attack
  • Loading client with concurrent simultaneous threads
  • Coercive parsing attack
• Discovered Exposure
  • Unlimited message flow
  • Unfair service SLA distribution
  • Back-end CPU and I/O Saturation

Denial of Service - XML Gateway Secured

• How to Defend
  • Deploy XML gateway
  • Set allowed transaction rates (Group, user, or IP)
• Advantages
  • Message flow limited to specified rate

Another Example: Denial of Service through Coercive Parsing

• Sending malformed XML data (removing the ">" end tag) creates increased time to parse a request

XML Web Services Based XSD Mutation Attack

• How to Attack
  • Obtain WSDL
  • Derive message structure and types from WSDL schema
  • Send SOAP message mutations based on schema
• Discovered Exposure
  • Code paths not handled for exceptions
  • Stack traces returned with implementation details
  • Application failure

XSD Mutation Attack - XML Gateway Secured

• How to Defend
  • Deploy XML Gateway
  • Enforce inbound message structure and type validation
  • Cleanse outbound data (stack traces, sensitive data)
• Advantages
  • Reduce parser impact on web service
  • Remove vendor and implementation details in response
  • Protect application layer code paths on web service

XSD Mutation - Secured

1. Deploy specialized XML Gateways - Packet firewalls and HTML application firewalls are insufficient
2. Validate XML against a robust schema
3. Tighten Schema: restrict unbounded strings, etc
4. Enforce XML specific detection rules (node depth, recursive payloads)

Best Practices for Countermeasures

• Information Control - Outbound
  • Restrict SOAP Faults
  • Protect Sensitive Information
  • Audit Transaction Flows
• Information Control - Inbound
  • Tighten Payloads
  • Enforce SLA
  • Disallow SQL, virus, malicious code
• Use Web Services Penetration Testing Product
• Deploy XML web Services Gateway
• Deploy Centralized XML Security

"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%

• Barbarian Horde
  • Our castle walls must keep us safe
    • Script kiddies and DDoS

• Ninjas
  • Knowledgeable “Haxx0rs” with deliberate intent
    • Social engineering to exploits
• Vampires
  • Generally have to be “invited” in
    • Convert others to their side
    • Malware, worms, and botnets
  • Vampires are social creatures

Problems with Traditional Mechanisms

• The Barbarian Horde
  • How do we know its working?
• Ninjas
  • Ninjas are stealthy and think outside the box
  • Social Engineering can grant all manner of access
• Vampires
  • What happens if you’re the first one bit?
  • Where do you have your safeguards?

How can Flow Data help? (Packet level logging for network devices – Ex: NetFlow)

• Global Accounting
  • Who, what, where, when, how
• Barbarians
  • Who made it through the castle wall?
• Ninjas
  • Forensic data
  • “Soft-Firewall” like rules
• Vampires
  • Containment is key – one hop away
  • Policy verification

Why Flow?

• Leverage your existing network infrastructure to quickly, accurately detect, contain and remediate incidents.
• Anywhere from a 3-10% impact on processor.  Memory impact is even smaller.

Freeware flow data

• FLOW-TOOLS
• NMon

Behavioral Analysis?

• Flow data is awesome.  Why the expert system?
  • Flow data is plentiful – drinking from the firehose can hurt
• The problem of context
  • Signatures and rules may not always be appropriate
• Bobby Sue doesn’t normally upload this many files to the Net
• Who has staff available to constantly scrub files and graphs?

Finds almost all web application vulnerabilities.  Cross platform (written in python).  Uses tactical exploitation techniques to discover new URLs and vulnerabilities.  GTK and Console user interface.  Web service support.  Exploits [blind] SQL injections, OS commanding, remote file inclusions, local file inclusions, XSS, unsafe file uploads and more.  WML Support (WAP).  Really easy to extend.  Synergy among plugins.  Ability to find vulerabilities in query string, post data, URL filename, headers, file content (when uploading with forms) and web services.  130 plugins and growing.  Manual analysis web applications.

w3af is divided into two main parts, the core and the plugins.  The core coordinates the process and provides features that plugins consume.  Plugins share information with each other using a knowledge base.  Design patterns and objects everywhere!  8 different types of plugins exist:

• Discovery Plugins: Find new URLs and create the corresponding fuzzable requests (webSpider, urlFuzzer, googleSpider, pykto)
• Discover plugins are run in a loop, the output of one discovery plugin is sent as input to the next plugin.  This process continues until all plugins fail to find a new fuzzable request.
• Other discovery plugins try to fingerprint remote httpd, allowed HTTP methods, verify if the remote site has an HTTP load balancers.
• Audit Plugins: They take the output of discovery plugins and find vulnerabilities like [blind] SQL injection, XSS, buffer overflows
• Grep Plugins: These plugins grep every HTTP request and response to try to find information.  Examples are findComments, passwordProfiling, privateIP, directoryIndexing, getMails, and lang.
• Attack Plugins: These plugins read the vuln objects from the KB and try to exploit.
• Output Plugins: They write messages to the console, html or text file.
• Mangle Plugins: They modify requests and responses based on regexs
• Evasion Plugins: They modify the requests to try to evade IDS detection
• Bruteforce Plugins: They try to bruteforce logins

The presenter then demonstrated the w3af utility.  Very clean looking GUI similar to many of the linux GUI's available.  Good use of tabs to separate various outputs.  I haven't used it, but it looks fairly intuitive.  It has the ability to create exploit shells (OS, SQL, etc) just like I've seen with uber-expensive products like CoreImpact.  Ability to use python statements in HTTP requests to iterate through different pages. Some really useful graphing.

• archiveDotOrg plugin: Searches archive.org for older versions of the site, links that were linked somewhere in the past and now are kept in the dark.  Old and unmaintained sections are prone to vulnerabilities
• Use of PHP easter eggs to fingerprint the remote PHP version.  Old and almost forgotten technique.  Accurate fingerprinting.  Almost nobody disables the eggs (expose_php=off)
• Good samaritan module: A faster way to exploit blind SQL injections!  A funny way to exploit blind SQL injections!  "Guiding the blind man"
• Virtual Daemon: Ever dreamed about using metasploit payloads to exploit web applications?  Now you can do it!  Coded a metasploit plugin that connects to a virtual daemon and sends the payload.  The virtual daemon is run by a w3af attack plugin and receives the payload and creates a tiny ELF/PE executable.
• w3afAgent: A reverse "VPN" that allows you to continue intruding into the target network.  Send the w3afAgent client to the target host using a transfer handler (wget, tftp, echo).  The cient connects back to w3af where the w3afAgent server runs a SOCKS daemon. (Just like CoreImpact!!!  Freakin' sweet!)  UDP traffic doesn't work, but could.  Raw sockets, and sniffing won't work.
• Web 2.0 Support.  w3af can analyze pages that make heavy use of JavaScript.  THe manual solution available to achieve this task is the spiderMan plugin.  Local proxy daemon.  Analyzes requests and creates fuzzable requests.  The user needs to navigate the JavaScript sections of the site.  Supports JSON.

Future

• Some level of javascript support (mozrepl)
• More stable core
• Less false positives/negatives
• More attack plugins
• Better GTK user interface
• Better management report generation
• Long descriptions for vulnerabilities using OWASP attack information from the wiki.

Site: http://w3af.sf.net