Discovering CVE-2018-11512 - wityCMS 0.6.1 Persistent XSS
#1
Discovering CVE-2018-11512 - wityCMS 0.6.1 Persistent XSS

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 exponential possibilities if ever a bug is found. This is because a white box type of assessment looks into the internal structure of how an application works.
 
WityCMS for instance is a system made by CreatiWity which assists in managing contents for different uses like personal blogging, business websites, or any other customized systems. In this post, I will walk through the steps from setting up the CMS, finding a web application issue, and how to process 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:\xampp\htdocs\ 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.

[Image: wity_CMS_1.png]

6. You should now able to browse the application by visiting http://localhost/witycms-0.6.1/

[Image: wity_CMS_2.png]

7. Fill in data required like for “Site name”, I’ve added in “Test”. You should be able to click on the next button afterwards.

[Image: wity_CMS_3.png]

8. The next is defining the homepage of the system. You can choose any from the options. For example:

[Image: wity_CMS_4.png]

9. Setting up the database should follow. From step #5, I have used the database name “creatiwity_cms” so this goes in the database setup.

[Image: wity_CMS_5.png]

10. Enter the administrator account details and click “Launch install!” (I have added in the user “admin” with the password of “admin” here)

[Image: wity_CMS_6.png]

11. Once successful, this page should pop up:

[Image: wity_CMS_7.png]

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 for this one can be a field that requires user details such as the user’s email, first name, last name, address, and many other 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 automation of finding these fields. Since I have installed it in Windows, I had to use the command “findstr” instead of “grep” (So 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:\xampp\htdocs\witycms-0.6.1\*.html"
 
The result of running the command above will be:

[Image: wity_CMS_8.png]

Now since the result is surely astounding because there are a lot of fields, we can easily pin point 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:

[Image: wity_CMS_9.png]

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 show up like the one below:

[Image: wity_CMS_10.png]

When the “Administration” hyperlink was clicked, I got redirected to the Settings page first thing because this was the page I entered during the setup and the first field there is the website’s name too.

[Image: wity_CMS_11.png]

A very basic test for XSS is through adding a Javascript code such as:
 
Code:
<script>alert(1)</script>

[Image: wity_CMS_12.png]

When the “save” button gets clicked, the field returns the value:

[Image: wity_CMS_13.png]

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 would be finding out how the sanitizing method works.
 
Whenever data like the one mentioned 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.

[Image: wity_CMS_14.png]

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:\xampp\htdocs\witycms-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.

[Image: wity_CMS_15.png]

The result of the command points us to the files WMain.php, WRequest.php, and WSession.php because the other files are pertaining 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:

[Image: wity_CMS_16.png]

Replacing the “script” tag with an empty string actually works as a sanitizing technique however, it should at least do the filtering 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:

[Image: wity_CMS_17.png]

Since there is no recursion for the filter function, the filter can only work for an input like this:

[Image: wity_CMS_18.png]

The filter can then be bypassed by entering an input like:

[Image: wity_CMS_19.png]

Trying this out as the input in the website’s name field will get us a result of:

[Image: wity_CMS_20.png]

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:

[Image: wity_CMS_21.png]

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 more.

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 following 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 has already been done.
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://github.com/Creatiwity/wityCMS/issues/150https://github.com/Creatiwity/wityCMS/co...229147de44
 
Filling in the information should be detailed. To make the CVE number processing fast, a public reference should exist which discusses the details of the vulnerability and a possible fix if existing. For example, before sending in the report, an issue was opened in the project’s GitHub page with the suggested description. Since there are a lot of CVE numbers representing persistent XSS issues, I searched for one and grabbed the idea of how to construct a good description and notice that the posted issue in GitHub will show the same description found in the CVE number description here.
 
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 CVE numbers should be accurate. Changing details of the report sent to CNAs will slow down the process of the application which means, the vulnerability has to be confirmed first to make sure that time is not wasted for both sides.
  • More details about the conditions for CVE number applications can be found here
  • VulDB helps in public advisories. Try to 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 the offensive-security team tries their best to test the proof of concept when they can. Here is the exploit-db.com entry and notice that it is currently pending for verification. The submission instructions can be found here.
 
I found other persistent XSS vulnerabilities in this specific version of wityCMS but I didn’t apply a CVE number for it. Can you identify them? Looking forward to hearing comments or questions. Cheers!
Reply
#2
Did you author this post or did you copy/paste it from somewhere online?
Reply
#3
(06-02-2018, 09:05 AM)mŷth Wrote: Do you author this post or did you copy/paste it from somewhere online?

Hi mŷth! Yes I did create this post originally. I didn't copy/paste this from somewhere online. Why if I may ask?
Reply
#4
Nice! I’d say the score is going to be slightly low because you have to be authenticated and have administrative access, but still nicely done!
Reply
#5
(06-02-2018, 01:55 PM)ekultek Wrote: Nice! I’d say the score is going to be slightly low because you have to be authenticated and have administrative access, but still nicely done!

Definitely true ekultek but one thing I learned during the PWK labs from offensive-security is that, things just take time. As long as the vulnerability exists, still needs patching to make sure. Thanks a lot!
Reply
#6
(06-02-2018, 02:12 PM)nats Wrote:
(06-02-2018, 01:55 PM)ekultek Wrote: Nice! I’d say the score is going to be slightly low because you have to be authenticated and have administrative access, but still nicely done!

Definitely true ekultek but one thing I learned during the PWK labs from offensive-security is that, things just take time. As long as the vulnerability exists, still needs patching to make sure. Thanks a lot!

Yeah, vulnerabilities should always be patched, even if they require admin priviledges.
Good job on the CVE and on the thread. It was interesting and started from the basics so it can reach everyone.

Good luck on ToTM! Smile
Reply
#7
This post actually got me into searching my gitlab server for xss vulnerabilities and what not, and I’m happy to say I’ve discovered one or two.
Reply
#8
(06-15-2018, 01:25 AM)ekultek Wrote: This post actually got me into searching my gitlab server for xss vulnerabilities and what not, and I’m happy to say I’ve discovered one or two.

Oh cool! Well done man!
Reply
#9
Awesome share, love the use of the findstr method. gGoing to try to apply this to other web apps.
Reply
#10
(06-25-2018, 04:22 PM)Infinityex Wrote: Awesome share, love the use of the findstr method. gGoing to try to apply this to other web apps.

Thanks a lot man! Let us all know if you find something on your side. Cheers!
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  [Tutorial] XSS through Exif headers Insider 1 640 06-16-2020, 11:51 AM
Last Post: LaZr4us
  Guide to XSS (Examples included) NO-OP 3 12,538 04-29-2019, 12:44 PM
Last Post: mhiats37
  [PoC] RunBox.com x MailChimp.com - Stored XSS Vulnerabilities (Bug Bounty Hunting) Daisuke Dan 3 5,829 04-24-2019, 08:47 PM
Last Post: thunder
  Exploiting Reflective XSS (Post) Insider 1 4,245 04-24-2019, 08:32 PM
Last Post: thunder