頻道欄目
首頁 > 資訊 > 網站安全 > 正文

關于php萬能注入密碼的一點點研究

09-09-29        來源:[db:作者]  
收藏   我要投稿

黑暗訪問者

昨天一直在搞站,從下午兩點一直到晚上十一點宿舍熄燈,很是過癮,其中用到的一個技術很值得回味與研究。簡單的說下經過:

resin3.0.21的服務器,利用爆源碼的漏洞可以讀取任意盤符的任意文件。隨手讀了下boot.ini文件,發現是windows服務器。如圖1.所示但是不支持../類似的相對路徑。在url后面加"c:"也沒能瀏覽到c盤的文件。接下來就在url后面加N多特殊字符,不過問題來了,resin把錯誤全都定向到一個錯誤頁面,沒法爆出錯誤來,本來想用jsp爆錯誤的方法爆出路徑來,可是卻一直沒有進展。

很長一段時間沒有想到更好的辦法。期間用resin的漏洞讀到了my.ini讀到了mysql數據庫root的密碼,可是端口不讓連。用nmap掃描了一下。發現了3389和1723(vpn),80(resin)8080(php+apache+mssql后來才知道用的mssql服務器因為沒有獨到c:windowssystem32inetsrvmetabase.xml該文件所以認定沒有裝iis)登陸界面發現是2003的操作系統。5次ift之后發現沒有后門,很正常,這個就不多做考慮了。

用wwwscan掃描了一下,沒什么有價值的東西,拉天賜物語一起來搞,結果也不樂觀。只掃到pay等等幾個沒什么利用價值的東西。

小龍給我一個后臺登陸入口的地址:http://w,還有ww.xxxx.com:8080/admin_manage/。如圖2.和目標網站是同一個服務器,只是端口換成了8080,php的腳本。輸入一個不存在的頁面,查看報錯信息,根據經驗可以肯定是apache的搭建的。他找到了php站的絕對路徑,方法是在后臺輸入’php驗證界面就報錯了。

然后就是看源代碼找相對路徑了,很幸運找到了后臺的主要文件。發現后臺的文件居然很多沒有權限驗證。

    現實再一次打擊了我,居然后臺的每個連接都不能訪問。最后確定文件被刪除。我日。又是一次沉痛的打擊。沒辦法只能繼續搞。

     用resin看了下后臺的驗證文件(main.php)結果發現可以用萬能注入碼。源代碼如下:

include_once ("./include/connect_db.php");
$mydb = new mydb ();
$conn = $mydb->open ("unicom");

$sql0="select pass_wd,user_name,powers from t_admin_user where user_id=".$_POST[account]."";
$result0=mssql_query($sql0,$conn);
$row0=mssql_fetch_array($result0);

if ($row0["pass_wd"]!=md5($_POST["passwd"])) {
?>
<script language="javascript">
alert("Óû§Ãû»òÃÜÂë´íÎó£¡");
top.location.href="http://xxxxx/admin_manage/index.php";
</script>
<?
exit();

分析后發現如果密碼不正確就用exit();強制退出了。沒辦法繞過。

select pass_wd,user_name,powers from t_admin_user where user_id=".$_POST[account]."";

$result0=mssql_query($sql0,$conn);

if ($row0["pass_wd"]!=md5($_POST["passwd"])) {

完美的說了萬能密碼的可能性。不過還有一點就是這個網站的gpc為on了所有的單引號都給轉義了。貌似不能搞,可是后來和小鳥碰撞出了火花,說明了雙字節編碼漏洞的利用方法,雖然不是萬能但是這個網站確實感冒了。

構造語句為:螨union select top 1 0x3231323332663239376135376135613734333839346130653461383031666333,user_name,powers from t_admin_user--

密碼處填寫admin。

0x6361343532616336646235336531633130643664376635663833343463323631是admin的32位md5加密后的散列的值然后再轉成十六進制后的結果,為什么不是16位的?因為php的md5()函數加密后就是32位的。不信自己可以試試。為什么還要用十六進制轉換,原因是不能出現單引號。而且0x6361343532616336646235336531633130643664376635663833343463323631也要放在第一位,原因很簡單,看它的查詢的代碼就知道了。

提交后結果如圖4所示

雖然報錯了,可是說明是可以注入成功的。感覺真的很有意思。不過最后發現了一點很有意思的東西,就是在第一個字符是單引號,后面不是單引號的情況下。同樣也是可以繞過gpc的,不知道是什么原因,可能是mssql數據庫的問題。

順便說下,期間將后臺這個貌似注入點的注入點post轉發到get后用工具跑結果pangolin發現是個注入點,不過權限是public的,手工測試了下,貌似可以建表,不過也不知道到底成功沒有。手工爆表沒有爆出結果來。

小鳥說回來在linux下搞。

還會繼續關注這個網站。到時候更新到博客里。

相關TAG標簽
上一篇:臺積電:絕大多數7nm客戶都會轉向6nm_IT新聞_博客園
下一篇:最后一頁
相關文章
圖文推薦

關于我們 | 聯系我們 | 廣告服務 | 投資合作 | 版權申明 | 在線幫助 | 網站地圖 | 作品發布 | Vip技術培訓 | 舉報中心

版權所有: 紅黑聯盟--致力于做實用的IT技術學習網站

美女MM131爽爽爽毛片