Docstoc

XML Digital Signatures _ Encryption

Document Sample
XML Digital Signatures _ Encryption Powered By Docstoc
					May 12, 2007

ToorCon Seattle ‘07

Attacking Web Services Security
Message Oriented Madness, XML Worms and why SSL still doesn’t suck.

• Brad Hill

brad@isecpartners.com

https://www.isecpartners.com

Attacking Web Services Security

ToorCon Seattle ‘07

Welcome.
 Great party last night!  Thanks for waking up in time to

see my talk.

Attacking Web Services Security

ToorCon Seattle ‘07

Who am I?
 Senior Security Consultant with iSEC

Partners
 Previously a developer and security expert

in the financial services and high-tech sectors.
 Based here in Seattle

Attacking Web Services Security

ToorCon Seattle ‘07

Some background…

Attacking Web Services Security

ToorCon Seattle ‘07

Two years ago at Black Hat. . .
 Scott Stender & Alex Stamos of

iSEC present: “Attacking Web Services: The Next Generation of Vulnerable Enterprise Apps”

Attacking Web Services Security

ToorCon Seattle ‘07

Attacks Old and New
 XML, SOAP and UDDI  Why the OWASP Top 10 still matter  New variants like XML, DTD and XPath Injection  Complexity and Denial of Service attacks against XML

applications

Attacking Web Services Security

ToorCon Seattle ‘07

Web Services can be scary
 Discoverable  Complex  Vulnerable

Attacking Web Services Security

ToorCon Seattle ‘07

Message Received
 Half a dozen presentations and at least one book by

others have followed. (repeating mostly the same material)
 Scott & Alex were careful not to…  But few resist the temptation to offer an easy

solution:

Attacking Web Services Security

ToorCon Seattle ‘07

WS-Security (to the rescue)
 Integrity  Confidentiality

 Security tokens
 Other higher-level protocols frequently considered to

fall under this umbrella as well.

Attacking Web Services Security

ToorCon Seattle ‘07

WS-Actually Get Some Work Done

WS-Security
WS-Federation WS-Policy WS-SecureConversation

WS-Trust
WS-Security Policy XML Encryption SAML Kerberos X.509 Security Token Profiles

XML Digital Signatures
XML, SOAP, WSDL, Schema, WS-Addressing, etc. HTTP .Net TCP Channel, Fast InfoSet, etc.

Attacking Web Services Security

ToorCon Seattle ‘07

SSL is Everybody’s Whipping Boy
 Too old, boring and standard for marketers to sell.
 WS-Security has dozens of new boxes to check.

 Even the smart bloggers and pundits are hatin’
 Ian Grigg (financialcryptography.com)
 “The mantra of "you should use SSL" is just plain stupid.”

 Gunnar Peterson (1raindrop.typepad.com)
 “SSL is what is usually bandied about as a security model by

Restafarians”
 Arthur (emergentchaos.com)
 “least useful security technology since tinfoil underwear”

 And that’s all just in the first week of May, 2007.

Attacking Web Services Security

ToorCon Seattle ‘07

“Connection Oriented” is Old and Busted “Message Oriented” is the New Hotness

Attacking Web Services Security

ToorCon Seattle ‘07

I Respectfully Disagree
 SSL provides what is needed for most real world Web

Services deployments.
 WS-Security is too complex, too error prone and has

too much attack surface.
 A plea for security sanity and simplicity.

Attacking Web Services Security

ToorCon Seattle ‘07

Some terminology
 WSSE == WS-Security  When I say SSL, I mean SSLv3 and TLS
 10 years of habit. Everybody knows SSL.

TLS sounds like a cable TV network or a disease.  And I mean with client certificate auth.

Attacking Web Services Security

ToorCon Seattle ‘07

Reality of Secure Web Services
 Almost nobody is deploying them to public audiences.
 Almost nobody is deploying non-WSSE Web Services to

wide public audiences.

 Web SSO systems are the pseudo-exception  Many public users  Still only a handful of trusted WSSE-aware endpoints

Attacking Web Services Security

ToorCon Seattle ‘07

Where are they really?
 Used internally for SOA enterprise message buses.  And to expose a few B2B endpoints to a few trusted

customers.
 Standard interface, goes through firewalls.  B2B VPNs are too much of a hassle.

Attacking Web Services Security

ToorCon Seattle ‘07

Threat Realities
 Businesses place a lot of trust in their partners.  IT risk management is rolled up with other fraud,

errors and omissions and managed with contracts, audit and lawyers.
 Still need to build robust applications, but attacks at

