1

Securing Multiparty Online Services via Certification of

Symbolic Transactions

Eric Chen (Carnegie Mellon University)

Shuo Chen, Shaz Qadeer, Rui Wang (Microsoft Research)

2

Multiparty online services

shopper

PayPal.com (cashier)

Buy.com (merchant)

user

Facebook.com (identity provider)

foo.com (relying party)

user

login.facebook.com

bar.com

graph.facebook.com

Third-party payment Single sign-on

Authorization

3

Unfortunately, …

• Plenty of logic flaws discovered

• The No.4 cloud computing top threat

• According to the Cloud Security Alliance

• Serious consequences

• purchase without making payment

• log into other people’s accounts

• obtain unintended authorizations

• …

4

Program verification needed!

• Program verification

• For many years, researchers have been advocating for it

• Rarely put in practice by real developers

• Several practical hurdles

• Our work – Certification of Symbolic Transaction (CST)

• Significantly lowers the hurdles.

5

Platform (modeled)

Why is verification hard in reality?

Platform (modeled)

Public metho

dsb.com source code

a.com source code

c.com source code

a.com specb.com

specc.com spec

Protocol

doc that

describes X

A multiparty system based on protocol X

Attacker (modeled

) top

-level

infin

ite loop

Written in English.

Developers: Does every possible transaction satisfy safety property in

spec?

Verifier (e.g., theorem prover or model checker)

Platform (modeled)

6

cvPlatform (actual)

cv cv

Certification of Symbolic Transaction (CST)

b.com source code

a.com source code

c.com source code

A system-wide multiparty property,

independent of specific protocols

Actual user/attacke

r

Certifier

Platform (actual)

Platform (actual) Does this

transaction satisfy the system-wide

property?

A toy example

b.com source code

a.com source code

c.com source code

(C == true) iff (i. B[i] ==

A)

bool C

int array B[ ]

secret int A

Ambient predicate

• Ambient predicate cannot be concretely checked

• c.com has no access to concrete values of A[ ] and B

• CST’s approach -- to collect source code to symbolically check ambient predicate

8

A real example:Third-party payment

9

Protocol flow and safety property

cashier merchantclient

PlaceOrder_req

PlaceOrder()PlaceOrder_resp

Pay_reqPay()Pay_resp

CompleteOrder_reqCompleteOrder ()CompleteOrder_resp:

accept/reject

payments[ ]

Data: Data:

orders[ ]mySellerI

D

i. ( cashier.payments[i].status == “Paid” && cashier.payments[i].total ==merchant.orders[completeOrder_req.orderID].gross && cashier.payments[i].payee == merchant.mySellerID &&

cashier.payments[i].orderID == completeOrder_req.orderID )

• Regardless of specific protocols, this property must hold:

• “The order to be checked out on the merchant is paid on the cashier”. Ambient predicate

10

A traditional implementation (without CST)

• NopCommerce integrating Amazon Payment

Amazon TStore.com (running

NopCommerce)

clientPlaceOrder_req<orderID

=123>PlaceOrder()

Pay_req<orderID=123,total=35,returnURL=https://TStore.com/completeOrder.aspx> Pay()CompleteOrder_req<orderID=123,status=Paid>

CompleteOrder ()CompleteOrder_resp: accept/reject

TStore

Amazon

• The implementation is vulnerable• Allows an attacker (Mark) to pay to his own store (MarkStore.com),

but check out an order from TStore.com (details in the paper).

• Every party performs some local checks, but the ambient predicate is not explicitly checked!

11

The implementation enhanced by CST

Note: #PlaceOrder, #Pay and #CompleteOrder are the SHA1 hash values of the source code of PlaceOrder(), Pay() and CompleteOrder().

Amazon TStore.com (running

NopCommerce)

client PlaceOrder_req<orderID=123,

SymT= >PlaceOrder()

Pay_req<orderID=123,total=35,returnURL=https://TStore.com/

completeOrder.aspx, SymT= >Pay()

CompleteOrder_req<orderID=123,status=Paid, SymT= >

CompleteOrder ()

TStore

Amazon

Final SymT=

SymT = SymT =TStore.com::#PlaceOrder()SymT =Amazon.com::#pay(TStore.com::#PlaceOrder())Final SymT=TStore.com:#CompleteOrder(Amazon.com::#pay(TStore.com::#PlaceOrder()))

12

The certifier’s job

Assume {TStore.com, Amazon.com} are the only trusted parties;

Prove the following theorem:

TStore.com:#CompleteOrder(Amazon.com::#pay(TStore.com::#PlaceOrder()))

