
Online databases dropping like flies, with 10,000 falling to ransomware - SQL2219
http://arstechnica.co.uk/security/2017/01/more-than-10000-online-databases-taken-hostage-by-ransomware-attackers/
======
Will_Do
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
3\. Bitcoin

~~~
21
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.

~~~
branchless
What actually happens when you try to get out of bitcoin? Let's say I put in
$5k a few years back which is now worth $100k. I have to go on the exchange
and nominate a bank account then sell then they transfer say USD into my
account? At this point is this "capital gains" taxable?

Assuming I'm willing to pay the tax if it's due has anyone had trouble with
authorities questioning your new cash pile say if before this you had no real
money and lucked out on Bitcoin?

~~~
yason
You have proof of this as the bitcoin transactions are public. The taxman can
verify that you bought your coins five years ago and sold them this year.
Multiply those by the BTC exchange rate five years ago and now, and it should
be obvious that you put in 5k and got out 100k. You could've bought stock, or
other currencies, but you bought BTC and it skyrocketed.

~~~
lisper
> The taxman can verify that you bought your coins five years ago and sold
> them this year.

How? The public block chain only contains records of how coins moved from one
wallet to another. It doesn't have any information about who those wallets
belonged to, or what the terms of the transaction were. Maybe the coins were
sold for fiat currency, or maybe they were compensation for goods and
services. There's no way to know just from the information in the blockchain.

[EDIT] Let me make this more clear: it is easy to anonymize BTC. It is so easy
that the technique even has a name (bitcoin tumbling) and companies that will
do it for you as a service (e.g.
[https://bitlaunder.com](https://bitlaunder.com)). (I thought this was common
knowledge around here.) In the face of these facts, how is the IRS going to
enforce the tax code against a someone who tumbles their coins?

~~~
beambot
Even if you received the BTC for goods and services, and then held them for 5
years and they 20x in value... you still owe capital gains. It's like saying:
5 years ago I sold goods and services for $100, bought stocks with the $100
and now that stock is worth $2000. When you sell the stock, you pay capital
gains on $1900; you also should've reported that $100 in revenue from 5 years
ago.

As for anonymity... you lose it when you associate a bank account to get
liquidity (as mentioned by GP: "nominate a bank account"). Of course, this
assumes you can't get liquidity in some other way... but that's non-trivial
with large qty of BTC.

~~~
throwaway91111
Sure. But the enforcement is said law of near impossible if you're trying to
avoid it and you find a willing BTC purchasing person.

~~~
obstinate
A good chunk of tax law is unenforceable if the evader is really clever.
That's like observing you can murder someone and get away with it if you leave
no evidence. But it's a big risk. You wanna risk jail to keep 15-18% extra? I
know I don't.

------
iask
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
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

------
kahnpro
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.

------
tkyjonathan
Absolutely ridiculous that MongoDB is this insecure by default.

~~~
peterwwillis
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?

~~~
jasondc
+1 Ideally, databases should never have internet access

~~~
monksy
Tell that to frontend javascript devs who think they don't need a back end
system.

Without a public facing DB they're pretty much dead in the water.

~~~
bartread
The more things change, the more they stay the same. I'm thinking of people
who back in the 90s/early noughties didn't want to bother with a middle tier
application, and instead talk directly to the database from their fat
clients(1) because it was easier.

(1) This, btw, is what many SPA are: fat client apps running within a browser.
When I came back to web development four years ago one of the biggest
surprises was how much like desktop development it had become in many ways.

------
sakabaro
> 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.

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

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

------
kennysmoothx
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.

~~~
threeseed
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.

~~~
angry_octet
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.

~~~
ivanhoe
True, but it doesn't stop people (and worms) from trying endlessly and filling
you logs with tons of rubbish that makes it hard to spot the real threats.

~~~
vacri
Fail2Ban helps there.

------
tzmudzin
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?

~~~
pjc50
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

~~~
saycheese
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.

~~~
matt4077
The "data" (the unknown variables) always varies. That's why you need n >> 1
in A/B tests. And you are only testing one variable: the asking price.

~~~
saycheese
Thanks, though what does "n >> 1" mean?

(Ask since to me it reads as gibberish and there's no way to Google it
myself.)

~~~
thmorton
Usually this notation ("x >> y") means " _x_ much larger than _y_ ," so you
need way more than 1 person to A/B test.

~~~
saycheese
Thanks. Normally need more few thousand to do a valid A/B test; meaning to me
the comment makes no sense.

------
andybak
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.

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

~~~
tracker1
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.

------
spullara
Blackhat hackers attained product-market fit in 2015.

