Content Management Systems (CMS) are usually good to check out for security issues, especially if the system is gaining popularity or being used by a number of people. Doing a white box type of assessment not only gives the potential to discover security issues but it opens interesting possibilities if ever a bug is found. This is because a white box assessment looks into the internal structure of how an application works.
WityCMS, for instance, is a system made by CreatiWity which assists in managing content for different uses, like personal blogging, business websites, or any other customized systems. In this post, I will walk through the steps of setting up the CMS, finding a web application issue, and processing a CVE for it.
Installation (Windows with XAMPP)
1. Download a copy of the source code (Version 0.6.1).
2. Extract the folder /witycms-0.6.1 from the archive to C:xampphtdocs or where ever you have installed XAMPP in Windows.
3. Assuming Apache and MySQL are running, visit http://localhost/phpmyadmin/index.php.
4. Click on the “databases” tab.
5. Type in “creatiwity_cms” as the name of the database and click create.
6. You should now able to browse the application by visiting http://localhost/witycms-0.6.1/
7. Fill in data required. Like for “Site name”, I’ve added in “Test”. Click on the Next button.
8. Next comes defining the homepage of the system. You can choose any from the options. For example:
9. Setting up the database is next. From step #5, I have used the database name “creatiwity_cms” so this goes in the database setup.
10. Enter the administrator account details and click “Launch install!” (I have added user “admin” with the password of “admin” here)
11. Once successful, this page should pop up:
Finding a Web Application Security Issue
Since this article is about CVE-2018-11512, I will be limiting the scope of finding web application vulnerabilities to a persistent XSS vulnerability. But first, let’s try to understand what a persistent XSS is.
According to OWASP, “Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites”. This simply means that an attack can happen if an injection point can be taken advantage of in a website. Basically, there are three types of XSS but I’ll discuss the common ones – namely reflected and persistent.
Reflected XSS can happen whenever an input data is thrown back at us after a request has been made. A very good example of a potentially vulnerable point for reflected XSS is a search function in a website. When a user enters a term in the search field and the website returns the term entered, that search function is potentially vulnerable to a reflected XSS.
Persistent XSS on the other hand is also called “stored” XSS. This type of XSS can only happen if the value is being saved somewhere in the system, whether it is through a database or a file, and later retrieved for presentation. An example of this one can be a field that requires user details such as the user’s email, first name, last name, address, and more. This can also be settings in a system that a user is able to change in any time.
In the case of wityCMS, the target is to find fields that can save data in the system. This can basically be done both manually and through automated finding of these fields. Since I have installed it in Windows, I had to use the command “findstr” instead of “grep” (Sorry “grep” fans). A reference of “findstr” can be found here.
To list down the files having input fields, we can use the following flags:
/S = Recursive searching
/P = Skip files with non-printable characters
/I = Case insensitive
/N = Prints the line number
/c:<STR> = String to look for
Code:
findstr /SPIN /c:”<input” “c:xampphtdocswitycms-0.6.1*.html”
The result of running the command above will be:
Now, since the result is surely astounding because there are a lot of fields, we can easily pinpoint potential input boxes to start with once we login to the administrator panel. By visiting the URL http://localhost/witycms-0.6.1/, a noticeable value can be seen as shown in the image:
When we were setting up the system, we were asked to input the site name and it’s currently showing up in the main page. Wondering if that site name could lead to a persistent XSS, let’s see if it can be modified within the administrative settings.
Login to the administration panel with the credentials entered during the setup. Once logged in, a small link to the administration panel should look like below:
When I clicked on the “Administration” hyperlink, I got redirected to the Settings page because this was the page I entered during the setup and the first field there is the website’s name too.
A very basic test for XSS is through adding a Javascript code such as:
Code:
<script>alert(1)</script>
When you click the “save” button, the field returns the value:
Notice that the tags <script> and </script> were stripped off. Since the tags were stripped, we now know that there is a sanitizing mechanism in the code. The next step is finding out how the sanitizing method works.
Whenever data like the above is being saved in the database, a request is being processed. In this case, we should be able to identify if the request method is a POST or GET by right clicking the field and doing an “inspect”. After viewing the client source code, it can be confirmed that the method is a POST request.
At this point, we should try to find where the POST request happens so we can see the sanitizing method. To do this, type in the following command in cmd:
Code:
findstr /SPIN /c:”$_POST” “c:xampphtdocswitycms-0.6.1*.php”
The command is similar to what we did earlier to find files containing the “input” tag but this time, we are trying to find references of “$_POST” in .php files.
The result of the command points us to the files WMain.php, WRequest.php, and WSession.php because the other files pertain to libraries included. Browsing these files will then point us to an interesting function found in WRequest.php as shown below and notice that when a script tag is found, it is being replaced by an empty string:
Replacing the “script” tag with an empty string actually works as a sanitizing technique but it should filter recursively. After doing more analysis, it has been found out that the “filter” function was being called only once by referring to this function found in the same file:
Since there is no recursion for the filter function, the filter can only work for an input like this:
The filter can then be bypassed by entering an input like:
Trying this out as the input in the website’s name field will get us a result of:
Once this payload becomes the site name, a visiting user will be able to come across this script even when he or she is unauthenticated:
This opens a whole new world of opportunities because being able to execute an unwanted script when a user visits the website can be disastrous. Examples for this could be redirecting a user to a phishing site, executing miner scripts without the knowledge of the user, or many other possibilities.
Processing a CVE Number
Since this bug leads to a security issue and the CMS application is being used by about a hundred or more people, I decided to process an application for a CVE number as to get a public advisory. CVE or the “Common Vulnerabilities and Exposures” is simply a list of entries that show references of vulnerabilities for applications used in computing. There are CNAs or “CVE Numbering Authorities” that process these CVE numbers depending on the application support. For instance, if a security issue has been found in a Lenovo device, it should be reported to Lenovo’s PSIRT (Product Security Incident Response Team). After they assess the vulnerability, they will process a CVE number for it.
This simply means that if a security issue has been found in a product or project of a company that’s also a CNA, they can process the CVE number directly. A list of CNAs can be found here . In the case of wityCMS, CreatiWity, the creator of the product is not a registered CNA so we can request a CVE number for this persistent XSS through MITRE Corporation. Below are the steps to process a CVE number.
1. Confirm if the product is managed by a CNA. If it is managed by a CNA, report the vulnerability to that specific CNA. If not, report it to MITRE Corporation.
2. Confirm if the vulnerability found has already been assigned a CVE number. This can be done using a simple Google search about the product. Always check for the product updates to confirm if a public advisory already exists.
3. For wityCMS’s case, I have used MITRE’s CVE form which can be found here.
4. Fill in the form with the required details. For wityCMS, I have added in the following:
Vulnerability Type: Cross-Site Scripting
Product: wityCMS
Version: 0.6.1
Vendor confirmed the vulnerability? No (Not acknowledged yet at the time of request)
Attack Type: Remote
Impact: Code execution
Affected Components: Source code files showing “site_title” as output
Attack Vector: To exploit the vulnerability, one must craft and enter a script in the Site name field of the system
Suggested Description: Stored cross-site scripting (XSS) vulnerability in the “Website’s name” field found in the “Settings” page under the “General” menu in Creatiwity wityCMS 0.6.1 allows remote attackers to inject arbitrary web script or HTML via a crafted website name by doing an authenticated POST HTTP request to admin/settings/general.
Discoverer: Nathu Nandwani
Reference(s): https://ift.tt/2BaQje8
Information you provide should be detailed. To make the CVE number processing fast, a public reference should exist to discuss details of the vulnerability and a possible fix (if existing). For example, before sending in this report, I opened an issue in the project’s GitHub page with the suggested description. Since there are a lot of CVE numbers representing persistent XSS issues, I figured there would be good examples. I found one and used it as a model.
Final Tips:
CVE number processing takes only a day or two if the details have been disclosed publicly, so it is always best if you communicate with the developer or the response team associated with the project for proper fixing first.
Details of CVEs should be accurate. Changing details of the report sent to CNAs will slow down the process of the application. That means the vulnerability has to be confirmed first to make sure that time is not wasted by both sides.
More details about the conditions for CVE number applications can be found in the document at this website: https://ift.tt/2nG4oGN
VulDB helps in public advisories. Register in VulDB and you can submit an entry there. For example, here is the VulDB entry of this security issue.
Submit an entry for exploit-db.com too. This doesn’t only show proof of the issue, but it also adds a credible reference for the CVE number because offensive-security teams try their best to test the proof of concept. It’s here https://vuldb.com/?id.118269 and notice that it is currently pending verification. The submission instructions can be found here.
I found other persistent XSS vulnerabilities in this specific version of wityCMS but I haven’t gotten a CVE numbers. Can you identify them? Looking forward to hearing comments or questions. Cheers!
The post Discovering CVE-2018-11512 – wityCMS 0.6.1 Persistent XSS appeared first on Cybersecurity Insiders.
August 15, 2018 at 09:11PM
0 comments:
Post a Comment