# Presentation: 197985

## XML Intrusion Prevention

- Blake DournaeeSenior Security ArchitectSarvega, Inc. _[blake@sarvega.com](mailto:blake@sarvega.com)_
- April 2005

**Notes:**
This is a presentation on the emerging XML Intrusion Prevention Space

## Agenda

**Level Setting**
**Lingo, Requirements, Categories, Definitions**
**General Threat Model**
**Structural Threats**
- Problem Examples
- Typical Countermeasures
**Semantic Threats**
- Problem Examples
- Typical Countermeasures
**SOAP and the Universal Tunnel**
**Summary / Q&A**

**Notes:**
This presentation should run about 35 minutes.

XIP is a new area and relies on specific assumptions about the network architecture.

## XIP – XML Intrusion Prevention

**XIP - The theory and practice of protecting against *****XML Content Attacks***
***XML Message Sent to an application to put the system in a state beneficial to the attacker***
- Deliberate Attacks (Active Attacker)
- Inadvertent Attacks (Software Bug)
**XML Web Service Architectural Assumption**
- Different than Web Application Security
- XML/HTTP or SOAP/HTTP
- Similar attack types (SQL Injection, Buffer Overflow)
- Different Architecture
- App-to-App interaction using XML messages wrapped in SOAP envelopes

**Notes:**
XIP, yet another acronym.

XML Content attacks take many forms: Denial of Service Attack, Code Injection, Spoofed Message.

Inadvertent attacks are innocent malformed messages or messages that are too large.

## The Threats: Lingo

**Coercive Parsing**
**Content Tampering**
**Parameter Tampering**
**SQL/XQuery Injection**
**XML Virus**
**X-Malware**
**Code Injection**
**Malicious Morphing**

**Oversize Payloads**
**Replay Attacks**
**External Entity Attacks**
**Buffer Overflow**
**XDOS**
**Recursive Payloads**
**Routing Detour**
**WSDL Scanning**
**Schema Poisoning**

## XML Web Services Architecture 

**DMZ**

**Web Service Client**

**Web Server **

**Web Service (Partner) **

- SSL/ TLS

- HTTP

- HTTP

- SSL/ TLS

**Internet**

**Application Servers **

**DB **

**G/W**
**Router **

**External Firewall**

**Content Switch**

**Internal**
**Firewall**

**SOAP Payloads can carry arbitrary XML and flow freely over port 80**

**LAN**
**Switches**

**Application**
**Infrastructure**

## XML Threat Model

- HTTP

- TCP

- Application

**XML Payload**

**Notes:**
What does the threat model look like for XML documents? Aside from the Lingo we talked about at the beginning of the presentation, what sorts of threats is XML data susceptible to?

The XML Payload is in between the consuming application and the HTTP layer

## XIP Device Requirements

**XIP Device: The firewall or IDS system responsible for XIP.**
**Two Requirements**
**Resiliency: **An XIP device should never crash or cause a denial-of-service condition when processing bad XML data.
**Content Scrutiny: **An XIP device should never pass on XML content that will blow out a downstream entity or cause it to perform unauthorized functions
**Theme: Protect *****itself***** and protect *****its application domain***

## XIP Device

**DMZ**

**Web Service Client**

**Web Server **

**Web Service (Partner) **

- SSL/ TLS

- HTTP

- HTTP

- SSL/ TLS

**Internet**

**Application Servers **

**DB **

**G/W**
**Router **

**External Firewall**

**Content Switch**

**Internal**
**Firewall**

**XIP Device**

**LAN**
**Switches**

**Application**
**Infrastructure**

## XML Threat Model

- HTTP

- TCP

- Application

**XML Payload**

- Encoding ThreatsStructural ThreatsGrammar Validation ThreatsSemantic ThreatsExternal Entity ThreatsXML Security ThreatsAlgorithmic Threats

## XML Threat Details

**Encoding Threats**
**Threats related to naïve or broken XML parsers not designed to handle encodings correctly**
**Failure to maintain encoding information for an XML document**
**Structural Threats**
**Threats related to the structure of the XML document, such as oversized payloads and components**
**Grammar Validation Threats**
**Threats related to schema validation or equivalent**
**Semantic Threats**
**Code Injection, SQL injection – any threat that manipulates the representation of the XML document to change the semantics**
**External Entity Threats**
**Manipulation of the XML processor de-reference external URIs**
**XML Security Threats**
**Misapplication of XML Security such as XML Digital Signatures and XML Encryption**
**Algorithmic Threats**
**DoS Attacks that take advantage of the underlying XML processor implementations (such as a hash table attack)**

