Shuo Chen (MSR)
Joint work with
Rui Wang, Kehuan Zhang, XiaoFeng Wang (Indiana Univ.), Shaz Qadeer (MSR)
A multi-component system across the Internet
Security/privacy implications not fully recognized by web developers
…
Desktop app: everything
Simple
SaaS app:
on one
machine
client and server
Typical SaaS app today:
client and multiple services
across trust boundaries
How to Shop for Free Online – Security Analysis
of Cashier-as-a-Service Based Web Stores
To appear in Oakland’11
Some interesting items that we bought from web stores
Breath alcohol
tester from
Buy.com
Charger
from
Buy.com
DVD from
Agility cream
GoodEmotionsDVD from Pride
Nutrition
Journal (digital
copy) from
LinuxJournalStore
Didn’t pay, or only paid the prices that we set arbitrarily
Because of logic bugs in checkout mechanisms
APIs as web services
An important ingredient in the concept of software-as-aservice
e.g., Bing Search APIs, Google Map APIs, Facebook APIs, PayPal APIs
Intuition: security for multi-party web apps can be very
challenging
Need to show a significant empirical evidence
Mom,
can I do X?
Sounds reasonable,
but ask Dad to call me.
Mom
I think it is
fine.
Naughty
kid
Sounds like a wacky
idea. I am not sure.
What do you think?
Dad,
Mom is ok about
X’, can you call
her?
Dad
OK.
3rd-party cashiers
e.g., PayPal, Amazon Payments, Google Checkout
We call them CaaS (Cashier-as-a-Service)
A decision to be made jointly
The merchant handles the order
The CaaS handles the payment
Decision: has the shopper properly made the
payment for the order?
Buy.com
RT1.a
RT1.b
Thank you for your order!
Please
confirm:
RT4.a
Your
order
#12345 will be shipped.
shipping address:
RT4.b
Viewxxxxxxxxxxxxxxxxxxx
the order
Shopper
billing address: T
Why do you
RT3.a.a RT3.a.b
T
xxxxxxxxxxxxxxxxxx
think that I
RT2.a
total amount:
have to run a
$39.54
browser? RT2.b
This is just one example. Pay Now
RT3.a
• There are many payment methods, such as
PayPal Standard, PayPal Express, Amazon Simple
RT3.b
Pay, Checkout By Amazon, Google Checkout.
PayPal
• Even for one payment method, each merchant
(CaaS)
application integrates it in a different way.
RT: HTTP round-trip
: Web API
The most popular .NET based open-source merchant app
The most popular commercial merchant app
Used by 15000+ businesses across 65 countries
Interspire’s own hosting service
A store for consumer electronics
12 million shoppers
Logic flaws in 9 checkout scenarios
Explained in this talk
scenario
description
NopCommerce with PayPal standard
Pay arbitrary amount to check out
NopCommerce with Amazon Simple Pay
Pay to the shopper himself, but check out from the victim
store.
Interspire with Amazon Simple Pay
No need to pay
Interspire with PayPal Express
Pay for a low-price order, check out a high-price one.
Interspire with PayPal Standard
Pay for an order, check out an arbitrary number of orders of
the same price.
Interspire with Google Checkout
Pay for only the least expensive item in the cart
JR.com with Checkout-By-Amazon
Pay arbitrary amount to check out
Buy.com with PayPal Express
Pay for an order, check out an arbitrary number of orders.
Amazon Payments SDK
No need to pay
Note:
1. only high-level summaries in this talk;
2. Subtleties in the source code are critical, but skipped;
3. Please read the paper for the whole stories.
.
pay in Amazon
RT1.a:Chuck,
TStore.com/placeOrder
with this signed letter:
Amazon,
I want to pay
RT1.b: redir to
T*
Dearletter
Amazon,
with this
(CaaS.com/pay?orderID&gross&returnURL
…)
Great,
I will
ship
order#123
Tis $10, whenCit
Dear
Amazon,
RT3.a:
?payeeEmail
&
TStore.com
is(returnURL
paid,
call me
at 425-111Jeff,
order#123!
C
T
T
C*
order#123
is [Jeff’s
$10, when
it …)
(T)
status
&gross
2222.
signature]
I want
to=PAID&ordereID
buy
this
is paid, call me at 425-111DVD.
Jeff
RT3.b:[Jeff’s
Purchase
done
2222.
signature]
T*
RT2.a: (CaaS.com/pay?orderID&gross&returnURL …)
Hi,
T
C
RT2.b: redir to (returnURL ?payeeEmail &
C $10 has been paid
T for T C*
status =PAID&ordereID
order#123.&gross …)
CaaS.com (C)
i.e., Amazon
payeeEmail=
a@b.com
TStore.com/placeOrder:
orderID=InsertPendingOrder
()
[Amazon’s signature]
TStore.com/finishOrder (handler of RT3.a):
if (verifySignature(RT3.a) ≠ CaaS) exit;
Shopper Chuck
if (GetMsgField(“status”) ≠ PAID) exit; /*payment status*/
order= GetOrderByID(ordereID);
if (order==NULL or order.status ≠ PENDING) exit;
Amazon
order.status=PAID;
Note: the phone number is analogous to the returnURL field in Amazon Simple Pay
Anyone can register an Amazon
seller account, so can Chuck.
We purchased a $25 MasterCard
gift card by cash;
We registered it under the name
“Mark Smith” with fake
address/phone number.
Registered seller accounts in
PayPal, Amazon and Google using
the card.
Chuck’s trick
Mark, pay in Amazon
with this signed letter:
Amazon,Dear
I want
to pay
Amazon,
order#123
is letter
$10,
with this
Great,
I will
shipwhen it is
Dear
Amazon,
paid,
call
me at 425-111-
Jeff,order#123!
order#123
is $10,
when it is
2222.
I wantpaid,
to buy
this
call[Jeff’s
me atsignature]
425-111DVD.
2222. [Jeff’s signature]
Jeff
[Mark’s signature]
Hi,
$10 has been paid for
order#123.
payeeEmail= a@b.com
[Amazon’s signature]
Shopper Chuck
(and seller Mark)
Pay to Mark, but check out from Jeff.
Amazon thought that Chuck was buying from Mark
Jeff thought that Chuck was paying to Jeff
Amazon
TStore.com
(T)
RT1.a: TStore.com/placeOrder
C
RT1.b: redir to CaaS.com/pay?token
A
A
RT3.a: TStore.com/finishOrder?token &payerID
T*
RT3.b: redir to TStore.com/updateOrderStatus?orderID
T*
RT4.a: TStore.com/updateOrderStatus?orderID
RT4.b: Purchase done
A
RT2.a: CaaS.com/pay?token
RT2.b: redir to
C
C
TStore.com/finishOrder?token &payerID
CaaS.com
(C)
T
C
RT1.a.a: CaaS.com/SetExpCheckout?identity &…
T
C
RT1.a.b: token
T
C
RT3.a.a: CaaS.com/DoExpPay?identity &token &gross RT3.a.b: result
Session1: pay for a cheap order (orderID1)
in PayPal, but avoid the merchant from
updating it status to PAID
TStore.com
Session 2: place an expensive order
(orderID2) , but skip the payment step in
PayPal
TStore.com
RT3.b
RT3.b
RT4.a
(RT3.b) redir to
TStore.com/updateOrder?orderID1T*
(RT3.b) redir to
T*
orderID2T*
TStore.com/updateOrder?orderID2
(RT4.a) call TStore.com/updateOrder?orderID1T*
Expensive order2 is checked out from session 1
Attacker
(shopper and
Mark.com)
RT1.a: jeff.com/placeOrder
loop
Jeff.com
RT3.a: jeff.com/finishOrder
RT2’.a: replay the message
jeff.com/
handleIPN
mark.com/
handleIPN
RT2.a: paypal.com/stdPay?
orderID&gross&merchantID
&IPNHandler
PayPal.com
Normally, IPNHandler is
jeff.com/handleIPN
Attacker can set an
IPNHandler
mark.com/handleIPN
And let PayPal send the
payment notification to
Mark.
Use a loop to place and
check out many sameprice orders by replaying
the stolen message.
(A)
TStore.com (T)
RT1.a: TStore.com/updateCart
RT1.b
RT2.a: TStore.com/checkout
T*
RT2.b: redir to (CaaS.com/pay?sessionID&cart…)
T
RT3.a.a: (TStore.com/handleIPN ?
C
C
T
identity & status &sessionID &…)
RT3.a.b: OK
T*
RT3.a: (CaaS.com/pay?sessionID&cart…)
RT3.b: status=PAID
(C)
TStore.com/handleIPN:
1: if (GetMsgField(“status”) ≠ PAID) exit; /*payment status*/
2: cart = LoadShoppingCart(GetMessageField(“sessionID”));
3: order = CreateOrder(cart);
4: order.status=PAID;
The order is generated
based on the cart at the
payment time (RT3.a).
The payment amount is
calculated based on the
cart at the moment when
the shopper clicks
“checkout” (RT2.a).
Between RT2.a and RT3.a,
the shopper can add
more items to the cart.
Installed NopCommerce and Interspire on our own web server.
Constructed attacks against them.
Against our own store on BigCommerce.com -- Interspire’s
hosting service.
Against real stores powered by NopCommerce and Interspire.
Constructed similar attacks against web stores running closedsource software, e.g., Buy.com and JR.com.
Without source code access, some exploit ideas are still applicable.
Experiments were conducted under close guidance of
an Indiana University lawyer.
Obtained the support from Dean of School of
Informatics
Principles:
No intrusion
No eventual monetary damage to the stores
Communicated full details to all affected parties
Pleasant outcome
Nobody expressed any negative opinion on our tests.
Our responsible effort was appreciated by most of them.
Dear Buy.com customer service,
Dear buy.com customer service,
Last week I placed the two orders (Order Number: 54348156
I am
a Ph.D.Support
student doing
research on e-commerce security. I bumped
From:
Buy.Com
<customerhelp@noreply.buy.com>
Order number: 54348723) in buy.com. Both items were shipped
anJun
unexpected
issue in buy.com's mechanism for accepting
Date:into
Sun,
13, 2010technical
at 3:32 PM
recently, but I found that my paypal account has not been charged for
the paypal
payments.
I appreciate
if you
can forward this email to your
Subject:
Re: Other
questions
or comments
(KMM3534132I15977L0KM)
the order 54348723 (the alcohol tester).
engineering
team.
To: Test
Wang ruiwangworm@gmail.com
After card
our refund–eligible
we mailed
the products
My credit
information is: period,
[xxxxxxxxx]
The total
of the order
The
finding
is regarding
theBuy.com.
order 54348723. I placed the order in an
Thank
you
for
contacting
us
at
back by
a or
certified
mail.charge
We disclosed
technical
Re: Other
questions
comments
54348723
is $5.99.
Please
my credit
card. details to
unconventional manner (by reusing a previous paypal token), which
Buy.com
willthem.
onlytobill
yourout
credit card only when a product has been
(KMM3545639I15977L0KM)
allowed
check
Thankme
you very
much the product without paying. I have received the
shipped.
We in
authorize
onI your
asHere
soonisasmy
you
place
product
the <customerhelp@noreply.buy.com>
mail.payment
Of course
needcredit
to paycard
for it.
credit
card at
Buy.Com
Support
Wed, Jun
16, 2010
an order.
Once
an
item
has
shipped,
your
credit
card
is
billed
for
that
information [xxxxxxxxxxxx]. Please charge my card. The total on the
6:25 PM
item invoice
and for is
a $5.99.
portion of the shipping and/or tax charges (if
To:
Test Wang <ruiwangworm@gmail.com>
applicable).
Hello Test,
If there are items on "Back Order" status, your credit card is
Thank
you for contacting
us at Buy.com.
re-authorized
for the remaining
amount and all previous authorizations
Based
on our records
youreason
were billed
on 6/10/2010
for $5.99.
Tofor
confirm
are removed.
This is the
you may
have multiple
billings
your
order.
your
billing information please contact PayPal at
https://www.paypal.com/helpcenter
or at 1-402-935-2050.
…
Amazon SDK vulnerability
15 days after our reporting, they released a new set of SDKs for all supported
languages and a security advisory, crediting Rui Wang
On 11/1/2010, 40 days after the advisory, Amazon stopped serving requests
made by the vulnerable SDKs. All merchants must use the new version.
Amazon Simple Pay issue
Being fixed.
Interspire
Fixed all.
NopCommerce
Fixed all but one (the Amazon Simple Pay issue).
Buy.com and JR.com
We have sent the reports. No response. Not aware of their progress.
(skipped in this talk)
i) We manually extracted a subset of the checkout
logic from Interspire;
ii) Used Poirot (being developed by MSR) to do a
bounded verification on the extracted model to
measure the complexity of the checkout logic.
re
The real challenge that I see in system security in general
formal protocol
How to extract the
logic model?
Actual
merchant
system
How to check?
predicates
(The verification community
knows already )
System researcher’s
contribution
Actual
CaaS
system
What to check?
Security goals
(e.g., shopper
should not be able
to shop for free)
Verification: it is just a
reachability problem on a
map.
We translate it
into the concrete
destination.
We draw the map
We translate it
into the concrete
start point.
Attacker’s goal
The real world
Actual operational context
Verification is a heavy tool
Don’t just force people to use it.
Be realistic -- the industry produces tons of programs, but can only
afford to verify a tiny percent of it
Tell them where to use, and convince them why.
We tell people that 3rd-party service integration is a
meaningful place to apply, and give them strong
evidences.
Side-channel-leaks in Web Applications:
A Reality Today, A Challenge Tomorrow
In Oakland’10
• split between client and server
• state transitions driven by network traffic
Worry about privacy?
Let’s do encryption.
• The eavesdropper cannot see the contents, but can
observe :
• number of packets, timing/size of each packet
• Previous research showed privacy issues in various
domains:
• SSH, voice-over-IP, video-streaming, anonymity channels (e.g.,
Tor)
• Our motivation and target domain:
• target: today’s web applications
• motivation: the web is the platform to deliver SaaS.
• Surprisingly detailed user data are being leaked out
from several high-profile web applications
• personal health info (illnesses/medications/surgeries)
• family income
• investment details (mutual fund choices and allocations)
• search queries
• The root causes are some fundamental characteristics
in today’s web apps
•Defense is non-trivial
• effective defense needs to be application specific.
• calls for a disciplined web programming methodology.
Scenario: search using encrypted Wi-Fi WPA/WPA2.
Example: user types “list” on a WPA2 laptop.
821
 910
