Web Services Security Pete Lindstrom, CISSP Research Director Spire Security, LLC [email protected]

Web Services SecurityPete Lindstrom, CISSPResearch Director

Spire Security, [email protected]

Agenda

Web Services Threat Profile

Top Ten Attacks

Defending Against the Top Ten Attacks

Conclusions

Web Services Opportunities & Risks

Multiple data sources provide many alternatives and opportunities for business.• How do we ensure that the data sources are legitimate?

Real-time transactions can be submitted just-in-time.• How do we validate the data prior to its use?

Contextual data makes integration easy.• Who else may intercept the data?

Directories allow for dynamic lookups and immediate gratification.• How do we validate the directories?

Web Services: Bane or Panacea?

Standardization: common communication protocols• Easier to learn technology, higher likelihood of finding a

target.

Loose-coupling: flexible architecture• More uniquely addressable attack points.

Federation: working together• More ways to “hide” amidst legitimate traffic.

From monolithic mainframe, to two- and three-tier client server, to n-tier Web. Now, we have n-peer Web Services

Increased functionality brings increased risk, but it may be worth it.

Web Services Components

XML/SOAP Communication protocols.

Configuration Data (the setup)

XML Processors

• Legacy Apps

• External Entities

XML/SOAP Protocols

Protocol Abuse

XML Information as:• Protocol / Tags

Expected operations• RPC / Command (embedded code)

And variables, flags, attributes• Data/transaction• URIs - pointers

Web Services Configuration Data

Web Services Description Language

(WSDL) Files

XML Schemas

XSLT Files

WS-Policy information

XML Processor

Standard operations• Parse XML• Aggregate data• Transform data• Canonicalize data

All Legitimate manipulation of data after the source.

Legacy bolt-ons

Untrusted entities

ApplicationsApplications

RepositoriesRepositoriesXML ProcessorXML Processor

XML-DBFile Systems

RDBMS

XML-DBFile Systems

RDBMS

.Net/J2EE

Legacy Apps

Met

ho

ds

and

Bin

din

gs

We

b S

erv

ice

s C

on

su

me

r

Protocol Conversations

Program Instructions

Transactions

XML DocumentsP

arse

, Eva

luat

e, T

ran

sfo

rm

Local/UDDILocal/UDDI

SchemaWSDL

WS-PolicyXSLT

SchemaWSDL

WS-PolicyXSLT

External Entities

Format/C14N

XML Route/Switch


Data Protection Goals

Confidentiality – protect data from being seen by

inappropriate people/entities.

Integrity – protect data from being modified

inappropriately.

Authenticity – ensure the data and its source are

legitimate.

Availability – ensure the data is accessible by

appropriate entities.

Basic Confidentiality

Encryption:

Encrypt data with symmetric key

Securely transfer key to recipient

(e.g. encrypt symmetric key with recipient’s public key)

Decryption:

Securely receive key

(e.g. decrypt symmetric key with recipient’s private

key)

Decrypt data with symmetric key

Candidate Recommendation

How to represent encrypted data within XML

Separate encrypted data from encryption

information

Super-encryption

http://www.w3.org/Encryption/2001/

XML Encryption

XML Encryption Elements

<EncryptedData> container element

<EncryptionMethod> element: describes the encryption algorithm.

<KeyInfo> element: defined in XML-DSIG

<CipherData> envelopes or references raw encrypted data• <CipherValue> raw data if enveloped• <CipherReference> reference data if detached

XML Encryption

Encryption:

Use <EncryptionMethod> to create <CipherValue> described by <CipherData> elements.

Securely transfer key to recipient using <KeyInfo> or out of band method.

Decryption:

Retrieve key using <KeyInfo>.

Take <CipherValue> and identify <EncryptionMethod> to decrypt data.

XML Encryption Scenarios

Encrypt XML Element

Encrypt Element and Content

Encrypt XML Content (Character Data)

Encrypt Arbitrary Data and XML

Documents

Super-encryption

XML Encryption - Example

<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>

Unencrypted Data

Source: XML Syntax and Processinghttp://www.w3.org/TR/2002/CR-xmlenc-core-20020304/

123456789


<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo>

Encrypting an XML Element (<CreditCard>)


123

9


<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </CreditCard> </PaymentInfo>

Encrypting XML Elements and Content


1234

89

(<number>; <issuer>; <expiration>)


<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>

Encrypting XML Content (number itself)


12345

56789


<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>

Encrypt Everything


1

XML Encryption Roundup

The goal is confidentiality (privacy).

The key is the key – key management.

Must be able to retain keys over time.

Must be able to protect the keys.

Must keep the key and the cipherdata separate.

Integrity & Authenticity

Sign:Process data through one way hash

