1. Cassis, March 8 th 2005 Formal Tools for Web Services Security Cédric Fournet Microsoft Research, Cambridge joint work with Karthik Bhargavan, Andy Gordon, Greg OShea, 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-based crypto 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. Whats a Web Service? A web service is a web site intended for use by computer programs instead of human beings. (Barclay et al) So XML not HTML Service messages in SOAP format: Envelope/Header – addressing, security, and transactional headers Envelope/Body – actual payload Service metadata in WSDL format: For each SOAP endpoint, list of operations For each operation, request and response types XMLRequest Client Server XMLResponse

4. A Sample SOAP Request <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 20 Says: get me status of order 20

5. A Sample SOAP Request 20 Says: get me status of order 20 XML not meant to be read by humans, so well omit namespace info, and trailing brackets…

6. Another SOAP Request http://bookshop/ws/OrderStatus http://www.bookshop.com/ws/orderstatus.asmx uuid:5ba86b04-3c0f-428b-8dd6-17804286fe40 20 Optional headers tell SOAP processors what to do with the envelope (automatically)

7. 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,…

8. Alice" "mTbzQM84RkFqza+lIes/xw==" "2004-09-01T13:31:50Z" "U9sBHidIkVvKA4vZo0gGKxMhA1g= "8/ohMBZ5JwzYyu+POU/v879R01s=" "FABRIKAM" "CONTOSO" Securing SOAP Messages UsernameToken assumes both parties know Alices secret password p Each DigestValue is a cryptographic hash of the URI target hmacsha1(key, SignedInfo) where key psha1(p+nonce+created) header defined by OASIS WS-Security 2004 includes identity tokens, signatures, encrypted message parts Dozens of implementations, including Microsoft Web Services Enhancements (WSE)

9. 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 deploy their 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 for security We have found a range of problems in sample code, thus motivating our research on theory and tools

10. An XML Rewriting Attack From: Alice To: Bookshop Action: Buy Charlies book (signed by Alice) Alices laptop Alices bookshop (Web Service) Someone on the net (Charlie?) Sent: Monday From: Alice To: Bank Action: Pay Charlie $20 (signed by Alice) Sent: Tuesday From: Alice To: Bank Action: Buy Charlies book (signed by Alice) Sent: Wednesday From: Alice To: Bookshop Action: Buy Charlies book (signed by Alice) Alter and replay envelopes to confuse participants

11. A Signed SOAP Message Before... Alice cGxr8w2AnBUzuhLzDYDoVw== 2003-02-04T16:49:45Z Ego0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= Bob 1000 Message to banks web service says: Transfer $1000 to Bob, signed Alice Bank can verify the signature has been computed using key derived from Alices secret password

12. and After an XML Rewriting Attack Alice cGxr8w2AnBUzuhLzDYDoVw== 2003-02-04T16:49:45Z Ego0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= Bob 1000 Charlie 5000 Although Alices password has not been broken, the message now reads Transfer $5000 to Charlie, signed Alice Charlie has intercepted and rewritten this message The indirect signature of the body, now hidden in BogusHeader, may still appear valid

13. A Long History of Attacks AB C We assume that an intruder can interpose a computer on all communication paths, and thus can alter or copy parts of messages, replay messages, or emit false material. While this may seem an extreme view, it is the only safe one when designing authentication protocols. Needham and Schroeder CACM (1978) 1978: N&S propose authentication protocols for large networks of computers 1981: Denning and Sacco find attack found on N&S symmetric key protocol 1983: Dolev and Yao first formalize secrecy properties wrt N&S threat model, using formal algebra 1987: Burrows, Abadi, Needham invent authentication logic; neither sound nor complete, but useful 1994: Hickman (Netscape) invents SSL; holes in v2, but v3 fixes these, very widely deployed 1994: Ylonen invents SSH; holes in first versions, now very widely deployed 1995: Abadi, Anderson, Needham, et al propose various informal robustness principles 1995: Lowe finds insider attack on N&S asymmetric protocol; rejuvenates interest in FMs circa 1999: Several FMs for D&Y problem: tradeoff between accuracy and approximation circa 2004: Many FMs now developed; several deliver both accuracy and automation

14. Pi Calculus & Cryptography Milner, Parrow, Walker (1989) Computation is name-passing between parallel processes on named channels. Each name has a mobile scope. Spi calculus: Pi + cryptographic operations (Abadi Gordon 1999) Mobile scopes can represent local 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 for various security properties

15. The Samoa Project, Briefly If misconfigured or mis-implemented, WS-Security protocols vulnerable to XML rewriting attacks TulaFale shows the absence of such attacks given a description of the protocol First analysis tool for XML-based crypto protocols Automatic analysis of hand-written models via applied pi calculus and Bruno Blanchets ProVerif tool Policy generator/analyzer produces TulaFale from 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 security errors found in reviews of sample policies

16. TulaFale: a language for WS-Sec OK, or No because… WSE 1.0 out of the box What TulaFale does CLR (IL) SOAP processing WSE 1.0 ProVerif Analyzer [B. Blanchet] TulaFale C# code TulaFale script predicate library intermediate pi-calculus We designed TulaFale, a programming language to model WSE protocols and hand-wrote models for a series of WSE protocols (POPL04, FMCO03) TulaFale = pi + XML + predicates + assertions

17. 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; but not confidentiality

18. Client(kr,U) Server(sx,cert,S) isMsg1(-,U,S,id1,t1,b1) isMsg2(-,S,id1,id2,t2,b2) begin C1 (U,S,id1,t1,b1) end C1 (U,S,id1,t1,b1) begin C2 (U,S,id1,t1,b1,id2,t2,b2) end C2 (U,S,id1,t1,b1,id2,t2,b2) An intended run of the protocol 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

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

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

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

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

23. TulaFale Demo Automatic verification of following reachability and safety properties via TulaFale/ProVerif

24. Opponent Client(kr,U) Server(sx,cert,S) isMsg1(-,U,S, id1,t1,b1) Suppose a client does not sign the message identifier id1... begin C1 (U,S,id1,t1,b1) end C1 (U,S,id1,t1,b1) id1:=id2, Replay isMsg1(-,U,S, id2,t1,b1) end C1 (U,S,id2,t1,b1) Copy 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

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

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

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

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

29. Discussion A first formal analysis of WS-Trust and WS-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

30. Policy-Based Security

31. 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 X509v3 S Body() UsernameToken U Body() Header("To") Header("MessageId)

32. Analyzing Policy Configurations Us pwd Vs pwd cert key Regular Web Service T Security Layer Us pwd cert Client App Security Layer User U Premium Web Service S Security Layer Web Server Vs pwd cert Client App Security Layer User V Policy3.xml Policy4.xml Policy1.xml Policy2.xml Automated tools for collecting, parsing policies from IIS Servers, Clients Config = [Policy1, Policy2, Policy3, Policy4]

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

34. Security for All Generated Configs? Theorem: All policy configurations generated from link specs enforce their security goals For all link specifications L, S(C(L),L) provides request & response authentication, correlation, and secrecy. Hence, at least generated configs can be safely deployed Proof: Non-obvious: there are infinitely-many link specs Use combination of automated proofs and manual reasoning Hint 1: Reduce to 4 base kinds of link-generated policies Hint 2: Prove that configs with all links enabled is secure (programmed unfoldings in the pi calculus)

35. 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 preserves secrecy of passwords and signing keys

36. Policy Advisor Demo

37. 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 model and 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 of security 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