Security vulnerabilities

Hi Cyril,

The mentioned report only states half of what we reported here, and the mentioned report doesn't even explain any exploitation scenario, we think for that reason you made the report invalid, but we shared much more than the mentioned report. We shared how this can be abused to generate pre-authentication account takeover of any upcoming account, by combining this email verification bypass + (either access token creation/adding user with full permissions to the victim account by attacker which remains in the account as we tested), this will give persistent access of the victim's account to attacker eternally, also this can be abused on mass users as there is no validation for mass account creation. We know email verification bypass was not that harmful, but since the other things mentioned here, can be abused for pre-auth account takeover scenarios like https://www.vaadata.com/blog/what-is-pre-account-takeover-exploitations-security-tips/ Thus we reported it, hopefully you'll re-evaluate the report based on this information.

Looking forward to your response.

Thanks,
Cipher Warriors Security

We do not consider not verifying email addresses as a vulnerability. It has been reported many times before, e.g. https://security.alwaysdata.com/task/13.

Regarding pre-auth account takeover, your very own link states that "The platform must allow SSO authentication", which we don't.

Hi cyril,

Allow me to clarify, this vulnerability class is confusing for many people, because it's farely new.

The idea is,
1. an attacker is able to create and get access of an account of victim. the attacker can in anyway leave something, to get persistent access of that account.
2. In future date victim comes and recovers the account, and starts to use that account.
3. And, if even after the victim recovering the account, if attacker is able to access the account/or it's data/or anything belonging to the user, then that creates a shared account/data access scenario between the attacker and the victim.

The mentioned url is only one way to get a shared access of account, that specific example is applicable for targets which has social login. But, in Alwaysdata's case the scenario is completely different, you know logical bugs are never the same, but what's important, the shared account access should be there after victim recovers their account, and in Alwaysdata's case the shared access can be created with generating access tokens on the victim account, as well as if the attacker let's say adds another user to this victim's account attacker@gmail.com and gives him full permissions, so when in future victim even if recovers the account, but the access token will be there (which gives the attacker persistent access), also the added user by attacker will have persistent access of the account, are you getting my point, the idea is 'shared-account access' with any means. And, in different workflows that comes differently. Hopefully, you did understand it this time. right? :)

And, many companies prefer to not even implement email verification, but sensitive actions in those cases are always behind email verification wall, like in this case creating access token or adding user should be behind email verification wall, or old access tokens should always be revoked when a user changes their password, which will avoid the shared account access scenario. Do you need anymore clarification? if yes, we're here to make this understandable to you, this is a business logic bug so never stays same, but probably you're now getting the idea of the exploit:)

Thanks,
Cipher Warriors Security

Hi Cyril,

Do you have anymore queries regarding this? We hope, you were able to understand the vulnerability.

We're looking forward to hearing from you, on how you plan to approach it.

Thanks,
Cipher Warriors Security