cassis, march 8 th 2005 formal tools for web services security cédric fournet microsoft research,...

Cassis, March 8th 2005

Formal Tools for Web Services Security

Cédric FournetMicrosoft 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

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

What’s 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

XMLXMLRequesReques

tt

Client

Server

XMLXMLResponsRespons

ee

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"> <soap:Body> <GetOrder xmlns="http://microsoft.com/petshop"> <OrderId>20</orderId> </GetOrder> </soap:Body> </soap:Envelope>

Says: “get me status of order 20”

A Sample SOAP Request

<Envelope> <Body> <GetOrder> <OrderId>20</>

Says: “get me status of order 20”

XML not meant to be read by humans, so we’ll omit namespace info, and trailing brackets…

Another SOAP Request

<Envelope> <Header> <Action>http://bookshop/ws/OrderStatus</> <To>http://www.bookshop.com/ws/orderstatus.asmx</> <MessageId>uuid:5ba86b04-3c0f-428b-8dd6-17804286fe40</> <Body> <GetOrder> <OrderId>20</>

Optional headers tell SOAP processorswhat to do with the envelope (automatically)

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

<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"

Securing SOAP MessagesUsernameToken

assumes both parties know Alice’s secret

password p

Each DigestValue is a cryptographic

hash of the URI target

hmacsha1(key, SignedInfo) where

keypsha1(p+nonce+created)

<Security> header defined by OASIS

WS-Security 2004 includes identity tokens,

signatures, encrypted message

parts

Dozens of implementations,

including Microsoft Web

Services Enhancements

(WSE)

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

An XML Rewriting Attack

From: AliceFrom: AliceTo: BookshopTo: BookshopAction: “Buy Charlie’s book”Action: “Buy Charlie’s book”(signed by Alice)(signed by Alice)

Alice’s laptop

Alice’s bookshop(Web Service)

Someoneon the net(Charlie?)

Sent: MondaySent: MondayFrom: AliceFrom: AliceTo: BankTo: BankAction: “Pay Charlie $20”Action: “Pay Charlie $20”(signed by Alice)(signed by Alice)

Sent: TuesdaySent: TuesdayFrom: AliceFrom: AliceTo: BankTo: BankAction: “Buy Charlie’s book”Action: “Buy Charlie’s book”(signed by Alice)(signed by Alice)

Sent: WednesdaySent: WednesdayFrom: AliceFrom: AliceTo: BookshopTo: BookshopAction: “Buy Charlie’s book”Action: “Buy Charlie’s book”(signed by Alice)(signed by Alice)

Alter and replay envelopesto confuse participants

A Signed SOAP Message Before...

<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</>

Message to bank’s web service says: “Transfer $1000 to Bob, signed

Alice”

Bank can verify the signature has been computed using key derived from Alice’s

secret password

and After an XML Rewriting Attack

<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</>

Although Alice’s 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

A Long History of Attacks

A B

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 protocol1983: Dolev and Yao first formalize secrecy properties wrt N&S threat model, using formal algebra1987: Burrows, Abadi, Needham invent authentication logic; neither sound nor complete, but useful1994: Hickman (Netscape) invents SSL; holes in v2, but v3 fixes these, very widely deployed1994: Ylonen invents SSH; holes in first versions, now very widely deployed1995: Abadi, Anderson, Needham, et al propose various informal “robustness principles”1995: Lowe finds insider attack on N&S asymmetric protocol; rejuvenates interest in FMscirca 1999: Several FMs for “D&Y problem”: tradeoff between accuracy and approximationcirca 2004: Many FMs now developed; several deliver both accuracy and automation

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 for various security properties

The Samoa Project, Briefly If misconfigured or mis-implemented, WS-Security

protocols 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 via

applied 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

TulaFale: a language for WS-Sec

OK, orNo because…

WSE 1.0 out of the box

What TulaFale does

CLR(IL)

SOAP processin

g

WSE 1.0ProVerif Analyzer

[B. Blanchet]

TulaFaleC# code

TulaFalescript

predicatelibrary

intermediate pi-calculus

We designed TulaFale, a programming

language to model WSE protocols and hand-wrote models for a

series of WSE protocols(POPL’04, FMCO’03)

TulaFale = pi + XML + predicates + assertions

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

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

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


TulaFale library includes

predefined predicates for XML

signatures and encryption

For example, this predicate uses these predicates to check

structure of Message 1


The implicit attacker, running in parallel, can: Send and receive on the soap channel Generate arbitrarily many users and services Initiate arbitrarily many sessions


By sending a message on init, the attacker can

pick any payload and destination

Each end-event marksthe intent to accept a message as valid

Each begin-event marksthe intent to send a message

Messages are exchanged on a public SOAP channel

TulaFale Demo

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

OpponentClient(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)


id1:=id2, Replay isMsg1(-,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

OpponentClient(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 doesn’t generate fresh id1’s, then message correlation (C2) fails; the tool easily finds this bug

isMsg1(-,U,S, id1,t1,b1)

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?

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

A Typical System

Client

STS

Service

1. RST

2. RSTR

3. “Session Exchanges”

SCsSCT

…

SC

Trust

SecureConv

STS = Security Token Server

RST = Request Security Token

RSTR = RST Response

SC = Security Context

SCT = SC Token

Open-Ended Conversations

Client Service

begin Cn

end Cn

begin C’n

end C’n

getSC get

SC

for n ¸ 0

We prove authentication forwhole sessions

We rely on some combination of manual and automated proofs

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

Policy-Based Security

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”)</>

Analyzing Policy Configurations

U’s pwd V’s pwd’

certkey

RegularWeb Service

TSecurity

Layer

U’s pwdcert

Client App

SecurityLayer

User UPremium

Web ServiceS

SecurityLayer

Web Server

V’s pwdcert

Client App

SecurityLayer

User V

Policy3.xmlPolicy4.xml

Policy1.xml Policy2.xml

Automated tools for collecting, parsing policies from IIS Servers, ClientsConfig = [Policy1, Policy2, Policy3, Policy4]

Modelling Security Policies

OK, orNo because…

Static warning

s

WSE 2.0 out of the box

What our tools do

CLR(IL)

SOAP processin

g

ProVerif(pi calculus)

TulaFale

C# code TulaFale script S(C(L),L)

predicatelibrary

Analyzer S(-,-)

In WSE 2.0, WS-SecurityPolicy files drive security; hence, we can

generate TulaFale directly from implementation files

(CCS’04)Generator C(-)

policy configC(L)

spec L of asecure link

WSE 2.0

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)

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

Policy Advisor Demo

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 applicabilityDetails, papers, tools, pointers at http://Securing.WS

cassis, march 8 th 2005 formal tools for web services security cédric fournet microsoft research,...

Documents

security roadmap wssecurity

soap format

soap request http

xml syntax security

soap endpoint

soap processors

crypto protocols dolevyao

sample soap request20