Web Services Security

1
Web Services Security

• Pete Lindstrom, CISSP
• Research Director
• Spire Security, LLC
• www.spiresecurity.com
• petelind_at_spiresecurity.com

2
Agenda

• Web Services Threat Profile
• Top Ten Attacks
• Defending Against the Top Ten Attacks
• Conclusions

3
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?

4
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

• 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.

Increased functionality brings increased risk,
but it may be worth it.
5
Web Services Components

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

6
XML/SOAP Protocols

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

7
Web Services Configuration Data

• Web Services Description Language (WSDL) Files
• XML Schemas
• XSLT Files
• WS-Policy information

8
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

9
Web Services Threat Profile
10
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.

11
Basic Confidentiality

• Encryption
• Encrypt data with symmetric key
• Securely transfer key to recipient
• (e.g. encrypt symmetric key with recipients
  public key)
• Decryption
• Securely receive key
• (e.g. decrypt symmetric key with recipients
  private key)
• Decrypt data with symmetric key

12
XML Encryption

• Candidate Recommendation
• How to represent encrypted data within XML
• Separate encrypted data from encryption
  information
• Super-encryption
• http//www.w3.org/Encryption/2001/

13
XML Encryption Elements

• ltEncryptedDatagt container element
• ltEncryptionMethodgt element describes the
  encryption algorithm.
• ltKeyInfogt element defined in XML-DSIG
• ltCipherDatagt envelopes or references raw
  encrypted data
• ltCipherValuegt raw data if enveloped
• ltCipherReferencegt reference data if detached

14
XML Encryption

• Encryption
• Use ltEncryptionMethodgt to create ltCipherValuegt
  described by ltCipherDatagt elements.
• Securely transfer key to recipient using
  ltKeyInfogt or out of band method.
• Decryption
• Retrieve key using ltKeyInfogt.
• Take ltCipherValuegt and identify
  ltEncryptionMethodgt to decrypt data.

15
XML Encryption Scenarios

• Encrypt XML Element
• Encrypt Element and Content
• Encrypt XML Content (Character Data)
• Encrypt Arbitrary Data and XML Documents
• Super-encryption

16
XML Encryption - Example
Unencrypted Data
lt?xml version'1.0'?gt ltPaymentInfo
xmlns'http//example.org/paymentv2'gt
ltNamegtJohn Smithlt/Namegt ltCreditCard
Limit'5,000' Currency'USD'gt ltNumbergt4019
2445 0277 5567lt/Numbergt ltIssuergtExample
Banklt/Issuergt ltExpirationgt04/02lt/Expirationgt
lt/CreditCardgt lt/PaymentInfogt
1 2 3 4 5 6 7 8 9
Source XML Syntax and Processing http//www.w3.or
g/TR/2002/CR-xmlenc-core-20020304/
17
XML Encryption - Example
Encrypting an XML Element (ltCreditCardgt)
lt?xml version'1.0'?gt ltPaymentInfo
xmlns'http//example.org/paymentv2'gt
ltNamegtJohn Smithlt/Namegt ltEncryptedData
Type'http//www.w3.org/2001/04/xmlencElement'
xmlns'http//www.w3.org/2001/04/xmlenc'gt
ltCipherDatagt ltCipherValuegtA23B45C56lt/Cip
herValuegt lt/CipherDatagt
lt/EncryptedDatagt lt/PaymentInfogt
1 2 3
9
Source XML Syntax and Processing http//www.w3.or
g/TR/2002/CR-xmlenc-core-20020304/
18
XML Encryption - Example
Encrypting XML Elements and Content
(ltnumbergt ltissuergt ltexpirationgt)
lt?xml version'1.0'?gt ltPaymentInfo
xmlns'http//example.org/paymentv2'gt
ltNamegtJohn Smithlt/Namegt ltCreditCard
Limit'5,000' Currency'USD'gt
ltEncryptedData xmlns'http//www.w3.org/2001/04/xm
lenc' Type'http//www.w3.org/2001/04/xmle
ncContent'gt ltCipherDatagt
ltCipherValuegtA23B45C56lt/CipherValuegt
lt/CipherDatagt lt/EncryptedDatagt
lt/CreditCardgt lt/PaymentInfogt
1 2 3 4
8 9
Source XML Syntax and Processing http//www.w3.or
g/TR/2002/CR-xmlenc-core-20020304/
19
XML Encryption - Example
Encrypting XML Content (number itself)
lt?xml version'1.0'?gt ltPaymentInfo
xmlns'http//example.org/paymentv2'gt
ltNamegtJohn Smithlt/Namegt ltCreditCard
Limit'5,000' Currency'USD'gt ltNumbergt
ltEncryptedData xmlns'http//www.w3.org/2001/04
/xmlenc' Type'http//www.w3.org/2001/04
/xmlencContent'gt ltCipherDatagt
ltCipherValuegtA23B45C56lt/CipherValuegt
lt/CipherDatagt lt/EncryptedDatagt
lt/Numbergt ltIssuergtExample Banklt/Issuergt
ltExpirationgt04/02lt/Expirationgt
lt/CreditCardgt lt/PaymentInfogt
1 2 3 4 5
5 6 7 8 9
Source XML Syntax and Processing http//www.w3.or
g/TR/2002/CR-xmlenc-core-20020304/
20
XML Encryption - Example
Encrypt Everything
lt?xml version'1.0'?gt ltEncryptedData
xmlns'http//www.w3.org/2001/04/xmlenc'
MimeType'text/xml'gt ltCipherDatagt
ltCipherValuegtA23B45C56lt/CipherValuegt
lt/CipherDatagt lt/EncryptedDatagt
1
Source XML Syntax and Processing http//www.w3.or
g/TR/2002/CR-xmlenc-core-20020304/
21
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.

