Defrauding Merchants Like It's Y2K by Yuk Fai Chan and Craig Barretto at BSides Toronto 2022

and I'm Craig Barreto Chan um we're here to talk about defraudi Merchants like it's Y2K uh we also did this talk at sector but uh yeah we thought we'd come and give you guys the short version b-sides and a little bit more technical uh so a little bit about me I'm a security consultant uh pen tester researcher generally I'm a curious guy when it comes to any sort of app or mobile app uh co-founded proact and uh yeah I'm not a lawyer so because we're talking about fraud not a lawyer just to be clear and I'm yukvue Chan the other uh co-founder at proact security you may also have seen me at West Toronto uh

where I helped with the chapter and organize things and I am also not a lawyer so a quick agenda will be looking back at history and uh seeing how a classical uh vulnerability that applications will make can be leveraged in how mobile applications and and Merchants do payments third party payments and also in in-app purchases will show you what can go wrong and give you actual examples and then talk about how you can fix things so looking at what I guess applications used to do when it was year 2000 uh for an e-commerce platform so you'd have the customer and then a merchant so the website uh you would visit their e-commerce website and they will give

you a list of products that you can purchase and uh the price for for each then you say hey I want to buy this TV so you would add that TV to the cart and with that request you would uh tell the the application what is the item that you're trying to buy so it's super TV uh you say Quantity of one I just want one and the price is 200. and then uh the the merchant will just tell you hey if you want this this is the total you have to pay 200 dollars you will pay that total and then um the order will be confirmed and they go they will start fulfilling your order

I guess to the audience what can go wrong here price that's right well yes yes you allow the client to supply that the value of of the price so what can a bad person do is when they add the TV to the card they change the price to something that is lower five dollars if the application is not doing proper validation they will accept that and say hey the order that you have the total that you have to pay is five dollars and if you pay that they will still confirm the order despite paying a much lower amount so this is the type of vulnerability that will be um talking about but just applying it to

how modern Merchants are doing things all right quick show of hands any qsas in the house anyone here says no no all right pen testers all right perfect so you guys are going to enjoy this one then all right so uh using third party uh payment processors so if you guys have seen anything like this before I'm sure many of you have you've got your customer your uh Merchant and then you've got your payment processor so something like moneris Global Payments you name it uh so you do your checkout they send you the the merchant then sends you to uh the third party your browser's doing this now I'm just talking about like a regular e-commerce

platform so you cut you have an iframe and many of you probably when you're using an e-commerce site you see the iframe pop up you might not even know that you're sending it to another company um but if you're using something like if you're intercepting the traffic then you obviously see it and then you get back your uh payment iframe you send your payment details so your credit card all your information and then you get a payment confirmation back now you may get a payment confirmation back or a token that might be used for like something like card on file and then you send the payment confirmation to the merchant Merchant then does some sort of internal

server to server validation with the payment processor and your order is confirmed anyone see where this can go wrong based on the previous history lesson we just gave

um

yes and no but typically what happens is when you get sent to the payment processor there's a there's a series of information that gets sent to the payment processor which usually includes a hash right and usually with a secret so they if you try to modify the price again there are some cases where this is implemented wrong but majority of the time that we've seen if you try to modify that the any sort of transaction with the payment processor might fail right um but you you are on the right path uh and when we get to there I'll show you but it's usually around seven where things kind of go wrong as well as you could skip three four five

and six so um so really quickly uh for the payment reference stuff so when the the payment processor sends you a response back it's usually like a positive saying yeah you're good um and then you send that receipt or that information to the merchant and then the merchant will then process the order um that this is a way um to prevent or to limit your scope for PCI right you're you're using an iframe so you're not sending the credit card information directly to the merchant you're sending to the payment processor who then you know they have their controls in place for PCI um but then it also limits your scope now what we've seen from doing a number

of different pen tests is that when we do scoping calls with with Merchants they're like okay you're gonna go right to the payment page well yeah but what happens after the payment page right usually a lot of the times and I I thought I heard someone giggle or heard it is that you go right to the payment page that's not the end of the pen test right the pen test is also should continue afterwards right you might not want a pen test you know your your payment processor because they've already said that they've pen tested their stuff but uh the the scope of the pen test should be all the way through right you can exclude maybe the payment

processor um and then the payment reference like I mentioned before could be a token for maybe a one-off transaction to say yes you're good good like a like a hash um or it could be another hash that's used to identify you as a customer that can then be used for future purchases so like let's say for example you save your your credit card on file um as I'm sure many of you have seen it's really easy to then just select the credit card when you're doing your transactions future transactions and then going through the the payment workflow without actually having to input your credit card again now the payment references in the tokens should be uniquely generated so they're

