C.P Sub V5.21 CSRF 分析

前言介紹:


終於有空檔可以寫這篇文章了!,由於都在忙、所以便無法出這份報告...

這節要來分析是一個公告系統的 CMS 開源專案 。

名為C.P Sub 公告系統是一款可以讓網站管理員從後台發布最新資訊,並且可供網站使用者嵌入至前台為資訊系統的強大應用功能,台灣「教育政府企業」有些部份都搭配使用它來作為最新消息系統提供使用者可知道該站消息。

後台編輯器採用了流行得CKeditor ,因此對一個編寫文章的人來說非常實用及容易上手。

漏洞重現:

*另提,不得不說開發者已經針對全部程式碼加上了基本token 驗證、也非常迅速響應漏洞問題,值得嘉許。

去年九月時候上報了此漏洞issue ,到了今年2月才獲得專案開發者全面修補更新檔。

接下來是先嘗試漏洞複測在針對程式碼進行追溯分析

首先,在後台當然是測試安全性!因此好奇的觀察頁面發現了文章刪除,這時腦子想的是在這裡是否可控?








意外看到了,刪除使用GET 方式來request 且附帶著公告參數值(id) 意指藉由這種模式來對Server 端請求刪除



↑ 也可以發現使用了onclick 事件的return confirm 屬性來針對刪除前的詢問作後續處理,但是得必須知道,對於沒有使用令牌來驗證且是以 get 方法含著有敏感資訊傳輸都是非常不安全作法!

所以構造這類利用代碼也是非常容易的,只要針對想刪除公告id 即刪除命令傳給再登入後台情況下管理員就可成功攻擊。

但這漏洞影響有限,後續可能可搭配一些漏洞結合技巧來作更嚴重攻擊。

Poc Payload:

<html>
<head>
<title>CSRF</title>
</head>
<body>


    <form action="http://website/manage.php">
      <input type="hidden" name="p" value="article&#95;del" />
      <input type="hidden" name="id" value="2" />
      <input type="submit" value="Hello" />
    </form>


</body>
</html>

漏洞分析:


接下來是要分析整個影響該漏洞問題的程式碼進行梳理分析

根據manage.php page 的p 參數來找尋



先判斷並以get 方式定義了p變量,且由getLib 函數定位當前page 位置然而交給setFilter 過濾其他額外頁面,如果獲取訪問當前頁面存在列表則以p 賦予顯示否則為空。

當然刪除文章是加載article_del ,因此定義到admin\article_del.php 文件




可以看到request 文章以GET id 參數值賦值給$getId ,刪除文章以delArticle 方法包含了$getId ,所以我們定位回溯到採用delArticle  函數方法


刪除文章時先check id 文章列表是否存在可正常顯示內容並且使用了setFilter 過濾,getLib 函數尋找當前要刪除id 是否存在,若存在則調用success_msg 函數顯示訊息

刪除過程當中沒有其他多餘檢查及令牌存在,因而後台發出刪除文章時、若id 存在資料庫則放行刪除,造成主要原因問題。


修補後詳細資料通報給Twcert Taiwan  後轉給Tanet 學術單位發布相關漏洞通知:







時間表:


2018 / 09 / 21  - 整理漏洞詳細資訊通報給C.P Sub 開發者

2018 / 09 / 21 - 收到開發者初步回復:已收到,正在調查及排定時間修補

2019 / 02 / 11 -  收到開發者回復:已經修補漏洞問題


*非常感謝開發者以往一直以來的協助及確認!

*轉載請註原文連結









  • 分享: