DOS access to a user's account (Application-Level Denial-of-Service)

Hey Guys,

 Back again,Having no work to do so, narrating this.😑😑

 This is  a finding of just some days back. Before getting the whole situation correctly I was thinking that this is a "registration misconfiguration" but thanks to team that they investigate and clarify  the bug.

Reason to write this is to show that how strange behavior can be a big logical flaw, when ever you feel  dig deep why this is happening or discus with security team.

About Program (web application)

Bound by non disclosure policy so I will not include name. Application is Built to monitor AWS and optimize AWS bills and services, Like we have many member in project same here we can add members in it.

Vulnerability:

 The issue is very simple: During inviting a member Program's invite API does not check if the user exists in all 3 regions of AWS API's, so someone in region us-west-2 can invite a user that already exists in ap-southeast-2 which is  identified by  the code which causes this issue. So,during this process the code was not able to handle this exception and give permission. Bug can be used to DOS access to a users account and possibly other strange behaviors,  "Application-Level Denial-of-Service (DoS) High Impact and/or Medium Difficulty".

 

How I Identified:

By this strange behaviors-  

If a email is already registered by user with program and then that email accept a invitation to be a part of that organization then user can not login again by the true credentials once user logout from the invited organization account.

Normal situation:

A email is sent  to user to invite, user accepts invitation  and be a part of that organization  until organization admin revoke that invited member but this user cant make his own ac on this same email.

Summary:

(Only read if you have lot of time and you dint get the scenario) 

1) email:- account1@gmail.com - registered as "own ac user" in program as own account

password:-Password_for_own_account
password:-password_for_invited_organization

2) email:- account2@gmail.com - not registered as "own ac user" in program

password:-password_for_invited_organization

• when account1@gmail.com will accept a invite to be a part of any organization.
  1) will open the invite link and enroll with new password (password_for_invited_organization) to be a member of that organization.
  2) account1@gmail.com will when logout, user will not able to login again in that organization, Because the page/API for login in both AC is same

So when this user will use email:- account1@gmail.com and use  password:- password_for_invited_organization  credentials to login in invited organization,  application will not grant to login in invited organization because application check only his/her own account credentials. Application do not check email:- account1@gmail.com  password:-password_for_invited_organizationcredential to access in invited organization.

• When account2@gmail.com will accept a invite to be a part of any organization. 

           1) will open the invite link and enroll with new password to be a member of 
              that  organization.

           2) account1@gmail.com will when logout, user  will able to login again in that
               organization.

Now, This user account1@gmail.com can login again because user is only enrolled with invited organization so, web application has to check only one condition.

 Timeline:

1) Day 1 reported
2) Day 2 tag "need more info"
3) Day 4 provided info
4) Day 6 tag "Not applicable" ( because of not reproducible)
5) Day 7 gave more info
5) Day 11 external member added and confirms the issue and allotted bounty. 

From the bounty bought This