**Notes:**
This is a very broad model; The XIP space is very new and there isn’t a lot of information about the most common attacks, so this model tries to be overly comprehensive in understanding the range of threats.

Algorithmic Threats: Manipulating the XML document to force the internal data structures to behave inefficiently.

## Structural Threats

- _[... it is important to realize that any lock can be picked with a big enough hammer.](http://www.quotationspage.com/quote/22723.html)__ _
-     **- Sun System & Network Admin manual**

**Notes:**
The previous 10 slides try to give a broad overview of the XIP space. The remainder of the presentation will focus on Structural and Semantic threats, two of the most common types of XML Content attacks.

Structural Threats are a good starting point to begin looking at XML content attacks.

## Structural Threat: Huge Document

- <Envelope>
-   <Header>
-     <wsse:Security>
-       **<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>**
**      ****<Attack>DoS</Attack>...**
-      <Signature>...</Signature>
-     </wsse:Security>
-   </Header>
-   <Body>
-     <GetStockQuote>     <Ticker>CSCO</Ticker>
-     <GetStockQuote>
-   </Body>
- </Envelope>

**Notes:**
The first example would be schema valid, but clearly the second example is more than 16 bytes.

## Structural Threat: Weird Structure

- <Envelope>
-   <Header>
-     <wsse:Security>
-       **<Attack a1=“1” a2=“1” a3=“1” a4=“1” a5=“1” a6=“1”...**
**       ****<Attack>**
**         ****<Attack>**
**           ****<Attack>**
**             ****<Attack>....               **
-      <Signature>...</Signature>
-     </wsse:Security>
-   </Header>
-   <Body>
-     <GetStockQuote>     <Ticker>CSCO</Ticker>
-     <GetStockQuote>
-   </Body>
- </Envelope>

## Structural Threat: Huge Binary Blobs

- <Envelope>
-   <Header>
-     <wsse:Security>
-       **<Attack>****hbCBDZXJ0aWZpY2F0aW9uIEF1dGhv**
**xMDMxODU4MzRaMFwxCzAJBgNVBAYT**
**1cml0eSwgSW5jLjErMCkGA1UECxMi**
**1dGhvcml0eTCBmzANBgkqhkiG9w0B**
**sbsZwmdu41QUDaSiCnHJ/lj+O7Kwp....**
-      <Signature>...</Signature>
-     </wsse:Security>
-   </Header>
-   <Body>
-     <GetStockQuote>     <Ticker>CSCO</Ticker>
-     <GetStockQuote>
-   </Body>
- </Envelope>

## Structural Threats: Why?

- Why should a large or oversize payload cause a problem?
- Why haven’t we seen these types of threats with “regular” network traffic?
- Answer: The attacker is relying on inefficient XML parsing models
- DOM Based Parsing

## Parsing: SOAP Document Example

**<****S:Envelope ****xmlns:S****="http://www.w3.org/2001/12/soap-envelope"****>**
** ****<****S:Body ****Id=****"MsgBody"****>****<****fn:Order ****xmlns:fn=****"http://www.foo.com/fakens"****>**
**     ****<****Item****>****Pool Table****<****/Item****>**
**     ****<****Quantity****>****1****<****/Quantity****>****              **
**     ****<****AccountNumber****>****123456789****<****/AccountNumber****>**
**     ****<****Price****>****$800.00****<****/Price****>**
**   ****<****/fn:Order****>**
** ****<****/S:Body****>**
**<****/S:Envelope****>**

**Notes:**
Here is a sample SOAP document. How many children does the document element have?

## DOM Example

**Document**

**<Envelope>**

**<Body>**

**<Order>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**<Item>**

**<Quant>**

**<Text>**

**<Acct Num>**

**<Price>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**<Text>**

**All are subtypes of ‘Node’**

**Notes:**
The Document Object is the entry point into the document.
The <Envelope> element is the document element.

The children of <Envelope> include two text nodes, denoted T.

## DOM Parsing Memory Requirements

**Notes:**
Largely Platform Independent. Same memory requirements for Windows XP as well as Redhat 9.0 using J2SE 1.4.2

Java Based DOM Parsing:
25 MB – 120 MB
50 MB – 260 MB
100 MB – 525 MB
150 MB – 800MB

## SAX Specific Exploits

- What about stream-based parsing?
- In general, less vulnerable
- Usage dependent
- Context-free filtering
- Overlapped parsing and consumption
- Stream replay and storage

## Context-Free Filtering

- Single element search
- Event Callbacks Required
- startDocument() / endDocument()
- startElement() / endElement()
- All other data is filtered and lost

- XML

- E1,E2,E3,...,En

**?**

- Trash

- Application

## Overlapped Parsing and Consumption

- Ordered Processing
- Read XML in chunks and then process
- Simple content models with repetition
- Very little content caching

- XML

- E1,E2,E3,...,En

- Application

- Trash

## Stream Replay and Storage

- Context-sensitive SAX parsing
- Caching (replay) of complete documents or subdocuments
- Can approach DOM-like memory usage

- XML

- E1,E2,E3,E4,E5,E6,E7,...,En

- Trash

- Application

- In-memory

## XML Parsing Conclusions

- DOM parsing is a memory hog
- SAX parsing can be a memory hog
- Usage dependent

## Typical Countermeasures

**W3C Schema Validation**
- Standardized grammar validation
- Validate the document against a schema to ensure that it matches

## Schema Validation Problems

- Parsing Precondition
- Paradox: You have to parse before you validate
- Extensible Standard Schemas
- Schema is not “by design” a security feature

## Parsing Precondition

- Logical split between parsing and validation
- Naïve implementations parse first and then validate second, when it is too late
- Smarter implementations can *begin *schema validation while parsing, but can’t finish until parsing finishes
- Sequence of elements a, b, & c: I need to parse to the end to see if the element “c” is present.
- Pathological nodes are always parsed before validated
- Schema validation comes ‘too late’
- Special checks outside of schema validation (limit enforcement) are required

## XML Schema Extensibility

- Value in *general, extensible *content models
- Not practical to be so restrictive
**<xs:any processContents=“lax" ****	****  maxOccurs="unbounded"/>**
- Weakest Link Property
- An attacker only needs to find one extensibility point
- Explicit *schema hardening *_breaks _standards
- Hardened schemas are vulnerable if not protected by a digital signature or trusted source

## OASIS WS-Security Schema Example

- <xsd:complexType name="SecurityHeaderType">
- <xsd:sequence>
-   **<xsd:any processContents="lax" minOccurs="0“ maxOccurs="unbounded">**
-   <xsd:annotation>
-   <xsd:documentation>**The use of "any" is to allow extensibility and different forms of security data.**</xsd:documentation>
-   </xsd:annotation>
-   </xsd:any>
-  </xsd:sequence>
-   **<xsd:anyAttribute namespace="##other“ processContents="lax" />**
-   </xsd:complexType>

## Schema Validation: Inadequate

- Schema valid <wsse:Security> element:
**<wsse:Security xmlns:wsse=****“http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>**
**<Attack>DoS</Attack>...**
**</wsse:Security>**
**  **

**Notes:**
The first example would be schema valid, but clearly the second example is more than 16 bytes.

## Structural Threat Prevention: Requirements

*Wire speed *Limit Enforcement for XML Parsing
- Oversize payloads
- Oversized element names, attribute names and processing instruction target names.
- Limiting the maximum number of attributes per element.
- Limiting the depth (nesting) of elements.
- Limits on the size of the processing instructions, comments, single CDATA items, and attribute values
*Wire speed* Schema Validation for hardened schemas
*Wire speed *XPath Filtering
- Used to filter XML based on known traffic

## Semantic Threats

## SQL Injection Example

- Assume that a query is being run as follows:
-  query = "select count(*) from users where userName=‘ **" &  userName & “** ' and userPass=‘ **" & password & “** ‘ "
- Boolean short-circuiting techniques
-  select count(*) from users where userName='john' and userPass='' or 1=1 --'

**Notes:**
The above query uses ASP.NET syntax

## SQL Injection

- Web Applications are highly susceptible
- Weak typing of Web-based languages
- Ease of use vs. Security
- Ad-hoc coercion of data-types
- SOAP-based applications are less susceptible
- Easier to enforce stronger typing with SOAP
- SOAP faults may return extra information
- <faultstring> element returns stack traces

## SOAP: SQL Injection Example

- <soap:Envelope xmlns:soap=“ “>
-   <soap:Body>
-     <fn:PerformFunction xmlns:fn=“ “>
-      <fn:uid>8123</fn:uid>
-      **<fn:password>**
**       ’****or 1=1 or password=‘****   </fn:password>**
-     </fn:PerformFunction>
-   </soap:Body>
- </soap:Envelope>

- Strong typing mitigates the attack on the uid parameter

## SOAP Array Attack

- <soap:Envelope xmlns:soap=“ “>
-   <soap:Body>
-     <fn:PerformFunction xmlns:fn=“ “ xmlns:ns=“ “>  <DataSet xsi:type="ns:Array"
-            ns:arrayType="**xsd:string[100000]**">
-     <item xsi:type="xsd:string">**Data1**</item>
-     <item xsi:type="xsd:string">**Data2**</item>
-     <item xsi:type="xsd:string">**Data3**</item>
-     </DataSet>
-     </fn:PerformFunction>
-   </soap:Body>
- </soap:Envelope>

- DoS Condition with memory pre-allocation

## Typical Countermeasures

- W3C Schema Validation
- Standardized Grammar validation
- Schema <pattern> Facet / Regular Expressions
- Stronger Schema datatypes
- Application Checks
- Strong typing and input validation can prevent SQL injection style attacks

## Schema Validation Problems

- Manual Schema Modification
- Stronger typing must be manually added to schemas
- Breaks standards
- Highly Tedious
- Incomplete Protection
- Regex Capabilities inadequate

## <Pattern> Facet Example

-   <xs:simpleType name="zipcode">
-    <xs:restriction base="xs:string">
-      <xs:pattern value="[0-9]{5}(-[0-9]{4})?"/>
-    </xs:restriction>
-   </xs:simpleType>
- You must specify the entire value space
- Logical negation of an expression not possible
- Can’t say: “Don’t allow any documents with SELECT, WHERE, OR, 1=1” within element X.

## Semantic Threat Prevention: Requirements

*Wire speed *word filter
- Case blind or case sensitive
- Regex filter
- Scanning for double dash, single quote, & hash
- SOAP Attachment Scanning
- Case blind or case sensitive
*Wire speed* Schema Validation for hardened schemas

## XML & Web Services:  The Universal Tunnel

## De-Perimiterization	

- XML Web Services are *more *than just a different class of network traffic
- XML Web Services represents a crucial paradigm shift of the network perimeter.
- XML Web Services provide a *universal tunnel*

**Notes:**
Services are implicitAnything on the network may be exposed as a web service.

## Network Targets

**SLIP/PPP**
**FTP**
**Telnet**
**Gopher**
**IMAP**
**POP**
**rlogin**
**HTTP**
**SMTP**

**VPN (IPSec/SSL)**
**SCP**
**SSH**
**RDP**
**SRTP**
**IMAPS**
**SMTP**
**HTTPS**
**SOAP/XML**

_**Circa 1995**_

_**Circa 2005**_

## Universal Tunnel Problems

*“*I need to get this file to you and can’t wait for the network guys to open up FTP, just download my WSDL and build a client for it...”
- In principle, secure versions of existing protocols can be re-implemented quite easily over XML Web Services
- XML Web Services platforms provide quick and easy deployment of services
- Future prediction: Open Source XML Web Services implementing existing network protocols
- FTP/Telnet/SSH/SCP/RDP/IMAP...

## Security Cycle

- 1995: Proliferation of Internet-based Protocols

- Deployed protocols are *porus *and provide multi-vector attack opportunities

- 2005: Proliferation of Secure Replacements; XMLWeb Services developed

***XML Web Services and the universal tunnel***

## Summary

- Multiple Threat categories for XML
- Structural threats need limit enforcement
- Semantic threats need regex and word filtering
- Both threats are mitigated by schema validation
- All of it needs *wire speed *processing
- SOAP is a Universal Tunnel
- XML is more than a “type” of traffic