Extortionists competing to get paid for the same databases!
-
Now we get to witness competitive market value in action!
-
I seriously do not get how there are tens of thousands of databases open to the public.
I mean you have to try to fail that hard, IMO.
-
@JaredBusch said in Extortionists competing to get paid for the same databases!:
I seriously do not get how there are tens of thousands of databases open to the public.
I mean you have to try to fail that hard, IMO.
Probably just following a set of directions that don't include changing the defaults.
Probably a ton of WordPress installs/routers/etc with admin and admin out there, too...
-
@BRRABill said in Extortionists competing to get paid for the same databases!:
@JaredBusch said in Extortionists competing to get paid for the same databases!:
I seriously do not get how there are tens of thousands of databases open to the public.
I mean you have to try to fail that hard, IMO.
Probably just following a set of directions that don't include changing the defaults.
Probably a ton of WordPress installs/routers/etc with admin and admin out there, too...
The MariaDB database behind my WordPress installs is behind a firewall. It is not directly publicly accessible.
The MongoDB running my company blog is behind a firewall. The blog pages use it. It is not open to the public. I did not open or close anything. It is a default install.
-
I don't know.
THis is all the article says...
"If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them."
-
@BRRABill said in Extortionists competing to get paid for the same databases!:
I don't know.
THis is all the article says...
"If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them."
A server with no firewall maybe.
-
@BRRABill said in Extortionists competing to get paid for the same databases!:
I don't know.
THis is all the article says...
"If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them."
Yeah, they are taking things out of context. A default MongoDB on an non-default server that has no firewall. MongoDB does not open the firewall ports on a default install.
Beyond that, MongoDB that is open to the public is not yet installed completely. "Default settings" is misused here. "Settings used before installation is complete" is not the same as "default." Most modern NoSQL Clusters use a "database network" approach that requires you to configure the networking as part of the basic install.
No different than someone saying that a SAN is "wide up and browesable by the public" over the Internet by default. Um, yeah, if you forget to have it on its own network. But that's a ridiculous thing to claim.
-
@JaredBusch said in Extortionists competing to get paid for the same databases!:
@BRRABill said in Extortionists competing to get paid for the same databases!:
I don't know.
THis is all the article says...
"If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them."
A server with no firewall maybe.
A server with no firewall, with an incomplete installation.
-
@scottalanmiller said in Extortionists competing to get paid for the same databases!:
@JaredBusch said in Extortionists competing to get paid for the same databases!:
@BRRABill said in Extortionists competing to get paid for the same databases!:
I don't know.
THis is all the article says...
"If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them."
A server with no firewall maybe.
A server with no firewall, with an incomplete installation.
Talk about IT fails, geesh.
-
Explanation of the vulnerability
Understanding the hack
The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections.
Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections.
Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step.
Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye, you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates.
The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB. In other words, this is something that everyone could have known about for a while.
-
@Romo said in Extortionists competing to get paid for the same databases!:
Explanation of the vulnerability
Understanding the hack
The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections.
Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections.
Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step.
Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye, you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates.
The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB. In other words, this is something that everyone could have known about for a while.
That's not a vulnerability, that is STILL a half configured system AND no firewall on the server. And MongoDB 2.6 is relatively old, we are on 3.3 these days. This is a database cluster component, not a complete database piece on its own. Whatever "security" professional is writing this piece clearly isn't aware of what they are writing about. What they write is half true, 27017 is listening on 0.0.0.0, but it does so for a reason and is only vulnerable in places where someone did not finish setting up their database AND their server. It's not a vulnerability in the product.
