Now, if you go without saying that all vulnerabilities are not the same,
and some vulnerabilities are actually caused by human error and not just in
something that we actually code. So a lot of times that we see inside of our
OAuths top 10, or even if we go to SISA, the actual website, CISA,
and we look at common CVEs, we're used to seeing things like a patch from
Microsoft or some other third party vendor to go out there and fix a
security mishaps that was problematic with the
system in the beginning. Now, that's not always the case with
vulnerabilities. There are cases, and I'm going to show you a few of them as an
example, that it could be just configuration error. It could be an
oversight on the system or network administrator or even us as the
cybersecurity professionals of the organization. Nobody's perfect. But the
idea behind this is to have a standard idea of some of those
vulnerabilities that are human error, so that we can
basically roll a dex our way to them if we want to try to exploit them.
One of those errors that's always popping up that's not a software or
hardware defined thing is passwords. Simplistic passwords that are
cracked very easily based on the fact that people don't like using
multiple passwords, and they don't like using complex passwords.
So birthdays and pet names for also people, so like I call my wife,
wife, birth associated with other hints that may be familiar to us, home
address,
whatever the case may be. And this also goes back to where we
spend a little bit of time doing OS in in order to be able to exploit some of
these vulnerabilities. If you're familiar with the answer 20 questions
about yourself on social media, those are questions engineered to be able to
help you as a hacker or pen tester to go through and answer
security questions that are most common with a lot of applications.
So when we talk about misconfigurations, it's not always
through the system itself. So let's take a look at the side screen here real
quick
and inside of our depth lab, I have the windows 10 open which you can see
with the mulleted long horn here. This is a five out of 10
mullet because it's facing the wrong direction. Now as we
go in here, I'm going to move this over just a little bit for us. This is our
system that's actually doing the bewap.test site. So if
inside of this playground, if you go to bewap.test, like in the previous skill,
this is where it's going to. The reason I bring this up is because we're
going to do a little bit exploring inside of the actual
file directory system and don't worry when I get there, I'll zoom in for us.
Now we know that basic configurations with things like
IIS and Apache and other bits of software can be searched or googled
as a verb and find out basic install locations. That's not always where
things go, but that is where things do get installed by default.
And bewap.test is no different as we have C drive
iNet pub and now I'm going to zoom in for us real quick.
You can see there that I have an iNet pub folder. We established in the
previous
skill and we'll reestablish here that this is in fact IIS with some of the
tools that we use. If I zoom out and then go ahead and go
inside of the iNet pub and then go into www root,
that's where the basic website for IIS is installed at on a system.
Now inside of here is where all of our bewap.test
site is actually configured and set up and installed.
So like we mentioned in the previous skill, if you want to set this up, don't
be
afraid to walk through here and take a look at some of the configuration
files. Well, configuration files you say, that's exactly what we're going to be
pointing out as a human error in this. Inside of
bewap or www root and the bewap folder are a bunch of
PHP's and INI files that run behind the scenes.
And while this may not be the same for every single website out there,
a lot of default documentation that we studied in the last skill applies to
things like this because you can very easily pull up documentation for bewap.
And a couple of the files that we want to pay particular attention to are
settings, configs, or anything that has a identifiable keyword like admin.
And that's exactly what we took a look at here. I am taking a look at
inside of notepad++, the wrong ones, but I'm going to go to file a
reset and we're taking a look at the bewap.connect.php.
And let me minimize that. I'm going to show you where it's at inside the folder
.
It's right here inside the main bewap folder
right there. And you can also see right above that is configure.ink.php.
That'll come important in a second. But the first one that we have
is our connect.php. And this is the actual PHP configuration file for how
bewap is connecting to not only database of my sequel,
but also the IIS platform overall. And you can see here,
the first thing that sticks out to us is everything is in plaintext.
Nothing is hidden. And this is a configuration error on our part as humans
that won't necessarily come up as a vulnerability
inside of a scanning program like Nessus or Nikto as we go moving forward with
different tools. So taking a look at this, we can see here that there
is first our call to link another file config.ink.php, which was the other
file that I showed you. And then right below that we see that we're
linking into MySQL Connect and the variables of dbconnect,
dbuser.ink and dbpassword. Now you may not be familiar with full PHP
programming because I'm not. But I know enough of basic programming
architecture to be able to identify that these are variables and that we have a
call to another file. So let's take a look at that other
file, which is configure.ink.php. And I have already opened that up
previously or I thought I did. That's okay, we'll go to open.
We'll scroll down to configure, which is a C.
There it is. config.php. And this is where we start getting into
even more settings that are easily identifiable as not right.
So as I zoom in, we can see that we have an include for admin settings.php,
which goes a little bit further into the stuff. But right below that you see
that our variables from the previous file are present db,
dollar sign db underscore server username password and name. And as if you can
see
here, right over there, that password and username
are very much in plain text along with the call to which database is being
connected to. So this right here already tells us
that we have a database assigned to the actual web
server as a web application. And we can see very clearly
the address, the username, the password. And we can
not even though we shouldn't assume, but we can already know that there is
access to this database that's presented to us in plain text.
Now the reason this becomes very important for us is because even though
this won't pop up as a vulnerability inside of NSS or
NCTO or any other vulnerability scanning assessment,
what this will do is come up for us as a way to be able to
pin test against those username passwords by using simple commands like
WGet. When we learned how to crawl a website, there's
expansions upon WGet, which we'll look further into as this
course continues, that we can actually pull files up based
on our crawling of the website. And if this pops up in our crawl,
half the work is done for us, knowing it's half the battle,
G.I. Joe. Now let's zoom out and take a look real quick at also the
settings admin settings file real quick. And we're not going to stay too much
into that. I'm just looking for the open here. There it is.
Admin settings. And again, it gives us the same thing. As a matter of fact, I'm
going to highlight it real quick and then zoom in for us.
You can see here that we still have username passwords, addresses,
and also the actual database name itself, all in plain text.
Now granted, I'm on the actual bwap.test system itself and have
root access to the system, but we can access this remotely and we have.
And that is through our crawl with WGet. And by a little bit of expansion,
again,
as we continue, we'll see how to get all of these files.