the business logic layer (SQL injection, etc) are not the biggest concern.

Attacking Web Services Security

ToorCon Seattle ‘07

Exclude the Anonymous Attacker
 The biggest threat for Web Service endpoints

exposed to the public Internet is the anonymous attacker.
 The security technology you want should

authenticate your genuine users and exclude everyone else as thoroughly and efficiently as possible.

Attacking Web Services Security

ToorCon Seattle ‘07

Why message oriented security sucks.

Attacking Web Services Security

ToorCon Seattle ‘07

Reason 1: Attack Surface
 To make a security decision about a

message, you need to have a message!
 Getting a message is not free.
 Getting a WS-* message is super extra

not free.

Attacking Web Services Security

ToorCon Seattle ‘07

WS-Actually Get Some Work Done

WS-Security
WS-Federation WS-Policy WS-SecureConversation

WS-Trust
WS-Security Policy XML Encryption SAML Kerberos X.509 Security Token Profiles

XML Digital Signatures
XML, SOAP, WSDL, Schema, WS-Addressing, etc. HTTP SSL .Net TCP Channel, Fast InfoSet, etc.

Attacking Web Services Security

ToorCon Seattle ‘07

SSL Anonymous Attack Surface

SSL

Attacking Web Services Security

ToorCon Seattle ‘07

WS-Security Anon Attack Surface
WS-Security
WS-Federation
WS-Policy WS-Trust WS-Security Policy

WS-SecureConversation

XML Encryption

SAML

Kerberos

X.509

Security Token Profiles

XML Digital Signatures

XML, SOAP, WSDL, Schema, WS-Addressing, etc.
HTTP .Net TCP Channel, Fast InfoSet, etc.

Attacking Web Services Security

ToorCon Seattle ‘07

WS-Security Anon Attack Surface
WS-Security

XML Encryption

SAML

Kerberos

X.509

Security Token Profiles

XML Digital Signatures

XML, SOAP, WSDL, Schema, WS-Addressing, etc.
HTTP .Net TCP Channel, Fast InfoSet, etc.

Attacking Web Services Security

ToorCon Seattle ‘07

A Target-Rich Environment.
 Protocol handlers  XML parsers  Remote references  URI endpoint  SOAP Action Header

Attacking Web Services Security

ToorCon Seattle ‘07

App-level attacks, coming soon to a messaging security layer near you!

Attacking Web Services Security

ToorCon Seattle ‘07

Worse than it even appears.
 I went bug hunting.  Detailed design review and survey of the literature

for XML Digital Signatures and XML Encryption.
 The “XML, etc.” layer is bigger than you suspect.
 Canonicalization, XPath, XPath Filter 2.0, XPointer,

XSLT, remote references…

Attacking Web Services Security

ToorCon Seattle ‘07

New classes of attack against WSSE
 Element wrapping attacks
 Move content around or substitute content in a

signature.  Michael McIntosh & Paul Austel of IBM Research
 Many trivial denial of service risks.  These are big specs with a lot of complexity.

Attacking Web Services Security

ToorCon Seattle ‘07

Get totally owned.
 I found design flaws in the WSSE base technologies

enabling arbitrary, remote, anonymous code execution.
 Found a way to write a cross-platform worm in XML

as a Digital Signature!
 Works on multiple vendor implementations.  Come see the gory details at BlackHat.

Attacking Web Services Security

ToorCon Seattle ‘07

SSL with client certificates keeps attackers out of your message stack.
 Widely deployed  Widely reviewed

 Mature and stable
 All the attacker gets to play with is the SSL

implementation itself

Attacking Web Services Security

ToorCon Seattle ‘07

Message Oriented Security Sucks:
Reason 2

Attacking Web Services Security

ToorCon Seattle ‘07

Your application isn’t really message oriented!
 People have deep and unexamined expectations that:
 Messages will arrive in order  Messages arrive in a timely manner  Messages will not be replayed  Messages will not be dropped

 Stateful at “Layer 8”, even if individual service

invocations/messages are stateless.

Attacking Web Services Security

ToorCon Seattle ‘07

Thought experiment
 Cell phone SMS is as “message oriented” as it gets.  You and two friends are trying to arrange to meet for

happy hour via SMS.
 I can reorder, delay, drop and replay your messages.
 Good luck!

Attacking Web Services Security

ToorCon Seattle ‘07

Some solutions to this. . .
 But not always interoperable, or still in committee.  You have to realize you need a solution, and learn

how to apply an appropriate one.
 It’s mostly free in SSL.
 You’re leaving money on the table when you walk

away from security guarantees you can get for free.

