Web Services Security Pete Lindstrom CISSP Research Director

Web Services Security Pete Lindstrom, CISSP Research Director Spire Security, LLC www. spiresecurity. com petelind@spiresecurity. com

Agenda l Web Services Threat Profile l Top Ten Attacks l Defending Against the Top Ten Attacks l Conclusions

Web Services Opportunities & Risks l Multiple data sources provide many alternatives and opportunities for business. • How do we ensure that the data sources are legitimate? l Real-time transactions can be submitted just-in-time. • How do we validate the data prior to its use? l Contextual data makes integration easy. • Who else may intercept the data? l Directories allow for dynamic lookups and immediate gratification. • How do we validate the directories?

Web Services: Bane or Panacea? From monolithic mainframe, to two- and three-tier client server, to n-tier Web. Now, we have n-peer Web Services l Standardization: common communication protocols • Easier to learn technology, higher likelihood of finding a target. l Loose-coupling: flexible architecture • More uniquely addressable attack points. l Federation: working together • More ways to “hide” amidst legitimate traffic. Increased functionality brings increased risk, but it may be worth it.

Web Services Components l XML/SOAP Communication protocols. l Configuration Data (the setup) l XML Processors • • Legacy Apps External Entities

XML/SOAP Protocols l Protocol Abuse l XML Information as: • • Protocol / Tags § Expected operations RPC / Command (embedded code) § And variables, flags, attributes Data/transaction URIs - pointers

Web Services Configuration Data l Web Services Description Language (WSDL) Files l XML Schemas l XSLT Files l WS-Policy information

XML Processor l Standard operations • • Parse XML Aggregate data Transform data Canonicalize data l All Legitimate manipulation of data after the source. l Legacy bolt-ons l Untrusted entities

Web Services Threat Profile External Entities Local/UDDI Format/C 14 N Schema WSDL WS-Policy XSLT XML Route/Switch . Net/J 2 EE Transactions XML Documents Parse, Evaluate, Transform Program Instructions Legacy Apps Methods and Bindings Web Services Consumer Protocol Conversations XML Processor Applications XML-DB File Systems RDBMS Repositories

Data Protection Goals l Confidentiality – protect data from being seen by inappropriate people/entities. l Integrity – protect data from being modified inappropriately. l Authenticity – ensure the data and its source are legitimate. l Availability – ensure the data is accessible by appropriate entities.

Basic Confidentiality Encryption: l Encrypt data with symmetric key l Securely transfer key to recipient (e. g. encrypt symmetric key with recipient’s public key) Decryption: l Securely receive key (e. g. decrypt symmetric key with recipient’s private key) l Decrypt data with symmetric key

XML Encryption l Candidate Recommendation l How to represent encrypted data within XML l Separate encrypted data from encryption information l Super-encryption l http: //www. w 3. org/Encryption/2001/

XML Encryption Elements l <Encrypted. Data> container element l <Encryption. Method> element: describes the encryption algorithm. l <Key. Info> element: defined in XML-DSIG l <Cipher. Data> envelopes or references raw encrypted data • <Cipher. Value> raw data if enveloped • <Cipher. Reference> reference data if detached

XML Encryption: l Use <Encryption. Method> to create <Cipher. Value> described by <Cipher. Data> elements. l Securely transfer key to recipient using <Key. Info> or out of band method. Decryption: l Retrieve key using <Key. Info>. l Take <Cipher. Value> and identify <Encryption. Method> to decrypt data.

XML Encryption Scenarios l Encrypt XML Element l Encrypt Element and Content l Encrypt XML Content (Character Data) l Encrypt Arbitrary Data and XML Documents l Super-encryption

XML Encryption - Example Unencrypted Data 1 2 3 4 5 6 7 8 9 <? xml version='1. 0'? > <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> <Credit. Card Limit='5, 000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </Credit. Card> </Payment. Info> Source: XML Syntax and Processing http: //www. w 3. org/TR/2002/CR-xmlenc-core-20020304/

