|
Task Description
Description:
There is a logic flaw in the permissions system. When a user is deleted through the /permissions/[id]/delete/ endpoint, the system does not properly check if the requester is allowed to delete that specific user.
By intercepting the request and changing the id value, a user can delete the main admin — even if they don't have permission to do so. This can lead to full account takeover if the attacker had added themselves earlier as a user
Steps to Reproduce:
1. Create a new account on alwaysdata with the following email:
`ebrahimmagdy517@gmail.com`
(will be referred to as the **primary account** / Account A)
2. Inside the admin panel, go to:
`https://admin.alwaysdata.com/permissions/`
3. Add a second email address as a team member/user:
`testhackers663@gmail.com`
(will be referred to as (secondary account) / Account B)
4. Accept the invitation and activate Account B via the link received in email.
5. As Account A (ebrahimmagdy517@gmail.com), go to the Permissions panel again.
6. You will (see Account B) listed and a “delete” button next to it.
However, you **cannot delete Account A (yourself)** — which is expected.
7. Use Burp Suite to intercept the deletion request for Account B, for example:
POST /permissions/402834/delete/
8. Modify the ID in the request to match Account A’s ID (e.g.,402812 ):
9.Send the modified request. (It will succeed), even though you are trying to delete the owner of the project
10. As a result:
- Account A is no longer part of the project and has lost access.
- Account B now fully controls the project/domain (`aqaqwq.alwaysdata.net`) including settings, databases, and any hosted files.
Impact:
An attacker can exploit an IDOR vulnerability to delete the main admin account by modifying the user ID in a delete request. This leads to:
Full account and domain takeover
Loss of access for the original owner
Complete control over data, settings, and services
If an attacker gains temporary access to the admin’s email, they can add their own account, then remove the real owner — resulting in a critical security breach
Recommendation:
- Implement strict access control checks on the `/permissions/[id]/delete/` endpoint.
- Deny deletion requests for project owners, regardless of ID manipulation.
- Ensure server-side validation enforces user role & permissions.
- Consider using UUIDs or scoped IDs instead of numeric incremental IDs for more secure object references.
Proof of Concept (Video):
https://drive.google.com/file/d/1XMGLchHjj1Wl6EsgRPUZeniTexVCTJsb/view?usp=drive_link
Severity:Critical
|
