Online databases dropping like flies, with 10,000 falling to ransomware

http://arstechnica.co.uk/security/2017/01/more-than-10000-online-databases-taken-hostage-by-ransomware-attackers/

by SQL2219 • 10 years ago

237 149 10 years ago

arstechnica.co.uk

Will_Do• 10 years ago

I feel like this is a new golden age in being a blackhat. Back 5-10 years ago there was no IOT and all databases were password protected by default. Now we have:

1. IoT with basically no security

2. No(Auth)SQL.

Also, dev time has become so expensive, the InfoSec teams in the companies I've worked at have had shockingly low head counts for all the responsibilities they have.

bostand• 10 years ago

3. Bitcoin

213• 10 years ago

Indeed, bitcoin is the true enabler.

But the dangers are pretty high. You never know how ten years from now the digital trail you left comes back to bite you.

Cashing large amounts it's not trivial. Sure, you can meet in private locations with local bitcoin buyers, but when you have $1 mil to sell it gets tricky, there aren't that many buyers in any particular area. And then you have the problem of justifying how you suddenly have one million.

ycmbntrthrwaway• 10 years ago

Before bitcoin and even now there are options such as liberty reserve and web money.

nickjarboe• 10 years ago

The major plot point of Neal Stephenson's novel Reamde (2011) was people paying off ransomware in a MMORPG with in-game gold which was easily changed for real money. One of the characters makes the comment that ransomware was not possible until anonymous payment online could happen. It would be interesting to know when Stephenson became aware of bitcoin.

peterwwillis6• 10 years ago

It's been the golden age for script kiddies ever since fuzzing and injection became the most effective blind attacks. Who needs a database password when you have %27 ?

It used to be you had to actually break into a system to exfiltrate all its data. Now you just make an HTTP query. Owning a big system was really important because bandwidth and server space was expensive. Now you rent some VPS space with bitcoin you made from spam or DDoS-for-hire using someone else's botnet that had been sitting around with a default password, and use it to distribute pirated media like it's text files. Mass-scan for SQL injections, inject some malware you found on a forum, and amass a botnet to play with. What a time to be a script kiddie.

I'm not sure about the modern age, but to me the golden age of blackhats was pre-2003, when nobody was really watching their networks or systems and advanced techniques were everywhere with zero defenses. Metasploit and the age of shitty webapps and packaged malware ushered in the dumbing-down of blackhats as a general concept.

(Get off my lawn!)

matt40773• 10 years ago

I'm not sure if security didn't actually improve dramatically. Web frameworks seem to have SQL injection and cross-site scripting more or less under control these days. Cloud setups and containerisation should also help (servers are more easily rebuild and therefore more likely to be fully patched, infrastructure-as-code is easier to review, most servers/containers are only running one service etc.)

joering2• 10 years ago

Googling %27 didn't find much - can you elaborate?

simonjgreen• 10 years ago

It reminds me of the days of everyone running open WiFi or even wep

paganel2• 10 years ago

I run open WiFi at my home, I still pretend to live in a world where sharing your Internet connection is just basic human decency. I inspect my router's logs from time to time to check for huge blobs of traffic not coming from my devices, and that's about it.

chaotic-good2• 10 years ago

> No(Auth)SQL.

Absence or presence of auth is irrelevant. You're database servers, message queues and other infrastructure shouldn't be accessible from the internet. No auth protocol can protect you from this.

cm21874• 10 years ago

If the default settings are dangerous, then the product is to blame, not the user.

tzmudzin• 10 years ago

The interesting part is the relatively low ransom amount.

I understand it needs to be low enough to make payment an "attractive" option (at least compared to other means of recovery, if any...). But 200 USD is significantly less than the 500 USD ransom extorted from private PC users.

Should we conclude the extortionists expect the database content to be worth less to a company owning it than a private person is willing to pay for his/her pictures, music files and documents?

213• 10 years ago

If the data is valuable presumably it would have a backup.

Many of these could be caches, or rebuildable from other sources.

Many could be disposable.

Since you can't really know which database is valuable and which not, you sort of average the price, since this is volume game.

Or maybe he want's to give the impression that this is not very profitable, to keep others from doing the same.

g00gler• 10 years ago

I assume that's the case. Securing mongodb isn't rocket science, it's not all that different from any other database, so I can't imagine a business with any value has unsecured mongodb instances.

What I mean is, it's pretty ignorant that just because authentication isn't on by default you don't turn it on at all.

Even if you don't want to or don't think to configure mongodb itself setting up a firewall also seems to be common sense.

Thus, the only reason they'd be unsecured is they're either for random tests or hobby.

pjc50• 10 years ago

Hypotheses:

- A/B testing of ransom prices will happen

- the person paying the ransom is not the company but an employee afraid for their job

- companies more likely to be able to restore from backup

saycheese4• 10 years ago

It would be really hard to run an A/B test of any meaning since the value asked and the data would both vary; to do a true A/B test there may only be one variable, the populous must be very similar, etc.

