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.