Friday, May 10, 2024

Using a feature to takeover your account - Hacking an SSO implementation

This week, I found a super cool bug that allowed me to steal any account in the vulnerable application. The target was a private bug bounty program (so no disclosure). This bug is a problem with the SSO implementation and how the application trusts the SSO server so much that it allows us to use it to steal user accounts.



Just an overview of the site I was hacking, the site is a multi-level user application, that allow users to be part of multiple projects (personal project, organization project). We can invite any user to be part of a project, the user will be in a state of "invited" until he opens the link that is sent to his email and accepts the invite.

The problem

While hacking this app, I found that I could enable the SSO feature without buying the premium account (this is also a bug, already reported and already paid out), I made a PoC for this first bug, I registered an account in Okta, and did the configuration with the app, so the users in my organization could log in using the SSO feature. One of the options that I have to configure before enabling SSO is the email domains that are able/mandatory to login using SSO.





If a user from my organization logs in with that email domain, he will be redirected to the Okta login page.


Well, I don't know if any of you, readers, already work with Okta SSO (this was also my first time), but the process to add a user in your Okta organization is really simple (maybe too simple). We can click in "add user", set the user's email and password to log in to our Okta organization, and that's it.


The email owner doesn't have to accept anything (which helps when importing users in a bulk process, I guess).

When configuring the SSO in the vulnerable app, we "create" a subdomain inside the vulnerable site, so we can use this subdomain for our users to login. (This is a config that must be set on the SSO server and client).


After configuring the SSO, the process will be: User access our subdomain of the vulnerable site → Redirect to our Okta login page → Login using Okta credentials → User is logged in and can access ALL his projects.

I think you may notice the problem. I didn’t at first, just reported access to the SSO feature and take the rest of the day to read Lord Of The Rings. When I stopped my reading session and was just walking in the room, something clicked in my head, "What if...?".

Exploiting

For those of you that are slow like me, the bug is a simple logic problem with a BIG impact. Let's think about the following scenario.

Bob is a legitimate user, using the app alone or with a team; he is an admin on his projects.

David is a bad guy with access to the SSO feature; let's see how David can steal Bob's account.

David starts by adding Bob to his organization inside the vulnerable app.




Now that Bob is invited to David's organization, he is in an "invited" state, but this doesn’t make any differences to David, the attack can continue without problem, and Bob doesn't have to accept the invite.

The next step is to add Bob to our Okta organization and set a password for him.


Now Bob is an user in our organization, inside the vulnerable app and inside Okta, Bob don't have to accept anything (imagine he is sleeping 😴 ).

Well, with our SSO configured, we can just start using it. David can access his new SSO subdomain inside the vulnerable app and be redirected to his organization's Okta login page.




David can use the email and password he set for Bob in Okta and log in inside the vulnerable app. Because there is no segregation between projects, David can log in to Bob's account and see all of Bob's projects.



Overview

Well, the process can be summarized in:
  • Attacker adds the victim to his organization inside the app;
  • Attacker adds the victim to his organization inside Okta;
  • Attacker configures the SSO feature;
  • The attacker logs in to the vulnerable app using Okta with the victim credentials.


Conclusion

I think this bug is wayyy more common than it seems, probably many applications will trust the SSO server to know if a user belongs to an organization or not.

Well, this bug was rewarded as a P2 (which I don't agree with, I think it is a P1 but nehhh). So keep hacking, and if you found a similar bug in the past, or if you find one after reading this post, send me a message, I would love to know!!!




Using a feature to takeover your account - Hacking an SSO implementation

This week, I found a super cool bug that allowed me to steal any account in the vulnerable application. The target was a private bug bounty ...