DIMACS workshop, May 5

1
DIMACS workshop, May 56 2005Formal 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-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
• (DolevYao, 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 Alices
secret password p
ltEnvelopegt ltHeadergt ltSecuritygt
ltUsernameToken Id1gt
ltUsernamegtAlice"
ltNoncegt"mTbzQM84RkFqzalIes/xw"
ltCreatedgt"2004-09-01T133150Z"
ltSignaturegt ltSignedInfogt
ltSignatureMethod Algorithmhmac-sha1gt
ltReference URI2gt
ltDigestValuegt"U9sBHidIkVvKA4vZo0gGKxMhA1g
ltSignatureValuegt"8/ohMBZ5JwzYyuPOU/v
879R01s" ltKeyInfogt
ltSecurityTokenReferencegt
ltReference URI1 ValueTypeUsernameTokengt
ltBody Id2gt ltStockQuoteRequestgt
ltsymbolsgt ltSymbolgt"FABRIKAM"
ltSymbolgt"CONTOSO"
ltSecuritygt 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(pnoncecreated)
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 banks web service says Transfer
1000 to Bob, signed Alice
ltEnvelopegt ltHeadergt ltSecuritygt
ltUsernameToken Id2gt
ltUsernamegtAlicelt/gt
ltNoncegtcGxr8w2AnBUzuhLzDYDoVwlt/gt
ltCreatedgt2003-02-04T164945Zlt/gt
ltSignaturegt ltSignedInfogt
ltReference URI 1gtltDigestValuegtEgo0...
lt/gt ltSignatureValuegtvSB9JU/Wr8ykpA
laxCx2KdvjZcclt/gt ltKeyInfogt
ltSecurityTokenReferencegtltReference
URI2/gt ltBody Id1gt ltTransferFundsgt
ltbeneficiarygtBoblt/gt
ltamountgt1000lt/gt
Bank can verify the signature has been computed
using key derived from Alices secret password
7
and After an XML Rewriting Attack
Charlie has intercepted and rewritten this message
ltEnvelopegt ltHeadergt ltSecuritygt
ltUsernameToken Id2gt
ltUsernamegtAlicelt/gt
ltNoncegtcGxr8w2AnBUzuhLzDYDoVwlt/gt
ltCreatedgt2003-02-04T164945Zlt/gt
ltSignaturegt ltSignedInfogt
ltReference URI 1gtltDigestValuegtEgo0...
lt/gt ltSignatureValuegtvSB9JU/Wr8ykpA
laxCx2KdvjZcclt/gt ltKeyInfogt
ltSecurityTokenReferencegtltReference
URI2/gt ltBogusHeadergt ltBody
Id1gt ltTransferFundsgt
ltbeneficiarygtBoblt/gt
ltamountgt1000lt/gt ltBodygt
ltTransferFundsgt ltbeneficiarygtCharlielt/
gt ltamountgt5000lt/gt
The indirect signature of the body, now hidden in
BogusHeader, may still appear valid
Although Alices 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 Blanchets
  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(POPL04, FMCO03)
What TulaFale does
TulaFale script
predicatelibrary
WSE 1.0 out of the box
TulaFale
C code
intermediate pi-calculus
WSE 1.0
CLR (IL)
ProVerif AnalyzerB. 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
  messageand 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
piXMLpredicatesassertions
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
piXMLpredicatesassertions
TulaFale library includes predefined predicates
for XML signatures and encryption
For example, this predicate uses these predicates
to check structure of Message 1
16
piXMLpredicatesassertions

• 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
piXMLpredicatesassertions
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)
id1id2, 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 doesnt generate fresh id1s, 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
Open-Ended Conversations

• We prove authentication forwhole sessions
• We rely on some combination of manual and
  automated proofs

Client
Service
get SC
get SC
begin Cn
end Cn
begin Cn
end Cn
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

ltPolicy IdMsg1"gt ltAllgt
ltConfidentialitygt ltTokenInfogt
ltSecurityTokengt
ltTokenTypegtX509v3lt/gt
ltClaimsgtltSubjectNamegtSlt/gtlt/gt
ltMessagePartsgtBody()lt/gt ltIntegritygt
ltTokenInfogt ltSecurityTokengt
ltTokenTypegtUsernameTokenlt/gt
ltClaimsgtltSubjectNamegtUlt/gtlt/gt
ltMessagePartsgtBody() Header("To")
Header("MessageId)lt/gt
28
Modelling Security Policies
What our tools do
In WSE 2.0, WS-SecurityPolicy files drive
security hence, we can generate TulaFale
directly from implementation files(CCS04)
spec L of a secure link
Generator C(-)
Analyzer S(-,-)
WSE 2.0 out 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)
OK, orNo because
SOAP processing
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