How do Database breaches occur

[overwraith]

So I have been learning about databases for a couple of years now, and I have been wondering about database security. How do most of the database breaches occur in businesses? If you leave open an sql connection tool like sqldeveloper or sqlplus, etc, on a terminal is there any possibliltity of the database being breached through sql, (physical attack) or does an attacker have to copy the entire database file, and then decrypt it offsite? Frequently you hear about SQL injection attacks, those occurr over the web, and I am pretty familiar with how those work. I was under the impression that the majority of database vendors built in a layer of encryption into their database files, but I could be wrong. If anyone knows anything I would appreciate learning about how database security works.

[digip]

Most database attacks happen based on vulnerabilities in a few ways, depending on where you are accessing them. For starters, web sites that let you query the database via things like a search form or login form, are the most commonly attacked, but not always needed. It usually lies in not properly sanitizing the inputs and queries you ask them, which aren't filtering appended commands to force the site to spit out data. In many cases, it can also be done directly from the address bar, not requiring you to do a POST with a form, but rather a direct GET from the URL. Example would be something like a site that loads as follows:

site.com/page.php?index=1 where 1 is either a record in the database such as a user, or reference to data such as other pages or any data set for that matter. Things you often see in this resepct, people just brute the sequential records, such as with wordpress users as follows: site.com/?author=1 where record 1 is usually admin, and record 2, the next users name, and so on.

SQLi or sequel injection attacks have other methods that can check specific tables, by trying other types of attacks from standard queries to timed attacks. Joe McCray has a lot of videos on advanced SQL attacks and if you get a chance check out his talks and papers. Really good resources that in itself explains way more than I can go into.

Then there are flaws in different versions of different vendor database software as well, from MySQL to Microsoft's, to Oracle and so on, and they all have different ways of querying them as well as different versions have more specific related vulns. Not too long ago, there was one for MySQL that was easily exploited with a few lines of code, basically dropped you into a MySQL session. TrustedSec had written a quick script to test if servers were vulnerable to this attack, but if you had that specific version, you basically gave up the goods with this test -> https://www.trustedsec.com/june-2012/massive-mysql-authentication-bypass-exploit/

[overwraith]

That's interesting, so physical attacks are usually out of the question. I guess they would be with the DBs being usually in secured rooms. I was actually interested in something ducky related, but I guess it is probably not possible or advisable.

[no42]

Depends on how the database/system is implemented?

Part 1: Getting access to the database.

SQL injection through web applications is usually the most common ways, as web applications are so common these days. What people sometimes forgot is that binary/native/thick applications can also communicate with databases, and sometimes a network port is available. But usually if the application is in the public domain a web gateway is used to proxy the database traffic; as opposed to internal (eg. corporate) domains will have the databases accessible across an internal network.

With logical access to the database services; you can try many other attacks; brute-force the login, apply any remote code election exploits, some database versions even suffer authentication bypasses.

Part 2: Configuration of the database

With access to the database, the next step is usually a privilege escalation to get database administrator (DBA) privileges; some databases are misconfigured that you may have logged in as the DBA. But if you haven't, your looking for a weakness in the functionality or a stored procedure to give you extra permissions or alternatively brute-force the dab admins credentials.

Once dba privileges have been achieved you can plunder all the databases stored on the affected server. In addition to all the associated users passwords hashes; its likely that passwords are repeated by developers on other systems, or could be domain-accounts leading to further compromise.

[cooper]

Using a Ducky for DB access.... yeah, not likely.

There are as many ways to breach a DB as there are to legitimately access a db:

1. Attack the app. Hack the application that has a legitimate, pre-authenticated connection with the DB. A good example is SQL injection.

2. Attack the machine running the app. Hack the machine that has a legitimate connection with the DB. There's going to be a file on the system that contains the DB credentials used by the application, so with that you now have access to the db.

3. Attack the machine that can access the DB. You hack a machine that can access a DB but you can't, for whatever reason, access the config file with the credentials (say you hacked the webserver and the DB-using app isn't run from that webserver, so you would need to escalate your privs to access them but because the admin wasn't a complete dolt you have a hard time doing this). You can then attempt to brute-force the DB's connection or maybe start a sniffer local to the machine to see the legitimate application log into the DB. Or simply listen to the traffic long enough since the nature of the app is such that it retrieves approx. 50% of the full database contents daily.

4. Attack the DB machine. You hack a machine that has legitimate access to the DB and you find out from the config file or sniffing what the IP of the DB server is, but you know the DB being accessed is uninteresting even though there are likely other, much more interesting databases provided by the DB service. You attack the DB network service itself to gain access to the DB machine and take it from there.

5. Attack the database files. You hack a service running on the machine that also runs the database and you pwn the box you simply make a local copy of the db files for an offline attack.

6. Attack the database backup files. You'd be amazed how often this gets overlooked. You hack the backup server, make a local copy of the db backup files, restore it on your own machine and peruse the data at your leasure. An often overlooked version of this is hitting a courier over the head with a mallet, swiping a USB stick from his pocket or simply having the luck of finding such a stick in the train wagon after some exec accidentally dropped it.

7. Attack the database administrator. Find out who has administrative access to the DB, pick up his kid from school, make the kid call its parent and you're pretty much set.

8. Attack the database hardware. Buy up surplus server hardware from the company and see if they forgot to wipe something or if what was wiped may still be recoverable.

There's a myriad of ways and you should try to prevent all of them, which means:

1. Write good/run well-maintained apps.

2. Harden the boxes that can access the DB.

3. Ensure the db is only accessed via encrypted channels with a honking firewall in between that knows exactly which machines should have access to the DB.

4. Harden your DB machine - it should only expose the DB service. Put an IDS up that beeps when other services are sought on the machine.

5. Make the DB service use encrypted files on the filesystem. This isn't the same as using an encrypted filesystem since all but 1 attack is based on the likely situation that you're attacking a live server which already has this filesystem mounted.

5. Have your app encrypt the data before it stores it in the DB. And we're not just talking about the password, SS# and CC# but also other private data like gender, DoB, home address, email address, linked twitter/facebook/linkedIn/NextHype account IDs... Basically everything that uniquely identifies this person on another system should not be visible as-is from the DB - this one alone mitigates to a very high degree most attack vectors.

6. Encrypt your backup files.

7. Keep track of where your data is transported to. I've heard stories of a company sending a stick via the post office using a standard envelope and, because those things aren't handled delicately the stick broke free. The stick was never found, so they now had to assume the data on the stick was actively being accessed by a malicious party, and act accordingly.

[overwraith]

I like the mallet technique... Thanks everybody, that's good food for thought.

[no42]

$5 wrench technique always a winner: https://xkcd.com/538/

[cooper]

[newbi3]

SQL Injection doesn't have to just occur on a webpage. It could be exploit in any application that talks to a SQL database. Consider this for example:

There is a game that stores all of its user creds in a SQL database. The user is prompted to login and the username field isn't sanitized before checking against the database. If the user entered something like john' then an error would be raised. Now the only other thing that would need to happen is the sql error be displayed on the game somewhere. Or depending on how the errors are handled the SQL error could be returned to the client but not displayed on the game but if you were doing a pcap you would be able to see the error in the packets captured.

Edited April 20, 2015 by newbi3

[Mampt0n]

7. Attack the database administrator. Find out who has administrative access to the DB, pick up his kid from school, make the kid call its parent and you're pretty much set.

Wow, that escalated quickly.

[Jason Cooper]

"Always use parameterized queries" is high up on my list of good habits a programmer should have. Just like "Changing the sa account password on the database from the default" is high up on my list of good habits DBAs should have