XML Encryption - Example Encrypting an XML Element (<Credit. Card>) 1 <? xml version='1. 0'? > 2 <Payment. Info xmlns='http: //example. org/paymentv 2'> 3 <Name>John Smith</Name> <Encrypted. Data Type='http: //www. w 3. org/2001/04/xmlenc#Element' xmlns='http: //www. w 3. org/2001/04/xmlenc#'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> 9 </Encrypted. Data> </Payment. Info> Source: XML Syntax and Processing http: //www. w 3. org/TR/2002/CR-xmlenc-core-20020304/

XML Encryption - Example Encrypting XML Elements and Content (<number>; <issuer>; <expiration>) 1 <? xml version='1. 0'? > 2 <Payment. Info xmlns='http: //example. org/paymentv 2'> <Name>John Smith</Name> 3 <Credit. Card Limit='5, 000' Currency='USD'> 4 <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. w 3. org/2001/04/xmlenc#Content'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> 8 </Credit. Card> Source: XML Syntax and Processing http: //www. w 3. org/TR/2002/CR-xmlenc-core-20020304/ 9 </Payment. Info>

XML Encryption - Example Encrypting XML Content (number itself) 1 <? xml version='1. 0'? > 2 <Payment. Info xmlns='http: //example. org/paymentv 2'> 3 <Name>John Smith</Name> 4 <Credit. Card Limit='5, 000' Currency='USD'> 5 <Number> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. w 3. org/2001/04/xmlenc#Content'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> 5 </Number> 6 <Issuer>Example Bank</Issuer> 7 <Expiration>04/02</Expiration> 8 </Credit. Card> Source: XML Syntax and Processing 9 http: //www. w 3. org/TR/2002/CR-xmlenc-core-20020304/ </Payment. Info>

XML Encryption - Example Encrypt Everything 1 <? xml version='1. 0'? > <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Mime. Type='text/xml'> <Cipher. Data> <Cipher. Value>A 23 B 45 C 56</Cipher. Value> </Cipher. Data> </Encrypted. Data> Source: XML Syntax and Processing http: //www. w 3. org/TR/2002/CR-xmlenc-core-20020304/

XML Encryption Roundup l The goal is confidentiality (privacy). l The key is the key – key management. l Must be able to retain keys over time. l Must be able to protect the keys. l Must keep the key and the cipherdata separate.

Integrity & Authenticity Sign: l Process data through one way hash l Sign hash with source private key l Transmit data Validate: l Validate signature with source public key l Re-hash data and compare

XML Signature l RFC 3275, March 2002 l Works with any data object l Sign data in same XML document • • Enveloped signatures (signature is child) Enveloping signatures (signature is parent) l Sign data that is external to signature

XML Signature <Signature> <Signed. Info> <Canonicalization. Method /> <Signature. Method /> <Reference> <Transforms> <Digest. Method> <Digest. Value> </Reference> </Signed. Info> <Signature. Value /> <Key. Info /> </ Signature> Container Format Data Signature Algorithm Hash Value Signed Hash Info Key Information

XML Signature Elements l <Signature> element: Root l <Signed. Info> element: Container for signature information. l <C 14 NMethod> element: Algorithm used to format data prior to signing. [XML-C 14 N] l <Signature. Method> element: Algorithm used to sign the hash (DSA-SHA 1; RSA-SHA 1)

XML Signature Elements (cont’d) l <Reference> container for signatures. l <Transforms> describes processing requirements prior to sign/validate. l <Digest. Method> algorithm used to create hash. l <Digest. Value> the hash itself l <Signature. Value> the operational results of signing the hash. l <Key. Info> information on how to retrieve the validation key.

