作者：huha@知道創宇404實驗室
時間：2020年8月26日

前言

代碼審計的思路往往是多種多樣的，可以通過歷史漏洞獲取思路、黑盒審計快速確定可疑點，本文則側重于白盒審計思路，對Centreon V20.04[1]的審計過程進行一次復盤記錄，文中提及的漏洞均已提交官方并修復。

概述

Centreon（Merethis Centreon）是法國Centreon公司的一套開源的系統監控工具 。該產品主要提供對網絡、系統和應用程序等資源的監控功能。

網站基本結構

源代碼目錄組成

centreon/www/網站根目錄

centreon/www/include/核心目錄結構

概述一下

  • centreon/www/index.php是網站的入口文件，會先進行登錄認證，未登錄的話跳轉進入登錄頁，登錄成功后進入后臺
  • centreon/www/main.php與centreon/www/main.get.php，對應PC端與移動端的路由功能，根據不同的參數，可以加載到后臺不同的功能頁面，在實際調試的過程，發現使用main.php加載對應的功能頁時，最終會調用main.get.php，所以路由部分直接看main.get.php即可
  • entreon/www/include/目錄包含核心功能代碼、公共類。其中有些功能代碼可以直接通過路徑訪問，有些則需要通過main.get.php頁面進行路由訪問
  • centreon/www/api/目錄下的index.php是另一處路由功能，可以實例化centreon/www/api/class/*.class.php、centreon/www/modules/、centreon/www/widgets/*/webServices/rest/*.class.php、centreon/src/中的類并調用指定方法

在審計代碼的時候，有兩個要關注點：

  • 重點審查centreon/www/include/和centreon/www/api/class/兩個目錄，因為這些目錄下的功能點可以通過centreon/www/main.php或centreon/www/api/index.php路由訪問

  • 重點尋找繞過登錄認證或者越權的方式，否則后臺漏洞難以利用

代碼分析

如下簡要分析centreon/www/目錄下的部分腳本

index.php

index.php會進行登錄認證，檢查是否定義$_SESSION["centreon"]變量，這個值在管理員登錄后設置。程序登錄有兩種方式，使用賬密或者token，相關邏輯在/centreon/www/include/core/login/processLogin.php中。不止index.php，centreon/www/include/下大部分功能頁都會檢查session，沒有登錄就無法訪問

main.get.php

這是主要的路由功能，程序開頭對數據進行過濾。$_GET數組使用fiter_var()過濾處理，編碼特殊字符，有效地防御了一些XSS，比如可控變量在引號中的情況，無法進行標簽閉合，無法逃逸單引號

對_POST中的指定參數，進行過濾處理，對數據類型進行限制，對特殊字符進行編碼

最終_POST數組賦值到$inputs數組中

全局過濾數據后，程序引入公共類文件和功能代碼

99行session取出，認證是否登錄

通過登錄認證后，程序會查詢數據庫，獲取page與url的映射關系，程序通過p參數找到對應的url，進行路由，映射關系如下

接著248行include_once $url，引入centreon/www/include/下對應的腳本

這里將page與url映射關系存儲到本地，方便后續查詢

api/index.php

這是另外一個路由功能

同樣需要驗證登錄，104行$_SERVER['HTTP_CENTREON_AUTH_TOKEN']可以在請求頭中偽造，但是并不能繞過登錄，可以跟進查看CentreonWebService::router方法

在\api\class\webService.class.php，其中action參數可控

311行判斷isService是否為true，如果是，dependencyInjector['centreon.webservice']->get(object)

313行centreon.webservice屬性值如下，對應的是centreon/src目錄下的類

$webServicePaths變量包含以下類路徑

接著346行檢查類中是否存在對應方法，在374行處調用，但是在350~369進行了第二次登錄認證，所以之前$_SERVER['HTTP_CENTREON_AUTH_TOKEN']偽造并沒能繞過登錄

過濾處理

除了main.get.php開頭的全局過濾操作，程序的其他過濾都是相對較分散的，對于SQL注入的話，程序的很多查詢都使用了PDO進行參數化查詢，對于PDO中一些直接拼接的參數，則單獨調用某些函數進行過濾處理。比如下邊這里進行數據庫更新操作時，updateOption()會進行query操作，$ret["nagios_path_img"]可控，但是這里調用escape()函數進行轉義

路徑限制

不通過路由功能，直接訪問對應路徑的功能代碼，大部分是不被允許的，比如直接訪問generateFiles.php頁面

可以看到39行檢查oreon參數，這就是為什么要通過main.get.php去訪問某些功能點。當然有一些漏網之魚，比如rename.php頁面，這里只是檢查session是否存在，在登錄狀態下，可以通過路徑直接訪問該頁面。

One-click To RCE

XSS

在上一節的最后，為什么要糾結通過路徑訪問還是路由訪問呢？因為通過main.get.php中的路由訪問的話，會經過全局過濾處理，直接通過路徑訪問則沒有，這樣就有了產生漏洞的可能，通過這個思路可以找到一個XSS漏洞，在rename.php中程序將攻擊者可控的內容直接打印輸出，并且沒有進行編碼處理，缺乏Httponly與CSP等的攻擊緩存機制，當管理員點擊精心構造的鏈接時，將觸發XSS執行任意js代碼，導致cookie泄露。

漏洞分析

漏洞入口

centreon/include/home/customViews/rename.php

前邊也提到，46行驗證session是否存在，所以受害者只要處于登錄狀態即可，59行echo直接打印_REQUEST)返回的值，rename函數中對params['newName']，因為直接通過路徑訪問，沒有經過任何過濾處理

所以elementId控制為title_1(任意數字),設置newName為script標簽即可

授權RCE

程序在使用perl腳本處理mib文件時，沒有對反引號的內容進行正確的過濾處理，攻擊者利用XSS竊取的憑證登錄后，可上傳惡意文件導致遠程代碼執行，即One_click to RCE

漏洞分析

可以順著CVE-2020-12688[

查看源碼，38行執行了shell_exec(command從form)，打印$form方便調試

之前記錄的page與url的映射關系現在就可以派上用場了，設置page為61703，通過main.php或main.get.php可以路由到formMibs.php，也就是下邊的文件上傳功能

調試發現formMibs.php中31行的manufacturerId可以通過上傳數據包中mnftr字段修改，但是被filter_var()處理，只能為整數

雖然緩存文件名是不可控的，但是上傳的mib文件內容可控，shell_exec()中執行的命令實際為（"xxx.mib"代表緩存文件名）

/usr/share/centreon/bin/centFillTrapDB -f 'xxx.mib' -m 3 --severity=info 2>&1

centFillTrapDB是一個perl腳本，代碼在/bin/centFillTrapDB中，用use引入centFillTrapDB模塊

use命令尋找的路徑默認在@INC下，但不知道具體在哪里，可以全局搜索一下

最后在usr/share/perl5/vendor_perl/centreon下找到script目錄，有我們想要的文件

把centFillTrapDB模塊拉出來靜態看一下，發現存在命令執行且內容可控的位置，實際調試發現最終分支是進入541行，540行和543行是我添加的調試代碼

在perl中反引號內可以執行系統命令，534行trap_lookup可控，對于mib文件來說，{IFS}代替

為了方便構造mib文件，打印出反引號中的命令，并在服務器shell中進行測試

構造/tmp/1.mib文件

命令行執行

centFillTrapDB -f '/tmp/1.mib' -m 3 --severity=info 2>&1

可以清晰的看到command，并且執行了curl命令

修改mib文件中的命令，在瀏覽器上傳進行測試，成功執行whoami并回顯

審計總結

文本主要分享了一些白盒審計思路，但就像之前所說的，審計的思路往往是多種多樣的，以下是個人的小小總結：

  • 分析歷史漏洞，在復現和調試的過程中，可以比較快的了解這個框架的結構，也可以從歷史漏洞中獲取思路，舉一反三
  • 黑盒審計，開啟抓包工具，測試可疑的功能點并觀察數據包，這樣可以加快對網站路由的熟悉，也可以快速的驗證一些思路，排除一些可能性，仍然存疑的功能點可以在白盒審計時進一步確認；
  • 白盒審計，入口腳本，路由方式，核心配置，常用功能模塊和數據驗證過濾操作，這些都是要留意的，當然最主要還是看入口，路由和數據過濾驗證的部分；其他的如核心配置，常用功能模塊，可以按需查看，大概了解了網站架構就可以開始看對應的功能代碼了，看的時候可以分兩個角度：一個就是從剛才黑盒測試遺留的可疑點入手，斷點功能代碼，審查是否存在漏洞；另一個就是從敏感關鍵字入手，全局搜索，溯源追蹤。
  • 注重不同漏洞的組合攻擊，無論是這次的Centreon One_click to RCE漏洞，還是通達OA任意刪除認證文件導致的未授權RCE、PHPCMS V9 authkey泄露導致的未授權RCE，打的都是一套組合拳，在漏洞挖掘的過程可以多加關注

參考鏈接

[1] Centreon V20.04

https://github.com/centreon/centreon/releases/tag/20.04.0

[2] CVE-2020-12688漏洞公開細節

https://github.com/TheCyberGeek/Centreon-20.04

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1313/