Web Services Security Pete Lindstrom, CISSP Research Director Spire Security, LLC www.spiresecurity.com [email protected]
Dec 30, 2015
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
Web Services Threat Profile
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 Encryption - Example
<?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>)
Source: XML Syntax and Processinghttp://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
123
9
XML Encryption - Example
<?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
Source: XML Syntax and Processinghttp://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
1234
89
(<number>; <issuer>; <expiration>)
XML Encryption - Example
<?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)
Source: XML Syntax and Processinghttp://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
12345
56789
XML Encryption - Example
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
Encrypt Everything
Source: XML Syntax and Processinghttp://www.w3.org/TR/2002/CR-xmlenc-core-20020304/
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
Web Services Threat Profile
Top Ten Attacks
• Note: These are primarily THEORETICAL attacks!
Defending Against the Top Ten 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
Web Services Threat Profile
1
2
3
4
5 67 8
9
10
Modify
Sniff
Spoof
Replay
Agenda
Web Services Threat Profile
Top Ten Attacks
Defending Against the 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…