Live data from Hacker News

Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

news.ycombinator.com

1–10 of 52 posts

Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#1
_TL;DR_: Stytch, a Login SaaS Unicorn, has no CRSF-protection in their authentication API and other questionable security practices, coupled with a nonexistent security policy.

First of all: Why am I posting this on Hacker News instead of disclosing directly?

From experience, a lack of security policies and of communication on existing vulnerabilities implies retaliatory practices when submitting vulnerabilities responsibly. Since MITRE CVE does not accept vulnerabilities for SaaS services, I figured that Hacker News would be the way to get Stytch aware of their issues without getting me in the crosshairs.

The setting:

A few weeks ago (in June 2022 to be exact) I was looking at different authentication services and Stytch was one of the services that got my attention. Stytch.com was founded in 2020 with over $125M [1] raised at a $1bn+ valuation [2].

Checking out what the fuzz was about I decided to look into their security practices. The lack of a bug bounty program (e.g. HackerOne), ethical disclosure policy, and security policy already left a bad feeling. But I was keeping an open mind and wanted to see what their API has to offer.

The scoop:

The most critical issue I came across was a complete lack of Cross-Site Request Forgery defenses. All of the provided authentication APIs (e.g. [4]) except for Social Sign-In are vulnerable to the most basic of login attack vectors: Login CSRF [3]. This can be used to steal credit card information, for example. CSRF is completely missing in all of the Stytchs API concepts, a major oversight in the API design.

Further I found that the OTP tokens sent via their "passwordless" email authentication were valid for up to 7 days and did not invalidate on use. Attackers may find old magic link tokens in the browser, chat, or email histories and use them to get a valid session. While this issue has been fixed since June 2022, the vulnerability was not disclosed to customers.

Recently, Stytch has introduced a concept from OAuth2 called PKCE - a spec that is difficult to master for everyday developers - into their non-standardized Magic Link API which does not use a three-legged delegation authorization mechanism. This is not a direct vulnerability per se, but at least a questionable choice in terms of security.

A full report can be found here for anyone interested: https://www.klgrth.io/paste/kmxof

[1] https://www.crunchbase.com/organization/stytch-auth [2] https://stytch.com/blog/announcing-series-b/ [3] https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf [4] https://stytch.com/docs/passcodes#sms_auth

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#2
Disclosure: I work for a competitor of Stytch, FusionAuth.

First, I'm sorry you felt you had to post this on HN to both alert users and not be retaliated against. I wish you'd had an avenue to disclose the issues less publicly. This would allow the company to fix them and not put their customers at risk.

I think every company, and certainly every auth company, should welcome security issue reporting, as well as take other steps like regularly paying for pen testing. We do ( https://fusionauth.io/security ).

However, I haven't looked at how Stytch implemented PKCE, but it can provide CSRF protection in some scenarios.

The bigger picture is that this is just another reason to not invent your own standards. Use options like OIDC and benefit from the hard won wisdom of others.

Other reading:

* https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... the OAuth Security BCP

* https://owasp.org/www-community/attacks/csrf CSRF attack description

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#5
Even more damning, looks like they got a SOC-2 Type II via Vanta in July of 2021. I just had to go through SOC-2 Type II at two startups in the last few years so I'm very familiar with the requirements. How the hell did they pass multiple penetration tests and a third party audit with such blatent security issues that an automated scan would detect? If anything, I think this says something much more damning about Vanta and/or about whatever penetration testing firm and/or auditor Vanta referred them to. It's on Vanta to make good referrals, it's on the auditor to validate that the pen tester is reputable and that all the requirements are met, and it's on the pen tester to actually check these things. All are at fault.

They never should have come close to passing. Details on the audit seem to be sparse so I can't call out the auditor and/or penetration tester but yeah this is a real bad look for the whole industry.

This really muddies the water for every security-minded startup that has taken the trouble to go through SOC-2 or ISO 27001. Very disappointing.

I guess billion dollar valuation really can buy you a rubber stamp.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#6
throwaway because I am in the ecosystem

Stytch... is a weird business. It's unclear to me why they were able to raise so much money with such low revenue. It's almost as if the VCs really really wanted them to succeed, hoping and dreaming and throwing cash into the fire.

there was a lot of fanfare around their founding team but not sure if they did that much at their previous employer.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#7
post #4

Could be an interesting marketing approach for a Security/Pen Test SaaS.. Heres a vulnerability, pay for our service and we'll provide a full report.

I get spam for that all the time - both for "pen test" and for "seo test".

Basically someone fires up a tool that checks a few things mentioned in a best practices document somewhere, scans as much domains as possible, and then sends out emails with the (subset of) the results.

Invariably, the results are false positives but hey, if you don't know that, they might get a new client. They'll file the (automatically generated) report and presto, easy money and a chance to upsell a retainer.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#8
Isn't CSRF basically dead after `SameSite=Lax` was made the default [1]? Also, magic links being valid upto certain time doesn't sound a serious vulnerability to me. If the hacker has access to person's email/browser, the game is already over. There could be valid reasons—UX-wise—for not making magic links invalidate on the first use. Ex, the user wants to login on phone with the same link. I am sorry, but the post sounds more like amateurs who love reporting things like this to companies, hoping one of them will fall for it and pay them a bounty.

[1]: https://scotthelme.co.uk/csrf-is-really-dead/

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#9
post #5

Even more damning, looks like they got a SOC-2 Type II via Vanta in July of 2021. I just had to go through SOC-2 Type II at two startups in the last few years so I'm very familiar with the requirements. How the hell did they pass multiple penetration tests and a third party audit with such blatent security issues that an automated scan would detect? If anything, I think this says something much more damning about Van…

Might be like the credit rating agencies in 2008. If you want to keep your business with venture backed startups, you better play by their rules.

Re: Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities

#10

Isn't CSRF basically dead after `SameSite=Lax` was made the default [1]? Also, magic links being valid upto certain time doesn't sound a serious vulnerability to me. If the hacker has access to person's email/browser, the game is already over. There could be valid reasons—UX-wise—for not making magic links invalidate on the first use. Ex, the user wants to login on phone with the same link. I am sorry, but the post s…

SameSite cookies don't protect against Login CSRF by default, since that attack can be triggered by a request that carries no cookies at all.

I wrote a bit about that here: https://simonwillison.net/2021/Aug/3/samesite/#login-csrf-sa...

Plus, SameSite cookies are only supported by 95% of worldwide browser traffic, according to https://caniuse.com/same-site-cookie-attribute

If you're a vendor selling SSO services I'm going to expect you to have 100% coverage on CSRF mitigations like this!

Post reply on HN