Sign hash with source private key

Transmit data

Validate:Validate signature with source public key

Re-hash data and compare

XML Signature

RFC 3275, March 2002

Works with any data object

Sign data in same XML document

• Enveloped signatures (signature is child)

• Enveloping signatures (signature is parent)

Sign data that is external to signature

XML Signature<Signature>

</ Signature>

<SignedInfo>

</SignedInfo>

<Reference>

</Reference>

<Transforms><DigestMethod><DigestValue>

<KeyInfo />

<CanonicalizationMethod />

<SignatureMethod />

<SignatureValue />

ContainerContainerFormat DataFormat Data

Signature AlgorithmSignature Algorithm

Hash AlgorithmHash Algorithm

Signed Hash InfoSigned Hash Info

Hash ValueHash Value

Key InformationKey Information

XML Signature Elements

<Signature> element: Root

<SignedInfo> element: Container for signature

information.

<C14NMethod> element: Algorithm used to format

data prior to signing. [XML-C14N]

<SignatureMethod> element: Algorithm used to sign

the hash (DSA-SHA1; RSA-SHA1)

XML Signature Elements (cont’d)

<Reference> container for signatures.

<Transforms> describes processing requirements prior to sign/validate.

<DigestMethod> algorithm used to create hash.

<DigestValue> the hash itself

<SignatureValue> the operational results of signing the hash.

<KeyInfo> information on how to retrieve the validation key.

XML Signature

Sign:

Canonicalize data (<CanonicalizationMethod>)

Process data through one way hash (<DigestMethod>; <DigestValue>)

Sign hash with source private key (<SignatureMethod>; <SignatureValue>)

Transmit data

Validate:

Validate signature with source public key

Re-hash data and compare

Manifests

“Once-removed” signature. Validate the

signed signatures.

Useful for performance considerations.

Provides selective validation.

Gotcha: individual signature validation

must then occur within the application.

• Individual signatures are not validated by xml

signature.

XML Signature Roundup

Always include dynamic information in

signed data.

• Protect against replay attacks.

Retrieve key info out-of-band.

Validate all algorithm sources.

Transaction Attack MethodsAttack Description Solution

Modify Change data within a

transaction.

Sign

Sniff Intercept and read data in a

transaction.

Encrypt

Spoof Submit fake transaction. Validate

Replay Resubmit real transaction. Validate/Audit

Transaction Security

Sniff

Replay

SpoofModify

Authentication & Access Control

On the user side:

Authentication validates the identity of the credential owner.

Access control maps an entity to its corresponding attributes (e.g. roles, group membership, etc.)

On the resource side:

Describes under what conditions an entity is allowed to access a particular resource.• e.g. user name, group membership, time of day, etc.

OASIS Committee Specification

Assertions about authentication

Assertions about attributes

Assertions about authorization decisions

http://www.oasis-open.org/committees/security/

Security Assertion Markup Language

(SAML)

SAML

SAML Bindings and Profiles

Binding

SOAP over HTTP

Profiles

Browser/Artifact Profile (URL Query)

Browser/POST Profile (Form)

Replaces cookies

SAML Roundup

Web Services Implementation

Session-based Protocol

Basic usage model: Single Sign-on

Useful for existing web and legacy apps

Rule

• Target, Effect, Condition

Policy Statement

• Multi-rule, Target, Obligations

Policy Set Statement

• Multi-policy, Target, Obligations

XML Access Control Markup LanguageXML Access Control Markup Language

(XACML)(XACML)

XACML

PAP – Policy Administration Point

PRP – Policy Retrieval Point

PEP – Policy Enforcement Point

PDP – Policy Decision Point

PIP – Policy Information Point

XACML

PEP

PDP

2.decisionrequest

PRP 4. policy PIP5. saml attributequery

8. authorizationdecision

3. target7. saml attribute

assertion

environmentresourcesubject

6a. attribute

6c. attribute

6b. attribute

PAP

1. policy

9. obligations

PolicyEnforcementPoint (PEP)

PolicyDecision

Point (PDP)

PolicyRetrieval

Point (PRP)

PolicyInformationPoint (PRP)

PolicyAdministration

Point (PAP)

XACML

PAP – PRP: define policy. (admin action)

PEP – PDP: initial request and final

decision.

PDP: Reconciles SAML assertions and

XACML policy info. (next-gen firewalls?)

• Takes request from PEP, policy from PRP, and

attributes from PIP.

XACML Roundup

Not ready for primetime, but…

Vendors have always had this capability in native

apps.

Will standardize ACL models.

Can (potentially) replace native models.

Great for interchange of rules/policies.

SAML - XACML

SAMLAssertions

XACML

Security “Specifications”

