Account takeover of existing HackerOne accounts through SCIM provisioning

How it was found

After numerous attempts and understanding, I was able to take over existing user accounts through SCIM provisioning.

When using SCIM provisioning, the following must be met:

• Verified domain.
• Working SSO configuration.

Initially, I thought this would automatically be a certain loophole. In my first attempt, this was the procedure used for testing:

1. Import organisation users into Okta.
2. Receive an error stating that existing users don't have matching email domains to the verified one on file.
3. Change the email.
4. Instead, a new user is created in the organisation's users page.

After many attempts, I figured out how to change the sequence to:

1. In Okta, create a user whose email I control, say [email protected]
2. Import organisation users into Okta.
3. Assign the victim account to the created user in step 1.
4. Change the email parameter field to [email protected]
5. Change password.
6. Bingo!

I then thought this looked too easy, so I assigned the user access to Okta and tried to log in via SSO, but it failed and did not work. Why?

Two fields in Okta are of importance: username and email.

{F4416609}

{F4416611}

• If the attacker with verified domain as verified.com adds a victim as [email protected] to Okta, you will get an error that ato.com does not match the H1 verified domain settings.
• If the attacker with a verified domain as verified.com adds a victim as [email protected] to Okta and then changes the username and email to [email protected], it will instead create a new user in the H1 organisation.
• If the attacker with verified domain as verified.com adds a victim as [email protected] to Okta, with the username as [email protected] and email field as [email protected], the victim's email will be changed, AND no notification will be sent to the victim (issue 2)
• Now the attacker wants to log in. If the attacker wants to do so via the SSO provider (Okta), they can't add the victim to the Okta directory since the username [email protected] has already been imported and is in use.

{F4416607}

• So the attacker sets a password reset, which also does not send a notification to the user! (issue 3) Rather, the new email is controlled by the attacker.

Setup:

Before you proceed, have the following setup:

1. A sandbox program setup from here and don't delete the demo members.
2. Contact HackerOne support to activate SSO and SCIM provisioning for your sandbox program.
3. Set up SSO with Okta
4. Set up SCIM in Okta
5. Added users.

Steps To Reproduce

1. Go to the Okta directory and add a user with an email you have access to.
2. Go to the Okta application configured for Hackerone SCIM provisioning and import users.
3. In your imported users, assign the user [email protected] ( or any other user if the demo member is deleted)
4. Under the Okta application configured for Hackerone SCIM provisioning, tap on the Assignments tab, then the pencil icon to edit.

{F4416681}

5. Look for the email field and change it to what you control and in line with your verified domain.

{F4416680}

6. Save.
7. It will automatically sync.
8. Reset the user password, and you should be in.

Proof of concept:

███

Impact

Why I think this is so critical is that apart from taking over user accounts, take note of EVERY new organisation, sandbox alike, there are two users present by default:

• Demo Triager [email protected]
• Demo Member [email protected]

The above are always present and already members of the sandbox, private, and public organisations unless removed. (I tested on an old sandbox I own, wish I didn't delete them.)

All the attacker has to do is import these default members, leave the username unchanged, change the email, password reset, and they are in!.