Release v1.5.7
This release is a security release to fix two security vulnerabilities and add a missing check in the verification API.
- Fixed an authentication bypass via an HMAC signing oracle if the API debug mode is enabled. Found and reported by 5afagy via our security. Affected versions: > v1.1.0-beta.1 < v1.5.7
- Fixed the incomplete list of privileges, which led to a privilege escalation for reader project members. Found and reported by 5afagy. Affected versions: > v1.4.0-beta.1 < v1.5.7
- Added verification of the form signature in the verification process. This is not a security vulnerability, but an incomplete check. Found and reported by 5afagy.
- Added an alert below the API debug mode warning not to use it in a production environment.
- Added an exclamation icon in the project list for each project that has the API debug mode enabled.
We thank 5afagy for reporting, helping to understand, and fixing these security vulnerabilities and issues.
We recommend updating to v1.5.7 as soon as you can.
Details of the security issues
Description of the security issue
API Debug mode: The idea of the API debug mode is to help developers understand what is going wrong. Since the information mosparo returned was not masked, the same information can also be used by an attacker to create a valid API authorization.
Privilege escalation: The newly added submission rules (v1.5) as well as some functions of the optimized rule editor (v1.4) were not correctly protected. A project member with the role `Reader` can access and manipulate submission and field rules.
Risk assessment
Both risks are high and can be a real threat to a mosparo project. But there are very simple solutions for both risks (without updating to v1.5.7):
API debug mode: Disable the API debug mode in a project. The risk of this issue is eliminated. If the API debug mode was enabled in a productive environment, you should reissue the API keys.
Privilege escalation: Remove all project members with the role ‘Reader’. The risk of this issue is eliminated.
If the API debug mode is enabled, an attacker could send valid API requests for the verification, statistics, and rule package API endpoints.
In both cases, an attacker can change rules (privilege escalation) or rule packages (API debug mode). The other functionalities (verification and statistics API endpoints for API debug mode) do not change how mosparo works.
It is not possible to request any form or user data. Since there is no API endpoint for this, an attacker cannot request any form or user data. It is possible to request the metadata for a submission via the verification API endpoint, but the metadata is submitted manually from the frontend anyway (not internal metadata).
The API debug mode should not be enabled in a productive environment.
Changes to mitigate the security issues
API debug mode: The API debug mode now masks sensitive values. This is still helpful for a developer, but does not allow a valid API request.
Privilege escalation: The privileges were adjusted so that a project member with the reader role can no longer change the rules.
Future changes
For both cases, we’ve identified better solutions for the future. With our next bigger release, v1.6, we’ll resolve both situations with better options:
API debug mode: The API debug mode will be removed from mosparo. Instead, we’ll add an API response history that tracks API responses in a separate list in the administration area. Tracking can be enabled if required.
Privilege escalation: The system right now uses an ‘allowed by default’ system, which means that a reader always has access to every new route. With v1.6, we change that system to a ‘denied by default’ system, which means that a reader does not have access by default.