XML Signature Sign: l Canonicalize data (<Canonicalization. Method>) l Process data through one way hash (<Digest. Method>; <Digest. Value>) l Sign hash with source private key (<Signature. Method>; <Signature. Value>) l Transmit data Validate: l Validate signature with source public key l Re-hash data and compare

Manifests l “Once-removed” signature. Validate the signed signatures. l Useful for performance considerations. l Provides selective validation. l Gotcha: individual signature validation must then occur within the application. • Individual signatures are not validated by xml signature.

XML Signature Roundup l Always include dynamic information in signed data. • Protect against replay attacks. l Retrieve key info out-of-band. l Validate all algorithm sources.

Transaction Attack Methods Attack Modify Description Change data within a transaction. Solution Sign Sniff Intercept and read data in a transaction. Encrypt Spoof Submit fake transaction. Validate Replay Resubmit real transaction. Validate/Audit

Transaction Security Sniff Modify Spoof Replay

Authentication & Access Control On the user side: l Authentication validates the identity of the credential owner. l Access control maps an entity to its corresponding attributes (e. g. roles, group membership, etc. ) On the resource side: l Describes under what conditions an entity is allowed to access a particular resource. • e. g. user name, group membership, time of day, etc.

Security Assertion Markup Language (SAML) l OASIS Committee Specification l Assertions about authentication l Assertions about attributes l Assertions about authorization decisions l http: //www. oasis-open. org/committees/security/

SAML

SAML Bindings and Profiles Binding l SOAP over HTTP Profiles l Browser/Artifact Profile (URL Query) l Browser/POST Profile (Form) l Replaces cookies

SAML Roundup l Web Services Implementation l Session-based Protocol l Basic usage model: Single Sign-on l Useful for existing web and legacy apps

XML Access Control Markup Language (XACML) l Rule • Target, Effect, Condition l Policy Statement • Multi-rule, Target, Obligations l Policy Set Statement • Multi-policy, Target, Obligations

XACML l PAP – Policy Administration Point l PRP – Policy Retrieval Point l PEP – Policy Enforcement Point l PDP – Policy Decision Point l PIP – Policy Information Point

XACML Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Retrieval Point (PRP) Policy Administration Point (PAP) Policy Information Point (PRP)

XACML l PAP – PRP: define policy. (admin action) l PEP – PDP: initial request and final decision. l PDP: Reconciles SAML assertions and XACML policy info. (next-gen firewalls? ) • Takes request from PEP, policy from PRP, and attributes from PIP.

XACML Roundup l Not ready for primetime, but… l Vendors have always had this capability in native apps. l Will standardize ACL models. l Can (potentially) replace native models. l Great for interchange of rules/policies.

SAML - XACML SAML Assertions XACML

Security “Specifications” WSSecure Conversation WS-Policy WS-Federation WS-Authorization WS-Trust WS-Privacy WS-Security SOAP Foundation

WS-Security l Message Integrity l Message Confidentiality l Message Authentication l Associated Security Tokens l Encoded Binary Security Tokens

Follow-on Specs l WS-Policy: How senders and receivers specify capabilities and requirements. l WS-Trust: Establish direct and brokered trust. l WS-Privacy: State privacy policies and adhere to them. l WS-Secure Conversation: How to establish keys. l WS-Federation: How to link trust models. l WS-Authorization: How access policies are specified and managed.

Agenda l Web Services Threat Profile l Top Ten Attacks • Note: These are primarily THEORETICAL attacks! l Defending Against the Top Ten Attacks l Conclusions

1. XML Encapsulation l Attacks legacy bolt-on XML processors. l External operation of normally local functions. l Uses “CDATA” feature in XML to “tunnel” through to app.

XML Encapsulation Example <? xml version="1. 0"? > <? xml-stylesheet type="text/xsl" href="#? m$ux" ? > <xsl: stylesheet xmlns: xsl="http: //www. w 3. org/TR/WD-xsl"> <xsl: script> <![CDATA[ x=new Active. XObject("WScript. Shell"); x. Run("%systemroot%\SYSTEM 32\CMD. EXE /C DIR C: \ /a /p /s"); ]]> </xsl: script> <msux> msux written by georgi guninski </msux> </xsl: stylesheet> Source: http: //www. guninski. com/ex$el 2. html

