Hacker News new | past | comments | ask | show | jobs | submit login

So...Golden SAML isn't a vulnerability, as the CyberArk article quoted in the post reiterates, it's a type of attack that requires completely comprising the box before using. Unless I am misunderstanding something, I don't see any particular flaw, per se. As Microsoft (mocked in the article) would say, it's not crossing a security boundary. SSO will ALWAYS have this particular tradeoff. If your SSO infrastructure is compromised, everything that uses it is at risk of being compromised.



Yes, it requires getting admin to the AD FS server https://www.netwrix.com/golden_saml_attack.html which is kind of glossed over but surely is the real "hack"?


Exactly! AD FS is part of Tier 0 in the same way as Active Directory itself and needs to be treated and secured as such. Of course, security goes a long way when it's part of a holistic approach like zero trust.

Mitigation is also not really possible when using SSO. One way would be to require the target service to require a second factor in addition to a valid SAML token, but then each user needs to keep current its second factor, whatever it might be, in each target service. This get unmanageable quite quick not to mention that there are basically no SaaS or self-hosted applications out there that support SSO and a second factor at the same time.


Yes, that's what I understood too. The article seems to exaggerate some points, and this is one of them.

It's like creating an attack called "GOLDEN ADMIN". If you have admin credentials, you can log in as the admin and do anything you want! Wow!

(I know that letting attackers authenticate to anywhere without generating logs is bad, but still... i agree with the parent reply)


Sounds like the vulnerability was one within AD FS and that exposed the private key, making golden SAML possible.


It was the SolarWinds hack that gave internal access and potential admin rights. It's no different than if a domain controller gets compromised. The attacker has gained control of the keys to kingdom; it's an inherent risk to SSO.


> If your SSO infrastructure is compromised, everything that uses it is at risk of being compromised.

Really? Can you not think of any approach that gives SSO and accountability?

I think there are




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: