Accidentally (or because of some other tool’s poor design) open up a server to the WWW. But unauthenticated unfettered remote admin access by default?! Is it still a thing for Mongo? Oh my! I guess that’s what you get when the “conversion funnel” guys take over “engineering”
> Is it still a thing for Mongo?
No. Hasn't been for years.
> I guess that’s what you get when the “conversion funnel” guys take over “engineering”
That's also what you get when you post rubbish without even bothering to check.
When running inside a docker container this won’t be much use though as the container handles the port forwarding. It would be a much better default to ensure authentication by default, considering how widespread exploiting of this has become with bots.
You don't have to bind to 0.0.0.0:[port]. If you want the server to remain accessible only locally, bind the container to 127.0.0.1:[port]. Docker is not preventing anyone from doing this.
Yeah that's all fine and dandy, but the docker default is to bind to 0.0.0.0, so it really should be taken into account. I honestly would have to go and look up the flags needed to change the bind address, but I know the port ones (as I'm sure do many people who copy/paste docker lines from random repos), so it's still insecure for a common configuration/setup.
I've never quite understood the opposition to just shipping mongodb with authentication on by default. What sort of use-case does it solve by not requiring it, and is it worth all the bad publicity every time this crops up in a new exploit report?
Unless this is literally running on a single 1U host in some colo, there is no excuse for not having defense in depth. An old school DMZ if you are in a datacenter. A VPC if you are on the cloud. Then client certs for everything. Two factor for ssh. Auditing. These are straightforward to set up, with different options if you have time-but-not-money or money-but-not-time. If you have not-money-and-not-time then this i…
> there is no excuse for not having defense in depth. An old school DMZ if you are in a datacenter. A VPC if you are on the cloud. Then client certs for everything. Two factor for ssh. Auditing. Maybe there is no excuse, but literally every company I've worked for (including Fortune 500s) has been missing at least one item from your list. So "industry best practice" means committing less time and money than it would…
So the excuse is "my company doesn't take infosec seriously". Like every similar issue of "should do but don't" (testing, formal promotion processes, diversity, harassment response), you get to decide to tolerate it or get a job elsewhere. My experience is that the companies that take this stuff seriously also do a better job of converting my skills into cash, and as a result, pay me better.
NewsBlur's founder here. I'll attempt to explain what's happening. This situation is more of a script kiddie than a hacker. I'm in the process of moving everything on NewsBlur over to Docker containers in prep for the big redesign launching next week. It's been a great year of maintenance and I've enjoyed the fruits of Ansible + Docker for NewsBlur's 5 database servers (PostgreSQL, MongoDB, Redis, Elasticsearch, and…
I think I can imagine why you would need a combination of PostgreSQL, Elasticsearch, and Redis, but what problem does MongoDB solve for you?
These are crimes. Where is law enforcement? I am not sure why the public still gives them a pass and treats computer crimes differently. With the resources of the federal government, it shouldn't be hard to find and take down the criminals. Think of how easily the criminals exploit their victims - it is just as hard for the criminals to play defense as it is for everyone else.
Yeah, it's been more than hour. How dare the police not apprehend anyone yet!
> Heavy fine yes but not arrest AFAIK. Newsblur is an American org. GDPR is a foreign law that has no relevance to American firms lol.
> GDPR is a foreign law that has no relevance to American firms lol. I couldn't agree more with the spirit of your comment, but sadly the reality may be somewhat more nuanced: GDPR in the USA https://www.cookiebot.com/en/gdpr-usa/ " The GDPR has extra-territorial scope, which means that websites outside of the EU that process data of people inside the EU are obligated to comply with the GDPR. ... In fact, the very fi…
In other news, a company selling a GDPR compliance service is trying to scare companies into buying their service. Shocking to see!
In reality, a US business with no EU presence only has to follow US laws. The only "enforcement" power the EU has would be to order the website to be blocked in the EU, and I'm pretty sure they can't even do that.
I'm on the same side of the argument as you and indeed I believe I feel as strongly about it as you. Especially in regards to brushing it off, calling them script kiddies[1], generally being "well aw shucks aren't I great for not deleting my copy of the data, I'm so great"[2] about the whole thing grinds my gears too. I'm saying whoever is ransoming the data already has the data, the data is out of Newsblur's control…
There is a material difference to users between a single attacker having (and possibly ignoring) a data dump, and that attacker publishing that dump publically, or selling it to someone who plans to exploit its contents. The attacker has offered to not publish if they are paid. Their word probably isn't worth much, but $1,000 seems like an affordable sum for a business to gamble on them being honest about it. And if…
The fact that you believe paying the ransom is even an option shows that you really aren't even qualified to be discussing this topic. People with your mindset are a big part of the reason that ransomware is still going strong. The other big part is people who don't run their systems correctly in the first place.
> The likes of AWS already make it a bit harder to expose an insecure server Has this changed recently? S3 was a huge part of data leaks a few years ago, and that's basically a managed server.
Indeed, AWS has both made it more difficult to create a world-readable S3 bucket, and made it much more obvious in the UI. Some things I've noticed just clicking around the S3 console right now: - There is an account-level S3 setting to instruct S3 to ignore public access grants in all buckets in that account (i.e. no matter how bucket is configured, public access is impossible). - The list of S3 buckets in the S3 co…
And yet, I still came across one of these recently with vast amounts of absolutely radio active data in it.
I'm on the same side of the argument as you and indeed I believe I feel as strongly about it as you. Especially in regards to brushing it off, calling them script kiddies[1], generally being "well aw shucks aren't I great for not deleting my copy of the data, I'm so great"[2] about the whole thing grinds my gears too. I'm saying whoever is ransoming the data already has the data, the data is out of Newsblur's control…
There is a material difference to users between a single attacker having (and possibly ignoring) a data dump, and that attacker publishing that dump publically, or selling it to someone who plans to exploit its contents. The attacker has offered to not publish if they are paid. Their word probably isn't worth much, but $1,000 seems like an affordable sum for a business to gamble on them being honest about it. And if…
Giving them $1000 confirms the value, allowing them to list the dump at a higher price than the usual $10-50 spammers would pay (each) for the email addresses alone