Verifying email bypass

How it was found

During an assessment made on a separate web-application using theirs customers to use Stripe for their payments, I detected a different behavior between account created using the standard interface and the account created using the connect portal.

Classic User creation.

Users can create their account using the classic interface on https://dashboard.stripe.com

[image]

By analyzing the traffic, we can see that the user is created with a POST request made on https://dashboard.stripe.com/ajax/register.

[image]

The new user can directly access to the dashboard without verify the email address entered in the creation form. However till the user has not verified the email, all features were limited to test data.

[image] [image]

These restrictions did not allowed to generate invoices or payments on behalf of not verified mail the mail entered during the creation process.

Connect User creation.

Stripe API proposed some Oauth features described in this article (https://stripe.com/docs/connect/oauth-reference).

The workflow begin with this type of url : https://connect.stripe.com/oauth/authorize?response_type=code&client_id={{CLIENT_ID}}****

Once the user reached this page, he has two options :

• Sign-in with an existing account.
• Create a new account.

The second option asked to the users several informations such as

• Personnal details (name, last name, adress)
• Business details (website, activities, company adress etc)
• Email adress
• Bank details

Second factor with SMS is required and verified for the account creation.

[image] [image] [image] [image]

Once all required informations has been filled and validated, the account is created using the API endpoint and the users is redirected to the client page with the access token generated.

[image]

By the way, by browsing the dashboard website, the user is connected with the new account.

Vulnerabilty.

Instead of the user created with the standard interface, the account created with the API can access to all Stripe feature such as :

• Creating invoices and send them by email.
• Creating subscriptions.
• Managing customers.
• etc...

The main concern is the email adress is not verified at this moment, it means that an attacker can impersonate a real company by spoofing the emails address.

Impact

In the POC scenario, I created the account [email protected] for Michelin Group company. Even if I don't have access to this email, I was able to spoof invoices for Michelin.

The invoices received by customers are valid because sent by Stripe and saying that [email protected] generated the invoice.

[image] [image] [image] [image] [image]

The generated invoice cannot be considered a spam as it was sent by Stripe...

To complete the report, I generated some little invoices to validate the payment and the payout to the attacker bank.

[image] [image]