OK, I want to quickly discuss what could possibly be the easiest vulnerability to exploit, there is
something called sensitive data exposure, and it's exactly, as it says, its vulnerability that developers
make by exposing some unwanted information in the Web page.
Now, sensitive data exposure can be as something as trivial as showing the application version, but
it can also be as something as big as exposing perhaps entire database in the Web application.
And anyone with a little bit of knowledge is going to be able to access it if they want.
So it can be a big vulnerability.
Now, this type of data exposures don't occur that often.
However, you will find them from time to time.
Usually the data will be exposed in the source code itself from the Web page, perhaps multiple developers
worked on the website and they left comments for each other in the code regarding some Web page details.
But if you come across to something like this.
Well, then there are two possibilities, either the developer didn't take a single look at the webpage
before putting it online or it's made they are purposely as a honeypot and honeypot is something used
to catch hackers.
Nonetheless, it's most likely going to be the first thing that the developer forgot to remove his comments
from the code.
As we can see in this example, there is a comment that says, hey, I put the passwords file in sledged
data directory.
Now that could possibly be left for another developer that is going to take over the project.
And maybe before they put out the entire website, they forgot to remove it altogether.
Now, the plan of the attack is simple and it goes like this, we search through the code and through
the Web page, if there is sensitive data exposure, we might find something useful, such as hidden
directory or an admin page or perhaps a database.
And we use that data to then gain access to things that shouldn't be out there for public to access.
Let's see a simple example of this with our tri Hackney platform challenge, so right here I have navigated
to my own challenge inside our try hackery platform.
And under the task number eight, we have sensitive data exposure.
Now, I have already set everything up.
I have started my machine.
Here is the IP address of the machine, if you want, before you do the challenge, feel free to read
through all of this and make sure that you've read through other parts as well, because the sensitive
data exposure has four parts.
It has TASC eight, desk nine, Task 10 and Task 11.
Now, under the task 11 are our challenges, which we are going to do right now.
So, as it says, it's now time to put what you learned into practice and there's not much to do right
here, we just want to copy the IP address and paste it right here.
And it will load the page for our challenge.
So we can already see that the page is simple, it has some text right here, an image, it has a login
button and it has this button right here that says sense and sensitivity.
We can click on all the buttons if would like just to see what happens.
If we click on login button, it will lead us to this page where we need to specify username and password.
And if we click on this, if we just go back to the main page, let's try to find sensitive data exposure.
If we read through this text right here, we won't really see anything useful for us as well as on the
page itself, we don't really see anything that could potentially give us some more detail than we should
have.
So let's take a look at the source code.
We right click and go view page source.
So we take a look at the code, it's just a simple code.
We got some directories right here, slash login slash assets, and that would pretty much be about
it.
We don't get any comment whatsoever.
No, we will want to visit these directories in order to see what files perhaps are there.
But before we do that, let's also go to the login page and view page source on this page as well.
And here we have one comment that says, must remember to do something better with the database, then
store it in slash assets and remember slash assets.
Is that the rectory that we saw from the first code?
And it appears that they've stored the entire database in that directory.
So if we can access it, we have sensitive data exposure.
But of course, this is to the extreme part.
You rarely see something like this happen, although it does happen sometimes.
So let's go to the assets.
OK.
And here it is, we got all the regular files, such as JavaScript files, BHP files, the SS files,
and we also have webapp DOT DB, which stands for database.
We can download this file if we want to save it on our machine.
And then we can go through their entire database in order to find out some information, perhaps about
users, about their private data and other things as well.
And we're going to do that right now.
So let's open a terminal.
Let's navigate to the download directory where we downloaded our Web app, Dot DB, and in order to
navigate through this database, we can type the comment SQL Light three and then webapp DOT DB, which
is the name of our database.
We press enter and it will open this CircuLite interpreter where we can type in our ESKILD code.
So first thing with this database, we want to see all of the tables that it has and we can do that
by typing the comment dot and then tables.
If we press enter, we get to output right here that says it has sessions, table and users table.
We're more interested in this user's table since perhaps maybe there are passwords.
So what we can do is we can run the ask your command to select everything from this table and the command
would go like this select start and start simply stands for everything.
And then from the end users, let's not forget the semicolon at the end and the free press enter.
We get this output right here.
Now, before we discuss this output, let's go back to our task and see what we need to submit.
So the first thing that it asks us is what is the name of the mentioned directory?
We can already specify the answer, which is assets.
Submit that and it's the correct answer.
It says navigate to the directory you found in question one, what file stands out as being likely to
contain sensitive data?
And in our case, that is webapp dot.
Let's submit that as well and use the supporting material to access the sensitive data.
We did it.
And the question is, what is the password hash of the admin user?
So could it be that these are the password hashes?
Well, they most likely are.
We are in the database and usually databases store passwords in hash value and not in plain text.
So we can copy the hash and specify it to see whether it's the correct answer for the user admin.
Let's go right here and paste the hash.
And it's the correct one now with tasks.
What is the plaintext password from this hash?
So we must crack it first.
We can do that with the help of an online website.
We can navigate to a website like track station dot net.
And here we can type in our hash, which hopefully will get cracked by this website down here, it says,
which hash type's does it support?
And they probably have a huge database with a bunch of plain text passwords that they run our hash against
and see whether they found a match.
So let's paste our hash right here.
Let's click.
I'm not a robot.
Let's select all the bridges.
Verify.
And let's click on crack hashas.
When we get the output, our hash is the type of m the five and in plaintext it is squirty you.
I hope so.
This is the password in plain text for the admin account.
Let's call it.
Go back to our page.
And let's type admin and then the password that we just cracked.
And here it is, we found the flag for our challenge.
Now we can submit both the plaintext password and the flag right here.
Awesome.
So this was an example of sensitive data exposure, and we're not going to take a look at more examples
because this is pretty much what it will always be.
You search through the Web page and through the code.
If you find something useful, you use it to gain access.
If it's, of course, something as big as database exposure or password's exposure.
In other words, this is not a technical vulnerability, it's strictly bound to developers making a
mistake and leaving something out there for public to see.
Nonetheless, thank you for watching.
And in the next lecture, we're going to tackle another vulnerability type, which is called Broken
Access Control, see in the next lecture.