1 / 31

DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security

DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security. Cédric Fournet Microsoft Research, Cambridge joint work with Karthik Bhargavan, Andy Gordon, Greg O’Shea, Riccardo Pucella, Ricardo Corin. MSRC Samoa: Details, papers, tools, pointers at http://Securing.WS.

eliot
Download Presentation

DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DIMACS workshop, May 5—6 2005Formal Tools for Web Services Security Cédric Fournet Microsoft Research, Cambridge joint work with Karthik Bhargavan, Andy Gordon, Greg O’Shea, Riccardo Pucella, Ricardo Corin MSRC Samoa: Details, papers, tools, pointers at http://Securing.WS

  2. Our starting point (2003) Two parallel trends over past five years: • Rapid invention and deployment of XML-basedcrypto protocols for securing web services • Flexible message formats for interop • Enables home-grown protocols • New crypto protocols are often wrong, XML or not • Sustained and successful effort to develop formalisms and tools to verify crypto protocols • (Dolev&Yao, BAN,) FDR, Athena, Isabelle, ProVerif, … • At MSRC: spi, sjoin, Cryptyc, applied pi calculus, … Timely opportunity to develop tools for validating standards-based XML crypto protocols

  3. Web Services Security • SOAP level security aims to provide end-to-end, compositional application-level security, independently of transport protocol • Fresh standards: • Security Roadmap • WS-Security, May 2004 (Draft: Apr 2002) • WS-Trust, WS-SecureConversation, WS-SecurityPolicy,… • A grammar for SOAP-based security protocols • Automated processing of security headers • Informal semantics except for XML syntax • Security tokens = wire format for claims and evidence • Keys, certificates, x509 signatures, Kerberos tickets,…

  4. Securing SOAP Messages UsernameToken assumes both parties know Alice’s secret password p <Envelope> <Header> <Security> <UsernameToken Id=1> <Username>“Alice" <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" <Signature> <SignedInfo> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#2> <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> <Body Id=2> <StockQuoteRequest> <symbols> <Symbol>"FABRIKAM" <Symbol>"CONTOSO" <Security> header defined by OASIS WS-Security 2004 includes identity tokens, signatures, encrypted message parts Each DigestValue is a cryptographic hash of the URI target Dozens of implementations, including Microsoft Web Services Enhancements (WSE) hmacsha1(key, SignedInfo) where keypsha1(p+nonce+created)

  5. Attacks on SOAP security • Web services vulnerable to same sorts of attacks as conventional websites • Buffer overruns, denial of service, SQL injection, etc • New concerns: flexible, XML-based protocols • Web services developers can design and deploytheir own application-specific security protocols • XML message format open to rewriting attacks • Much like classic active attackers (Needham-Schroeder ’78) • Opponent can redirect, replay, modify, impersonate • New: message processing is driven by a flexible,semi-structured message format • Flexibility is usually bad news for security • We have found a range of problems in specs & code,thus motivating our research on theory and tools

  6. A Signed SOAP Message Before... Message to bank’s web service says: “Transfer $1000 to Bob, signed Alice” <Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</> Bank can verify the signature has been computed using key derived from Alice’s secret password

  7. and After an XML Rewriting Attack Charlie has intercepted and rewritten this message <Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <BogusHeader> <Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</> <Body> <TransferFunds> <beneficiary>Charlie</> <amount>5000</> The indirect signature of the body, now hidden in BogusHeader, may still appear valid Although Alice’s password has not been broken, the message now reads “Transfer $5000 to Charlie, signed Alice”

  8. The Samoa Project: Tools • If misconfigured or mis-implemented, WS-Securityprotocols vulnerable to XML rewriting attacks • TulaFale — shows the absence of such attacksgiven a description of the protocol • First analysis tool for XML-based crypto protocols • Automatic analysis of hand-written models viaapplied pi calculus and Bruno Blanchet’s ProVerif tool • Policy generator/analyzer — produces TulaFalefrom declarative XML policy files that drive WSE 2.0 • Hence, can directly analyze WSE 2.0 configurations • First source-based formal verification of interoperable implementations of crypto protocols • Policy advisor — runs 35+ queries for securityerrors found in reviews of sample policies

  9. TulaFale

  10. TulaFale: a language for WS-Sec TulaFale = pi + XML + predicates + assertions We designed TulaFale, a programming language to model WSE protocols and hand-wrote models for a series of WSE protocols(POPL’04, FMCO’03) What TulaFale does TulaFale script predicatelibrary WSE 1.0out of the box TulaFale C# code intermediate pi-calculus WSE 1.0 CLR (IL) ProVerif Analyzer[B. Blanchet] OK, orNo because… SOAP processing

  11. Pi Calculus & Cryptography • Milner, Parrow, Walker (1989) • Computation is name-passingbetween parallel processes onnamed channels. Each namehas a mobile scope. • Spi calculus: Pi + cryptographicoperations (Abadi Gordon 1999) • Mobile scopes can representlocal keys and fresh nonces • Processes represent protocol configurations • Contexts represent active attackers • Applied Pi: Pi + equational theory (Abadi Fournet 2001) • There is a generally-useful theory (equivalences, proofs) • Using tools such as ProVerif (Blanchet 2001—), we can mix manual and automated proofs of various security properties

  12. Example: A Secure RPC • A typical system model: • A single certification authority (CA) issuing X.509 public-key certificates for services, signed with the CA's private key. • Two servers, each equipped with a public key certified by the CA and exporting an arbitrary number of web services • Multiple clients, acting on behalf of human users • Threat model: an active attacker, in control of network, but knowing none of: • The private key of the CA • The private key of any public key certified by the CA • The password of any user in the database • Security goals: authentication of each message;and correlation of request and response

  13. An intended run of the protocol Server(sx,cert,S) Client(kr,U) begin C1 (U,S,id1,t1,b1) isMsg1(-,U,S,id1,t1,b1) end C1 (U,S,id1,t1,b1) begin C2 (U,S,id1,t1,b1,id2,t2,b2) isMsg2(-,S,id1,id2,t2,b2) end C2 (U,S,id1,t1,b1,id2,t2,b2) Msg 1 includes signature of S,id1,t1,b1 under key derived from username token for U Msg 2 includes signature of id1,id2,t2,b2 under public key of S

  14. pi+XML+predicates+assertions TulaFale predicates defined by Horn clauses with message patterns For example, this predicate is usedin two ways, to construct and parse Message 1 TulaFale messages are terms in a many-sorted algebra with sorts:

  15. pi+XML+predicates+assertions TulaFale library includes predefined predicates for XML signatures and encryption For example, this predicate uses these predicates to check structure of Message 1

  16. pi+XML+predicates+assertions The implicit attacker, running in parallel, can: • Send and receive on the soap channel • Generate arbitrarily many users and services • Initiate arbitrarily many sessions

  17. pi+XML+predicates+assertions By sending a message on init, the attacker can pick any payload and destination Each begin-event marksthe intent to send a message Messages are exchanged on a public SOAP channel Each end-event marksthe intent to accept a message as valid

  18. Some Tulafale queries We also run basic reachability queries (sanity checks) We verify two correspondence properties from end-events to begin-event with matching contents (including both messages for C2)

  19. Suppose a client does not sign the message identifier id1... Opponent Server(sx,cert,S) Client(kr,U) begin C1 (U,S,id1,t1,b1) isMsg1(-,U,S, id1,t1,b1) Copy end C1 (U,S,id1,t1,b1) id1:=id2, Replay isMsg1(-,U,S, id2,t1,b1) end C1 (U,S,id2,t1,b1) Pair (id1,t1) uniquely identifies the message only if id1 and t1 are signed We found and fixed faults like this in preliminary WSE samples

  20. What else might go wrong? Opponent Server(sx,cert,S) Client(kr,U) isMsg1(-,U,S, id1,t1,b1) begin C2 (U,S,id1,t1,b1,id2,t2,b2) Call 1 isMsg2(-,S,id1, id2,t2,b2) SOAP Fault isMsg1(-,U,S, id1,t1’,b1’) Call 2, re-using id1 isMsg2(-,S,id1, id2,t2,b2) end C2 (U,S,id1,t1’,b1’,id2,t2,b2) If the client doesn’t generate fresh id1’s, then message correlation (C2) fails; the tool easily finds this bug

  21. Secure Conversations

  22. A TulaFale Summer Case Study • WS-Security provides basic mechanisms to secure SOAP traffic, one message at a time • Signing and encryption keys derived from long-lived secrets like passwords or private keys • If a SOAP interaction consists of multiple, related messages, WS-Security alone may be inefficient, and does not secure session integrity • Standard idea: establish short-lived session key • Recent specs describe this idea at the SOAP-level • WS-SecureConversation defines security contexts, used to secure sessions between two parties • WS-Trust defines how security contexts are issued and obtained

  23. A Typical System STS 1. RST Trust 2. RSTR Client SCs SCT SC Secure Conv 3. “Session Exchanges” Service … STS = Security Token Server RST = Request Security Token RSTR = RST Response SC = Security Context SCT = SC Token

  24. We prove authentication forwhole sessions We rely on some combination of manual and automated proofs Open-Ended Conversations Client Service get SC get SC begin Cn end Cn begin C’n end C’n for n¸ 0

  25. Discussion • A first formal analysis of WS-Trust andWS-SecureConversation • XML syntax and automation very effective,against a demanding, realistic attacker model • Approx 1000 lines of script – too large for manual proofs • As is common, these specs: • focus on message formats for interoperability • are non-committal regarding security,for example, no clear spec of contents of SCs • By making modes, data, and goals explicit, we found design and implementation bugs

  26. Policy-Based Security

  27. Security Policies • Clients, services use XML files to pick security mechanisms • Located in same IIS virtual directory • Describe protocols to use for different services • Simple declarative description of deployed protocols • No need to look at messy C# code • We analyze policy files collected from client and servers • Easy to get them wrong • Many policies are insecure • Combination of policies may have unexpected effects <Policy Id=“Msg1"> <All> <Confidentiality> <TokenInfo> <SecurityToken> <TokenType>X509v3</> <Claims><SubjectName>S</></> <MessageParts>Body()</> <Integrity> <TokenInfo> <SecurityToken> <TokenType>UsernameToken</> <Claims><SubjectName>U</></> <MessageParts>Body() Header("To") Header("MessageId”)</>

  28. Modelling Security Policies What our tools do spec L of a secure link In WSE 2.0, WS-SecurityPolicy files drive security; hence, we can generate TulaFale directly from implementation files(CCS’04) Generator C(-) Analyzer S(-,-) WSE 2.0out of the box Static warnings C# code policy config C(L) predicatelibrary TulaFale script S(C(L),L) WSE 2.0 TulaFale CLR (IL) ProVerif (pi calculus) SOAP processing OK, orNo because…

  29. Security for Any Client Policy? • Theorem: If a service uses a link-generated policy, then irrespective of the client policies, the resulting configuration preserves request authentication and response secrecy • Hence, naïve clients cannot break service authentication • Proof: • Combination of automated proofs and manual reasoning • Hint: Even the weakest send policy preservessecrecy of passwords and signing keys

  30. WSE2 Policy Advisor(demo)

  31. Summary • Web services security specs encourage extreme flexibility • Message formats, composable protocols, configurations • Specs and implementations are only just emerging • Attacks and proofs are subtle: tool support needed • We bridge the gap between theoretical pi threat modeland XML as used in WS security protocols • Put effort into real samples & implementations, found bugs • Obtained theorems about wire-level protocols • Exploited automation for authentication & secrecy properties • We develop tools for the automated analysis ofsecurity for deployed systems based on crypto protocols • Proving protocols secure in isolation is not enough • Our tools find attacks, verify configs, generate safe configs • Good place to develop formal tools, get positive results • Standard message formats, composition, wide applicability Details, papers, tools, pointers at http://Securing.WS

More Related