Hacker News new | ask | show | jobs
by pqdbr 71 days ago
Recently we suffered a different kind of subscription bombing: a hacker using our 'change credit card' form to 'clean' a list of thousands credit cards to see which ones would go through and approve transactions.

He ran the attack from midnight to 7AM, so there were no humans watching.

IPs were rotated on every single request, so no rate limiter caught it.

We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.

We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.

Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.

We never thought this could bite us this way.

Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.

Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.

This is a big deal. Payment processors can ban you for allowing this to happen.

7 comments

Being used to validate stolen card numbers has long been a problem; we've had to put in a number of defenses to fight our way off whatever list of "easy sites" these folks maintain. I hadn't thought about the "change card" path though...another bit of time spent away from what our business is really supposed to be doing...
We solved this by introducing a silent block. If the system notices unusual behavior (too many payment attempts per user, for example), it no longer sends the payment attempt to the provider. Instead, it idles for a second or two and then just fails with a generic “payment declined.” Most attackers don’t notice they’re being blocked and just assume all credit cards are bad.
Sounds like any per-user detection wouldn't have worked in this case.
the "notice unusual behavior" is the hard part
thousands of $1 charges and refunds in a 7 hour period seems unusual to me. then again, i've never run a site that received thousands of charges ever, so seeing it in a few hours would be obvious.
Genuinely asking, are you a product manager? You’re giving me flashbacks to all of the PMs who suggested a 2-3 branch decision tree for a complex classification problem, because that’s what struck them as intuitive. We are just a few baby steps away from reinventing the entire field of fraud detection within this thread.
Sir, I resent the implication! I do not lie with such swine!

It's easy to say that every site must add protections against every single type of attack, except it's impossible for site owners to be experts in fraud. While credit card processing vendors are expected to be experts in fraud. I ask you where in this situation would be the better place to implement fraud detection? Of the two places, whose more financially at risk?

:)

I think we’re 100% in agreement: let the payment processors handle the fraud. Except payment processors unfortunately hold all the cards and will shut your site down if you don’t comply with their standards :(

Well, what you can do is notify the card issuer about those cards that went through, so they can mark them as stolen. That surely will make the hacker really happy, and discourage them of doing it again :)
So you mean you are keeping full card numbers somewhere in your logs to... fix some potential security issue...?
>Hey mr processor, the cards for transaction numbers x...y are stolen.
I'm assuming there were transaction IDs provided that can be given to the processor. If they can't do anything with the IDs, then that's a pretty broken system.
If you are the processor, yes, I guess. If you aren't, then you can provide the transaction ID to the processor and let it handle that part.
Pretty sure this goes against PCI DDS requirements to not store CC numbers.
Ouch. Just one credit card change per account?

This is one of those levels of monitoring that only gets put in place after such an event. Eg whole subsystem analysis - the change card feature being used 1000s of times (well, proportional to scale) in 7 hours is a massive red flag

> This is one of those levels of monitoring that only gets put in place after such an event.

For a website, yes. But honestly the credit card people and their infrastructure should probably _also_ watch out for this. They'd be in a much better place to detect these.

In a perfect world sure but in the real world if a processor catches something they will disable your processing and freeze any funds while making it a nightmare to remedy, so you really want them doing as little as possible.
They do, but they’re also just as aware that you could be the fraudster. So they put the punishment where it’s optimal for them. You are not inside their trust space.
Yeah, it seems like the site's processor should have noticed this one site sending thousands of $1 charges and refunds in a small window much more easily than the site recognizing it was being done. The processor has much more to loose multiplied across all customers making it worth their time
Cloudflare and any other anti-bot service is only good against people without willpower and knowledge to bypass them.

JS can be reversed, you clearly see what data points they use for detection. Anything can be spoofed and it will look like human behavior.

And if everything fails, you outsource it to AI - Always Indian :D

We had this happen on one of our sign up forms. I added a crappy open source image captcha and it went away. I guess whichever attacker was using us wasn't that motivated!
Did they use the same username/login every time?