Why are so many MongoDB databases left unsecured? Are they extraordinarily hard to secure? I imagine the people who are working with these databases must be aware of the numerous leaks, and pay close attention to securing the data, no?
Historically, MongoDB was unauthenticated and insecure by default. Because that's always a good idea.
You should never assume anyone is going to use your product in a secure fashion, and make it so that they have to at least make _some_ effort towards security.
Other than that, writing new features is fun, and you can get so many developers (that don't think about security) for the same amount of money as a good security professional, or a developer with even half an ounce of security sense, commands.
Security is always inconvenient, takes extra effort, and is invisible. So many companies and managers deprioritise it over more visible feature work, forgetting that security in and of itself IS a feature.
A lot of databases have this weird idea that there is some secure "internal network" and its OK to just pretend its 1995 in there. Antirez actively blogs about how "insecure" Redis is but its OK because just don't put it on the internet [1]. Others just avoid the subject completely. Never mind that internal networks get infiltrated all the time.
Security in depth is just not a thing a lot of people think about right now.
Okay, let's be fair, and I'm sure you realize this: having network ACLs that prevent unauthorized access is absolutely a good idea. "Internal networks" are not dead - they've become more advanced with "VPC" services and software defined networking.
Tunnelling Redis protocol over mutual TLS or something like that sounds like a good idea, but I don't think I've seen anyone doing that :(
Frankly, I would love it if there were a simple, open standard for authentication so every database didn't have to redo it. Maybe mutual TLS is that answer, though traditionally getting the infrastructure for that correct has been difficult.
Because if you make any mistake at all Redis will allow you shell access to the machine. This is not a theoretical attack Antirez tells you how to do it in his blog post.
And as you said, nobody bothers to tunnel with TLS. Your lucky if they even use a password.
Yeah exactly; which is why ideally, the container or box running Redis:
- Has practically nothing other than Redis on it.
- Has Redis running with minimal permissions and capabilities.
- Has no ability to make outgoing connections.
Which I'd say is vital security practice for anything running in production.
Few people will bother with TLS and you can see that based on the fact that I don't think cloud providers generally support it, but I personally did do this with stunnel at a time. Apparently Redis now recommends spiped, which looks good to me.
On an isolated network, even the compromise of a low level user/service account of a device/VM/container on that network gives you keys to the kingdom. A layered approach slows down or brings the penetration to a halt allowing time for detection and remediation.
In practice, people using AWS, GCP, Digital Ocean, etc. have options for setting more detailed network ACLs. Kubernetes implements a primitive called Network Policies that can also implement network ACLs, if you are running that.
In my opinion network ACLs are a pretty important part of a modern defense in depth, though you are absolutely right in that these measures are far from a panacea and usually only slow down horizontal movement.
They (for a long time) were default-no-auth is why.
Someone in a semi-technical role started one up, dumped a bunch of data on it, and it got left publicly accessible.
The problem is for people to be aware of the leaks, they need to be thinking about security at all, and I'd wager in most cases of mongo-based leaks, that wasn't even a consideration of the people who set them up.
“However, after further investigation and examination, DynaRisk updated its report to state that the combined number of emails leaked is 982,864,972 to be exact, and not 2 billion as previously reported.”
"Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag something, please don't also comment that you did."