Attacking Web Services Security

ToorCon Seattle ‘07

Transport layer security is proven for message oriented protocols
 Works for RPC just fine.  Just need to bootstrap and audit with real mutual

authentication.
 Readjust what the security and trust boundaries of

your system are to deal with a distributed world.

Attacking Web Services Security

ToorCon Seattle ‘07

Message Oriented Security (and specifically WS-Security) Sucks: Reason 3

Attacking Web Services Security

ToorCon Seattle ‘07

Tight Coupling of Security and Application Layers
 Extremely complex rules about what parts are signed

and what aren’t:
 XPath  XPath Filter 2.0

 XPointer
 XSLT

 Meta-similar to Newsham & Ptacek’s work on IDS

evasion via fragementation.  Plus TOC/TOU with remote references.

Attacking Web Services Security

ToorCon Seattle ‘07

This sucks.
 Signature or nearly equivalent processing has to

happen very close to the application’s use of the data.
 You are very tightly coupled to the programming

model of your security toolkit.
 If it ever did before, that $80,000 XML Security

Gateway doesn’t look so great anymore.

Attacking Web Services Security

All this stuff was added to support gateways and active proxies

ToorCon Seattle ‘07

 Complex identification of content to be signed  And content NOT to be signed  What does the gateway pass down?  If it’s supposed to be offloading the work from the

consumer, how does it indicate what is trustworthy and not?

Attacking Web Services Security

ToorCon Seattle ‘07

Message Oriented Security (and specifically WS-Security) Sucks: Reason 4

Attacking Web Services Security

ToorCon Seattle ‘07

Kc

A

Mp1 Mp2
Sign KA

C

Mp3 Mp1 M p2 M
Sign KA Sign KC Encrypt KB

HTTP HTTPS JMS TCP

B

• Durable security • Selective security • Mixed key/token types • Mixed key exchange

• Intermediate actors • Composable assertions • Transport agnostic

D
KB

Attacking Web Services Security

ToorCon Seattle ‘07

Complexity, Complexity, Complexity
 In addition to replay, reorder and drop protection, other things

you get for free in SSL and not in WS-Security:
 Forward secrecy.  No naïve sign and encrypt flaws. In WSSE, do you encrypt then

sign? Sign then encrypt? Sign, encrypt, sign?
 Don Davis’s “Defective Sign & Encrypt” paper

 What kind of token type?

 What do all these options & policies mean?

Attacking Web Services Security

ToorCon Seattle ‘07

Even the standards need standards.
 So complicated that the WS-I needed to be created.  Even WS-I is considered dead in the water at this

point by most.
 WS-Trust has the word SHOULD over forty times in

the spec. FOR A SECURITY TECHNOLOGY!!!

Attacking Web Services Security

ToorCon Seattle ‘07

WSSE is not “ready to use”
 It is a security protocol construction kit.  The average developer is every bit as

unqualified to create their own security protocol as they are to create their own encryption algorithm.
 They don’t even know they’re writing a new

protocol every time they set a policy.

Attacking Web Services Security

ToorCon Seattle ‘07

Even experts get it wrong all the time.
 Literature is littered with the corpses of

broken protocols.
 Subtle distinctions between properties of

symmetric vs. asymmetric algorithms.
 Naïve sign and encrypt flaw in Kerberos V

PKINIT found in 2005 (Scedrov, et al.)
 You don’t just need crypto experts, you need

enough for a red team.

Attacking Web Services Security

ToorCon Seattle ‘07

Example:
 A tale of two services.  A synchronous service with privacy, integrity and

mutual auth requirements and large bi-directional data flows.
 An asynchronous service with integrity but no privacy

requirement.

Attacking Web Services Security

ToorCon Seattle ‘07

Service A
 Kerberos token + SSL (no client auth)

SSL Channel

A

Kerberos Message AP_REQ

Client

Attacking Web Services Security

ToorCon Seattle ‘07

Service B
 Kerberos token + XML Digital Signature

Plaintext Channel

B

Kerberos Message AP_REQ
Signed KKerb

Client

Attacking Web Services Security

Both on same server…
SSL Channel

ToorCon Seattle ‘07

A

Evil Message

Kerberos AP_REQ

B

1. Attacker blocks delivery of message to Service B, foiling the replay cache, and strips the Kerberos AP_REQ.

A T T A C K E R

2. Attacker makes an SSL connection (no client auth) and replays AP_REQ with bearer semantics and a new message of its choosing.

Plaintext Channel

Message

Kerberos AP_REQ

Client

Signed KKerb

Attacking Web Services Security

