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. a year ago
A GitHub Issue asking the maintainers to create a SECURITY.md exists a year ago
We have contacted a member of the librenms team and are waiting to hear back a year ago
We have sent a follow up to the librenms team. We will try again in 4 days. a year ago
We have sent a second follow up to the librenms team. We will try again in 7 days. a year ago
We have sent a third follow up to the librenms team. We will try again in 14 days. a year ago
Tony Murray validated this vulnerability a year 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 a year ago
The fix bounty has been dropped
UserController.php#L183 has been validated
vautia
a year 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? :)

This vulnerability has now been published a year ago
to join this conversation