one time specific so even if you use the same credit card same credit card information it should always be different

all right um next we're going to talk about mobile and app purchases so these are purchases that you can do in a Merchants application uh on iOS or Android and you would do the payment not directly with the merchant themselves or the app providers themselves but you would do it with apple the app store or Google Play concept is very similar where you would request the product information and the app provider will give you that but when you select in-app purchase you talk directly with Apple or Google um you would send the payment request to the app distribution platform and they will process the payment and send you back a receipt or a token so similar

concept as to the the payment confirmation and or the token with the third party payment processors um once the application receives that uh they will send that uh receipt or purchase token back to the app server they should do their own validation and then once that's done they will deliver the purchase content or Grant the entitlements now just a little bit more on the receipts and the tokens um basically for for the Apple App Store the receipt is an encrypted value that contains all of the transaction information so the product the time of the purchase and so on and that uh can only be decrypted with uh by by Apple or by by with an iOS device

um yeah so for in-app purchases the the receipt contains the record record of a record of the sale and it can be for a one-time consumable or it can be for a subscription so think of let's say a game in uh on on an iOS device where you can buy some additional tokens or credits or you can have like a professional membership that that you pay for and you you pay for that every month or every year uh with the Google Play Store it's a little different they give you back a token the token itself is just a reference to the the transaction and the Google servers actually hold that transaction information so you have to

send that token back to Google so that they can give you that transaction information but a similar concept you would only Grant entitlements uh once that is validated with Google so what can go wrong so the app doesn't check the receipt payment token or the payment reference for validity or uniqueness so kind of what we were saying before so if we look at um you know we go through the workflow here you're essentially skipping the payment part so you're going down you're going through the I you're going to the iframe and then what you do so if you look at one two so you're getting sent to the third party the browser then requests the iframe from the third party payment

processor and then you you skip it entirely right now you can usually do this through burp right and it's usually very helpful if you do this transaction once because then you can see the entire workflow but then on subsequent requests uh or subsequent attempts to go through the workflow you can then just skip it and go straight to number six so a lot of times what we'll see is you'll see like a payment settlement or a payment confirmation uh request that gets sent um after the payment processor so when the payment processor sends you the response it says yeah you're good then the request that gets sent to the merchant just says yeah my transaction

was good here's the information what we're doing here is we're just replaying that and just going well we're going to send you a fraudulent payment confirmation we'll send you the same one that we received before or we'll send you one that's slightly modified the merchant then fails to validate it properly and then they confirm your order so then the second issue that we see yeah so the second issue that we see is that for some reason the app decides to Grant the entitlement the entitlement or give you the the purchase item based on a value that the user controls such as the TV example that we saw at the beginning so if we take the mobile

impact in-app purchase flow again so the beginning is still the same you pay for let's say 10 credits in your game and you get a valid receipt back um what you do is you send the valid receipt but change the product ID of what you're trying to purchase the apps a mistake here is that they allow the user to change our product ID if you do that you essentially get uh let's say 100 credits for the price of 10. and if the application does not do proper validation they will still give you those 100 credits so uh for the example that I explained I mean think about like a brick and mortar store right um so let's say Best Buy you

have a receipt for a TV that you bought you you go in you hand them in your receipt you say hey I'm here to pick up my my 50-inch TV they go okay cool here's your product you leave you hand your receipt to somebody else they go in they go here's my receipt for my 50 inch TV they go okay cool here's your 50 inch TV that's the example that we're kind of walking through with my first one this one this example here is you're saying okay I bought a 50 inch TV I have a receipt for a 50 inch TV you walk in and you go I bought a 72 inch and they go

okay cool you have a receipt it's a valid receipt great here's your 72 inch TV and they're not really confirming that yeah you bought a 50 inch now in a brick and mortar store that shouldn't happen but like online what we're finding is these receipts they're being they're being checked to make sure that they're valid receipts but they're not actually checking that their the receipt is for the right product there is an almost identical brick and mortar attack at slightly position in the chain you carry a stick on UPC code for a lower priced item that looks similar so when they scan it out and say yeah it's the right shape and size but it's

one by five yeah all right we're going to go into a conceptual example it's mocked up based on some actual applications that we've seen and here we're going to imagine that you and your friend can get a professional membership with one of the apps that you're using but only one of you pay for it um in this example we're going to be proact one and proactive two uh two friends who who are using this app so at the beginning proact uh user proact one is only a user of the free tier and then we'll go to uh proact2 as well if we see their profile they're also just uh members of the free tier now proact one will go and buy a

