[COMPUTER SOUNDS]
[MUSIC PLAYING]
Hello and welcome to the Hacker House, Hands-On Hacking
database theory module.
We're now going to explain all of the necessary theoretical
background for how to approach database servers
and attempt to compromise different database
installations.
So continuing with our theme of our course,
we're still once again sitting in the internal perspective.
Database servers are the kind of thing
that you would normally expect to see on an internal network
or perhaps inadvertently exposed in error on a network
perimeter.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
Databases-- what are databases?
Well, databases store data in a structured record.
They exist on a server, or a file system usually somewhere,
or could even be in memory somewhere.
And they have their own internal permissions.
So databases are their own kind of unique brand of security
problem in and of themselves.
They have their own internal permissions model.
They exist somewhere in a file system
or in memory or on a server somewhere.
And they have languages designed for querying them
and functions for performing tasks.
So it's a way of storing information, making it easier
to sort through, indexing it, and things like that.
So different kinds of things with databases.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
And when we're talking about hacking databases,
one of the you'll need to learn is the concept of a database
schema.
If you think back to our open source intelligence
module, where we went through a SQLite database
and showed you how you could explore some of the schema that
was in there, learn the size of the table,
well, databases need to have schemas.
You need to understand how information is stored
inside the structured record.
So databases contain tables, which
are made up of columns that usually hold variables.
And these variables can be of different data types.
As an example of this, we could have a database called people.
And inside of that people, we could
have a table containing names.
And inside of those table containing names,
we could have columns, which contain strings
of first name and last name.
So those columns first name and last name hold strings--
strings being alphanumeric or similar principal ASCII
characters and, indeed, unprincipled characters
as well.
But holding strings, something like a name and a last name.
So a database schema.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
So if you have a database schema,
if you think of accessing that information, a record,
you might want to do that pragmatically.
It's no good just to open it open up and then say
index one or index two.
So a structured query language, or SQL,
is commonly used to describe queries that access records
or data inside a database.
And it's a common way of describing
how to search for specific sets of information.
As an example of a database query,
you could use select first name comma last name from names.
So thinking back to our database example,
you could select the column first name and last name
from the table of names and display all of the first names
and last names in that database.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
MySQL is a database server, typically runs on TCP port
3306 by default. We have encountered it briefly
on the web module.
But MySQL is kind of a weakness in that it
leaks a lot of software-type version information
in it's welcoming banner.
It almost always has a root user, which
can most often be brute forced.
And it can also, if you access a MySQL service-- which
if you recall back, we were able to access it with a proxy.
You were able to load file and read file.
You can actually read and write files
using the MySQL database built in functionality.
It's got a long history of databases, many of which
you can actually use to compromise the database
and gain access to the data that's held inside it
if it's not been fully updated.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
Postgres, another SQL-like database or SQL database
typically runs on ports 543, 5433, and 5432.
It's similar to MySQL, but different enough
that it can be annoying.
It can also read and write files.
It requires a function, however, to be created for this task.
It requires you to actually extend
the functionality of Postgres because it doesn't by default
bundle this capability.
It doesn't have a root user.
It doesn't have a default account out of the box.
But it's quite often shipped and configured
with postgres postgres, or psql, or some similar variation
of PostgreSQL.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
Likewise all the all the database software
that's out there that powers these kinds of databases,
Oracle.
Oracle is a commercially available SQL database
that comes in a variety of different versions.
And it's characteristically seen as a TCP port 1541, known
as a TNS listener service.
And you can actually use a pl script called tnscmd.pl.
Which you can then query that TNS listener service
and then do things like an enumeration,
try to identify the database set and context,
and try to actually login then as users like Scott
Scott, Tiger Tiger, SYSDBA.
And in all my time in my life hacking into computers,
I've never encountered an Oracle database
which I haven't been able to break into using the default
usernames and passwords.
I've never encountered such a database that's
been sufficiently hardened.
Because, out of the box, Oracle ships with so many
defaults that usually at least one of them is overlooked.
And from there, I'm able to escalate
privileges or abuse many of the missing patches in the Oracle
database.
So it really is kind of a joke when it comes to security.
And I'm not sure why anyone would really ever take it
seriously.
But Oracle databases also do have a lot of vulnerabilities.
So if you see an Oracle database,
chances are you'll get in with a default,
and then you may use some SQL injection
to get DBA privileges, if you haven't already
obtained DBA privileges by simply logging in with SYSDBA
SYSDBA.
So things like that with Oracle--
really weak, really insecure.
If you see Oracle, chances are a default username and password
will let you in.
At least that has been the case for me in my entire career.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
User defined functions-- you can define your own functions
inside a database and link to software libraries.
So if you access a Postgres database,
and you find that Postgres doesn't
allow you to read and write files, what you can do
is you can define your own user-defined function.
You can actually load a library file in
and add your own functions to the database.
And you can create a read file function
that allows you to read files.
So using user-defined functions, you
can often compromise a database server using that database
server to get your privilege, escalate privileges, become
whatever privileges the database might have.
And as an example, you could hack a web server,
and you could maybe find a vulnerability in the database.
The additional tier of that web server
might give you extra permissions or access to a new server.
So hack a web server with a command injection bug,
hack the database, maybe you'll be able to escalate privileges.
Or maybe you'll get access to another system or server.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
Authentication bypass issues-- MySQL
has had a history of authentication bypass issues.
CVE-2012-2122 is a vulnerability which occurred.
If you try to log into MySQL 256 times in a loop,
because of an optimization that was performed by the compiler,
it would actually eventually just permit you
into the system.
So it was found that if you tried
to log into a system 256 times, you would eventually get in.
So very simple authentication bypass problems.
There was also another vulnerability in 2004
whereby you could simply try to log
into a database with an empty password,
and it would allow you to access the database-- so
authentication bypass issues.
There are a few of them.
They're kind of going away now.
We have not seen so many of them in recent years.
But they have, in the past, risen their heads.
So they're very good ones to be aware of.
So MySQL authentication bypasses--
good things to check for.
Also the Postgres service has a number of equally interesting
vulnerabilities.
But for some reason is less targeted by adversaries,
perhaps because of its market penetration.
However, there are a number of vulnerabilities to it,
but much less public exploits.
So you may need to write your own.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
Alternatively, you might come across non SQL
or NoSQL-like databases, things like MongoDB.
It's a popular NoSQL database that's
designed to take advantage of modern computing
technology for speed.
And often it seems to be configured frequently
without passwords.
So what happens is people will try
to access this service using ransomware or something.
So they'll log into a service, they'll copy the database,
then they'll delete all the data from the database leaving
a message saying, if you don't pay me bitcoin,
you're not having your data back.
So this is a way in which these kinds of databases
are being abused, monetization for insecure passwords.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
And unfortunately, there was other databases,
like Redis, another popular NoSQL database,
which uses in-memory data structures to increase speeds
as a database.
And NoSQL apparently seems to mean no authentication.
I was actually really relieved when
NoSQL was introduced into the market
because it had no authentication usually by the default,
and I'd been running out of ways to bypass databases.
I actually got scared that I'd have to start
working to hack into them.
But thankfully, people created NoSQL, which basically
meant no authentication.
And I was able to continue accessing databases long
into the night.
So we have now brute force attacks
that can be used against auth.
If used, an interesting behavioral characteristic
of Redis is because it's been designed
to do very high speed in-memory access of data structures,
it's also really good at doing high speed brute force attacks.
So even if you set a password on a Redis instance,
you can test a few 100,000 passwords
in a matter of minutes.
So you can effectively brute force
the password for a Redis database
in a short space of time.
So even when somebody has taken steps to secure it,
it's generally accessible through brute force attacks.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
So what do you do?
How do you target a database then?
So what do we do in this situation?
So the first thing we'll do is we try and get access
to the database in some way.
We want to be able to see what data is inside of it.
And we want to be able to query the information
in the database.
So we want to be able to look at the data.
So we've got access to the database somehow.
And once we've got access to the database,
we'll likely need to be a privileged user
in the database.
So we'll need to be a database administrator
or elevated privileges inside the database.
We'll then try and use the database.
Can we access the file system?
Can we change the data and give us some access
to some more apps and things?
But can we use that database to access the file system?
Can we use it to upload code and execute commands?
And then can we leverage any additional vulnerabilities
to exploit that database software as well?
So obviously, the data is important, but also
the risk to the system that hosts the data,
because it may be possible to escape that database
and attack the server that hosts it.
[MUSIC PLAYING]
[COMPUTER SOUNDS]
So tools that you put in your database hacking tool box.
Things like sqlmap is a SQL injection
exploit tool. nosqlmap is a similar tool
for NoSQL-like databases.
UDF exploits-- you'll need some user-defined function exploits.
Some brilliant tools written by a Italian security researcher
named as Raptor, and we can have a look through some of those.
tnscmd.pl, our Oracle TNS listener tool
if you're going to target Oracle TNS.
Also SQL clients-- you're going to need something
like Microsoft SQL, Management Studio.
Or you'll need MySQL clients or Postgres clients.
You'll need a database client to communicate with you.
You could try tools like SQuirreL, which may support
more than one kind of database.
But I like to have databases installed
on hand in a virtual machine to test things out against as I'm
doing these attacks.
That brings us to the conclusion of our basic primer
on how to use a SQL.
We're going to now look at some of these concepts in practice--
so by trying to take advantage of a database server
in the practical elements of this module.
So this module is available as an ISO format.
So you can use the same lab swapping technique
as we've used in previous modules.
So make sure you've got your resource guides ready.
There are a number of references to SQL
and SQL-related commands buried in there that might be
of use to you in this module.
Again, these reference guides were
intended as just a useful resource for you
to look up various commands as we're doing
these kinds of activities.
So you could download from this database server
there and be able to use these resource guides
in this next practical module.
So thank you very much for taking the time
to complete this module.
And I'll look forward to seeing you in the next one.