“PwnDoc is a pentest reporting application making it simple and easy to write your findings and generate a customizable Docx report.– Official README.md
The main goal is to have more time to Pwn and less time to Doc by mutualizing data like vulnerabilities between users.”
We at the DGC wanted to streamline our documentation and reporting processes and decided to setup our own internal instance of PwnDoc in order to deliver high quality reports in less time for our clients.
In this process, the following security vulnerability was discovered.
Incorrect Access Control Vulnerability (CVE-2021-31590)
PwnDoc through 2021-05-12 has incorrect JSON Webtoken (JWT) handling, leading to incorrect access control.
With a valid JSON Webtoken that is used for authentication and authorization, a user can keep his admin privileges even if he is downgraded to the „user“ privilege.
Even after a user’s account is deleted, the user can still access the administration panel (and add or delete users) and keeps complete access to the system.
The flaw exists because the backend only verifies the JWT itself but misses essential checks against the database to verify that the stored data in the JWT is still applicable.
Furthermore the project used hard coded JWT secrets within the code so the generated JWTs stay valid after the software was re-deployed.
Tested version: Latest available as on 2021-05-12
In order to demonstrate the vulnerability, two admins need to be created:
second.admin logs in and get’s a valid JWT
Main Admin changes permissions of second.admin to only user rights:
Although second.admin should only have user permissions, he can create a new admin:
The main admin checks that something suspicious is going on and deletes all other users:
Even deleted, the second.admin keeps his admin permissions to view, modify or delete all other data:
Even after deleting all data and rebuilding the docker images…:
… the second.admin user still has admin rights – even though no user exists in the database!
The authentication and authorization processes must be adjusted to approve that the provided data within the JWT is still valid. In order to fix the issue the user’s existance, role and permissions have to be verfied on each request.
If the verification fails the application must deny access to the backend.
An related security fix for this vulnerability was submitted to the project maintainer, after several attempts to contact failed:
The author submitted also a pull request that changes the storage location and provides a fix so the security-related data (certificates and JWT-secret) are changing on each new build or setup as long as there are no overwrites done by the administrator:
|2021-01-21||Security flaw found and verified|
|2021-01-22||GitHub Security Advisory created / PR#74 submitted to pwndoc|
|2021-01-25||Created demo writeup for the repository maintainer|
|2021-01-26||@github-staff commented to the Security Advisory and asks to create the security advisory not from the fork but from the official repo instead|
|2021-01-27||Project maintainer contacted via GitHub asking to create a related security advisory directly within the pwndoc repo|
|2021-03-17||Project maintainer contacted via email asking to create a related security advisory directly within the pwndoc repo|
|2021-04-22||Requested CVE from MITRE|
|2021-04-23||Received CVE-2021-31590 from MITRE|
|2021-05-11||Created security fix for CVE-2021-31590|
|2021-05-12||Published security fix and vulnerability description|
Discovered and reported by Sascha Brendel | Senior IT-Security Engineer & Pentester