Catastrophic Security Desaster … There’s No Fix for Human Stupidity

I’m a Software Developer and Software Architect – and I’ve seen a huge amount of stupid bugs in code. But this time I see a bug in human behavior. Some German students of “The Center for IT-Security, Privacy, and Accountability” at the Saarland University discovered that thousands of databases from different companies are directly accessible from the internet (you should have a look at the original paper here: They did this research for MongoDB, but it seems that there are even more databases out there with critical data (like social security numbers and credit card information) that are currently accessible from the internet.

A default installation of MongoDB is without external access and without a password. “Partly secure” is worse than “not secure”, because many users think “partly secure” is equal to “secure enough”. In this case it’s only one single configuration value what makes the difference between “secure” and “open for everyone”. And when you want to split application server and database server, it’s really simple to just enable remote access.

CISPA does think that “… that responsible for these leaks is not MongoDB Inc. but the MongoDB users, who have insecurely configured the open source software…” – but I think this is not only the users fault. One design principle of software (whether it’s meant to be accessible from the internet or not) must be “secure defaults”. You should NEVER design your software in a way that it’s easy to be setup insecure. Especially with databases Microsoft did had a hard time realizing that the “sa” account without a password is a bad idea. They did come to this conclusion many years ago … but some other database provider still seem to think that developers and administrators are not clever enough to setup a password while setting up a database service. They don’t want to add the complexity to type in and remember (or document) the password to access a service while convincing the developer that using MongoDB (or other database engines) is a clever choice, because it’s so simple to setup.

Yes, it’s complete nonsense to open port 27017 for traffic from the internet into the DMZ or even worse into the corporate network. And yes, as an administrator you should ALWAYS become familiar with the products you allow in your network (being a “good” administrator is not about 8h a day looking at SCOM – it’s about constantly learning about the tools your users/developers do need and use). But in my opinion, it’s also up to the vendor of a tool to make it easy to use it in a secure way and to make it hard to use it in an insecure way. And in my opinion it’s complete nonsense to allow remote access to a “database” without any need of authentication – prohibiting such a nonsense must be done by the vendor in code and not only in documentation.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Sylvio's Infobox

Aktuelle Themen rund um SQL Server, BI, Windows, ...

Meredith Lewis

Professional Digital Portfolio

Vittorio Bertocci

Just another weblog

ScottGu's Blog

Just another weblog

AJ's blog

Thoughts and informations I think worthwhile to share...

Outlawtrail - .NET Development

Architecture & Design

SDX eXperts Flurfunk

Just another weblog

%d bloggers like this: