Cybersecurity

5695 readers

202 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Be respectful. Everyone should feel welcome here.
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
No Ads / Spamming.
No pornography.

Community Rules

Idk, keep it semi-professional?
Nothing illegal. We're all ethical here.
Rules will be added/redefined as necessary.

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Notable mention to [email protected]

founded 1 year ago

MODERATORS

[email protected]

Stripe API Key: $70k Stolen from CCs via merchant to debit card "Instant Payments" (webdesigneracademy.com)

submitted 1 year ago by [email protected] to c/[email protected]

9 comments fedilink hide all child comments

From the moment I began my freelance web design business back in 2014, I was collecting payments via Stripe and happily paying their processing fees for the ability to grow my business from just a desire for more freedom to running a company that employs women and supports them to create their own freedom and financial independence.

It never occurred to me that using Stripe to process payments would become one of the biggest risks to my small business.

My Stripe account was hacked due to Stripe’s lax security, over $70,000 of fraudulent charges were processed by the hacker through a fake connected account, paid out instantly to that person via Stripe’s Instant Payments to the hacker’s pre-paid debit card, and Stripe started pulling the money out of my business bank account to pay back the victims of the theft.

And Stripe says it’s my fault that my account was hacked and that I’m liable to pay back the victims of the fraud.

Listen to the full podcast episode or read on to find out exactly what happened and how to protect your business.

On a quiet Monday morning after the Easter holiday, I was sipping coffee on my couch in Columbus, Ohio like I normally do, snuggling with my dog and going through my normal morning entrepreneurial routine of checking emails and DMs on my business account when I see an email from Stripe with the subject line:

“Subject: [Action required] Closure of your Stripe account”

...

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 8 points 1 year ago (2 children)

I think that there's plenty of blame to go around, one of which is that Stripe's marketing makes payment processing with them seem like an easy, simple thing and it really really is not.

On the other hand, they're not wrong that if your API key is lost/compromised/found on github/the sticky note is stolen from under your keyboard then ultimately that's a loss caused by you, and they view it as you being responsible for whatever happens with your stolen credentials.

Credential management is not easy, and the default 'make this API key, paste it in this box, and then presto you take cards!' doesn't really explain what risks you're going to incur by doing that and how to mitigate them. Hell, engineers where I worked who knew better managed to do silly things with credentials - it's VERY easy to oops just once and not catch it, and hey presto, your stuff is now out there for everyone.

I spent a decade dealing with customer site compromises and it was firmly a case that about 30% of them were due to poor credential choice or management (shitty passwords, oops-my-api-key-is-on-github), 50% of them were due to unpatched or issues introduced by nulled plugins on Wordpress, and the remaining 20% was a mix of various CI (cough jenkins cough) tools used improperly, and just good old fashioned didn't-patch-it exploits live in the wild.

As another comment says, Woocommerce apparently DOES support limited API keys but their documentation doesn't actually acknowledge this because it's just "easier" to make people put in the keys to the kingdom than deal with having to support people who can't get it working and walk them through doing it a little bit more securely. I'm not really shocked: that's pretty normal behavior for a lot of developers who want to ship a cool thing, have it do nifty stuff, but don't want to have to support doing it securely because security is often annoying, adds complexity, and makes people unhappy. Until, you know, someone steals $70,000 and you get stuck dealing with it.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (1 children)

The problem is that creating a "Restricted API Key" means you have to tick "read" or "write" for dozens of different API "resource types".

So if WooCommerce doesn't document which resource types are needed, then "Restricted API Keys" are basically not supported because even security-conscious users cannot know how to produce a key that is fully functional yet satisfies the PoLP.

[–] [email protected] 5 points 1 year ago

Right, that was my point: Woocommerce doesn't want to tell people how to do it (even if the code itself would work with one) because then when it doesn't work they'll come to them and have to deal with the support.

And the fact it's dozens of resource types kinda re-states my commentary that it's not actually as easy or simple as Stripe makes it in the marketing, and Stripe also doesn't bother to explain to anyone how to safely use the API with restricted keys either; Stripe could just as easily write the documentation for Woocommerce given it's probably a fairly sizable portion of their small business self hosted customer base.

It's not all that shocking because rather a lot of software vendors behave in the same way.