Security & fraud: How to (NOT!) shop online for free
•
3 j'aime•3,163 vues
Yes, it happened: Just this year, researchers found flaws in how merchants integrated with a variety of payment systems—including PayPal!—and they were able to purchase items for free or reduced-cost. How to integrate securely with PayPal and avoid expensive mistakes.
Recommandé
Recommandé
Contenu connexe
Plus de X.commerce
Plus de X.commerce (20)
Dernier
Dernier (20)
Security & fraud: How to (NOT!) shop online for free
- 10. $ 39.95 $ FREE http://www.openclipart.org/detail/153163/book-orange-by-ypssun
- 11. Buyer clicks on “Buy Now”
- 12. Buyer Pays at clicks on PayPal “Buy Now”
- 13. Buyer Redirected Pays at clicks on to digital PayPal “Buy Now” download
- 14. Thank you for your purchase. You may download it now. http://www.commerce.tld/ebook.pdf
- 15. Buyer Attacker Redirected extracts Pays at clicks on to digital delivery PayPal “Buy Now” URL download
- 16. Buyer Attacker Redirected extracts Pays at clicks on Skips PayPal to digital delivery PayPal “Buy Now” URL download
- 18. <input type="hidden" value=http://www.commerce.tld/thankyou.html name="return" > </form>
- 19. Store gets an Buyer Attacker Redirected extracts Pays at encrypted clicks on Skips PayPal to digital button at delivery PayPal PayPal “Buy Now” URL download
- 20. <input type="hidden" value="-----BEGIN PKCS7-----MIIH+QYJKoZI […] QHPMWo=-----END PKCS7----- " name="encrypted">
- 21. <input type="hidden" value="-----BEGIN PKCS7-----MIIH+QYJKoZI […] QHPMWo=-----END PKCS7----- " name="encrypted">
- 24. 10000 € 5€
- 25. Store • Sends Buyer to PayPal
- 26. Store PayPal • Sends • Collects Buyer to Payment PayPal
- 27. Store PayPal PayPal • Sends • Collects • Returns Buyer to Payment Buyer to PayPal store
- 28. Store PayPal PayPal Store • Sends • Collects • Returns • Confirms Buyer to Payment Buyer to PAID PayPal store
- 29. Store PayPal PayPal Store • Sends • Collects • Returns • Confirms Buyer to Payment Buyer to PAID PayPal store Attacker changes price
- 30. Store PayPal PayPal Store Store • Sends • Collects • Returns • Confirms confirms Buyer to Payment Buyer to PAID amount PayPal store paid Attacker changes price
- 34. Store • Sends Buyer to PayPal
- 35. Store PayPal • Sends • Collects Buyer to Payment PayPal • Sends IPN to Store
- 36. Store PayPal PayPal • Sends • Collects • Returns Buyer to Payment Buyer to PayPal • Sends IPN store to Store
- 37. Store PayPal PayPal Store • Sends • Collects • Returns • Confirms Buyer to Payment Buyer to PAID via PayPal • Sends IPN store IPN and to Store Order ID
- 38. Store PayPal PayPal Store • Sends • Collects • Returns • Confirms Buyer to Payment Buyer to PAID PayPal • Sends IPN store to Store IPN handler points to attacker, Order ID = NULL
- 39. Store PayPal PayPal Store • Sends • Collects • Returns • Confirms Buyer to Payment Buyer to PAID PayPal • Sends IPN store to Store IPN handler Attacker points to Pays, attacker, PayPal Order ID = sends IPN NULL to attacker
- 40. Store PayPal PayPal Store Load new cart with•same items • Sends Collects • Returns • Confirms Buyer Skip PayPal to Payment Buyer to PAID PayPal • Sends IPN store to Store
- 41. Store PayPal PayPal Store Attacker Load new cart with•same items • Sends Collects • Returns uses • Confirms Buyer Skip PayPal to Payment Buyer to captured PAID PayPal • Sends IPN store IPN to Store
- 42. Store PayPal PayPal Store Attacker Load new cart with•same items • Sends Collects • Returns uses • Confirms Buyer Skip PayPal to Payment Buyer to PAID Repeat captured PayPal • Sends IPN store IPN to Store
- 43. Store PayPal PayPal Store Store Attacker Load new cart with•same items • Sends Collects • Returns uses • verifies IPN Confirms Buyer Skip PayPal to Payment Buyer to PAID not Repeat captured PayPal • Sends IPN store IPN previously to Store processed
- 47. PayPal • Collects Payment
- 48. PayPal Store • Collects • Session Payment = PAID
- 49. PayPal Store PayPal • Collects • Session • Returns Payment = PAID Buyer to store
- 50. PayPal Store PayPal Store • Collects • Session • Returns • Signs Payment = PAID Buyer to Order ID store
- 51. PayPal Store PayPal Store Store • Collects • Session • Returns • Signs • Validates Payment = PAID Buyer to Order ID session store and Order ID
- 52. PayPal Store PayPal Store Store • Collects • Session • Returns • Signs • Validates PaymentSkips = PAID PayPal Buyer to Order ID session store and Order ID
- 53. PayPal Store PayPal Store Store • Collects • Session • Returns • Signs Collects • Validates PaymentSkips = PAID PayPal Buyer to Order ID session signed store and Order ID Order ID
- 54. PayPal Store PayPal Store Store Attacker • Collects • Session • Returns • Signs • Validates buys low- Payment = PAID Buyer to Order ID session store and cost item Order ID
- 55. Attacker substitutes High-Cost Order ID PayPal Store PayPal Store Store Attacker • Collects • Session • Returns • Signs • Validates buys low- Payment = PAID Buyer to Order ID session store and cost item Order ID
- 56. Attacker substitutes High-Cost Order ID PayPal Store PayPal Store Store Attacker • Collects • Session • Returns • Signs • Validates buys low- Payment = PAID Buyer to Order ID session Repeat store and cost item Order ID
- 57. Attacker substitutes High-Cost Order ID PayPal Store PayPal Store Store Store Attacker • Collects • Session • Returns • Signs • Validates verifies the buys low- Payment = PAID Buyer to Order ID session Order ID Repeat store and cost item matches Order ID the session
- 61. PayPal • Collects Payment
- 62. PayPal Store • Collects • Token = Payment PAID
- 63. PayPal Store PayPal • Collects • Token = • Returns Payment PAID Buyer to store
- 64. PayPal Store PayPal Store • Collects • Token = • Returns • Confirms Payment PAID Buyer to token store PAID
- 65. PayPal Store PayPal Store • Attacker Collects • Token = • Returns • Confirms buys low- Payment PAID Buyer to token cost item store PAID
- 66. Attacker copies token value PayPal Store PayPal Store • Attacker Collects • Token = • Returns • Confirms buys low- Payment PAID Buyer to token cost item store PAID
- 67. PayPal Store PayPal Store • Collects • Token = • Returns • Confirms Skips PayPal Payment PAID Buyer to token store PAID
- 68. PayPal Store PayPal Store • Collects • Token = • Returns Attacker uses • Confirms Skips PayPal Payment PAID Buyer to PAID token token store PAID
- 69. PayPal Store PayPal Store • Collects • Token = • Returns Attacker uses • Confirms Skips PayPal Repeat Payment PAID Buyer to PAID token token store PAID
- 70. PayPal Store PayPal Store Store verifies the • Collects • Token = • Returns Attacker uses • Confirms token Skips PayPal Repeat Payment PAID Buyer to PAID token token matches store PAID the session
- 75. spoof@paypal.com cred@paypal.com sitesecurity@paypal.com
Notes de l'éditeur
- Let’s start off by talking about a modern-day diamond heist. I’m not talking about robbing an armored car or spending six months digging a tunnel under a bank. That’s too much work with too much risk. Instead, our clever thief works alone by shopping at an online diamond store. He fills his shopping cart up with thousands of dollars of diamonds, then on checkout…
- … he pays for a five dollar bottle of jewelry cleaner which the store accepts as payment in full for his diamonds. And the store will happily ship his diamonds directly to the dock where his getaway boat is waiting. Sounds like something out of the movies, right? As far-fetched as it seems, this type of checkout flaw exists in real online stores and has been demonstrated to actually work (although not with diamonds to my knowledge).How likely do you think it is the store will eventually detect and track down the problem? If the store believes every order was paid in full, is it even possible to discover the thief?
- Today we’ll be talking about integration flaws that allow attackers to shop online for free (or nearly free).I’m Bil Corry, a security engineer at PayPal and with me today is Harry Xue, an integration engineer also at PayPal. I’ve asked Harry to be here because I anticipate you’ll have integration questions after hearing this talk.Harry will be joining us later during the Q&A.
- When you leave here today, I have one goal: awareness. I want each of you to become aware that these types of integration flaws exist, they exist in real world and may exist in even your own store.It is my hope that you will return to your office and look for these flaws, as they are often subtle and difficult to find. And as we will cover, there is risk of severe financial loss.
- A quick warning about testing. Please only test websites that you own or have explicit permission from. It’s illegal in many jurisdictions to test websites when you don’t have explicit permission. It’s not like a few years ago…
- … when law enforcement might have let you go while praising your mad hacking skills. If you test a website without permission or worse, if you defraud a website …
- … law enforcement will track you down. I do not want to get letters from you in prison. Only test website you own!
- We’ll be covering five flaws today. I’ll be talking about them from a high-level, and at the end I have a reference to a research paper that goes into more depth and covers other integration flaws. And of course, feel free to ask questions. I’ll be pausing at the end of each flaw to answer a few questions and have set aside a longer Q&A session at the end of the talk. Finally, I’ll finish with a few concluding thoughts.Let’s begin…
- The first flaw we’re talking about today involves an attacker skipping past the PayPal checkout, and downloading the digital good for free. It’s due to using a non-encrypted button.
- Let’s first cover how it’s suppose to work. The buyer clicks on the “Buy Now” button.
- The buyer then pays at PayPal for the digital good.
- The buyer then is redirected back to the store to download their purchase and the store has received their money.
- The delivery page will look something like this, where the digital good is downloaded directly from the site.
- Now let’s talk about how an attacker is able to defraud the store and get the digital good for free.First, the attacker extracts the delivery URL from the “Buy Now” button – don’t worry about the details of how this is done, we’ll discuss it more in a minute.
- Next, the attacker uses the delivery URL to go directly to the digital good delivery page, skipping PayPal entirely.
- Now let’s go back to that first step, where the attacker is able to extract the delivery URL. How does he do it?If you look at the HTML source for the button, it doesn’t appear to leak any data.
- However, if you use a tool such as FireBug, you’ll see the button as it looks to the browser. You’ll notice the button is now human readable, including the delivery URL.Even without the tool, there’s a snippet of JavaScript that is available on underground forums that will extract the delivery page and go directly to it, skipping PayPal’s checkout.
- What should the store do? Go back to PayPal.com and get a new Buy Now button, either an encrypted button or a PayPal-hosted button. That will prevent this attack from working.
- And just to give you an idea of how the encrypted button works, here’s the HTML source for an encrypted button.
- And here’s the same encrypted button when using a tool like Firebug. It’s identical to the HTML Source, it does not leak the delivery URL.
- The lesson for this flaw, if you have an older “Buy Now” button, return to PayPal and generate a new button that is either encrypted or is hosted at PayPal. If you need help with this, please see me after the talk.
- That concludes the first flaw. What questions do you have about this issue?
- The next flaw we’re talking about allows an attacker to pay any price he wants for an item. It involves the store failing to validate the payment total.
- Let’s see how it’s suppose to work. The store sends the buyer to PayPal.
- PayPal collects the payment for the order.
- PayPal then returns the buyer back to the store.
- And the store confirms that the buyer has paid.
- Now let’s look at what happens when the attacker goes through the flow. The store sends the attacker to PayPal, however the attacker changes the price in that request to any price he wants to pay. PayPal then collects that price as payment, then sends the attacker back to the store. The store then confirms it was paid and ships the goods to the attacker at the low-price.What should the store have done?
- The store should have confirmed that the payment amount matched their invoice.
- Very important, if you’re expecting 10000 euro then you must check that you received 10000 euro.The lessons for this flaw, always validate the payment amount matches the invoice amount, and make sure the currency is correct.You don’t want 10000 dollars if you’re expecting 10000 euros.
- That’s the second flaw. What questions do you have about this issue?
- Our third flaw today involves paying for one order, then being able to purchase unlimited orders with the only constraint they must be at the same price point. In this attack, the attacker is replaying the payment notification.
- Let’s walk through how it’s suppose to work. The store sends the buyer to PayPal.
- PayPal collects the payment for the order and sends the Instant Payment Notification to the store.
- PayPal then returns the buyer back to the store.
- And the store confirms that the buyer has paid by checking the IPN and the Order ID
- Now let’s look at what the attacker does. The attacker will actually go through the flow twice.In the first flow, the store sends the attacker to PayPal, however the attacker changes the IPN handler to point to his own webserver and he sets the Order ID to null.
- The attacker then paysvia PayPal for the order and PayPal then sends the IPN to the attacker instead of the store.
- Now we’re on the second flow with the attacker.With the newly acquired IPN, the attacker goes back to the store and loads up his cart again with the same items, but this time he skips past PayPal.
- And he submits the captured IPN directly to the store, pretending to be PayPal.
- The store confirms the IPN is valid, and that the invoice amounts match, and ignores validating the Order ID since it’s null in the IPN. The store then marks the order paid and ships the order to the customer. The attacker can repeat this as much as he wants.What should the store have done?
- The store should have verified that the IPN wasn’t previously processed. That would have prevented this replay attack using the IPN.
- Lessons, be sure to verify all information that you have available, including the payment status, the transaction ID, the receiver email, the payment amount, and the currency.
- That’s flaw number 3.What questions do you have about this issue?
- This fourth flaw is the one I opened the talk with. The attacker has two shopping carts, by paying for the low-cost item, the buyer can switch carts mid-transaction and complete it using the high-cost shopping cart. This is known as cross-session tampering.
- Let’s look at how it’s suppose to work. PayPal collects the payment from the buyer.
- The store notes that the buyer has paid in the session.
- PayPal returns the buyer to the store.
- The store cryptographically signs the Order ID and redirects the buyer to the checkout page.
- On the checkout page, the store validates the order was paid via the session and validates the signed order ID. As you can see, the store has gone to some effort to prevent the buyer from tampering with the order details.
- Since the attacker can’t modify the transaction, the attacker instead uses two shopping carts. The first cart is filled with high-cost items, then the attacker skips PayPal and goes directly to the page where the store cryptographically signs the Order ID.
- The attacker collects the signed order ID and aborts the final checkout.
- Next the buyer uses the second shopping cart in another browser and purchases a low-cost item.
- This time, the attacker goes through the entire flow until the final step, where the attacker substitutes the signed order ID for the high-cost shopping cart. Since everything validates, the store is fooled into accepting a low-cost payment for a high-cost order.
- The attacker can then repeat as often as necessary.What should the store have done?
- The store should have added a check to make sure the Order ID is associated with the session to prevent cross-session tampering. That would have prevented the attacker from using multiple shopping carts to fool the checkout flow.
- Lessons, validate that the Order ID matches the session, maintain state on the server, and reduce as much as possible communication via server-client-server.
- That was flaw #4. What questions do you have about this issue?
- Our last flaw involves purchasing a low-cost item, then using the PayPal token from that transaction to make additional purchases for free. It’s known as a token replay attack.
- Let’s see how it suppose to work. PayPal collects the payment from the buyer.
- The store records that the token is paid.
- PayPal returns the buyer to the store.
- The store confirms the token was paid and completes the order.
- Now let’s look at what the attacker does. The attacker will go through two flows. The first is to purchase a low-cost item. The attacker chooses a low-cost item, then goes to PayPal and pays for it.
- When PayPal returns the buyer to the store, the attacker will capture the token value for later use. The attacker will then receive their goods like a normal purchaser.
- The attacker now returns to the store a second time. This time, the attacker fill his shopping cart up with whatever items he wants. He skips past PayPal and instead jumps to the final checkout.
- The attacker uses the valid PAID token from the low-cost purchase to trick the store into thinking he’s paid for the current order.
- The attacker then repeats for as many free items as he chooses.What should the store have done?
- The store should have verified the token was associated with the current session and made sure that it was used only once.
- Lessons, do not allow token reuse and validate that the token is associated with the session.
- That was our final flaw. What questions do you have about this issue?
- For all these flaws, even with strong due diligence, there is a chance you will not be able to find and fix them all. But that doesn’t mean you can’t catch it after the fact. Always reconcile your PayPal transactions with your invoices and make sure they match. If they don’t, then you may have one of these integration flaws. It’s a great early-warning system and will help you prevent massive losses.
- For those of you curious about the technical details, the first resource is an excellent paper on integration flaws, covering what we spoke about today and more.The last two are the PayPal developer guides for our APIs, which contain additional security information.
- And because I’m part of PayPal’s security team, should you come across a security issue, here’s how to report it to PayPal.Spoof@paypal.com is for fake PayPal emails, be sure to include the message headers.Cred@paypal.com is for leaked PayPal.com credentials. Do NOT try them out first to verify they’re real, we won’t know if you’re trying to break in or helping us. Just send it to us and we’ll take care of it.Sitesecurity@paypal.com is for anything else, such as a phishing site.We appreciate and welcome your security reports, and thank you for helping keep PayPal safe for our 100 million users.
- At this time, I’ll ask Harry to join me. What integration questions do you have? Or questions about anything we’ve talked about today?
- Some finals thoughts – these flaws are real and exist on real commerce sites. Jeremiah Grossman of WhiteHat Security has a great motto, “Hack Yourself First”. Go back and look for these issues. And build a reconciliation process that can catch these exploits, so even if you miss an integration flaw, you can still detect it after the fact and correct it quickly.Now go prevent your own diamond heist. Thank you.
- Thank you!