12 ms·
A small Stripe fraud story
- edwinwee 4y agoYes, this seems like some sort of card testing attempt. Glad most of the fraud was caught. Not sure if you’re the author, but I’d like to see how we could’ve helped better. Could you forward me your thread with support at edwin@stripe.com? Also, if you haven’t implemented them yet, I might recommend looking into CAPTCHA and rate limiting to help prevent future attempts.
- jstanley 4y agoThe author is a friend of mine but I've passed your comment on to him. Thanks!
- edwinwee 4y agoAppreciate it. Just connected with him.
- jamesfinlayson 4y agoI saw this happen recently and the account holder only got notified of the massive increase in transactions a day after the API key was cycled. I heard about this happening yet again too last month - August seems to have been the month of Stripe key leaks.
- edwinwee 4y agoWould suggest using webhooks to customize and trigger alerts (https://stripe.com/docs/webhooks https://stripe.com/docs/webhooks), or turning on payment notifications (https://support.stripe.com/questions/set-up-account-email-notifications https://support.stripe.com/questions/set-up-account-email-no...). But the best way to prevent this is to absolutely make sure secret keys are kept secret! We try to scour for leaks in the wild—and notify the owner directly—but can’t see everything.
- neodypsis 4y agoI hate the so-called card-testers, they target small businesses and put them at risk of being banned by payment processors. Stripe at least has their Stripe Radar service, which is easy to implement. The problem is when you have to work with less technologically-savvy providers (e.g., if you are not US-based and they don't offer 3-D secure). I'm currently looking to develop an anomaly-based system to help protect from this kind of attacks. Any pointers to open-source references I can look into?
- fibonacc 4y agocould you look into 2FA before a customer is able to checkout? unfortunately the only way to stop this seems to be to increase friction and suffer the conversion rates.
- neodypsis 4y agoI don't see how enabling 2FA for the user accounts could stop card-testers. Can you perhaps elaborate a bit more?
- simlan 4y agoHe is likely referring to the 2 FA of the credit card company. When the payment is made you are prompted to confirm the transaction in the mobile app or provide another key. Most my cards do that nowadays but it depends on the merchant.
- neodypsis 4y agoOh, I see. My country's processors still doesn't support 3-D Secure 2.0 for mobile applications.
- Ayesh 4y ago> Not US-based Most of the European and Asian countries (apart from China) are far more advanced with payment cards. Many not only have their own networks with 0-1% commission, compared to 2-4% on Master/Visa/Amex, but also have long required 2FA for online payments. They might be less tech savvy users, in that they will be taken as a surprise if a car rental company posted a temporary authorization or if someone charged your new card after you renewed it (Stripe can do it), but SMS/email 2FA is quite frictionless nowadays. US was in fact one of the last countries to commonly issue EMV (chip) cards.
- stnvh 4y agoInteresting on stripe's response to this matter. 'Debug environment spew leads to unauthorised api usage' - unfortunate and well worn. Like a good pair of slacks, it was simply your turn to wear them this time
- pkrotich 4y agoStripe Radar works great for these kind of fraud. We have a SaaS service with 30-Day free trials, yet we sometimes see a subscriptions within seconds of starting a trial with a pasted card info - most of them are flagged for review by Stripe Radar. Most definitely worth 5 cents per transaction if you’re not on standard pricing. We’ve also disabled use of pre-paid cards because we often see subscriptions with the sole purpose of bypassing trial limitations (e.g api limit) to abuse our services. Another fraudulent scheme that’s concerning for Stripe users is someone doing chargeback after a year of subscription - banks always side with the card user (even with login logs) and Stripe dings you $15 per chargeback - unless you signed up for Chargeback Protection.
- chrisseaton 4y ago> with a pasted card info Is pasting your card info wrong? My card info lives in my password manager so yeah I paste it in.
- deleted 4y ago[deleted]
- pkrotich 4y agoI don’t believe password manager counts as a paste but Ctrl+V does… and one of the signals that the user might not actually have the card when combined with IP location of the user and issuer. In our case the card was issued by a Saudi Arabia bank but the user pasted it from Morocco.
- chrisseaton 4y agoI copy and paste it out the password manager. Are you expecting your customers to literally hand-type card numbers into a website every time?
- pkrotich 4y agoNo I don’t have it blocked on my end - I was just referencing one of the signals Radar considers among other things (I don’t have inside info). When a charge is denied or flagged for review you can see signals used to score the risk.
- fastest963 4y agoBe careful, you might be charged for Radar processing and that can easily add up to thousands in fees when card testers target your site. You should really be implementing rate limiting and CAPTCHAs to prevent any issues.
- sgc 4y agoHow do you use captchas when the requests are not even coming from your site as the article indicated? It seems odd this is even possible, does stripe not allow you to register an ip whitelist for token generation etc so that at least part of the payment process must go through your site? It seems like stripe rate limiting is just on the api level, so you would need to implement your own ip based rate limiter on you site, if you could force part of the process to go through it.
- nightpool 4y agoWell, obviously all bets are off when an attacker compromises your Stripe private key. I think that's a bit of an exceptional case, it's kind of silly to blame Stripe for it when such an devastating vulnerability existed in the site.
- sgc 4y agoI agree, and think the article writer agrees, it was mainly their fault (after the actual fraudster of course). I still genuinely don't understand why such a basic thing as ip restriction is not part of the security settings in stripe. I keep looking for it thinking I must be missing it. On the user's site, it could be as simple as a fail2ban rule to deal with most of this. And no doubt he is not the only one to have done such a thing, given the number of libraries and frameworks people throw on their sites, all with their own layers of configuration.
- hibikir 4y agoEven without the vulnerability in the OP, card testing is a real problem, and will remain a real problem for anyone relying on credit card payments without some form of one time passcode verification: It's just way too profitable, but banks in the US don't seem to want to add the necessary friction. A secondary problem is that ultimately those taking payments end up having to either track you, or side with someone that does, as a way to try to detect suspicious activity. Whether it's Stripe directly, or Google via reCaptcha, someone is going to have to be peering into the metadata of your transaction to try to figure out if it's really you that is calling, or it's a fraudster. And when the store gives that traffic to Google, they aren't just going to use it to make sure you are who you say you are. It's really unfortunate that the card issuers are the ones that can fix the problem, while in practice, it's companies further down the line that are paying for this in fraud and fraud detection spend.
- abigail95 4y agoDoes the US not have Mastercard SecureCode, or Visa equivalent? Every time I make a big purchase locally to a local merchant I have to use an OTP from my bank. American companies never want to do it. Apple wanted me to send them bank statements to verify I was the card owner. I asked their fraud team to just use SecureCode and they had no idea what I was talking about.
- alberth 4y agoIt’s available in the US but it’s a merchants choice to use it (unlike in Europe with PSD2).
- jhugo 4y agoWhy do merchants not use it in the US? It's pretty much universal in Europe and many countries in Asia in my experience, and it would probably almost eliminate this type of fraud. Most of my banks give me an in-app notification in the mobile banking app that I have to accept, but some still use an SMS OTP.
- Gaessaki 4y agoCard testers are so frustrating to deal with. We run a food delivery platform coop that processes orders and then delivers them on behalf of our restaurant members. We’re an ideal card-testing target for the perps before they hit up the Apple store. Only basic anti-fraud measures because we’re a startup and as a reward, free meal if they find a card that works. The hit is usually doubly painful for us as we not only lose the money, and get the 15$ Stripe dispute fee, but we’re still on the hook for the restaurant’s food and driver’s tip and need to pay that out of pocket, and we also lose valuable time from our drivers. So all in all, a 50$ fraud might cost us 80$. The signs are always obvious. Always ~70$ orders. Asking for the food to be delivered to a person across the street. Obviously fraudulent names and emails. Postal codes from elsewhere in the province. Orders from only certain restaurants. The problem, we always catch this too late through manual reviews. The restaurant usually has the food made before we find out. Despite mitigations, blocking blocks of addresses (digital and physical), Radar, etc. it’s still trivial to get around and make fraudulent orders if you’re able to constantly acquire a fresh supply of new cards. We can probably build more sophisticated detection mechanisms, but we haven’t gotten there yet. We’ve resorted to just cancelling the order quietly once we find out, without informing the fraudster. When they invariably call an hour later inquiring about their delivery (with a voice totally not matching the name), we either tell them we’re sending cops or cuss them out loudly. The silver lining is that it’s fun to witness their reactions on the phone when they realize they’ve been caught. The banks and police are no help. There are obvious fraud patterns (we’ve physically seen the crooks and know where they live) and we have compelling evidence we can provide, but they won’t do anything. Understandably, they’re fighting the problem at a much greater scale and probably don’t have time for small peanut cases like ours, but it’s still frustrating nonetheless.
- xmprt 4y agoI'm always surprised that cops don't care about "small peanut" cases because that's exactly how you get to the head of an organized crime ring.
- warent 4y agoThis sounds like the kind of thing someone says which sounds true and compelling in an exciting way, but is actually totally bogus :) Do you have any evidence of this being true?
- quelltext 4y agoThe title is a bit misleading. It's not wrong. Someone used a leaked API key to do card testing. That explains why someone might be interested in the API key. However, the bigger part of the story is that Laravel or whatever framework they used has a dangerous footgun that can easily lead to exposing secrets.
- ipaddr 4y agoA show debug info environment file flag? What would you replace it with? Two flags?
- quelltext 4y agoThe article states: > The environment configured on the live site was actually set to production, but the configuration also has APP_DEBUG=true set which is why a 500 server error response was giving such neat and useful output. It should be easy to add additional safeguards / warnings to prevent this combination from being set.
- ceejayoz 4y agoLaravel's debug mode [has a big warning in the docs about this](https://laravel.com/docs/9.x/configuration#debug-mode https://laravel.com/docs/9.x/configuration#debug-mode), defaults to off, and newer versions of Laravel use a different error module that doesn't show env vars.
- quelltext 4y ago> In your production environment, this value should always be false. If the variable is set to true in production, you risk exposing sensitive configuration values to your application's end users. It's still a footgun. It's pretty clear that this shouldn't be done, so why allow it this easily? In prod it should emit a log message saying "you cannot do that. if you really, need to follow these steps: <something cumbersome like placing a file somewhere with some dedicated end date for debug mode, or scoping rules>"
- jhugo 4y ago
- jokethrowaway 4y agoI wonder if the op was charged stripe fees for the refunds
- Gasp0de 4y agoWouldn't the first thing you do be limit the use of your API key to certain source URLs or IPs? Is that not possible with Stripe?
- kaftejiman 4y agoThis is most probably some folks extending their card checker service with any mean.
- ChrisMarshallNY 4y agoThe linked freeCodeCamp story was quite sobering. > Sites that aren’t static either need to be retired or kept up to date. In my experience, not just sites. I’ve released over 20 apps, but most have been retired. I’ve also learned to “churn” the apps I keep up. I once received an offer to buy one of my apps. It was a simple app that hadn’t been changed or updated in a couple of years (not necessary), so I suspect the hacker assumed it was moribund (it was not). They would buy the app, repackage it, with an extra “gift,” then use Apple’s update service to infect previous users. I guess they knew how to sneak the trojan past App Review. I ignored the request. I’ve learned it’s not a good idea to “poke the bear.” I watched a friend lose a large phpBB site, because he attacked spammers (and they retaliated). Scammers/spammers/fraudsters are getting really clever, these days, and they have learned to leverage sloppy coders.