22
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

23
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

24
XML Signature
Container
Format Data
Signature Algorithm
Hash Algorithm
Hash Value
Signed Hash Info
Key Information
25
XML Signature Elements

• ltSignaturegt element Root
• ltSignedInfogt element Container for signature
  information.
• ltC14NMethodgt element Algorithm used to format
  data prior to signing. XML-C14N
• ltSignatureMethodgt element Algorithm used to sign
  the hash (DSA-SHA1 RSA-SHA1)

26
XML Signature Elements (contd)

• ltReferencegt container for signatures.
• ltTransformsgt describes processing requirements
  prior to sign/validate.
• ltDigestMethodgt algorithm used to create hash.
• ltDigestValuegt the hash itself
• ltSignatureValuegt the operational results of
  signing the hash.
• ltKeyInfogt information on how to retrieve the
  validation key.

27
XML Signature

• Sign
• Canonicalize data (ltCanonicalizationMethodgt)
• Process data through one way hash
  (ltDigestMethodgt ltDigestValuegt)
• Sign hash with source private key
  (ltSignatureMethodgt ltSignatureValuegt)
• Transmit data
• Validate
• Validate signature with source public key
• Re-hash data and compare

28
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.

29
XML Signature Roundup

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

30
Transaction Attack Methods
Attack 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
31
Transaction Security
32
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.

33
Security Assertion Markup Language (SAML)

• OASIS Committee Specification
• Assertions about authentication
• Assertions about attributes
• Assertions about authorization decisions
• http//www.oasis-open.org/committees/security/

34
SAML
35
SAML Bindings and Profiles

• Binding
• SOAP over HTTP
• Profiles
• Browser/Artifact Profile (URL Query)
• Browser/POST Profile (Form)
• Replaces cookies

36
SAML Roundup

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

37
XML Access Control Markup Language (XACML)

• Rule
• Target, Effect, Condition
• Policy Statement
• Multi-rule, Target, Obligations
• Policy Set Statement
• Multi-policy, Target, Obligations

38
XACML

• PAP Policy Administration Point
• PRP Policy Retrieval Point
• PEP Policy Enforcement Point
• PDP Policy Decision Point
• PIP Policy Information Point

39
XACML
Policy Enforcement Point (PEP)
Policy Decision Point (PDP)
Policy Retrieval Point (PRP)
Policy Information Point (PRP)
Policy Administration Point (PAP)
40
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.

41
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.

42
SAML - XACML
SAML Assertions
XACML
43
Security Specifications
WS- Secure Conversation
WS-Federation
WS-Authorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security
SOAP Foundation
44
WS-Security

• Message Integrity
• Message Confidentiality
• Message Authentication
• Associated Security Tokens
• Encoded Binary Security Tokens

45
Follow-on Specs

• WS-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.

46
Agenda

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

47
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.

48
XML Encapsulation Example

• lt?xml version"1.0"?gtlt?xml-stylesheet
  type"text/xsl" href"?mux" ?gtltxslstylesheet
  xmlnsxsl"http//www.w3.org/TR/WD-xsl"gtltxslscri
  ptgtlt!CDATAxnew ActiveXObject("WScript.Shell")
  x.Run("systemroot\\SYSTEM32\\CMD.EXE /C DIR
  C\\ /a /p /s")gtlt/xslscriptgtltmsuxgtmsuxwri
  tten by georgi guninskilt/msuxgtlt/xslstylesheetgt

Source http//www.guninski.com/exel2.html
49
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.

50
3. Recursive Elements

• Use XML within a document to reference another
  point in the document.
• Infinite loop

51
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).

52
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.

53
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 arent
  intended for public use.

54
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.

55
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.

56
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.

57
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.

58
Traditional Transaction Attacks
By the way, dont 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.
59
Web Services Threat Profile
7
8
5
6
2
Modify Sniff Spoof Replay
3
1
4
9
10
60
Agenda

• Web Services Threat Profile
• Top Ten Attacks
• Defending Against the Top Ten Attacks
• Conclusions

61
Security Reference Model
4. Monitor/detect inappropriate and/or malicious
activity
2. Control sources (users/others)

• Harden the
• Infrastructure

3. Harden the Process/data
62
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.

63
Identity Management

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

64
Trust Management

• XML-Encrypt
• XML-Sign
• Many other protocols

65
Threat Management

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

66
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

67
Agree? Disagree?
Pete Lindstrom petelind_at_spiresecurity.com www.spir
esecurity.com