

Ask HN: How databases are compromised? - smurfpandey

I just saw this: https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9277370  about SlackHQ&#x27;s database being compromised. I want to understand what are the different ways a hacker might get access to the database. As a general practice, you should put firewall in front of db to allow access only via your web servers. So what are the different ways to get access?
======
api
Depends on the database. In most cases it means someone got into the internal
backplane network and then accessed the database. Sometimes that requires no
authentication at all since people very falsely assume firewalled equals
secure.

Google "firewalking" for more sophisticated attacks against firewalls, but
usually a firewall can be breached via malware, phishing, specially crafted
web apps, XSS, etc. In general firewalls should be considered weak and only a
first line of defense. Far, far too much emphasis is placed on them at the
expense of host and app level security -- the "soft underbelly problem."

My personal and admittedly slightly fringe opinion is that you should harden
your apps, servers, and endpoint devices first and your network last. Assume
there is no firewall at all. Would your box be secure if it were just naked on
the Internet? If not, it's not secure.

Here's what I'd recommend:

\- Databases should always use local DB-level authentication. It's become
trendy of late to dispense with this. Some newer DBs I've seen don't even
support it, which is really stupid.

\- Keep DB passwords out of world-readable files, command lines visible to
'ps', and code repos!

\- The database should only bind to the backplane network device, not to
0.0.0.0 or ::0. Or if it's for local use only, use unix domain sockets or bind
to 127.0.0.1 or ::1.

\- There are some interesting local iptables rules you can use to control e.g.
which _users_ on a system are allowed to open sockets. These can be valuable
for loopback/localhost database access control as another layer of security.

\- Consider using VMs and/or containerization to separate concerns, though
this is not a panacea. Sometimes multiplying complexity and system count this
way actually makes it harder to defend your overall system, and of course
you're f'd if someone pwns the physical host. A bunch of isolated virtual
machines can also mean a lot of nooks and crannies where an attacker can set
up shop inside your network and hide out. I've heard un-policed systems/VMs
like this termed "crack houses."

\- Be very careful with backups. Sometimes people can compromise backups
instead of compromising your actual systems. Encryption is a good idea.

\- The meat sack between the chair and the keyboard is usually one of the
weakest links in system security. Beware of phishing attacks, social
engineering, and copy/pasting untrusted code off the net. The latter has
become a popular attack of late, especially given what can be done with
unicode and other weird tricks to hide stuff in innocent looking text. There's
also been cases where underhanded backdoors have been smuggled into
organizations via cooperative coding vectors like StackOverflow. Others
include just 'docker pull'ing any old Docker project off Docker Hub without
regard of what goodies may be hiding inside.

~~~
smurfpandey
Great advice. What about managed database service like amazon RDS. Can there
security group be breached? Also, how does this work there?

~~~
api
"Can there security group be breached?"

 _All_ security can be breached. The only 100% secure system is one that is
off.

In this case you are trusting Amazon to implement good host and network
security. The weak point here is the credentials you use to access the
database. Guard those with your life.

