Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

NoSQL Injections in Rocket.Chat - 492

Paul Gereste - Sonar SourcePosted 4 Years Ago
  • Rocket.Chat is an open source chat platform for team communication (like Slack). Both of these vulnerabilities are NoSQL injections in MongoDB that have a devastating impact on the application.
  • NoSQL queries are typically JSON objects that are based to the query object. Because of this, if the user input is simply added to this object with type validation, the meaning of the query can be changed (similar to SQLi). For example, the operator {"$ne":1} would force the query to always return true instead of being a normal input.
  • The first NoSQLi is in the validation of password policies. The bodies token does not have its type validated but is added directly into the query. Hence, NoSQLi operators can be injected into this in a blind fashion.
  • To do something meaningful with this, we need to create a blind oracle, such as a timing change or something else. In this case, the regex operator can be used to character by character to steal a users password reset. This is a horrible vulnerability that allows complete compromise of any non-2FA account.
  • The second vulnerability is in the users.list function. This function takes a parameter that is used for the users collection information. Because not all fields in the collection should not be accessible by everyone, there is a denylist of items.
  • This denylist of items does not consider the usage of MongoDB operators though! So, we have the ability to add an arbitrary operator into the query being used. The regex way would work just fine but there's a better way.
  • The $where operator can take JavaScript expressions for more complicated queries but only within the context of the MongoDB instance. By triggering an error message within the query via the JavaScript in the $where clause, the response could contain secrets inside of it!
  • This attack allows for the leakage of a controlled field! Using this, at the admin password hash and 2FA secret could be leak. Game over!
  • Once the admin user is compromised, it is even possible to pop a shell on the system. This is done by adding incoming and outgoing webhooks via the Integrations, code execution is trivial to get on the host machine. So, this is kind of code execution by design.
  • At this point, the attacker is trapped within the Node vm module which is apparently not made for security. To escape the VM context, the attacker has to get access to objects from the parent context. By referencing parameters given by the parent, a simple 3 lines of JavaScript gives access to the host machine.
  • Input validation is incredibly important for stopping simple attacks like this. Checking for types and values can drastically reduce the exploitability of an application.