membership a professional membership with the app the Apple App Store and then they get get they get a receipt back and they normally they will send the receipt back to the application the merchant the merchant will take that receipt and say hey this is a valid uh app store receipt and Grant you the entitlement of a professional membership so this is all normal flow but since proc1 and proc2 are friends and they're mischievous they will try to share the receipt and see what happens so proactive will replay that uh request with the same receipt that um proact one had from their payment and the application is not doing proper validation and uh the uh it grants the

professional membership to proactive as well while only one person has paid and then we can verify that by going back to their profile and checking their product one they did pay so they they are professional but proact2 did not pay but they also have the professional tier membership

and so when we look at the other example so you have um I think I think I mentioned this earlier you you buy a product and you replay this receipt but with a different product ID usually for something that that costs more so uh here you're gonna see the I don't know if you guys can see this very well but um this is kind of a typical example of what you would see when you're sending a request to uh your payment processor right so you have on the left uh this is again like a burp request uh which would have your credit card information um that you're then sending to a payment processor so again like Global Payments

or whoever monaris whoever you use and then they give you back the the uh the payment processor response which is then sent to the merchant in a subsequent request so I know you guys can't see this but we'll make it a little bit bigger so there you've got your product ID for product a and then you've got your your transaction hash right so this is a normal like payment processor response and this is the request that you're sending now back to the merchant you take the same request and you're just doing the replay you change the product ID with the same transaction hash so you're changing the product ID to something that's likely more expensive right so in

the example I said before 50 inch TV you switch it to a 72 inch TV and then you get the order confirmed so um kind of moving to like a real life example so um we had a couple others um we weren't allowed to talk about them so uh in in this case we did responsible disclosure uh so has anyone heard of the app called burner burner yeah pen testers you haven't heard of burner all right anyways it's a it's a it's a mobile application that you you can use to um to to get I guess virtual phone numbers uh to do text messaging um so that that way when you're you're testing for example or at least if you

want to anonymize text texting you can uh you can essentially buy credits and then use those credits to get phone numbers so like if you wanted an extra 647 number um that's essentially what you would use burner for so uh in back in May I took a look at Berner uh we were we actually use it um as a company and I thought I wonder if they have the same issue when I bought some credits and yeah like as I mentioned in the beginning I am a curious person so I decided to intercept using burp and yeah they had the vulnerability uh essentially I'll I'll show you what the requests look like but um as of I think like a month ago uh

this has been fixed on Android I didn't look at it on iOS so you're welcome to if you want to um so uh essentially this is this is actually the request that were sent uh I had one credit in my account uh I went to the Google Play store to buy additional credits the initial uh what I sent to Google was in a credit purchase so I think eight credits was like 349 once the transaction was completed this is the The Blob that got sent back the receipt that that Google gave me that I was then going to send to the merchant I changed it from credits of underscore eight whoops underscore eight two underscore

25 and on the far left or your right uh credits equals 26. so I had one credit now about 25. so yeah we've seen this quite a few times in a lot of the apps that we've we've been testing um and so yeah that's why we figured we'd do this talk all right now how do we fix this with most of uh application security vulnerabilities it's about uh input validation and also not trusting user input so um in the case of of burner for example they shouldn't trust the the user to provide the SKU it should be something that is track service side um and then you want to do validation validation validation if you receive a

uh payment token or an app store receipt from uh from Apple or the payment processor uh you need to one validate that it's Unique and also check that the transaction information matches what you have uh on the back end and there are some guidelines and and best practices that are provided by Apple by Google and the payment processors on how to do that and specifically um for App Store receipts Apple does expose an endpoint that's called uh verify receipt to to check that so you would pass the the encrypted blob that I was talking about the receipt back to that endpoint and the response will be a Json that includes all of the transaction information and you use that

a server side to do the validation to make sure that the purchase is legitimate legitimate before you grant the entitlements and remember that this needs to be done server to server so don't let your mobile app do that because um as we know users will manipulate the the requests and tamper with things hacker is gonna hack uh with Google same concept it's just that this time around you're you're passing a reference to a payment and the purchase token can be sent to two separate API endpoints one is just a product uh get the other one is subscription get obviously one for one-time consumables the other one is for recurring uh subscriptions and you would use this

information to verify that the purchase is legitimate legitimate before you grant the entitlements um and then just I've got some references as to uh the specific docs that Apple and Google will provide for verifying receipts and tokens uh if you want to take a picture do it now going twice and then for Google Play

all right that concludes our talk any questions [Applause]

so you could um but I think the scenario that we're talking about here is that they're not even validating the maybe the uniqueness of the token so if they don't validate the uniqueness of the tokens or they're not making sure that a token can be replayed then you don't need a race condition you just replay the same one over and over again and depending on the scenario you're looking at right if you're looking to like accumulate credits or or coins or whatever value that the app uses um you could just replay the request multiple times and potentially accumulate whatever currency or digital currency you want to use that's in that app so