Mass Assignment leads to Stored XSS in librenms/librenms

Valid

Reported on

Sep 21st 2022


Description

The application is vulnerable to mass assignment in the User object. A user is able to enable their own account and change their username. The username is not properly sanitized in the admin user overview, leading to a stored XSS attack.

Proof of Concept

Steps to reproduce:

1. Log in with an admin account.
2. Create a test user with the user role `Normal` & enable that user
3. Log in with the test user in a separate browser or private browser window
4. In the test user session, go to `/preferences`
5. Change the test user's password and log the request in Burp. The request should be an HTTP POST request to the endpoint `/users/<user_id>`
6. Send the request to Burp Repeater. Modify the request body to contain the values `enabled=1&username=<script>alert(document.location)</script>` & send it
7. In the admin sessions, go to `/users` to trigger the XSS

PoC request:

POST /users/4 HTTP/1.1
[...]
Cookie: laravel_session=[...]; XSRF-TOKEN=[...]

_method=PATCH&_token=e0NktnwRhcR1Jh2xpex25AFZ67PCsR4X72T3rd0F&enabled=1&username=<script>alert(document.location)</script>

Screenshot 1 (Manipulated Request)

Screenshot 1

Screenshot 2 (XSS)

Screenshot 1

Impact

A user is able to enable their own account if it was disabled by an admin while the user still holds a valid session. Moreover, the username is not properly sanitized in the admin user overview. This enables an XSS attack that enables an attacker with a low privilege user to execute arbitrary JavaScript in the context of an admin's account.

Occurrences

A user should not be able to enable their own account. If editing of the other fields is intended, the username should be properly sanitized to avoid the XSS vulnerability.

We are processing your report and will contact the librenms team within 24 hours. 2 months ago
We have contacted a member of the librenms team and are waiting to hear back 2 months ago
We have sent a follow up to the librenms team. We will try again in 7 days. 2 months ago
We have sent a second follow up to the librenms team. We will try again in 10 days. 2 months ago
We have sent a third and final follow up to the librenms team. This report is now considered stale. 2 months ago
Tony Murray validated this vulnerability 2 months ago
vautia has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Tony Murray marked this as fixed in 22.10.0 with commit 09a297 2 months ago
The fix bounty has been dropped
This vulnerability has been assigned a CVE
UserController.php#L183 has been validated
vautia
2 months ago

Researcher


Hi @maintainer, thanks for validating this report as well as the other three reports. Can we disclose these reports and maybe also go for CVEs? :)

Tony Murray published this vulnerability 16 days ago
to join this conversation