Cross-Site Request Forgery (CSRF) in polonel/trudesk

Valid

Reported on

Dec 21st 2021


Description

There is a CSRF vulnerability which would allow an attacker to restart the server by simply having a victim with the appropriate privileges visit an attacker's crafted webpage.

The vulnerability exists when performing a GET request to the /api/v1/admin/restart endpoint

There is also another CSRF vulnerability which would allow an attacker to disable a victim's 2FA (/api/v1/users/<user ID>/removel2auth). This requires the victim's user ID, but this can easily be obtained by simply deleting a conversation with the victim which is a vulnerability that I described here: https://huntr.dev/bounties/74c6f886-2869-4b32-bef3-2cb3991a9311

Proof of Concept

for resetting the server:

//serverReset.html
<html>
    <form action="https://docker.trudesk.io/api/v1/admin/restart" method="GET"/>
    <script>
        document.forms[0].submit();
    </script>
</html>

for disabling 2FA:

<html>
   < -- change the user ID to the user ID of the victim for which you're disabling 2FA -- >
    <form action="https://docker.trudesk.io/api/v1/users/<user ID>/removel2auth" method="POST"/>
    <script>
        document.forms[0].submit();
    </script>
</html>

Impact

This vulnerability is capable of performing a DoS attack on the server which can have a major business impact. It can be paired with the XSS vulnerability that I found & reported previously to create an even more effective DoS attack.

For example, an attacker could craft an XSS payload that would automatically redirect a victim to their webpage where the CSRF attack that restarts the server would take place. The attacker could spam the victim with messages that contain the XSS payload. Then each time the attacker opens the message, the victim would be redirected & the CSRF attack would take place and the server would restart.

Occurrences

As we can see, the only protection in the code is verifying that the user ID passed in the URL matches the user ID of the person making the request. And if the user IDs do not match up, an error stating "Invalid Account Owner" is returned (lines 939-940).

Moving onto line 949, which is after all error checking is finished, there is no CSRF token check before setting the MFA to null (req.session.l2auth = null).

We are processing your report and will contact the polonel/trudesk team within 24 hours. 6 months ago
We have contacted a member of the polonel/trudesk team and are waiting to hear back 6 months ago
We have sent a follow up to the polonel/trudesk team. We will try again in 7 days. 6 months ago
1d8 modified the report
6 months ago
1d8 modified the report
6 months ago
We have sent a second follow up to the polonel/trudesk team. We will try again in 10 days. 6 months ago
We have sent a third and final follow up to the polonel/trudesk team. This report is now considered stale. 5 months ago
Chris Brame validated this vulnerability 5 months ago
1d8 has been awarded the disclosure bounty
The fix bounty is now up for grabs
Chris Brame
a month ago

Maintainer


This has been fixed in v1.2.2. I will update this report once it is released.

Chris Brame confirmed that a fix has been merged on 2512b8 a month ago
Chris Brame has been awarded the fix bounty
users.js#L937 has been validated
to join this conversation