Welcome back. In this lesson,
we're going to be talking about
real life injection issues.
I'm going to introduce you to
an open source application called Joomla
and an example of
a SQL injection vulnerability: CVE-2017-8917.
I'm going to introduce
the current existing exploit for the CVE.
At the end of this lesson,
you'll be able to discuss about CVSS base scoring of
CVE-2017-8917 so that you
are familiar with measuring
the severity of this vulnerability,
and in general, having a look at how it's done,
what the thought process is.
But first, I'm going to go
into introducing the product called Joomla.
Now, I'm going to go
into introducing the product called Joomla,
and Joomla is an open source content management system,
otherwise known as CMS,
and it allows for creating and
managing digital content like
creating blogs and web posts.
It's written in PHP and uses MySQL as a database.
Now, with this particular CVE, CVE-2017-8917,
it was found by a company called Sucuri in 2017,
and it affects Joomla version 3.7.
The vulnerability in Joomla 3.7 is caused
by a new component called com_fields.
This vulnerable component is publicly
accessible if you have Joomla 3.7 running on
a publicly accessible server and if that is
the environment and the condition that you happen to
be running Joomla 3.7 on,
this issue can be exploited by
any malicious individual visiting your site,
your Joomla 3.7 application,
and you also have to be using com_fields as a component.
Now, based on the existing exploit
which was created by Sucuri,
this vulnerability can be accessed
through an example URL like this,
like the following in this slide.
As you can see, here are
some URL parameters and particularly,
this list full ordering parameter is what is affected.
Note that this particular URL example
is for a server that's running locally.
Now, to introduce the existing exploit
for the vulnerability CVE-2017-8917,
you can find this through a site called exploit-db.
An exploit-db is a great resource for finding
known exploits and can be
a great place to learn how exploits are built.
If you look at this exploit,
it's fairly easy to use and is
triggered using a tool called sqlmap.
Now, with knowing that this particular CV
exists and if you happen to be affected by it,
then how do you assess and
prioritize this particular vulnerability?
How do you know if you should act on this now or maybe
put it off because there are
other issues that are more important?
Let's assume that in your particular environment,
you have a Joomla web application
that is honest server that is
publicly accessible and you have a base install of MySQL,
and in Joomla, you are using
the com_fields as your component.
What we're going to do is we're going to
try to work out the base metric,
the exploitability base metric,
and you can see further details about
the components of this
from first.org specification document,
and I highly recommend that you go through and read this
because it helps you to have
the thought process for triaging vulnerabilities.
Now, moving on to
working out the exploitability base metric,
so the first component is the attack factor.
How is this attack deployed?
From the findings of Sucuri,
this is remotely accessible
and in terms of attack complexity,
it's considered low because we can expect
a repeatable success through
the fact that com_fields component is used,
and there's an existing exploit from exploit-db.
In terms of the privileges that are required,
there are no privileges that are required
and this is based on Sucuri's findings.
In terms of the user interaction required,
there are none and this is based on Sucuri's findings.
You basically have this automated exploit
that anyone can access and use.
Because of these parameters,
the CVSS base score for
this particular vulnerability for
the setup that you have would be
critical and you can find more information about this at
the NIST or NIST website for this particular CVE.
So in summary, we talked about
the Joomla product and a particular vulnerability for
Joomla 3.7 which was CVE-2017-8917.
Then, we talked a little bit
about the existing exploit for the CVE,
and then we learned how to
calculate the base score for the CVE
so that we could properly
investigate entry of vulnerability.
That's it for now. Thanks for listening.