822
 931
823
 995
824
 1007
Attacker’s effort: linear, not exponential.
Consequence: Anybody on the street knows our search queries.
Revealing your illnesses/medications/surgeries
and the type of doctor you are seeking
• Many vulnerable UI designs
• Entering health records
• By typing – auto suggestion
• By mouse selecting – a tree-structure organization of elements
• Finding a doctor
• Using a dropdown list as your search input
• Illness/medication/surgery information is leaked out,
as well as the type of doctor being queried.
Revealing your family income and
other info
• We studied TurboTax Online
• Design: a wizard-style questionnaire
• Tailor the conversation based on user’s previous input.
• The forms that you work on tell a lot about your
family
•
•
•
•
Filing status
Number of children
Paid big medical bill
The adjusted gross income (AGI)
All transitions have unique traffic patterns.
Entry page of
Deductions &
Credits
Summary of
Deductions &
Credits
Partial credit
$0Now,
Not eligible
Full credit
consult the IRS instruction:
$1000 for each child
Partial
credit$1000Not
eligible
Full
creditfrom $110,000.
Phase-out
starting
For every
income,
lose $50
$110000
$150000
credit.
(two children scenario)
$0Even
worse, most decision procedures for credits/deductions
have asymmetric paths.
Partial credit Not eligible
Full credit
Eligible – more questions
$115000
$145000
Not eligible – no more question
Entry page of
Deductions &
Credits
Summary of
Deductions &
Credits
Not eligible
Enter your
paid interest
Partial credit
Full credit
Disabled Credit
$0
Earned Income Credit
$24999
Retirement Savings
$41646
$53000
College Expense
$116000
IRA Contribution
Student Loan Interest
Child credit *
First-time Homebuyer credit
Adoption expense
$85000
$105000
$115000
$110000
$145000
$130000 or $150000 or $170000 …
$150000
$170000
$174730
$214780
Revealing your fund choices and allocation
Which funds you invest in?
• No secret.
• Each price history curve is a
GIF image from MarketWatch.
•Everybody in the world can
obtain the images from
MarketWatch.
• Just compare the image sizes!
How do you allocate your money?
• Based on the public information of
closing price of each fund, we are
able to recover the GIF pie-chart
using the image sizes in 4-5 days.
Inference based on the evolution of
the pie-chart size in 4-or-5 days
 800 charts
 80 charts
 8 charts
