MongoDB on breaches: Software is secure, but some users are idiots You shouldn't expect to see any end to data breaches caused by misconfigured instances of MongoDB soon, the company's strategy veep has told The Register. MongoDB is a fairly popular document store in the database world, used by eBay, Foursquare, and The New York Times. It's open source, available under the GNU APL v3.0 …
There is an emerging breed of devops/microservice web developers who take the view that firewalls are an unnecessary barrier to all their microservices talking to each other.
The same people who spin up insecure db instances on cloud providers.
This is in the Getting Started doc, in a red panel:
Warning:
Do not make mongod.exe visible on public networks without running in “Secure Mode” with the auth setting. MongoDB is designed to be run in trusted environments, and the database does not enable “Secure Mode” by default.
Warnings will be ignored, even if they're in red boxes. Who would've thought it?
It should be secure by default, with a red box in the Getting Started doc saying:
Warning:
Mongod.exe is not visible on public networks as it defaults to “Secure Mode” with the auth setting. MongoDB is designed to be run in trusted environments, so if you are confident in your network security you can disable this behaviour like this.....
I think SQL Server allowed no password for the sa account up to version 7, thereafter the installation required an sa password if installed in dual authentication mode.
Because blank was the first thing to try if you didn't have the sa password available, and it often worked.
MySQL/Maria requires a password for root and it has to be reconfigured for remote access because by default it will only work when used from @localhost.
Nowadays, people just use Pa55w0rd because nobody would ever think of trying that.....
... because their default setups usually created known users with default password, including highly privileged ones. Oracle's internal/oracle and system/manager, SQL Server's sa without password, Interbase sysdba/masterkey and so on.
Almost all of them understood it was a stupid practice and now require a password to be set, while non-critical accounts are disabled or no longer created.
And MongoDB didn't learn the lesson? Making the database inaccessible but from localhost is not the answer - it was a just a bad habit of the LAMP stack where the database was on the same host of the web server - every other databases usually resided on their own hardware and needed to be accessible on the network to be useful (sure, that network should not be the Internet...)
Most naive user will just make the database available on the network to access it and won't change/set default password if not explicitly asked.
Sure, you can blame the user just like those who didn't change their default Oracle passwords had to be blamed, but a lazy setup which just set default weak and known password is to be blamed as well.
Mongo have a point in that developers don't generally think about security- especially with the 'move fast, break things' mentality being shorthand with some as 'build shit, be sloppy' but equally it's nowhere a well thought out fresh out of the box experience. Very clear they're developers have never actually had to setup up a sharded cluster from the install or have any experience of secure environments or defense in depth. Silly things like being able to set the username and password to the same value, have multiple security schemas (do they apply it on the root or the db level? For some that's not clear and the documentation is poorly written).
Time for Mongo to grow up and hire some experienced hands who have gone through all the SQL injection instances and learned from those bitter and painful experiences. Could also do with hiring better documentation writers who actually have to follow the guidance they give before publishing it as it's all over the place.
Being fair to Mongo as well- it's a damn sight better from a security perspective than ElasticSearch (they didn't have ANY security until they bought someone who was tacking it on top- recipe for disaster in the short and long term as it's not built in at the ground floor), or Redis' reliance on Network ACLs (because you couldn't possibly spoof that...). In fact, if you merged Redis with Mongo and gave them some half sensible developers who have eaten the dog food they might have a far superior offering than the SQL crowd. But security is seen as a resource drain not a feature because it's not sexy for screen demos for the sales guys.
No, you didn't read the article "simple as creating a password", "since then our most popular installer, RPM, makes it so you cannot connect to MongoDB remotely ". And that's about the RPM installer only, what about the others?
I read 1) Mongo does not have a password until you create one 2) Its security just installed relies only on not being accessible outside the host - something most user will change ASAP to use the DB, while not setting a password....
It's really not different from the old habit of default known password.
"Sure, you can blame the user just like those who didn't change their default Oracle passwords had to be blamed, but a lazy setup which just set default weak and known password is to be blamed as well."
Car analogy time.
Kid, fresh out of college, buys first car. Just because it can do 180mph doesn't mean you should. Especially if it comes with a 70mph governor which you choose to by-pass. Driving lessons? We don' need no steenkin' driving lessons!
It's not as if people, devs, both new and old, don't know of the dangers out on the Internet Superhighway. Even the mainstream news carries stories of data breaches.
This doesn't surprise me at all. It's always good fun to port scan your local network ranges, those just outside your own front door. You can find some very interesting stuff that's unprotected, I've found MP3 and video NAS boxes with tons of media, lots and lots of printers ( wtf would you connect a printer direct to "da toobs" for? ), quite a Windows servers, all wide open.
Developers in particular were too afflicted by myopia, focusing on developing their applications, while “security isn't something they focus on until the end,” according to Stirman.
But in a previous article some nob executive said that operations was easy.
Oh well, just publish it. We'll figure out how to fix it later and blame ops when it is borked.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
