XML Intrusion Prevention

XML Intrusion Prevention Blake DournaeeSenior Security ArchitectSarvega, Inc.blake@sarvega.com April 2005

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

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

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

SOAP Envelope SOAP header Digital Signature SOAP Message SOAP Body SOAP SOAP SOAP SOAP SOAP XML Encryption XML Web Services Architecture DB DMZ Application Infrastructure Web Service (Partner) Internet HTTP HTTP SSL/ TLS G/W Router LAN Switches External Firewall Content Switch Internal Firewall Web Server SSL/ TLS Application Servers Web Service Client SOAP Payloads can carry arbitrary XML and flow freely over port 80

XML Threat Model Application XML Payload HTTP TCP

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

SOAP Envelope SOAP header Digital Signature SOAP Message SOAP Body SOAP SOAP SOAP SOAP SOAP XML Encryption XIP Device DB DMZ Application Infrastructure Web Service (Partner) Internet HTTP HTTP SSL/ TLS G/W Router LAN Switches External Firewall Content Switch Internal Firewall Web Server SSL/ TLS Application Servers Web Service Client XIP Device

XML Threat Model Application XML Payload Encoding ThreatsStructural ThreatsGrammar Validation ThreatsSemantic ThreatsExternal Entity ThreatsXML Security ThreatsAlgorithmic Threats HTTP TCP

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)

Structural Threats • ... it is important to realize that any lock can be picked with a big enough hammer. • - Sun System & Network Admin manual

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>

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>

DOM Example Document <Envelope> <Text> <Body> <Text> <Text> <Order> <Text> <Text> <Item> <Text> <Quant> <Text> <Acct Num> <Text> <Price> <Text> <Text> <Text> <Text> <Text> All are subtypes of ‘Node’

DOM Parsing Memory Requirements

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 Trash Application

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>

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 --'

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

Network Targets Circa 1995 Circa 2005 • SLIP/PPP • FTP • Telnet • Gopher • IMAP • POP • rlogin • HTTP • SMTP • VPN (IPSec/SSL) • SCP • SSH • RDP • SRTP • IMAPS • SMTP • HTTPS • SOAP/XML

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

XML Intrusion Prevention