Skip to content

Kimai API returns timesheet entries a user should not be authorized to view

Moderate severity GitHub Reviewed Published Mar 27, 2024 in kimai/kimai

Package

composer kimai/kimai (Composer)

Affected versions

< 2.13.0

Patched versions

2.13.0

Description

Summary

The permission view_other_timesheet performs differently for the Kimai UI and the API, thus returning unexpected data through the API.

Details

When setting the view_other_timesheet permission to true, on the frontend, users can only see timesheet entries for teams they are a part of. When requesting all timesheets from the API, however, all timesheet entries are returned, regardless of whether the user shares team permissions or not.

Example:
There are projects P1 and P2, Teams T1 and T2, users U1 and U2 and Timesheet entries E1 and E2. U1 is team leader of team T1 and has access to P1. U2 is in Team T2 and has access to both P1 and P2. U2 creates E1 for P1 and E2 for P2.
In the UI, U1 with view _other_timesheet perms sees E1 as he is a part of T1 that has access to P1.
In the API, however, he has access to E1 and E2.

Additionally, if U1 is not a team leader T1, he does not see any timesheet from a user other than himself in the UI, but still all timesheets in the API.

PoC

  • Give a user view_other_timesheet permission
  • The result of the UI and the API call to /api/timesheets?user=all differs in the data that is being returned

Curl command:

curl -X 'GET' \
  'https://kimai.instance.com/api/timesheets?user=all' \
  -H 'accept: application/json' \
  -H 'X-AUTH-USER: username' \
  -H 'X-AUTH-TOKEN: api_token'

Impact

This is at least an insufficient granularity of access control weakness. People can see timesheet entries they are not supposed to.
This greatly affects the confidentiality of timesheet entries.

Restricting API access to administrators is also not a valid solution, as API access is needed, for example, to use the mobile app.

References

@kevinpapst kevinpapst published to kimai/kimai Mar 27, 2024
Published by the National Vulnerability Database Mar 28, 2024
Published to the GitHub Advisory Database Mar 29, 2024
Reviewed Mar 29, 2024

Severity

Moderate

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
Low
Privileges required
Low
User interaction
Required
Scope
Changed
Confidentiality
High
Integrity
None
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:L/PR:L/UI:R/S:C/C:H/I:N/A:N

EPSS score

0.043%
(10th percentile)

Weaknesses

CVE ID

CVE-2024-29200

GHSA ID

GHSA-cj3c-5xpm-cx94

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.