So in our challenge, we put out that we wanted to be able to research a CVE and
see if there was either a zero day vulnerability for it or if there was it
within the exploit database.
So I have one pulled up here for you that I'm going to go to the side screen
real quick.
And we're taking a look at CVE 2012 2376.
Now, the reason I went with this one in particular is because as we continue
throughout the course, you're going to see a growing pattern of PHP usage
inside some of our labs and exploits geared towards PHP.
Now, it's not just that we're picking on PHP is that the way the labs are set
up, it allows us to be able to examine different exploitation methods.
And a lot of which have been examined through what you see here and other ones
that you may pull off.
So as we go through here, I do want to point out real quick that we have a lot
of references for this one as this is an attack on PHP version 5.4.3.
Now, that doesn't necessarily mean that it's matching the exact version that we
're using inside of our labs here coming up.
But what it does mean is that this is a known PHP issue and as a pen tester, it
is OK every now and then to take known PHP issues.
This is an example and try to apply it to software that we have today because
if it works and it's not a reported vulnerability, then we have a zero day that
we can report ourselves.
Now, as we continue to go throughout here, we can also see that inside the CVE
program references down at the bottom that there is an exploit DB reference to
this.
It's the third link from the top.
And you can see that there's other information about it as well too. So not
only do we get the idea that this is an exploit inside of PHP and is known, but
there is also now a known vulnerability for this.
So we could click on that and here we are back at our exploit window or website
here.
We could go through and see inside of here. Not only does it give us the
exploit details, but it also goes and gives us an example of code that we can
write in PHP.
And go and do some exploitation.
Sorry, I'm a little stuttery here because when I see this, I'm like, oh, man,
this is coming up and so the skills that we've done already.
So if in case you didn't know this one was done out of order and I'm moving
this up towards the front because it needed to be addressed first.
Now, inside of that, this was reported as a zero day when it was first
initially reported.
We can know this because as we zoom in, there's our CVE 2012 2376.
So this was and you can see right below that how long did this go as a zero day
vulnerability? Well, it started in May 11 of 2012 when it was first identified
and reported to this database and it was verified fixed 10 days later.
So there was a 10 day window where this vulnerability could was identified and
had known issues, but there was no actual fix for it.
So if you're a pen tester or let's say even worse, you're actually a hacker out
there.
This is a vulnerability that you have to be able to adapt to and you have free
reign for nearly 10 days because there's no known fix for this.
The flip side of that is is that as a security expert, a technician
practitioner or administrator, such as we are, we can actually take information
such as this that we found out about the zero day.
And let's pretend we were back in time when this was happening and implement
other security controls to be able to mitigate the risk that's associated with
the CVE.
Because as of May 11, it was reported, which means that it was now in known CVE
databases to be made into definitions for programs like Nessus.
And so while we may find this on our regular interval vulnerability assessment
of our organization and there may not be a fix, we could implement something
along the lines of stricter controls for access rights inside of either red hat
, which was on there. So Apache or inside of the windows world.
Now that original vulnerability was reported under red hat, but being that it's
PHP, which is a separate known program, this would be something that we would
take note of outside of specific operating systems.
Because I'm using PHP in an iOS Windows environment in the future skills that
we have in this course.
So if this was applicable to that versioning, you would be able to potentially
exploit, regardless of the actual operating system.
It's wonderful to be able to keep things like this in mind, especially as we
start to go through the rest of our pin 200 course together.
Remember, just because the resources online or offline doesn't mean you can't
use it. It just depends on knowing where that resource is for us to be able to
access it in the appropriate moments.
I hope this has been a forward for you and I'd like to thank you for viewing.
[BLANK_AUDIO]