i. ( cashier.payments[i].status == “Paid” && cashier.payments[i].total ==merchant.orders[completeOrder_req.orderID].gross && cashier.payments[i].payee == merchant.mySellerID &&

cashier.payments[i].orderID == completeOrder_req.orderID )

13

The certifier

Program synthesizer:1. Discard untrusted steps2. Stitch together trusted

steps3. Assert the ambient

predicate

de-hash table

Transaction

accepted.Off-the-shelf C# program

verifier

cache

Result:Verified.

miss

hit

{TStore.com, Amazon.com}

TStore.com:#CompleteOrder( Amazon.com::#pay( TStore.com:#PlaceOrder( )) i. ( blah blah … blah blah … )

R1=PlaceOrder(arbitrary);R2=Pay(R1);R3=CompleteOrder(R2);Assert( i. ( blah blah … blah blah … ));

14

If the attack is launched …

Program synthesizer:1. Discard untrusted steps2. Stitch together trusted

steps3. Assert the ambient

predicate

de-hash table

Transaction

rejected.Off-the-shelf C# program

verifier

cache

Result:Not

verified.

miss

hit

//PlaceOrder is discardedR1=Pay(arbitrary);R2=CompleteOrder(R1);Assert( i. ( blah blah … blah blah … ));

{TStore.com, Amazon.com}

TStore.com:#CompleteOrder( Amazon.com::#pay( MarkStore.com::#PlaceOrder() )) i. ( blah blah … blah blah … )

15

Applying CST in the real world

16

Applying CST on open-source ASP.NET solutions

• 3rd-party payment:

Standard

• CST’s project page• http://research.microsoft.com/en-us/projects/CST/

• Single sign on:in

OAuth 2.0

in

SDK

• A gambling scenario integrating four services

Coin tosser

cashierGambling site

Game token manager

17

Evaluation

• Lines of code (LoC):

• In every project, the LoC of added and changed code for each party < 200.

• Performance

• Near-zero amortized runtime overhead, thanks to caching.

• Security

• Analyzed cases: unbiasedly selected 14 vulnerabilities.

• 12 of them are logic flaws that CST is able to prevent.

• Two of them are not addressed by CST

• A signature validation flaw

• A client-side same-origin access violation.

• Protocol independence

• We come up with several implementations obviously violating OAuth 2.0, but CST makes sure that they all do “authentication” right!

18

Do I have to precisely understand OAuth 2.0 to be secure?

Identity Provider

Relying Party

client auth_req

<sessionID, AppID, redirect_uri>

auth_resp < code > signIn_req <

code > token_req <code, AppID, AppSecret, redirect_uri>Check AppID,

AppSecret, redirect_uri token_resp

<token>me_req <token>

me_resp <user_ID, …>

accept user_ID

• Question 1: is AppSecret needed for authentication?

• Question 2: can we use “token” for authentication?

• Question 3: what if identity provider doesn’t check AppID and return_uri for the token?

token

token

,

AppID,redirect_ur

i>,

AppID,redirect_uri>

Check AppID and

redirect_uri, then

• Difficult to understand exactly “which party should do what, and why” about a complex protocol.

• Much better to just verify that all parties collaboratively satisfy a system-wide property.

19

Conclusions

Visit: http://research.microsoft.com/en-us/projects/CST/

• CST sits on the middle-ground between static verification and runtime checking

offline, symbolic

Static verification

runtime, concrete

Runtime checkingruntime, symbolic

CST

• CST reduces burdens for developers to do verification• Able to verify a system-wide multiparty property

• Reduces the burden of modeling attacker and platform.

• The proof obligation is greatly reduced

• Not to prove safety for “all possible transactions” , but only the transaction that occurs at the moment.

20

Backup slides

21

The verifier and the cache

• The program verifier

ASP.NET C#

Visual Studio C# compiler

ByteCode

Translator (BCT)

Corral

.NET Byte Code

BoogieCode

Verifi

ed

Not verified• Caching is important.

• Synthesis and verification take 10-30 seconds

• Fortunately, SymT is symbolic.

•Caching is therefore effective.

• The cache is shared across all transactions of all users

22

Performance

  Per-transaction cost

One-time cost

Per-transaction runtime overhead

Program synthesis using a local de-

hash server

compilation, byte-code translation and

verification

Live Connect SDK 0ms 3ms 18 sec

OpenID 2.0 on DotNetOpenAuth 0ms 5ms 15 sec

Facebook SSO using ASP.NET MVC 4

0ms 5ms 12 sec

NopCommerce with Amazon Simple Pay

0ms 2ms 15 sec

NopCommerce with PayPal Standard

0ms 8ms 10 sec

Coin tossing gambling 0ms 3ms 32 sec