Php漏洞挖掘思路+實例

原文:Link
最近研究PHP漏洞的挖掘，總結了一些我挖到的漏洞，整理了一下思路，求各路神人補充、批評、指導~

本文所有示例均來自我在烏雲上已由廠商允許公開的漏洞

由於是實例的分析，基礎知識請百度，就不全都粘貼到前面了

0x01:  搜索所有的使用者可控變數（GET/POST/COOKIE/referer）

---

原因：所有使用者輸入都是有害的，代碼審計注重函數和變數，先看看在什麼地方會有輸入

可能出現的場景：

a) id=$_GET['id'];

可能存在的問題：

無過濾的SQL注入：

WooYun: chshcms 程氏CMS V3.0 注射（已在官方演示站測試）

$id=trim($_GET["id"]);

//下面直接就進查詢語句了

if($db->query("update".Getdbname('dance')." set CS_TID=".$tid." where cs_user='".$cscms_name."' and

當然，這是GET之後沒做過濾的情景

b) id=intval($_GET['id']);

可能存在的問題：intval對字元型無用，字元型變數是怎麼處理的呢？

如果字元型的addslashes，注意數字型盲注（見c2分析）

c) $tid=XX_Request("tid");

使用自己定義的安全過濾函數處理變數，很常見，很多框架都提供了解決方案，不過自己包裝一個也是很常見的

可能存在的問題：

c1) 有沒有忘記使用這個處理函數？

WooYun: chshcms 程氏CMS V3.0 注射（已在官方演示站測試）

$tid=CS_Request("tid"); //使用安全的CS_request addslash  


$id=trim($_GET["id"]); //呵呵呵，曲項向天歌，CS_Request哭了 

其實還是上面那個例子，自己忘了用這函數過濾了

c2) 函數本身是否安全？

WooYun: (新)程氏舞曲CMS 三步GETSHELL（實例演示+源碼詳析）

$t_Val = $magic?trim($_GET[$pi_strName]):addslashes(trim($_GET[$pi_strName]));

使用了addslashes，這就意味著逃脫單引號難度加大，需要尋找沒有單引號保護的語句注入

addslashes只處理單引號和斜杠，因此無法過濾形如 134 and 1=1 這樣的注射語句，請自行百度無單引號盲注

在下面的語句中，$cscms_name就是有單引號保護的，而$id是沒有單引號保護的

$db->query("update ".Getdbname('xiaoxi')." set CS_DID=1 where CS_ID=".$id." and cs_usera='".$cscms_name."'");

所以id引發了盲注

c3) 過濾函數能否滿足業務邏輯的特殊需求？

負數訂單啦，自己修改自己的投票數啦，各種業務邏輯上的問題都有可能發生

非常可惜，這個我還沒撞見過，如果以後撞見再更新到文章裡

d) 不要忘記我們能控制referer等變數

可能存在的問題：

雖然發現GET/POST都過濾處理了，但是referer和cookie容易被忽視

$_SERVER["HTTP_REFERER"] 例子：

WooYun: MacCMS 6.x referer處理不當引發注射

很遺憾，這個截至今日還未公開，等公開了大家再去看吧

$_COOKIE['xxx'] 例子：

WooYun: TCCMS全版本COOKIE注入（已演示證明）

$sql="select password from ".$_Obj->table." where id=".$_COOKIE['userId'];

情況和GET時是一樣的，不過注入時操作起來稍微麻煩些，SQLMAP教程我就不粘貼到這裡了，不會COOKIE注射的請百度

e) 還有其他的輸入變數，請各路高手帶著實例補充！

目前，我們瞭解了程式總體上是如何處理用戶輸入的

0x02：單獨搜索$_COOKIE，分析身份認證時的邏輯

---

原因：身份驗證屬於業務邏輯中“高危”的部分，大部分的高危漏洞都出在這裡

可能出現的場景：

a) 沒有cookie處理，直接全是session

那就等之後通讀代碼時直接去讀認證演算法好啦

b) 認證演算法中強度太弱（用可控的COOKIE算來算去），降低了偽造身份的難度

WooYun: (新)程氏舞曲CMS 三步GETSHELL（實例演示+源碼詳析）

第二步偽造身份時