WS-Secure Conversation

WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security

SOAP Foundation

WS-Security

Message Integrity

Message Confidentiality

Message Authentication

Associated Security Tokens

Encoded Binary Security Tokens

Follow-on SpecsWS-Policy: How senders and receivers specify

capabilities and requirements.

WS-Trust: Establish direct and brokered trust.

WS-Privacy: State privacy policies and adhere to them.

WS-Secure Conversation: How to establish keys.

WS-Federation: How to link trust models.

WS-Authorization: How access policies are specified and managed.

Agenda


Top Ten Attacks

• Note: These are primarily THEORETICAL attacks!


Conclusions

1. XML Encapsulation

Attacks legacy bolt-on XML processors.

External operation of normally local

functions.

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.w3.org/TR/WD-xsl"><xsl:script><![CDATA[x=new ActiveXObject("WScript.Shell");x.Run("%systemroot%\\SYSTEM32\\CMD.EXE /C DIR C:\\ /a /p /s");]]></xsl:script><msux>msuxwritten by georgi guninski</msux></xsl:stylesheet>

Source: http://www.guninski.com/ex$el2.html

2. Coercive Parsing

Attacks legacy bolt-on XML processors.

Attacks old targets in new ways.

External operation of normally local functions.

Instead of using CDATA, uses XML parsing capability.

3. Recursive Elements

Use XML within a document to reference

another point in the document.

Infinite loop

4. Jumbo Payloads

XML is verbose by nature, but still

expected to be of “reasonable” size files

– measured in KB or MB.

Jumbo payloads send a single file of

hundreds of gigabytes (for example).

5. Schema Poisoning

XML Schemas are used to define format and function of a document.

Manipulating the schema can:• Execute denial-of-service attack.• Change formats from dates to numbers, for example• Obfuscate data.

6. WSDL Enumeration

WSDL files provide detailed “API-like”

information for anyone accessing them.

Enumeration of WSDL files may expose

debug information or private commands

that aren’t intended for public use.

7. Routing Detours

XML by design is highly flexible.

WS-Routing allows for inserting or appending in-

process instructions that ensure a document gets

to its anticipated destination (proxy-like).

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

Rather than attacking the XML

document, attack the individual

components of an architecture.

Many waystations/interim queues of

documents provide an opportunity to

modify the contents.

9. XQuery Injection

XQuery and XPath are ways to describe

database queries using XML.

XQuery injection is the same as SQL

injection – insert commands into an

element that gets interpreted

inappropriately.

10. Malicious Morphing

Web Services is malleable by design.

Aggregate/Transform/C14N operations

are expected.

When they are performed by the wrong

entities, they can be used as an attack.

Traditional Transaction Attacks

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.

By the way, don’t forget these…

ApplicationsApplications

RepositoriesRepositoriesXML ProcessorXML Processor

XML-DBFile Systems

RDBMS

XML-DBFile Systems

RDBMS

.Net/J2EE

Legacy Apps

Met

ho

ds

and

Bin

din

gs

We

b S

erv

ice

s C

on

su

me

r

Protocol Conversations

Program Instructions

Transactions

XML DocumentsP

arse

, Eva

luat

e, T

ran

sfo

rm

Local/UDDILocal/UDDI

SchemaWSDL

WS-PolicyXSLT

SchemaWSDL

WS-PolicyXSLT

External Entities

Format/C14N

XML Route/Switch


1

2

3

4

5 67 8

9

10

Modify

Sniff

Spoof

Replay

Agenda


Top Ten Attacks


Conclusions

ThreatMANAGEMENT

TrustMANAGEMENT

IdentityMANAGEMENT

VulnerabilityMANAGEMENT

Security Reference Model

1.Harden the Infrastructure

2. Control sources (users/others)

3. Harden the Process/data

4. Monitor/detectinappropriate and/or

malicious activity

Vulnerability Management

Assumption: operating systems, databases, other existing components are hardened.

Evaluate external configuration data for “leaks”• XML Schemas, WSDL files

Create validated config files that can be compared/matched inline.

Create policy for authorized programs and input validation bounds.

Identity Management

Manage/issue certificates to known

partners/customers/others.

Always use certificates for identification

and authentication.

Users/Servers/Applications

Trust Management

XML-Encrypt

XML-Sign

Many other protocols

Threat Management

Monitor for policy violations

• Excessive size; out of bounds attributes; other

incorrect values.

Evaluate unsigned/unauthenticated

transactions

Transaction logs

Conclusions

Harden the hosts

Authenticate the components

Access Control

• Limit usage to specific entities

• Validate inputs (user and application)

Secure the transaction

Always follow the data…

Pete [email protected]

Agree? Disagree?

mailto:[email protected]