Steps To Find Vulnerabilities In Meteor Web Framework Code Review

We must thank IT virtualization as it led us to cloud technology. Today's IT infrastructures are already running their mission critical business applications on virtual machines.

Like the physical infrastructure, virtualization is also cursed with cyber security challenges. This article talks about a typical open source virtualization solution and depicts the steps to secure its.

Vulnerabilities in meteor framework

Meteor, or MeteorJS, is a free and open source isomorphic JavaScript web framework written using Node.js. Meteor allows for rapid prototyping and produces cross-platform (Android, ios, web) code. It integrates with MongoDB and uses the distributed data protocol and a publish subscribe pattern to automatically propagate data changes to clients without requiring the developer to write any synchronization code. On the client, Meteor can be used with its own Blaze templating engine, as well as with the angular or React frameworks.

Meteor is developed by the Meteor Development Group. The startup was incubated by Y combinator and received $11.2M in funding from Andressen Horowitz in July 2012. Meteor raised an additional $20M in Series B funding from Matrix Partners, Andreessen Horowitz and Trinity Ventures. It intends to become profitable by offering Galaxy, an enterprise-grade hosting environment for Meteor applications.


An exploitable security vulnerability has been discovered in Meteor through a downstream project's bug bounty program which affects a commonly used application configuration, and could be used to access users' private data or circumvent other protections an application may have in place.
By sending a specially crafted WebSocket payload, a malicious client can execute an update operation on individual MongoDB documents in violation of the collection's allow and deny rules, when particular third-party packages are installed. When the malicious WebSocket frame is evaluated against the developer-configured rules, the exploit disables specific rules which would have blocked the operation, thus allowing the operation to be executed.


While a default Meteor configuration using Meteor's core packages (for example, the accounts-* packages and allow-deny) is not automatically vulnerable, the exploit becomes possible when certain commonly-used third-party packages are also installed.
An application may be affected if it utilizes a MongoDB collection's Mongo.Collection#allow or Mongo.Collection#deny methods to define collection-level rules and also uses any third-party packages to enforce a schema on the same collection. This consideration applies whether the application uses .allow({...}) or .deny({...}) directly, or the third-party packages manage the collection's allow or deny rules on its behalf. Furthermore, Meteor.Collection is a (deprecated) alias for Mongo.Collection and is therefore subject to identical considerations.

Only Mongo update operations for documents which a user was allowed to update are affected. In the case where an update is allowed, this exploit may permit updates to unexpected parts of that document. This nuance becomes particularly relevant if an application has top-level properties which dictate a user's permission level, such as an isAdmin (or similar) field.

Other protected operations such as insert, remove, or fetch are not affected.
If an application does not use any Mongo.Collection#allow methods directly or indirectly, we have no evidence of exploitability. Additionally, if a collection explicitly denies all updates with .deny, then it will not be vulnerable.
If an application includes one of the following third-party packages, combined with allow rules without explicit deny rules (as outlined above), it may become vulnerable. The packages themselves are not to blame, though their presence may enable the exploit. These particular packages were chosen according to their popularity, not for any special role or fault in the exploit. Other packages which provide similar functionality should also be regarded with caution:
aldeed : collection2 or aldeed:collection2-core (or any other package which may be used for schema validation and enforcement): While these packages are functioning as designed, in some configurations they remove certain update parameters, which can change the behavior of the update. A collection which has not had a schema attached to it (for example, using .attachSchema) should not be vulnerable.
ongoworks:security : Versions of this package after 2.0 no longer create allow and deny rules automatically, which means the exploit should not work, though appending allowInClientCode() to a normal permission chain may result in the addition of vulnerable allow and deny rules.
alanning:roles : This package stores permission information as a top-level roles property on the user document, which, if exploited properly, could be modified.


The vulnerability has been fixed with the release of version 1.0.9 of the?allow-deny?Meteor package.
Regardless of whether you believe your application is affected, we highly recommend any application update to?allow-deny@1.0.9.
After updating and deploying the fix, applications which match the criteria for being affected should audit sensitive Mongo documents to ensure no user permissions have been maliciously elevated and no sensitive fields have been modified.

Meteor 1.4 or later

The command to update the allow-deny package and patch the vulnerability is:

meteor update allow-deny
After running this command, please verify that allow-deny@1.0.9 was installed, either by examining the output of the command or looking at your .meteor/versions?file.

Prior to Meteor 1.4

Any application running less than Meteor 1.4 should update to at least Meteor 1.4.x and apply this update using the above instructions. Meteor versions prior to 1.4 utilize Node.js 0.10.x, which is no longer receiving security updates from the Node Foundation and might already be susceptible to security vulnerabilities unrelated to this disclosure.

Running an unmaintained Node.js version is not recommended!

Meteor fully believes in ethical disclosure of vulnerabilities by security researchers who notify us with details and provide us time to address and fix the issues before public disclosure.

Credit for the discovery of this vulnerability goes to Sam sun who reported the bug in Meteor as part of the Legal Robot bug bounty program they operate through Hacker one.
At Valency Networks, we understand your web application and perform framework specific checks mentioned above. Our expertise in this matter enables us to be very accurate in terms of our vulnerability findings.