發現CVE-2018-11512-wityCMS 0.6.1 持久型XSS的示例分析

本篇文章給大家分享的是有關發現CVE-2018-11512-wityCMS 0.6.1 持久型XSS的示例分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

WityCMS就是一個由creatiwiwiwiwiwity制作的CMS系統，它幫助管理不同用途的內容，如個人博客、商業網站或任何其他定制系統。在本文中，我將介紹如何設置CMS，查找web應用程序問題，以及如何復現CVE-2018-11512漏洞。

環境安裝(windows下安裝xampp)

• 1.下載WityCMS0.6.1的源代碼

• 2.把/witycms-0.6.1 目錄復制到C:\xampp\htdocs\ 下 或者是你自己安裝xampp的的htdocs目錄

• 3.運行Apache和MySQL然后訪問http://localhost/phpmyadmin/index.php.

• 4.點擊"databases"(中文版本的"數據庫")

• 5.創建一個名為"creatiwity_cms"的數據庫

6.瀏覽器進入http://localhost/witycms-0.6.1/ 可以查看你的程序

7.填下"Site name(站點名稱)"之類的內容，我添加了一個"Test"，然后可以點擊next進入下一步了

8.然后是定義系統的主頁，你可以從選項中選擇任何一個。

9.接著設置數據庫，第5步那里我建了一個名為"creatiwity_cms"的數據庫，所以在這我們要這樣設置

10.輸入管理員賬號，然后點擊"Launch install!(開始安裝)"11.安裝成功后的頁面

查找漏洞

因為這篇文章主要是關于CVE-2018-11512的，所以我今天就只找這個程序中的持久型XSS的洞，開始之前，我們先了解下什么是持久型XSS。

根據OWASP的介紹，"跨站腳本攻擊(xss)是一種注入類型的攻擊手段，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中"。這意味著只要一個網站上存在注入點，xss就可能被觸發。目前有三種類型的XSS，但是本文我將討論常見的XSS，即反射型XSS和持久型XSS。

當輸入的數據被在發出請求后被返回給我們時，反射型XSS就會被觸發。對于反射型XSS來說，網站的搜索功能可以作為一個測試反射型XSS的很好的例子。當用戶在搜索框中輸入一段payload后，該搜索功能可能會受到反射型XSS的影響。

另外，持久型XSS也被稱為"存儲型XSS"。這種類型的XSS值會被保存在系統中的某個數據庫或是文件中。XSS的利用點通常存在于可以讓用戶隨時更改的設置操作中，比如用戶的個人信息頁，可以設置用戶的電子郵件，姓名，地址之類的地方。也可能存在于用戶可以自己更改的某些系統設置中。

對于wityCMS，我的目標是找到可以在系統中保存數據的利用點。這基本上可以手工完成，也可以通過工具自動找到這些利用點。由于我已經在Windows中安裝了它，所以我必須使用命令“findstr”而不是“grep”(抱歉，喜歡用"grep"的同學們)。可以在這里找到"findstr"的相關信息。

惡意代碼的文件，我們可以使用以下命令:">要列出可以輸入惡意代碼的文件，我們可以使用以下命令:

/S = Recursive searching
/P = Skip files with non-printable characters
/I = Case insensitive
/N = Prints the line number
/c:<STR> = String to look for

代碼:

findstr /SPIN /c:"<input" "c:\xampp\htdocs\witycms-0.6.1*.html"

這個結果肯定很讓人驚喜，因為可能存在XSS的地方太多了。登錄到管理員面板后，我們可以輕松的在輸入框中輸入我們的payload。通過訪問http://localhost/witycms-0.6.1/，我們可以看到一個很明顯的值，如圖所示:

我們安裝這個CMS的時候設置了這個站點名稱，它現在顯示在主頁上，不知道這個站點名稱會不會存在持久型XSS，現在我們看看能不能在管理設置里修改這個值。

使用安裝時設置的管理員賬號密碼登錄到管理面板，登錄后，管理面板中會有一個這樣的小鏈接:

點擊"Administration"后，網頁會被重定向到我們安裝時的執行設置操作的頁面，第一個設置值也是網站名稱。

插入一個非常簡單的XSS代碼試試:

點擊"save(保存)"后，返回值為:

可以注意到<script>和</script>標簽被過濾了，因此我們可以知道該系統中存在一個防護機制，所以現在我們需要找到這個防護機制的運行原理。

當數據被保存到數據庫中時，會處理一個請求。在這種情況下，我們應該能夠識別請求方法是POST還是GET，在頁面空白處右鍵單擊"審查元素"查看源代碼后，可以確認該方法是POST請求。

從這點來看，我們應該嘗試找到POST請求發生的地方，這樣順下去我們就可以看到防護機制的運行點。因此，在cmd中輸入以下命令:

findstr /SPIN /c:"$_POST" "c:\xampp\htdocs\witycms-0.6.1*.php"

這個命令類似于我們之前查找包含“input”標記的文件，但是這次，我們嘗試在.php文件中查找引用"$_POST"的地方。