PretzelFisch• 10 years ago

Once you agree to pay, they may come back with a higher offer. No reason to A/B until they have a live one on the line.

kukx• 10 years ago

"Promises to restore the databases in return for a ransom payment are dubious, since there's no evidence the attackers copied the data before deleting it."

I guess the high risk of getting nothing in return is affecting the pricing.

matt40773• 10 years ago

They should do a tit-for-tat data release. Pay 1/10 of the ransom, get 1/10 of the data.

88e282102ae2e5b• 10 years ago

It might just be as simple as $200 being a lot of money to the attacker.

johnmcaddaman• 10 years ago

Maybe, but the data in some of the mongo dbs listed on shodan didn't have anything good. Can't say all, but most of them were just random shit.

emiliobumachar• 10 years ago

For the sake of exhausting all alternatives, it could be a not-entirely-evil criminal activist who's not trying to maximize their gains at all.

The "tough love" approach to raising awareness about security.

tkyjonathan• 10 years ago

Absolutely ridiculous that MongoDB is this insecure by default.

peterwwillis6• 10 years ago

You expected a database sitting on the public internet to be secure? A very young one, no less?

Who is downvoting this? People who hate common sense?

abiox• 10 years ago

i can't downvote, but your question seemed like a nonsequitur.

jasondc• 10 years ago

+1 Ideally, databases should never have internet access

ivanhoe4• 10 years ago

How about expecting that DB doesn't bind to 0.0.0.0 by default and to force passwords to be set during the installation? Is that such an unreasonable thing to expect?

raverbashing• 10 years ago

"Recent" versions aren't. If you install .rpm/.deb versions you're also covered

