The March 24th public disclosure of a MongoDB zero-day vulnerability (CVE-2013–1892) has been raising eyebrows and initiating discussion among IT security and developers alike. Here’s why we think it stands out:
- Sometimes developers think that NoSQL databases like MongoDB are more secure because they are not vulnerable to SQL Injection, which is one of the most dangerous web application vulnerabilities
- MongoDB usage has been growing and many people consider it to be the leading NoSQL engine.
- The disclosed vulnerability is extremely high impact, and very much exploitable. The shell exploit templates have been surfacing within days of the disclosure.
The main lesson learned for developers and architects is that out-of-sight/out-of-mind features are still a major source of vulnerabilities.”If it is not documented, it should not be accessible.”
Generic and powerful interfaces such as the exploited nativeHelper interface, are like wild beasts. No matter how confident you get in taming them, they can always come back and bite you. The only way to protect yourself is to lock them down and prevent access except for cases they are needed.
It is worth pointing out that the Rails YAML vulnerability we discussed back in February had very similar root causes. It was due to a generic and powerful interface left accessible by default.
On a side note, check out this interesting post I dug out from October 2011! It seems that the possibility of code execution for this interface was brought up a long time ago. Possibly since there wasn’t a Proof-of-Concept attached to it, it didn’t get the needed traction and nobody picked up on it. One might wonder how many issues are out there without a public disclosure, and what is the destruction potential if it is picked up by a hacker with malicious intent.