3 Answers
3

This question is very broad. In general you need to know how all different technologies are configured and what their weaknesses are (refer to google).

"Databases" is a broad term. There are many types of databases using different languages:

LDAP (active directory, OpenLDAP,...)

SQL (MySQL, PostgreSQL, SQL server, Oracle,...)

noSQL (MongoDB, Cassandra,...)

When pentesting you can either focus on the service provided by the database itself:

authentication

concurrent connections

or you can try to get to the database via a program that connects to it (LDAP/SQL injection for instance).

The means can be different as well: you might want to dump the contents from the database or you might try to make the database issue a command (if it runs as SYSTEM/root you can get access to the underlying server to stage more attacks).

There are tons of different books on databases. In general I always look at everything O'Reilly has to offer. They have a quite rigorous reviewing and admission process. I suggest starting with SQL and LDAP as you will see these more in the wild than any other protocols.

Depending on what you need, database itself might be a nice first step to infiltrate or exfiltrate the rest of the OS. Learn the commands that allow you filesystem access (e.g. LOAD DATA INFILE)

Using data from databases can be very effective for enumeration of accounts. Often database names, users' names, table name match system user's names.

Passwords are my favorite content of databases. People tend to reuse passwords, so you can use them on system user accounts, email accounts, etc. Another thing about passwords in databases, they're usually stored using lousy hashes, like the old MySQL hash, or oracle's DES based hash, which are all very quickly crackable.

Also, you can find out more about the system with SHOW VARIABLESMySQL example that shows you paths for various storage engines, platform it's running on, whether it's 32/64bit, the exact version of the database, where the crypto keys or certs are, what other IP's the daemon is listening on...

Then you will usually have some sort of subshell mechanism, or at least ability to run SQL scripts from the filesystem. That's more DB<->filesystem communication, which can be useful.