Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example analysis of discovering CVE-2018-11512-wityCMS 0.6.1 persistent XSS

2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)05/31 Report--

The purpose of this article is to share with you the example analysis of finding CVE-2018-11512-wityCMS 0.6.1 persistent XSS. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

WityCMS is a CMS system created by creatiwiwiwiwiwity that helps manage content for different purposes, such as personal blogs, commercial websites, or any other custom system. In this article, I'll show you how to set up CMS, find problems with web applications, and how to replicate the CVE-2018-11512 vulnerability. Environment installation (install xampp under windows)

1. Download the source code for WityCMS0.6.1

two。 Copy the / witycms-0.6.1 directory to C:\ xampp\ htdocs\ or the htdocs directory where you installed xampp

3. Run Apache and MySQL and then access http://localhost/phpmyadmin/index.php.

4. Click "databases" (Chinese version of "database")

5. Create a database named "creatiwity_cms"

6. The browser can go to http://localhost/witycms-0.6.1/ to view your program.

7. Fill in "Site name" and so on, I added a "Test", and then I can click next to proceed to the next step.

8. Then it is to define the home page of the system, and you can choose any one of the options.

9. And then set up the database, and in step 5, I built a database called "creatiwity_cms", so here's what we're going to do.

10. Enter the administrator account and click "Launch install!" 11. Page after successful installation

Look for bugs because this article is mainly about CVE-2018-11512, so I'm only looking for holes in persistent XSS in this program today. Before we begin, let's take a look at what persistent XSS is. According to OWASP, "Cross-site scripting attacks (xss) are injection-type attacks that allow malicious web users to plant code into pages made available to other users." This means that xss can be triggered as long as there is an injection point on a website. There are currently three types of XSS, but in this article I will discuss the common XSS, namely reflective XSS and persistent XSS. The reflective XSS is triggered when the input data is returned to us after the request is made. For reflective XSS, the site's search function can be used as a good example of testing reflective XSS. When the user enters a payload in the search box, the search function may be affected by the reflective XSS. In addition, persistent XSS is also known as "storage XSS". This type of XSS value is saved in a database or file in the system. The use of XSS usually exists in settings that can be changed by the user at any time, such as the user's personal information page, where the user's email, name, address, and so on can be set. It may also exist in some system settings that users can change themselves. For wityCMS, my goal is to find a utilization point where data can be saved in the system. This can basically be done by hand, or these utilization points can be found automatically through tools. Since I have installed it in Windows, I have to use the command "findstr" instead of "grep" (sorry, students who like to use "grep"). You can find information about "findstr" here. For files with malicious code, we can use the following command: "> to list files that can enter malicious code, we can use the following command:

/ S = Recursive searching

/ P = Skip files with non-printable characters

/ I = Case insensitive

/ N = Prints the line number

/ c: = String to look for

Code:

Findstr / SPIN / c: "the English full name of CVE is" Common Vulnerabilities & Exposures ". CVE is like a dictionary table, giving a public name for widely recognized computer information security vulnerabilities or vulnerabilities that have been exposed. CNAs (CVE Numbering Authorities) handles these CVE numbering vulnerabilities according to the type of program. For example, if a security problem is found in Lenovo's device, it should be reported to Lenovo's product security emergency response team, who will give the vulnerability an CVE number after evaluating the vulnerability. This means that if a vulnerability is also found in CNA's products or projects, they can directly give a CVE number after evaluation, and the vulnerability can be found directly in the vulnerability list of CNAs's CVE. For wityCMS and CreatiWity, the creators are not registered with CNA, so we can apply to MITRE for the CVE number of this persistent XSS vulnerability. Here are the steps to deal with the CVE vulnerability event:

1. Confirm that the product is managed by CNA. If managed by CNA, a vulnerability for that particular CNA is reported. If not, report to MITRE.

two。 Confirm through google whether the discovered vulnerability has been assigned an CVE number. Check product updates frequently to make sure that vulnerabilities have been made public.

3. In the case of wityCMS, I used MITRE's CVE application form, which can be found here.

4. Fill in the required details in the form. With regard to this loophole in wityCMS, I fill in the following:

Vulnerability Type: Cross-Site Scripting

(vulnerability type: xss)

Product: wityCMS

(manufacturer: wityCMS)

Version: 0.6.1

(version: 0.6.1)

Vendor confirmed the vulnerability? No (Not acknowledged yet at the time-of request)

Whether the vendor has confirmed that the vulnerability is not available (not confirmed when the vulnerability is submitted)

Attack Type: Remote

Type of attack: remote

Impact: Code execution

(impact: code execution)

Affected Components: Source code files showing "site_title" as output

Affected components: output the source file of "site_title"

Attack Vector: To exploit the vulnerability, one must craft and enter a script in the Site name field of the system

Attack method: script must be manually injected into 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.

Vulnerability details: there is a stored XSS vulnerability in the site name field under the Settings menu of creatiwitycms 0.6.1, which allows remote attackers to inject arbitrary web scripts or HTML into admin/ Settings / General through an authenticated web request.

Discoverer: Nathu Nandwani

(discoverer: Nathu Nandwani)

Reference (s): https://github.com/Creatiwity/wityCMS/issues/150, https://github.com/Creatiwity/wityCMS/co...229147de44

In order for CVE to process faster, it is best to refer to some information that can help understand the vulnerability, describe the details of the vulnerability in detail, and, if possible, write down possible fixes for the vulnerability. For example, before sending the report, I found a possible point of this vulnerability on the GitHub home page of the project, because there are many CVE vulnerabilities that have been exposed about storage-based XSS, and I found one of them as a reference, and then came up with a method of constructing a storage-type XSS through this vulnerability, and noticed that it was possible to replicate the vulnerability in this GitHub project. One last tip

If the details are made public, the CVE number will only take a day or two to process, so it's best to communicate with the developer or the project-related response team first so that appropriate fixes can be made.

The details of the CVE vulnerability should be accurate. Changing the details of the report sent to CNAs will slow down the review, which means that vulnerabilities must be identified first and do not waste both parties' time.

More details on CVE vulnerability submission can be found here.

VulDB provides vulnerability disclosure services. Sign up for a VulDB account, where you can submit an entry. For example, here is the VulDB entry for this security issue.

It can also be submitted to exploit-db.com. This not only shows that the problem does exist, but also adds a credible reference to the CVE number, as the security team does its best to test and verify the existence of vulnerabilities. Here is an exploit-db.com entry, please note that it is currently waiting for validation. Submission instructions can be found here

The above is the example analysis of finding CVE-2018-11512-wityCMS 0.6.1 persistent XSS. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report