Hello everybody and welcome to this tutorial. Today, we're gonna just continue
on as this is a follow up tutorial. So, without further ado, let me just show the
modifications that I've made to the SQL map command. I have it here somewhere,
yep, there we go. So the address is pretty much the same as it was except there was
this bar thing at the end. It was in the address of the site, I've removed it,
I have literally no idea why but it's supposed to be there. I'm sorry for that.
Anyway, in the cookie section you will also need to make some modifications. So
this is the cookie that we have previously used, I have closed and
reopened the session since then so it is likely that this has changed, but you
will need to identify the cookie. So, it's PHPSESSID. This is the type of cookie
that we have picked up so just type it in, and you can also specify the
security level equals, and then you specify it here, it's low. Sorry, let me
just change that quickly, excellent, there we go. So I've been playing around
with it and I've been trying to see what happens with the
different sort of settings, and you see just to confirm on the website DVWA
security it is on high. So you see the setting here is on high, however
even though the setting is on high here you can play around with these cookies,
and you can do this on any other site pretty much. You can also modify the
cookies to get different sort of results. So if it's high here, and
even though the site is set to high, I can type in here low, and it's gonna go
as low, no problems. Now, this is not, as I said, this is not something that you can
apply here and here alone, this can be applied pretty much anywhere. Open up
your burp suite, take a look at the cookie section, and see what happens there.
Try logging in and out of the website, wiping your cookies clean, wiping
your browser history clean, and see if you have
five consecutive cookies, and see what happens. Or, log in through a
different browser, or log in through a different virtual machine, and just have
five, or something like that, consecutive complete cookies, and then
see how they change. If you can figure out their rates of change, and if you can
figure out how they're assigned, well, there you go, you need nothing else
pretty much. However, that is not really likely to happen, unless somebody has
some really bad cookie keys that then you can do pretty much whatever you want.
Let's just change this to high again, and I already have it cached, I have done
it several times, but if it doesn't work with high leave the high setting on the
website, but modify the cookie below and trick it in such a fashion. I
have a bad feeling it's gonna pull it from cache, and it did pull it from cache,
but it doesn't really matter. Yours is just gonna take a bit longer,
maybe like 30 seconds more, something like that, and you'll probably be
prompted with a question. Read through the question. If it finds
some vulnerabilities it will stop, and it will ask you do you want to continue
scanning even though I have found vulnerabilities. You can say either no or yes,
just type in n or y. For the time being, if you wish to follow exactly through
this tutorial, you can just answer with no because we are focusing on a
particular vulnerability, and we're not expanding on it. But, on your own, I would
strongly recommend that you do keep on scanning and try out different stuff. And,
as I said, if it doesn't exactly work with high just try
modifying cookies to low, and leave it on the site as high. Anyway, so we have
some information here, you can go ahead and read through it, it says parameter
ID get, type boolean based blind, title it says payloads, excellent!
Okay, so this is definitely vulnerable, and all this information tells
you is it tells you a bit about the vulnerability, and it confirms that it is
vulnerable, but you still need to actually do something
with it. You still need to try to extract information. By the way, your log files
are here. You see this file that I'm selecting? Do not forget to type in the
dot here, the one that I'm selecting now. So, just type in /root/.sqlmap/
output/ and this is my current IP address, but you know IP
addresses vary from one web server to another. So, just use the one that is
written out here in order to access the logs. There will be all sorts of
files there, but you can just go ahead and use the file named quite literally
log, open it up, and see what's written in it. Basically, you will have this here in
it, no problems. Anyway, now that we've established that it is vulnerable, I have a few
commands here that I have written out for myself.
Yep, there we go. So, let's just go ahead and clear the screen now. We know that it
is vulnerable, we're gonna use pretty much the exactly the same syntax, however
we want to add a few things. So, - -dbs, let's see how this works out.
Unable to retrieve the database names, falling back to the current database,
fetching database names, something went wrong because of limitation. Okay, let's try tricking the
website from high to low, and there we go, it's right there. So, once again, see
I've just modified the cookies themselves,
I haven't actually modified the site. If I go back to the site, if I click on
security, it is on high. You see this has not changed at all. I'll just go back
to the SQL injection (Blind), go ahead and open up the terminal, and it says here
available databases. So, we have dvwa, information_schema, MySQL, reference_
schema, and so on and so forth.
So, if we just go back to our command, we can type in -D for
database, and now we can retrieve tables from individual databases. By the way, the
DBS just gives you the databases, basically. It says
available databases, and the ones that you want to access depending on what
sort of information is contained where. You can't of course know, but it doesn't
really hurt just to check them out. Sometimes there is a lot of them, and it
can be a drag, but it doesn't matter. As soon as you get to this part, as soon as
you manage to go through the first barrier and actually access a
database remotely, you are there. Then it's just a matter of time, far
less time, primarily because you are able to go through those databases and figure
out what is where. Now if somebody is keeping an active track of what is going
on, and if somebody is monitoring this live, they will be able to see that there
was an incoming connection. That can be problematic because they can kick you
off. But, so what? If you do this at some ridiculous hours of the
morning, depending in which timezone the database is, you can
actually pull the databases, just download them, and then analyze them
later. So you have all the time in the world to analyze them after you have
pulled them, after you've pulled information, and after you've seen them. Then
you can just sit back, relax, disconnect your machine, and without risk
basically just go through the files and see what is contained
therein. Now I have immediately written here dvwa, but let's just go through some
of the other ones as well. Let's see what's in there. mysql - -tables, press ENTER,
is it gonna pull? Yep, there we go. So this is a relatively, excellent! So, we have
user, we have columns privileges, this is for the SQL, excellent!
We got a lot of tables here, let's see what we can do. Let's see what we
can do with this user. There's bound to be something there. I
mean, you can go ahead and check the others as well, but usually if there's
something that says user, password, or something of a kind, go and check it out.
I would go through every single thing once I fetch the database
because you never know how somebody's gonna name something, what sort of
credentials are they, what sort of identification are they going to use.
They might as well name this table user, well maybe not this particular one, but on
the sites, on the web server, cells where they can put their user names and
passwords in a database called, I don't know, Santa Clause, under a table called
wooden door, pretty much. So, once you have it invest a little bit more time and go
through these tables. Go through all the databases, go through all of their tables,
and go through all the contents of the tables. Try to figure out, just try to
see even though some of it is encrypted, fine, okay, store it, maybe decrypt it
later, but go through all of it, have a look at what is
within those databases. Because, as I said, a lot of things can be just
named differently, and you might skip it thinking it's nothing. Okay, so let's
let's just change the command, so let's say -T for table, and
let's say that I've one table user, and - -column, press ENTER, let's see what we
get. Do you want to use common column existence check? Sure, why not. Let's see
what happens. Please enter the number of threads. This
is a pretty small one, but the more threads you enter the faster it's
gonna go, but the risk of detection is higher, I guess. I don't know, let's see if
we can support four threads on this virtual machine. Apparently, we can. I
could have probably told it more but it doesn't really matter, this is gonna run
for a while, and then we're gonna see the contents of the table, basically.
We'll see the columns, and we'll see what's actually written in them. Anyway,
I will pause the tutorial here, I will let it finish, and then we'll pick up from
where we left off in the follow-up tutorial. Until then I bid you all
farewell, and wish you a lot of luck with this.
No comments:
Post a Comment