因為其他文件都與默認包含的庫有關，這些都pass掉。所以命令的結果指向文WMain.hp,WRequest.php和WSession.php。瀏覽這些文件將我們發現在WRequest中有一個有趣的函數。如下所示，當防護機制發現腳本標示符時，這些標示符將被一個空字符串替換:

由于過濾器函數沒有遞歸，所以過濾器只能攔截這樣的輸入:

所以輸入這種內容是可以繞過過濾器的:

在我們設置站點名稱的輸入框中輸入以下內容，我們將會得到以下結果:

一旦這個payload被設置為站點名稱，訪問網站的用戶將會觸發這個腳本，即使TA并沒有經過身份驗證。

這就開啟了新世界的大門，因為當用戶訪問網站時會執行某些惡意腳本可能會造成比較嚴重的后果。比如可以將用戶重定向到釣魚站點，在用戶不知情的情況下執行礦機腳本，或者其他很多操作。

處理CVE編號

由于這個bug容易引起安全問題，并且這個CMS正在被數以千計的人使用，所以我決定給這個程序申請一個CVE編號，以此來獲得一個公開的CVE條目。

信息安全漏洞或者已經暴露出來的弱點給出一個公共的名稱。cnas(cve-numbering-authorities)根據程序類型分別處理這些cve編號的漏洞。例如，如果聯想設備中發現了安全問題，應該向聯想的產品安全應急響應團隊報告，在評估了漏洞后，他們將會給這個漏洞一個cve編號。">CVE 的英文全稱是"Common Vulnerabilities & Exposures"，CVE就好像是一個字典表，為廣泛認同的計算機信息安全漏洞或者已經暴露出來的弱點給出一個公共的名稱。CNAs(CVE Numbering Authorities)根據程序類型分別處理這些CVE編號的漏洞。例如，如果聯想設備中發現了安全問題，應該向聯想的產品安全應急響應團隊報告，在評估了漏洞后，他們將會給這個漏洞一個CVE編號。

這說明，如果同樣是在CNA公司的產品或項目中發現了漏洞，他們評估后可以直接給出一個CVE編號，在CNAs的CVE的漏洞列表中可以通過編號直接找到這個漏洞。而對于wityCMS, CreatiWity這兩個產品，其創建者沒有注冊到CNA，所以我們可以向MITRE公司申請這個持久型XSS漏洞的CVE編號，下面是處理CVE漏洞事件的步驟：

• 1.確認產品是否由CNA管理。如果由CNA管理，則報告該特定CNA的漏洞。如果不是，則報告給MITRE公司。

• 2.通過google確認發現的漏洞是否已經分配了一個CVE編號。經常檢查產品更新，以確認漏洞是否已經公開。

• 3.對于wityCMS的情況，我使用了MITRE公司的CVE申請表單，可以在這里找到。

• 4.在表格中填寫所需的詳細信息。關于wityCMS的這個漏洞，我是這樣填的:

• Vulnerability Type: Cross-Site Scripting

• (漏洞類型:xss)

• Product: wityCMS

• (廠商:wityCMS)

• Version: 0.6.1

• (版本：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

• 受影響的組件:輸出"site_title"的源文件

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

• 漏洞詳情:在creatiwitycms 0.6.1的“設置”菜單下的“網站名稱”字段中存在存儲型XSS漏洞，允許遠程攻擊者通過一個經過驗證的POST HTTP請求向admin/ Settings / General注入任意的web腳本或HTML。

• Discoverer: Nathu Nandwani

• (發現者:Nathu Nandwani)

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

• 
  

為了讓CVE處理的更快一些，描述中最好引用一些可以輔助理解漏洞的資料，并且詳細地描述漏洞細節，如果可以，還應該寫上漏洞可能有的修復方案。例如，在發送報告之前，我在這個項目的GitHub主頁上發現了這個漏洞可能存在的點，因為有很多已經公開的關于存儲型XSS的CVE漏洞，我找了其中的一個作為參考，然后通過這個漏洞想到了構造一個存儲型XSS方法，并且注意到在這個GitHub項目中可能通過這個方法復現這個漏洞。

最后一點小貼士

1. 如果細節已經公開，那么CVE號處理只需要一兩天，所以最好先與開發人員或與項目相關的響應團隊進行溝通，以便進行適當的修復。

2. CVE漏洞的細節應該是準確的。更改發送給CNAs的報告的細節將減慢審核的速度，這意味著必須首先確認漏洞，不要浪費雙方的時間。

3. 更多關于CVE漏洞提交的細節可以在這里找到。

4. VulDB提供漏洞公開服務。注冊一個VulDB賬號，你可以在那里提交一個條目。例如，這里是這個安全問題的VulDB條目。

5. 也可以提交到exploit-db.com。這不僅顯示出問題確實存在，而且還為CVE編號增加了可信的參考，因為安全團隊盡其所能地測試驗證漏洞是否存在。這里是一個exploit-db.com條目，請注意它目前正在等待驗證。提交說明可以在這里找到

以上就是發現CVE-2018-11512-wityCMS 0.6.1 持久型XSS的示例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。