In our challenge we were seeing if we could run Nikto against a website of familiarity,
one that we have permission for, and that we can get information off of in order to be able to make
a determination in terms of security. Now we haven't really gone through and fixed any of
the vulnerabilities and I'm going to address that momentarily because this skill was about
identifying the actual vulnerabilities and exploits so that way we can address them later
on. Because as pen testers it's not about us fixing them and I'm going to come back to that
in a minute. What we're taking a look at here is Kali and we're running Nikto against cbtnuggets.com.
I have permission. Now I'm not going to go in depth and as far as the results are concerned,
I just want to give you the basic oversight and I'm also going to have the command for this below
even though it is in the video, don't you worry. So you can see that I ran this based on the FQDN
instead of the actual IP address itself and I identified the port of 443. Now because I ran it
as the FQDN, multiple IP addresses came back because there is a load balancing going on behind
the scenes which is good and you can also do more info on those IP addresses like getting with IANA,
figuring out where they're registered at, and figuring out who the actual owner is like a who
is and all that other great stuff and things to keep in mind. You'll also notice that there is
SSL info and you have information pertaining to the certificate and who actually issued that
certificate and then along with that you get basically that it was ran on a I've never been
able to pronounce nginx but that's the server that's running behind the scenes in that POSIX
based environment to host this actual web server and then you also see some of the security things
that have been identified like the anti-click jacking x-frame options header is not present.
Is that something that cbt.nginx needs to look into or is it balanced with code inside of that
script for the HTML page? Now I said that we would come back to it in just a second and here we are.
Do pentesters fix vulnerabilities found during their pentest? Normally no but this may change
based on who we're pentesting for as far as the organization goes. So if you're on a purple team
for instance that may be the case where you actually try to do a couple of pentest vulnerability
assessments within your own organization and you are responsible for taking care of them.
Now we also want to identify and this is something to keep in the back of your mind
that there's a differentiation between red and blue teams and although I do say purple
it's because that's what the two colors mix into. The red team is somebody or a group of
somebodies that is typically not within or under our same organization. We want an independent
view of what's actually going on within our security posturing to make sure that we're
actually doing everything that we need to do. I'm not saying we're cheating but I also say
that sometimes we want to save ourselves a little bit of embarrassment and let's say for instance
you had directory browsing enabled on your web server. You might not want that to be put out
there so if you're pentesting yourself you're sometimes likely not to kind of tattle on
yourself as much. Whereas a red team an independent red team will come in and tattle on you all day
long and that's one of the downsides to what we do as pentesters. We're tattletales. The blue team
is all about defense and they're the ones that implement the security controls in that
organization's environment and there has to be a balance. One of the things that we noticed on
the BWAP server is they run php7 and I've brought this up before too that because that's a major
vulnerability that we found inside of our scanning and assessments as the pentesters we go back to
the owner of it and say hey you need to upgrade to php8 or above or whatever the current one is
that's been duly tested. Now in the particular case of our lab if we did that it would brick
the entire BWAP system and therefore get rid of something for us to be able to practice with
in a controlled lab environment. If it was a real life web server that actually had hosting like
services like cbt nuggets for instance and we patch it then we're breaking the web server's
capability to have those services available to the general public and that could cripple the
organization. That's something to think about is that balance between security and availability
and it falls back into the CIA triad confidentiality integrity and availability. If we
add so much security and focus on the confidentiality and integrity of the actual server
itself and put too much into it we lose availability and losing that availability
means that we're essentially bricking and dossing ourselves and cutting ourselves off what's that
old saying cutting your nose off to spite your face one of those environments right so this is
really something to think about you may find assessments that show multiple vulnerabilities
but only one or two get fixed. Now there are other things that you could put into place
like we discussed ACLs and you know whitelisting blacklisting all this other great stuff and those
are things that you really want to consider when you're balancing security and availability.
I hope this has been informative for you and I'd like to thank you for viewing.