ToorCon Seattle ‘07

Works with SAML, too.
 And that’s just one example.
 WS-* repurpose of work by Kasslin & Tikkanen

 Building policies == building protocols

 When artifacts are valid across multiple contexts it

gets complicated.
 Public key, message oriented systems are much more

subtle in their properties than a secure channel.

Attacking Web Services Security

ToorCon Seattle ‘07

SSL gives you strong guarantees, for free
 Remove the weakness (and the

cost!) of the analysis and policy decisions.

Attacking Web Services Security

ToorCon Seattle ‘07

Why SSL doesn’t suck.

Attacking Web Services Security

ToorCon Seattle ‘07

“SSL won’t work for our message oriented awesomeness!”
 Yes, it will. In almost every case. XML security

gateways? They use a classic ‘façade’ design pattern and add SSL for inter-enterprise connections.
 SAML and WS-Federation are the only major

exceptions where you have messages that need more than point-to-point security.
 Note that these protocols recommend using SSL for

every leg, in addition to XMLDSIGs, due to known attacks. (Birgit Pfizmann & Thomas Groβ)

Attacking Web Services Security

ToorCon Seattle ‘07

“Client certs are hard to manage!”
 But not for B2B endpoints.
 Small numbers.  Programmatic clients.

 Under change control at the client end.

Attacking Web Services Security

ToorCon Seattle ‘07

“Certificate authorities are bad!”
 Yeah, sure whatever.  Add your trusted keys as implicit roots of trust.
 You probably have to do this with WSSE, anyway.

 Cut out the middleman.
 Again, almost nobody has more than a few dozen

authorized clients anyway.

Attacking Web Services Security

ToorCon Seattle ‘07

“Phishing, broken trust model, etc.”
 Are not an issue for programmatic

endpoints.

Attacking Web Services Security

ToorCon Seattle ‘07

“SSL is too heavyweight”
 HAHAHAHAHAHAHAHAHAHAHAHAHA!!!!

 Published benchmarks show WS-Security cuts

throughput by a factor of between 5 and 50 compared to SSL.
 And there are lots of cheap and effective SSL

accelerator products.
 WSSE performance problem is XML mangling. Some

appliances, but more expensive than SSL.

Attacking Web Services Security

ToorCon Seattle ‘07

“SSL terminated at corpnet edge”
 No good reason for that with programmatic Web Services.

 Mostly done to manage cost & maintenance of browser-

targeted, CA-issued server certificates.
 Programmatic endpoints can directly trust your certificate, so

much less need for this bad habit.
 Again, reconsider the boundary of the system for a distributed

world. It’s not a hardware box or process, it’s a trust boundary or an attack surface.

Attacking Web Services Security

ToorCon Seattle ‘07

Four Simple Principles For Web Services Security Sanity

Attacking Web Services Security

ToorCon Seattle ‘07

1.Encrypt by default

2.Prefer SSL with client auth 3.Infer keys from context
4.Scope policy with artifacts

Attacking Web Services Security

ToorCon Seattle ‘07

1 . Encrypt by default
 Quoting IanG again:
 “To remove the weakness of the

decision”

Attacking Web Services Security

ToorCon Seattle ‘07

2. Prefer SSL with client auth
 Has been the major subject of

this talk.

Attacking Web Services Security

ToorCon Seattle ‘07

3. Infer keys from context
 Key resolution from WS-Security or X.509 PKI is attack

surface.
 If you don’t need it, you don’t want it.

 Manage your trusted keys yourself, and retrieve them

by thumbprint until logistics dictate you must do otherwise.

Attacking Web Services Security

ToorCon Seattle ‘07

4. Scope policy with artifacts
 Recall our tale of two services.

 You have to make some of these decisions, and even

if you’re qualified, maybe you don’t have the time.
 Consider the scope of an authentication artifact to be

the boundary of a virtual “protocol”
 Keep your protocols simple – have one policy like “all

operations authorized by artifact X must enforce encryption and signing”

Attacking Web Services Security

ToorCon Seattle ‘07

Use WS-Security where you need it.
 But first think hard if it’s really adding security or just

attack surface and complexity.
 Layering signatures on top of SSL with client auth can

give you message-oriented security on top of strong protection against anonymous attackers.
 But publicly facing interfaces secured with only WS-

Security can be incredibly dangerous.
 And if you have homemade SAML consumers, better

come see me at BlackHat.

Attacking Web Services Security

ToorCon Seattle ‘07

Thank you!

Questions?

Brad Hill brad@isecpartners.com


				
DOCUMENT INFO