elseif($_COOKIE['CS_Login']!=md5($_COOKIE['CS_AdminID'].$_COOKIE['CS_AdminUserName'].$_COOKIE['CS_AdminPassWord'].$_COOKIE['CS_Quanx'])){

有什麼意義呢？COOKIE我們能控制，當然之後程式有別的驗證，這裡只是舉例，就這一句而言沒有意義

實際上漏洞裡這個CMS這個演算法，後面只是在認證時沒有用到安裝時admin寫死在config裡的驗證碼而已，不過難度已經降下來了

c) 直接能繞過

如果情況b 沒有其他驗證了，那就繞過了

目前我們只是驗證了登陸時的邏輯，之後還需分析許可權的縝密程度

0x03：搜索所有的檔操作函數，分析其邏輯

---

原因：檔操作函數屬於敏感函數，往往業務邏輯上的漏洞可能導致任意檔操作

可能出現的場景：

a) 任意文件下載

WooYun: appcms 最新版 1.3.708 任意文件下載

<?php  

if(isset($_GET['url']) && trim($_GET['url']) != '' && isset($_GET['type'])) {  

    $img_url = base64_decode($_GET['url']);  

    $shffix = trim($_GET['type']);  

header("Content-Type: image/{$shffix}");  

readfile($img_url);

} else {

die('image not find');  

}

?>

PS：由於是業務邏輯上的問題，是沒辦法通過自動掃描發現的，而且針對SQL和HTML的過濾是起不到特大作用的

任意檔讀取的最大作用是讀config.php 和各種系統的敏感檔（如何爆物理目錄？請看0x04）

b) 任意文件寫入

WooYun: CSCMS V3.5 最新版 後臺命令執行GETSHELL（源碼詳析）

發帖時仍未公開，所以先不做分析，等公開後更新~

任意檔寫入的最大應用就是寫馬了，最大障礙是繞過過濾的HTML字元比如： <>，解決方式是大量應用base64

c) 任意檔刪除

很遺憾，還沒撞見過，要是撞見一個該多好

任意檔刪除的作用可以是刪除install.lock，然後重裝CMS

d) 其他操作，求補充

檔操作可以結合爆目錄

0x04：爆物理目錄

---

原因：上一小節我們可能能夠任意操作檔，但沒拿到網站的物理目錄位址，的確可以用黑盒不停地試圖讀取 c:\boot.ini 和 /etc/passwd 之類的來試圖判斷，但是這麼弄實在不可靠

怎麼辦：使用php vulnerability hunter 自動掃描就好了，這個確實可以偷懶用工具掃描，因為這個爆目錄危害實在太低了，必須配合其他漏洞才有危害，所以一般CMS都會有這種漏洞，我是說能掃描出來的漏洞

WooYun: appcms 最新版 1.3.708 任意文件下載

如果你不知道物理路徑，你可以試著用工具掃描一下，然後再讀取

0x05：搜索eval，preg_replace什麼的，看看有沒有命令執行

---

原因：能直接執行PHP代碼，也就是說可以寫一句話木馬了（file_put_contents），當然，要找可寫目錄

這地方我一直沒能找到例子，沒有親自實踐過，求各路高手帶實例提供幾個？

0x06：可以開始通讀代碼了，從index開始，注意的是資料的傳輸和輸出函數

---

原因：常見模式化的漏洞都不存在的話，就要分析整個系統了，因此需要完全而徹底地去做審計，這樣比繼續單獨搜索變數然後跟蹤更加省力一些

可能出現的場景：

a) 之前的過濾全白費了

WooYun: YXcms1.2.0版本 存儲式XSS（實站演示+源碼分析）

沒公開，等公開再更新文章，這是一個存儲式xss

b) 二次注入

由於二次開發中從資料庫裡取出的值沒有過濾，導致注射，由於沒有直接從用戶輸入中獲得，所以之前步驟很難發現

哎呀，求各路高手提供個示例呀，我這個自己也沒有碰到過丫

c) 平行許可權、任意投票、越權訪問 等等 等等 一大堆

0x07 總結

---

目前我就知道這麼些，希望能對剛接觸PHP代碼審計漏洞挖掘的新手有點幫助，由於我也是剛開始學習PHP漏洞挖掘不久，希望大家能廣泛提供學習的建議以及思路，也請批評指正文章中不妥之處，更希望高手們能帶著示例來指導。