(And anyone who deploys any service on an internet-facing server should know what they're doing)

See https://blog.shodan.io/its-the-data-stupid/

jlgaddis2• 10 years ago

(And anyone who deploys any service on an internet-facing server should know what they're doing)

I agree that they should. History has shown us, however, that they very often don't.

Cozumel• 10 years ago

If people RTFM it would never have been an issue.

beambot2• 10 years ago

Defaults matter. Been shown time & time again... and not just for computers (look at organ donation!).

lawn• 10 years ago

If people constantly misuse the design, the people isn't to blame but the design itself.

homakov• 10 years ago

No they shouldn't, that's not how secure engineering works.

threeseed4• 10 years ago

This is Hacker News not Fox News. At least be intellectually honest.

It's not insecure by default. It just binds to all interfaces. Apache and Nginx both do this and we don't consider them to be insecure. Should a database be doing this ? That's debatable since it's a tradeoff between security and ease of use.

But that said if you are running an internet facing server without a firewall then you will have bigger problems than just your database.

e12e3• 10 years ago

I've always thought that the biggest service openbsd did, was teach people to remove unneeded stuff and turn off unused services. Remember when people used to sneer that X years without remote root in the default install was no wonder, because the Base install didn't do anything useful?

I also don't get this "firewall" idea. Why make something listen for everything, and then place a system outside to restrict it? Why not just whitelist what you want to listen to in the first place?

Note, I get that binding an application to localhost and then letting a dedicated proxy do the heavy lifting to link up with other systems (eg stunnel or haproxy) - but what does packet level filtering really gain you?

In general I see firewalls as just adding complexity - one more source of bugs and potential mis-configuration. (Say the fun when ipv6 exposes the soft inner network that everyone thought was "firewalled" when in fact it just had broken connectivity due to chappy NAT borne from scarcity of routable addresses).

liveoneggs• 10 years ago

insecure defaults are a key driver for increased adoption! It's worked for, at least: mongodb, redis, jboss, and elasticsearch

kennysmoothx3• 10 years ago

Does anyone know of a "security checklist" one could follow for mongodb?

I have not used mongodb in any production environment but it would be nice to know what one should do to make it secure.

cpolis• 10 years ago

https://docs.mongodb.com/manual/security/ is a good start(not being glib).

kennysmoothx3• 10 years ago

Awesome! Thanks for the heads up

https://docs.mongodb.com/manual/administration/security-chec...

jlgaddis2• 10 years ago

I don't use MongoDB but other, generic recommendations apply and would likely go a long way towards preventing this:

- deny (all) incoming traffic by default

- permit only desired traffic (to specific ports) from specific hosts

- avoid binding (listening) to interfaces you don't need to

- set up / verify authentication is in place

In addition to the link to the security manual that cpolis posted, there's also a MongoDB Security Checklist [0].

[0] https://docs.mongodb.com/manual/administration/security-chec...

kennysmoothx3• 10 years ago

Thanks! I appreciate your recommendations!

elchief• 10 years ago

Step 1: Uninstall mongo

threeseed4• 10 years ago

Step 2: Spend thousands of dollars / hundreds of hours rewriting your entire app just because you didn't think to have a firewall on your server.

But seriously thank you for that stellar contribution.

threeseed4• 10 years ago

The trick is to never assume that anything you're running is secure. Because nothing ever is these days.

So the usual rules apply: (1) have a firewall with only the bare minimum ports open, (2) make sure everything you are running is on unusual ports especially SSH, (3) VPN, jump hosts or port knocking if you need remote access, (4) use something like Fail2Ban or Sentry.

semi-extrinsic• 10 years ago

Only allow SSH login using keys, never passwords.

angry_octet• 10 years ago

The unusual ports thing is just a total waste of time. If someone wants in they are not going to brute force your ssh password over the network unless you've use stupidly simple passwords. They might get a targeted attack via reused passwords, which an unusual port won't stop either. If you can't control that then use 2FA or force use of ssh keys.

rsync• 10 years ago

"Does anyone know of a "security checklist" one could follow for mongodb?"

Firewall, on the local machine ALL ports except for the ones that you expect to be accessed remotely.

This is for all hosts - even your laptop. Never mind mongo.

There is no reason at all to leave inbound ports open for requests you don't expect to service.

Further, and I know this makes peoples heads spin and they foam at the mouth, but for ports you do need open, but don't serve the public (ssh, for instance) set up a port knock. Now it's invisible and you don't care about the 0day for that service.[1]

[1] Stop. Take a deep breath. Re-read the above post and realize that I did not say to remove your login passwords and keys and rely on only the port knock for security. Take another deep breath. It's going to be OK.

astonex• 10 years ago

There's a helpful post here http://tgrall.github.io/blog/2015/02/04/introduction-to-mong...

iask• 10 years ago

A couple of things:

Person develops 2 or 3 apps, setup 2 or 3 databases and thinks he/she is a professional.

Many businesses and managers care less about security and more about getting the deliverables into production.

Many CEOs and managers lack the understanding that once you launch (app, store, website etc) it doesn't end there, instead, moves into maintenance.

My company just hired an external company to assist with our IT infrastructure. I was asked to meet with the person that showed up to begin the take over. He was not interested at all in understanding what we do as a business. If you don't understand your clients, their interests, their responsibilities and obligations then, simply put, they are fucked!

synicalx• 10 years ago

I see this sort of nonsense ALL THE TIME. Most of the work I do/have done is at non-tech companies, so no one above the 'team leader' level is even remotely technical. Any sort of security that costs time or money becomes either a joke ("You want us to spend money on what?!"), or is just ignored entirely.

In my experience the issue isn't so much that C's and managers lack understanding, it's that they refuse to acknowledge that they lack understanding and refuse to listen to people who do understand because it's "Just IT". This mindset is something I've seen backfire many times over the years, and in the end it always ends up costing more than just doing things properly in the first place.

/endrant

kazinator• 10 years ago

No excuse for not backing up an online db at least daily.

An irrecoverable disk crash could hold your db ransom for $Inf.

sakabaro• 10 years ago

People who administer websites that use MongoDB should ensure they're avoiding common pitfalls by, among other things, blocking access to port 27017 or binding local IP addresses to limit access to servers.

Misconfigured mongodb servers are the issue here, not firewall. Default mongodb shouldn't listen blindly to any connections though.

kahnpro• 10 years ago

I know a company that got hit by this. Through some mistake in configuration, they exposed their mongodb. What I understand is that the ransom request is a total scam, they didn't download or encrypt any data, just ran the drop command and inserted the ransom message.

But they didn't hit the oplog/journal, fortunately the full history (a few months of data) was still in the journal, so they were able to replay it (minus the drop commands) and restored their data.

Certainly scared a lot of people and (hopefully) taught a lesson about double-checking what's exposed to the internet.

spullara• 10 years ago

Blackhat hackers attained product-market fit in 2015.

cm21874• 10 years ago

I am not familiar with MangoDB but if 10,000 MangoDB are "misconfigured" then perhaps the defaults are to blame, not the users.

tracker1• 10 years ago

I think there is definitely a need for some work in this space.. but the fact is, there are a LOT of databases open to the wild. These are just the ones that didn't bother to set an admin password. They also didn't setup any firewall rules.

    0. upload client public key
    1. Setup SSH auth by cert/key
    2. Move SSH to non-standard port
    3. Enable passwordless sudo
    4. Disable password auth
    5. Setup firewall to only allow the new ssh port
    6. Setup port knocking

Those are the first few things I do on a server... As locked down as I can get before doing anything else... of course, I'll also put the new ssh port and an alias in my ~/.ssh/config ...

Most cloud providers offer the option to have a "private" IP space... just having a proper firewall ufw/ipchains/iptables, etc config can go a long way towards helping lock things down.

Of course, that only goes so far when you aren't using passwords or TLS for client/server communications. But it's better than leaving the front door open with a sign saying as much.

andybak• 10 years ago

Several people below mention the ransomware aspect of this is a scam and no data is ever returned.

This is ironically a good thing as it poisons the well for 'legitimate' ransomware. The less people expect paying up to restore their data, the less people will pay up and the less viable ransomware is as a business model.

Online databases dropping like flies, with 10,000 falling to ransomware

Related Stories