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.