22324
>> Shuo Chen: It is my pleasure to introduce Rui Wang. Rui Wang is a fourth
year Ph.D. student at Indiana University Bloomington. His research is focused
on systems security, including e-commerce security, side channel issues, privacy
preserving techniques and reverse engineering of binary executables.
He has been the lead author of many papers in top tier security conferences,
including Oakland, CCS and USNIX security and this morning he's doing his third
internship with us here at MSR, and the work he's going to present today started
as his second internship last year.
It is about how can you shop for free online. So Rui.
>> Rui Wang: Thank you for coming to my talk. This is joint project between
Indiana University and Microsoft Research. The other authors are Shuo Chen,
Xiao Feng Wang, Shaz Qadeer.
In our research we did several interesting processes from Web stores such as
this DVD shown here and this Agility Cream. I guess this is for body building.
Not quite sure.
So it's interesting, because we did not pay for them. We only paid with arbitrary
price. We found a set of [inaudible] from the mechanisms of the Web stores.
Besides buying this kind of free stuff, we do have our serious academic
motivation which is to study the API as a Web service paradigm.
We know that today a lot of big websites expose their Web services through a set
of Web APIs, such as Facebook, PayPal, Amazon, too et cetera.
So a lot of websites causes APIs to integrate the third-party services. Now, the
whole system consists of the Web client, integrated websites. So service API
websites. I can give an example here. So Web client, maybe it's a browser, and
integrated website is like buy.com and service API websites is PayPal. So better
integrates PayPal and something like that. Third-party service integration.
Our intuition is that the security for such multi-party Web apps can be very
challenging. Of course, as system research, our goal is to show significant
empirical evidence to support the intuition.
In multi-partisan era, from the security angle, we have to consider if one party is
naughty, just like a kid, suppose those three parties can only communicate
through one phone call. The kid can tell mom story X, and tell dad a slightly
different story, X prime.
So even if mom and dad communicate, if they're not smart and careful enough,
the kid will have a good chance to get something that he does not deserve. So
this is intuition.
Concurrently we studied today's Web stores that integrates third-party cashier
services such as PayPal Amazon and Google Checkout. We call them cashier
as a service or simply CaaS. This scenario is very important because today a lot
of Web stores are using CaaS services, just to name a few here.
Now, the Web store only handles the order information, and the CaaS handles
the payment. So the whole system has to make a joint decision which is whether
the shopper has made the proper payment to the order.
Here I want to give you some basic knowledge about the checkout workflow.
Now, this side you see the familiar checkout page of the Web store, and that side
you see the three parties, which is the shopper, the Web store such as buy.com,
so CaaS such as PayPal.
You also see the Web APIs exposed by the two websites. So when the shopper
is ready to check out, it clicks the checkout with the PayPal button. This will
generate http round trip. This consists of http request, R.1.A from buy.com and
http response which is R.1b from buy.com. R.1b redirects the browser to PayPal
where the shopper will see the payments, confirmation page.
So the shopper confirms the payment by clicking this Pay Now button. This will
generate allhistory.a and PayPal then collects the payment, may communicate
with buy.com and then respond with ourhistory.B. ourhistory.B redirects as a
browser to buy.com where the shopper sees the order completion page.
Sorry?
>>: Like the interactive format of this talk ->> Rui Wang: Yeah, if you have any questions feel free to ask. Yes.
So in this process, you see that the shopper's browser is redirected back and
forth between the two websites. This is just one example. There are many other
payments methods such as PayPal Standard, Amazon Simple Pay, Google
Checkout, et cetera, and even for one payment method different Web store may
integrate it in a different way. So basically we have a lot of this kind of scenarios
to examine.
The problem is what do you think that the shopper has to run a browser to all of
these communications. Actually, the shopper has the complete freedom. He can
play with any of these messages, because all of the APIs are exposed to the
Web.
So under this adversary assumption can the shopper shop for free or set
arbitrary prices? So we studied the source code of the popular merchant
software such as NopCommerce, Interspire. Merchant software, software used
to build Web stores like NopCommerce and Interspire, power intensive,
thousands of stores on Internet.
There was a study Amazon as the case, which are used by the Web stores to
integrate Amazon payment services.
In addition, we studied the popular big store GR.com or buy.com but we don't
have source code. We studied them in black box fashion.
What we found is nine different checkout scenarios vulnerable to a set of logical
bugs, and as a result we can add shop for free or set self-determined prices.
This was the time limit. We only talk about three of the bugs in this talk.
Also know that we only talk about the high level summaries of the bugs. And
there's some software in the source code critical but cannot be covered here,
read the whole paper to understand the complete story.
We only talk about from the high level what these kinds of things look like.
>>: The open source, are they too closed source sites?
>> Rui Wang: We either -- we first studied open source merchant software and
also some commercial merchant software, actually the sales source code. We
still can buy the source code. And also we studied those big stores, which we do
not know what source code they're using when we studied the ->>: Appreciably harder than J.com [phonetic] or ->> Rui Wang: No, I think without source code access you cannot thoroughly
check what kind of problem they have. But because by using the experience we
gain from the source code analysis and also by reading the document, like
PayPal provided, we still can understand more about the traffic, not just the look
at plain traffic. You actually have a lot of contacts. Yeah.
The first case is about the merchant's software. NopCommerce integration for
Amazon Simple Pay. This is the figure of communications back and forth and
also the merchant side of logic and this figure is a little bit complex. This is
shown in the paper. But let me try to give you a simplified story, because these
are kind of a little bit complex and cannot be talked about this figure here.
A simplified story can be start from the [inaudible], who wants to buy a DVD from
the Web store Jeff, Jeff will compose, sign a letter and ask Chuck to forward to
Amazon to get the payment, letter says Dear Amazon, Order 123, using $10,
when it's paid call me at 425-111-2222. So Chuck will just forward this letter and
Amazon then verifies the signature and asks Chuck to do this payment and calls
the phone number and Jeff will ship the product.
So phone number here is analogs to the written URL. Actually all of these
communications are http, on https, just http messages. And this scenario is more
or less common sense, similar to real live purchase.
But in the online world, anyone can register Amazon seller account so can
Chuck. So what we did is to purchase a $25 MasterCard gift card. There is
some kind of -- this type of gift card which is called a MasterCard and you can
also purchase Visa gift card, and this kind of gift card we purchased by cash. We
didn't show our real identity.
Then we found out we can register -- we first registered the card under the fake
name Maximus with a fake address and phone number. So then we found that
this kind of MasterCard gift card can be used to register for seller accounts in all
the CaaS services.
So Chuck also plays a seller mark. He tells Jeff I want to buy this DVD. And Jeff
will give him the same letter. Now, instead of forwarding this letter to Amazon,
Chuck replaces the signature with Mark's signature because Chuck now has the
signing ability of Mark. And for Amazon, he only sees the order of Mark, has
nothing to do with Jeff.
After the payment is done, Amazon calls the number. But the number, actually
the receiver is Jeff. So for Jeff he indeed has a pending order which is 123 and
he verifies the signature, which is indeed Amazon's signature.
So ->>: I gather Amazon does not link the signature with the phone number or http
address, the signature, it's any signature that goes and you can mix it with any
phone number, not any but...
>> Rui Wang: The phone number is in the message. And is protected by the
signature. But Amazon does not guarantee that this phone number is exactly
Mark's phone number.
>>: A little bit of clarification. So here the message signed by Amazon, and it's
always signed by Amazon but there's no linking here. What you're saying is the
linking between the return URL and the previous, the signature on the previous
message which is now Mark's signature.
>>: That's missing.
>>: That's missing, yes.
>> Rui Wang: So Jeff does not anticipate that Amazon will send him notification
which is completely irrelevant because Amazon essentially says to Jeff that
Chuck just made a Mark -- Chuck paid Mark $10 for his Order 123. And Jeff will
finally ship the product.
So in this case Amazon thought that Chuck was buying from Mark. But Jeff
thought that Chuck was paying to Jeff. And this gap caused a problem.
The second case is about the merchant's software. Interspire integration of
PayPal express. Again, this is a figure of the communications shown in the
PayPal.
Let me try to give you a simplified story. Suppose we can only have one
shopping session, which is for this cheap order, order one. This is the sketch of
the communications shown in the previous slide.
The most important message is ourhistory.B, which is an inter website re
direction. And the interwebsite redirection will call the API update order, in which
the store attach argument, the ID, order ID 1 and signed by the store. T star is
signing. So the shopper cannot tamper with it.
And honest shopper will just do this redirection. But let's see if we start a second
shopping session. This time we place expansive order or order two. Then we
skip the payment step. So interesting thing is we still can get ourhistory.B which
is there is order signed by the store. So the next thing is pretty simple, just copy
and paste this value to R.a of the first session and release this message and in
this way we can check out the expansive order from the first session.
So the third case is about Interspire integration of Google Checkout. High level
summary of this bug is the payment total is calculated as a moment of RD.2a
that's when the shopper clicks the checkout button, and the order is created as a
moment of ourhistory.a that's when the shopper clicks the Pay Now button.
There's two moments. In between the two moments the shopper is allowed to
add more items. So then things become simple. You just place a cheap item in
the shopping cart, then you click the checkout button, then add more items and
click the Pay Now button. This way you only pay for the cheap item and you
check out the entire cart.
We confirm all of this with abilities in the real world in four levels. We first install
the NopCommerce and Interspire on our Web server. Used our own seller
accounts and buy accounts with successfully delete all the text.
Interspire has a famous hosting service, which is called Big Commerce. We
created our own store on Big Commerce and successfully confirmed these
attacks.
And then we really want to tell end-to-end story which is the malicious shopper
can really go to the real world to shop for free by exploiting this kind of logical
box.
So we found a real store part of NopCommerce, Interspire. These kind of stores.
And we check out physical goods and downloadable goods for free with less
payout for free.
And besides NopCommerce, Interspire we're also curious about the Web stores
whose source codes are not available to us. Can we still find similar bugs
because we cannot thoroughly check the logics. So we studied the popular
store, buy.com and G.com. We were able to show that without source code
access some [inaudible] ideas are still applicable.
We did -- sorry.
>>: Quick question. What did you need to modify in terms of software to pose as
the attacker? So you are running the Web browser, right, where all these
transactions are going through. What part of the software or the stream that was
being communicated did you have to modify? In other words, did you have to
modify IE to launch this attack or Mozilla to launch this attack or ->> Rui Wang: You actually have some tools to use. Like in Firefox you have
some kind of traffic monitoring tools. You can monitor the traffic. And also you
may use some kind of http or proxy or something which you can hijack the traffic.
You can modify the traffic. You actually -- you don't have to modify the browse.
You have a ->>: This is all done without modifying the ->>: Didn't modify in the process.
>>: The specific tools you use, at least the two tools. One is Firefox [inaudible],
which allows you to actually modify the http request responses and in some other
cases like you use [inaudible] proxy.
>>: [inaudible] proxy?
>>: Yes.
>>: Closed source site, not only did you not have the EXE but you [inaudible] you
had neither source nor object nor EXE.
>> Rui Wang: You said no source code and no what?
>>: No objection and no EXE.
>>: Didn't have any binaries you could actually reverse engineer.
>>: The only thing you have is the two edges ->> Rui Wang: The communications, yeah.
We did other experiments responsibly. First they were under the close guidance
of Indiana University lawyer to be sure we were not doing some crime.
And we got a support from the dean of our school, and we ensured that the
following principles are no intrusion to the websites. No monetary loss to the
Web stores, return the product or pay all money and we communicated all the
details to the affected parties.
The outcome is quite pleasant, because no party expresses an active point on
what hack, because we're really helping them to have the bug, and then we tell
them you have this bug you should fix. And most of them actually appreciated
our responsible efforts.
>>: Is it possible for you to configure these in any way so you could actually fix
the issue yourself or is it always required that the software providers had to
provide a fix?
>> Rui Wang: It is either the Web store have to do a fix and in some cases
maybe the service provider needs to do a fix. Because in the attack is like attack
path, strong as you find the points that you can block these paths, and then you
actually fix the problem.
So it's either the Web store can fix the service provider do something.
>>: You mean CaaS.
>> Rui Wang: Yes, the CaaS services, yeah.
Amazon published security advisory which is credited me and Interspire even
asked if I'm interested in doing security auditor work after knowing that I found
the flaw vulnerabilities in these and our research has been covered by a lot of
news articles, which are all positive about how we conducted this research.
We communicated all the details with the affected parties. This one with
buy.com customer service is pretty interesting. After we check out the product
for free, we send this message. Tell them that one order was not paid. So
buy.com responded with a generic message telling us all just all the possible
reasons for delaying credit cards, all the possible reasons. Misunderstanding
because the payment method was PayPal. The same we send a second
message. Tells them I'm a Ph.D. student doing security research and we used
the token. We released these kind of details.
And their reply is based on our record you will be the purchase date. So we had
this difficulty to convince we owe them money.
>>: [inaudible].
>> Rui Wang: So sometimes these type of attacks we believe is not easy to
notice by the accounting assistants of the Web stores.
And we finally returned its product after 45 days. We found the eligible period.
Because after that day, they will not refund us, we just return it, they will not start
the refund process. Then we disclosed all the technical details and they finally
fixed the bug.
>>: Based on the standard industry rate how much salary did it cost you to do
this paperwork? I think they would have much rather you had stolen the item and
disappeared.
>> Rui Wang: This is the status of bug fixes. In this process, most of the parties
were very responsive. And the good news is all the bugs has been fixed
recently. But like if you are a shopper may not be good news, because you can
never go to these websites for free.
And particularly interesting one is the Amazon SDK vulnerability. I did not
describe it in this talk. It actually affects almost all the Web stores which support
Amazon payments service. 15 days after our report Amazon released a new
batch of SDKs covering all the five programming languages they support, and
they published the security advisory in which they require all the Web stores to
upgrade to the new SDKs within 40 days. So this is pretty serious bug.
We also studied the complexity of the CaaS-based checkout lecture which is in
this talk. Specifically we manually extracted a subset of the checkout logic of
Interspire and then we used the [inaudible] which is developed by Microsoft
Research. I think one of the major developers is Shuo sitting here, and we used
the [inaudible] to do the verification and we measure the complexity of the
checkout logic.
When we talked to some, to verification researchers, some of them said that
product verification tools would have discovered these kind of bugs
automatically.
So what is exact contribution of this work? Actually, the real problem is not how
to check -- how to check formal model such as protocol against a set of security
predicates. It's not the real problem. The problem is there is no protocol, it's just
the work programs. The real fun part, 90 percent of our research time was on
starting this kind of real assistance, understanding the operational assumptions
of these systems and the accurate security goals and without such a clear
understanding, we can only say that a given perfect -- formal model, formal
protocol, that given adequate predicate, using the verification technique can, you
can rediscover these bugs.
So the real challenge here is not how to check but how to extract as a logical
model and what to check, which is the weather systems make contribution. A
metaphor can be the end-to-end problem here is to find a path. In the real world,
the verification is a technique to software reachability problem between two
points on a well defined map but we need to insert understanding of the real
world in order to draw a useful map. And we as a person as draw a map. In
conclusion we showed that multi-Web apps fundamentally more complicated
than as in traditional two party Web apps.
Just from the security sense. Some complexities include confusion, in
coordination, concurrency, weak bindings advisory play multiple roles.
We empirically prove that CaaS-based Web stores are under imminent threat.
And also due to our research we also believe that Web service integration may
become an important area to apply formal reasoning and testing approaches.
The key challenge is how to extract the model and the define security predicates.
Concurrently we only studied as regular checkout scenario and there are many
other important check out scenarios such as subscription, marketplace, gift
cards. I believe these are very good research opportunities. Also the integration
of other Web services, Facebook, LinkedIn allowed other websites to access its
usage data. Again, you see the signal three party scenario here and also
Google, Yahoo, Twitter allowed other websites to authenticate users through
them.
We actually had some encouraging progress along this direction. We really
appreciate people from Microsoft and Indiana University for their help on this
research. Without them the research cannot be possible.
Thank you.
[applause]
>> Rui Wang: Any other questions?
>>: Three comments. One is old USSR had store where you stood four times in
line because sheer end of money and the salesclerk handled goods and maybe
it's worth checking how they did it.
>>: In the real world?
>>: Yes, because we have the western model. You know the same guy pays the
money gives you the goods. Way too bureaucratic. The other is have you read
programming "Satan's Computer"?
>> Rui Wang: Programming.
>>: "Satan's Computer" by Rob Anderson. He expressed one principle, you
always name the parties involved. Don't let the crypto pursue it come from A, B
or C. Name it and of course secure it.
And you take a look at how red tape was used for real. It was English
documents.
>>: What's that?
>>: People -- red tape has become a real bad word. What you used to do you
punched holes in documents you ran red tape through it put a wax seal on two
ends of the tape so you could remove the document you could not interpolate
new documents in. You need something to tie two documents together. And
now we need a crypto logic equivalent of that.
>> Rui Wang: Yeah, we do.
>>: So I think probably a similar situation is that it does provide some primitives
like, of course, you can find two documents by [inaudible] them and providing a
signature. But the art here is how do you apply these messages here. Which
one should we -- because the binding should happen between which ones.
Those are not as clear.
>>: So the primitives are there but how to use them.
>>: So if you were working at Amazon and you wanted to determine how secure
your payment system is or containing similar weaknesses, how would you go
about doing so.
>> Rui Wang: If I was working at Amazon. I think maybe we can go back a little
bit.
Like we say here, the Web service integration may become an important area.
And the CaaS-based integration is one of these kind of service integration.
So I think I should be really interested in this kind of formal reasoning or testing
approaches which to see that if this kind of techniques, how we incorporate these
techniques to really ensure that there's no problem. But this is just one
technique, because like if Amazon provided this kind of payment service, actually
he is hard to ensure that the Web stores logic is correct. So I think he should
also spend much effort to help those Web stores to correctly, to integrate the
service.
And one effort may be providing security conscious guidance and also provide
some kind of automatic tool which can help check the logic, if the logic is correct.
>>: You're saying it's not just a technology.
>>: It's not just Amazon's problem.
>>: It's not a technical problem, it's also across organization.
>> Rui Wang: Yeah, it's across organization.
>>: It's about the interaction from an organization.
>>: The other thing that's coming out which is a lot of assumptions are being
made, never called out, never fully understood, right?
>>: So that brings me to sort of the question what is the technique here to solve
these problems? Or are you merely exposing that these problems exist? And
what's the solution to this problem?
>> Rui Wang: The solution, once you have found these kind of bugs, then the
solution is very simple. You just fix them. I mean, you know this bug exists ->>: But order ID from -- you say, okay, I sliced this new order ID into my URL
stream. But that is still -- isn't that a legitimate request? How do you distinguish
that from malicious -- how do you distinguish between two URLs? One of which
is malicious. Of course you copy this scenario. The other one would exactly you
intended that to be there, in the order it would be the signature.
So what I'm trying to get at is how do you differentiate these two URLs to be one
as malicious and one is right? From the --
>>: The problem there was no binding between order and payment of the order
so if you created -- it's like a time of check, time of use type of thing. So I think
the key here is good threat modeling and kind of what you pointed out what your
goals are and what are the assumptions you're making and looking at how those
interact. But certainly does get complicated when you're talking about third
parties and really have to take a look at the whole picture.
>>: So the seller and the cashier service, they have to get better data and they
have to understand each other much better. Because ultimately your user did
the shopper -- it will be given some code or some kind of JavaScript, right, or it is
going to open a Web page provided by a seller, and any logic that does all these
establishing https channels, getting URLs, URLs and whatnot, your shopper isn't
writing any of that code. What you said is that you modify that stream, right?
You modify it in some malicious way. Yes you used a proxy or something. But
you haven't really gone the next step whereas if you were really very malicious,
bad guy, you would change all of the code that is running on your machine. The
user. Right? What if you could actually write the down browser from start to end
and then talk to the seller and get the response and change it in any way, shape
or form, and then redirect the server? So there could be many more malicious
things you could have done.
>> Rui Wang: Yes, I think in current research what we've really done is we don't
even have to change like the browser side of logic or something. We only need
to manipulate those data back and forth.
I mean the communication with the Web stores, the communication with the
CaaS. We don't even need to change this kind of maybe a set of logic to the
Web browser, we didn't even do that, and we still have such power. And if we
considered that part, maybe more possibilities.
>>: Those two things are bugs, you exposed the bugs and the bugs will be fixed
by better integration. But then there's a whole second class of threats which if
you don't the this kind of -- I don't want to use the word denial.
>> Rui Wang: I think it assumes completely malicious browser.
>>: So if you have much more malicious components there, then do you think the
solutions, the solution that you're proposing where the seller and the cashier
service have to get better integrated blah, blah, blah, do those solutions be able
to thwart this problem if your attacker becomes much more malicious and he can
change many more things?
>>: He's asking the bug fixes that were made for these flaws, would they be valid
bug fixes even if the attacker model was way more adversarial?
>> Rui Wang: I think that the fix is just we tell them this bug and then they find a
way to block the attack path. So I think they fix the problem. So I think they
didn't have the --
>>: There's no guarantee. Because you're blocking ->> Rui Wang: You just blocked the third path.
>>: I think the solution should be -- even at this moment we are assuming the
most malicious kind of model, which is there's no logic on the shopper's side.
Whatever I receive I can completely mess up and just the message fields. So I
don't know whether there's anything that's more malicious than that.
Because we have no logic basically. We can do everything on the demand side.
>>: So what you're saying is you are allowing for that kind of -- so you are
assuming a perfectly capable adversary that can change each and everything on
its end and it will still work.
>>: Yes. But sometimes this kind of temporally needed fill in proxy, sometimes it
needs a Firefox -- that's the type of thing for more detail.
>>: Just one more comment. Just to understand, just to make it clear. There's
no reason why these problems cannot be solved in [inaudible] this is not an
impossible problem solving.
>>: The transactions, the securely ->>: Yes.
>>: One way to look at this is full implementation of the software that is around
these transactions, right?
>>: Well, maybe poor design and poor implementation.
>>: Thank you. Yes, absolutely.
>>: But that's like what you have just said can be applied to all uses of software,
right?
>>: I agree.
>>: All bugs like that.
>>: Right. Well, no, let me disagree. There are problems for which you cannot
solve.
>>: I see.
>>: So I can give you an example of a problem where the Internet at large, you
want strong consistency with high [inaudible].
>>: Cancel this problem. But this problem is one we could solve. It's not
impossible proxy solved problem. It's just a case of bad design.
>>: It's not impossible, but the thing is when you consider the complexity to deal
with and the scope, how many Web stores are there. So that may be some -- it's
critical.
>>: Individually you might be able to solve and treat one specific scenario that
might be nearly 100 percent perfectly secure. But it's very hard to say that it's
absolutely secure. And then we can take all stores, put together, all shopping
systems, and it's possible to secure them all.
>> Rui Wang: So any other questions?
>> Shuo Chen: Thanks.
[applause]