Skip to content

Project Takeover via IDOR in ProjectPermissionController

High
fguillot published GHSA-x8v7-3ghx-65cv Jun 6, 2024

Package

No package listed

Affected versions

<= 1.2.36

Patched versions

>= 1.2.37

Description

Details

The vulnerability is in the file app/Controller/ProjectPermissionController.php, more specically in the function addUser().

  • The users permission to add users to a project only get checked on the URL parameter project_id. If the user is authorized to add users to this project the request gets processed.
  • The users permission for the body parameter project_id is not verified while processing the request.

PoC

  1. login as admin and create two projects. For example 'secret' (id=1) and 'public' (id=2).
  2. create a new user 'unprivileged'
  3. add the user 'unprivileged' to the public project as a 'Project Manager'
  4. Start burp and login as the unprivileged user account
  5. Go to the edit permissions screen on the public project (/project/2/premissions)
  6. Enable intercept in burp
  7. Add the unprivileged user as a project manager again
  8. In the intercepted request change the project_id in the post request body from 2 to 1
  POST /?controller=ProjectPermissionController&action=addUser&project_id=2 HTTP/1.1
  [...]
  csrf_token=f607a23025aff9ab327e4e4cb0bac35b204705a2329fae4877bdc0c7ef839164&project_id=1&user_id=2&username=unprivileged&external_id=&external_id_column=&name=test&role=project-manager
  1. Go to the projects overview and see the private project, the unprivileged account is now a project manager for that project

Impact

This is an IDOR vulnerability with high impact.

An attacker with the "Project Manager" role on a single project may take over any other project.

Using this method the attacker could:

  • access information present in project the attacker should not have access to
  • change users access to project (e.g. kick them)
  • delete any ticket
  • edit any ticket
  • delete any project

Additional notes

addUser() does not verify the csrf_token parameter sent in the body.

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

CVE ID

CVE-2024-36399

Credits