2. Coercive Parsing l Attacks legacy bolt-on XML processors. l Attacks old targets in new ways. l External operation of normally local functions. l Instead of using CDATA, uses XML parsing capability.

3. Recursive Elements l Use XML within a document to reference another point in the document. l Infinite loop

4. Jumbo Payloads l XML is verbose by nature, but still expected to be of “reasonable” size files – measured in KB or MB. l Jumbo payloads send a single file of hundreds of gigabytes (for example).

5. Schema Poisoning l XML Schemas are used to define format and function of a document. l Manipulating the schema can: • • • Execute denial-of-service attack. Change formats from dates to numbers, for example Obfuscate data.

6. WSDL Enumeration l WSDL files provide detailed “API-like” information for anyone accessing them. l Enumeration of WSDL files may expose debug information or private commands that aren’t intended for public use.

7. Routing Detours l XML by design is highly flexible. l WS-Routing allows for inserting or appending inprocess instructions that ensure a document gets to its anticipated destination (proxy-like). l Inserting inappropriate or malicious routing instructions can allow for a man-in-the-middle attack or other attacks against conf, int, and avail.

8. External Entity Attacks l Rather than attacking the XML document, attack the individual components of an architecture. l Many waystations/interim queues of documents provide an opportunity to modify the contents.

9. XQuery Injection l XQuery and XPath are ways to describe database queries using XML. l XQuery injection is the same as SQL injection – insert commands into an element that gets interpreted inappropriately.

10. Malicious Morphing l Web Services is malleable by design. l Aggregate/Transform/C 14 N operations are expected. l When they are performed by the wrong entities, they can be used as an attack.

Traditional Transaction Attacks By the way, don’t forget these… Attack Description Modify Change data within a transaction. Sniff Intercept and read data in a transaction. Spoof Submit fake transaction. Replay Resubmit a legit transaction.

Web Services Threat Profile External Entities Local/UDDI Format/C 14 N Schema WSDL WS-Policy XSLT XML Route/Switch 7 8 5 6 2 Modify Program Instructions Spoof 4 Transactions 10 XML Documents Parse, Evaluate, Transform Sniff Legacy Apps 3 Methods and Bindings Web Services Consumer Protocol Conversations Replay . Net/J 2 EE XML Processor 1 Applications 9 XML-DB File Systems RDBMS Repositories

Agenda l Web Services Threat Profile l Top Ten Attacks l Defending Against the Top Ten Attacks l Conclusions

Security Reference Model 2. Control sources (users/others) Identity MANAGEMENT 4. Monitor/detect inappropriate and/or malicious activity Trust MANAGEMENT Vulnerability MANAGEMENT 1. Harden the 2. Infrastructure 3. Harden the Process/data Threat MANAGEMENT

Vulnerability Management l Assumption: operating systems, databases, other existing components are hardened. l Evaluate external configuration data for “leaks” • XML Schemas, WSDL files l Create validated config files that can be compared/matched inline. l Create policy for authorized programs and input validation bounds.

Identity Management l Manage/issue certificates to known partners/customers/others. l Always use certificates for identification and authentication. l Users/Servers/Applications

Trust Management l XML-Encrypt l XML-Sign l Many other protocols

Threat Management l Monitor for policy violations • Excessive size; out of bounds attributes; other incorrect values. l Evaluate unsigned/unauthenticated transactions l Transaction logs

Conclusions l Harden the hosts l Authenticate the components l Access Control • • Limit usage to specific entities Validate inputs (user and application) l Secure the transaction l Always follow the data…

Agree? Disagree? Pete Lindstrom petelind@spiresecurity. com www. spiresecurity. com