Welcome back to sensitive data, exposure session. In
this second part. We will exploit our intentionally, vulnerable
application to get access to some sensitive data.
We will jump straight to the hands on exploitation
before closing. We will review. What's
wrong with our Target application. Let's hack.
First, we will create a regular user account.
Before some shopping. Let's configure our default address
in payment methods.
Alright, we are now ready to buy some Joyce.
Let's review our order and proceed to checkout.
The next steps. We should be asked to select a payment method.
Let's pop up developer tools so that we can inspect what
data is exchanged between the browser and the backend server.
See how credit card number is masked in the
interface. However, if we look up the request
to retrieve credit card, details from the server, we
will find something completely different.
The credit card number was sent in clear text. Since
the application does not use https, anyone between
client and server will be able to see it as any
malware installed on client device.
Let's complete our order and see how far we
can go exposing sensitive data.
On our first session, we exploited the SQL injection
vulnerability to bypass authentication. In
that case. We could not retrieve any data from the database since
the backend server was just counting matched records. Instead
of returning the actual results. If we
find the vulnerable endpoint that asks for user input to
merge with the query template returning Found Records, then
chances are we will be able to access arbitrary data
on the database. Usually search features are
good candidates. Why not try our luck?
Let's pop up, developer Tools in search for orange, adding
a trailing single quote character as we
did in the injection, flaws session to exploit SQL injection.
Apparently nothing happened better opening. The
gate requesting a new tab so that we can easily modify the
qur L parameter.
Let's do it again.
Okay, this time it looks promising. We now
have a SQL error.
The percentage character is a good sign that the sql-like operator
is being used. But think how the backend query
template may look like.
This could be the back end query template. Let's
replace the input key word with our current payload
and see how it looks like.
Another SQL error. This time, the query is incomplete. Maybe
the query template tries to match our search keyword, both
in product title and description. Let's
get back to our query draft and improve it.
Since we were commenting, everything that comes after the place where our search
keyword is first interpolated. It doesn't
make sense. The problem is the end, unless there
are some brackets around this conditions.
Let's see what we get now.
The same error. Maybe there's more than one brackets around the condition.
Let's try with an additional brackets.
Alright, now we know that we are on the right track. Until
now. We were able to break the query template and
fix it with our won't payload. We
are just missing a way to join additional data to the query results.
SQL allows unions between query results
as long as they have the same number of fields. Let's
see how many fields are retrieved for products.
To be able to do a union. We need the second query to return nine
fields.
Let's test it.
Okay, we have our art coded record returned
by the database server. We can now guess table
name and some fields to expose data.
Table user does exist as well as ID field. Let's
try guessing other field names until we
get something juicy.
Finally passwords, or at least there
hashas, vulnerable applications tend
to use unsalted md5 hashes. If
this is the case, we should be able to get the original. Secret
searching. The hash. We got in some rainbow
table.
And we got it. Let's try to login as admin.
Since we're in, why not check some addresses or
credit card data.
We already know the trick to expose credit card details. Let's
pop up developer, tools, and reload the page.
And here they are the admins credit cards.
First, we saw that although credit card data
appears, masked on the screen. It is sent in. Clear
text from the server to the client since the
application does not Implement HTTP, someone between the
client and the server, such as a proxy will have
hot access to that data, exploiting a
SQL injection flow. We were able to retrieve arbitrary data
from the database. We saw that sensitive data
such as credit card, data is not protected at rest.
Finally still exploiting the SQL injection. Flaw.
All we retrieved authentication data. Although
passwords were not stored in clear text hashing
was not done properly and we were able to retrieve some
Secrets using rainbow tables. In
our next video. We will discuss what makes the application vulnerable
and how to prevent it.