Enterprise messaging platform forced to spill secrets

NoSQL bugs in Rocket.Chat left servers open to RCE attacks

Two newly patched bugs in Rocket.Chat made it possible for attackers to mount a series of attacks that ultimately led to remote code execution (RCE) on host servers.

Rocket.Chat is a popular open source enterprise messaging platform whose customers include Lloyd’s, Lockheed Martin, and the University of California, Irvine.

Three-stage attack

Rocket.Chat uses the MongoDB NoSQL database to store its data. During an examination of Rocket.Chat’s source code, researchers at SonarSource found two NoSQL injection vulnerabilities in the web interface that enabled attackers to send arbitrary commands to the backend database.

Adversaries could exploit the bugs to hijack user accounts, escalate privileges, and execute arbitrary system commands on the host server, SonarSource found.


RECOMMENDED Making justice secure again: How New Jersey Courts tackled the rush to remote working at the start of the Covid-19 pandemic


The first vulnerability was in the password reset API and was accessible to unauthenticated users. An attacker could exploit it to leak password reset tokens and hijack unprivileged user accounts.

Having gained authenticated access to the API, the attacker could then exploit a second NoSQL vulnerability to leak the email, password hash, and 2FA secret of any account. The attacker could use this to hijack an admin account, even if it was protected by 2FA.

Finally, through the admin account, the attacker could use Rocket.Chat’s ‘integrations’ feature to create a webhook that sends system commands to the host server.

Circumventing 2FA

The first vulnerability could only be exploited to hijack accounts not protected by two-factor authentication (2FA).



It should be noted that Rocket.Chat enables 2FA by default, although server admins can decide to override the default and users can always choose to disable 2FA.

“The recommendation is always to make the use of 2FA mandatory by default and educate the users about the importance of having additional security mechanisms enabled,” Bruno Cestari, security engineer at Rocket.Chat, told The Daily Swig.


Read more of the latest database security news


“Even the scenario of a low-privileged user not using the 2FA can be dangerous because if an attacker hijacks any trusted account, it can be used to perform social engineering inside the company to exfiltrate private data.”

The second vulnerability was even more critical because it circumvented all forms of 2FA.

“In this case, 2FA does not really protect admins, or any other user,” Paul Gerste, vulnerability researcher at SonarSource, told The Daily Swig. “Attackers can leak all data that is associated with a user, including 2FA-related information.”

The threat of NoSQL injection

Researchers at SonarSource helped the Rocket.Chat team patch both NoSQL injection vulnerabilities by implementing type checks and stronger restrictions on input parameters for the vulnerable web APIs.

“It seems that NoSQL Injections are not as well-understood as SQL injections among developers,” Gerste said.

“There are also fewer libraries (at least in the JavaScript/Typescript ecosystem) that help with securely handling NoSQL queries with user input than there are for SQL. We don’t think that Rocket.Chat is an outlier here, we would expect to see similar issues in other projects of that size.”

On a brighter note, Rocket.Chat’s Cestari underlined the power of open source security.

“[SonarSource] reported [the vulnerabilities] in a very detailed way, providing all information we needed to reproduce the issue,” he said.

“That was ultimately useful for our team to understand the problem and work on a fix. This case is an important example of how open source projects can contribute to the security of our community.”

Full technical details can be found on the SonarSource blog.


READ MORE Cockpit CMS flaws exposed web servers to NoSQL injection exploits