Size of day 4;
Prices of the day
Size of day 3;
Prices of the day
Size of day 2;
Prices of the day
Size of day 1
 80000 charts
Fidelity updates the pie chart every day after the market is
closed.
The mutual fund prices are public knowledge.
1 chart
Root causes: some fundamental
characteristics of today’s web
applications
Fundamental characteristics of web apps
• Significant traffic distinctions
– The chance of two different user actions having the same
traffic pattern is really small.
– Distinctions are everywhere in web app traffic. It’s the norm.
• Low entropy input
– Eavesdropper can obtain a non-negligible amount of
information
• Stateful communication
– Many pieces of non-negligible information can be correlated
to infer substantial information
– Often, multiplicative ambiguity reduction power!
Traffic pattern distinctions are everywhere. Which ones
will result in serious data leaks?
Need to analyze the application semantics, the availability of
public knowledge, etc.
Finding such leaks is hard!
Is there a vulnerability-agnostic defense to fix the
vulnerabilities without finding them?
Of course, padding is the right strategy.
Packet size rounding: pad to the next multiple of 
Random-padding: pad x bytes, where x  [0, )
We found that even for the discussed apps, the defense
policies have to be case-by-case.
OK to use rounding or random-padding
32.3% network overhead (i.e., 1/3 bandwidth on sidechannel info hiding)
Neither rounding nor random-padding can solve the
problem.
15
12
9
6
3
0
40%
30%
20%
10%
0%
1
16
64
128 256 512 1024 2048
overhead
Attack Power
Because of the asymmetric path situation
Rounding is not appropriate, because
Google’s responses are compressed.
The destination networks may or may not
uncompress the responses
E.g., Microsoft gateways decompress and inspect web
traffic, but Indiana University does not.
rounding before the compression Indiana
Univ. still sees distinguishable sizes;
rounding before the compression  Microsoft
still sees distinguishable sizes
Random padding is not appropriate, because
Repeatedly applying a random padding policy to
the same packets quickly degrades the
effectiveness.
The range of the randomness shrinks.
Suppose the user checks the mutual fund page 7
times, then
96% probability that the randomness shrinks to /2.
Fidelity cannot do the padding
Because the browser loads the images from
MarketWatch.
Many people may think that
We have type-safe languages; we have HTTPS.
secure web programming = web programming + secure infrastructure
This understanding is too shallow.
HTTPS
HTTPS
HTTPS
Think carefully about how your adversary can exploit
the multi-component nature of your app.
Microsoft
Martín Abadi, Johnson Apacible, Brian Beckman, Josh
Benaloh, Ranveer Chandra, Cormac Herley, Emre
Kiciman, Akash Lal, Rob Oikawa, Jim Oker, Dan Simon,
Yi-Min Wang
Indiana University
Beth Cate (lawyer), Robert Schnabel (dean of
Informatics)