我最近處理了一個Linux Web服務器被侵略的案件，作業(yè)的原因是客戶發(fā)現(xiàn)Web服務器上呈現(xiàn)了一個新的PHP文件，它與運轉(zhuǎn)在服務器上的WordPress運用程序和特定的用戶署理無關(guān)，全部的流量都被重定向到另一個站點。

 blob.png

本文并不是一個詳細的取證攻略，也不是一個翔實的安全作業(yè)呼應手冊。寫作的意圖是想為您供給一些思路，碰到需求處理這類Linux服務器被黑的Case時分，你應該作何考慮？施行那些行為？需求預備哪些常用的東西？

1．開端

當管理員第一次發(fā)現(xiàn)服務器被侵略后，當即整理了全部發(fā)現(xiàn)的歹意文件，修正了重定向的問題，以為全部都現(xiàn)已恢復了，直到不久之后服務器再次被侵略。管理員又做了修正作業(yè)，這次還更新了體系，在決議將運用程序轉(zhuǎn)移到一臺新服務器上之前，他們決議請其他人員查看以下，所以，我就上場了。

擺在我眼前的待取證對象是：

仍在出產(chǎn)環(huán)境中運轉(zhuǎn)的體系

至少遭受了兩次侵略

管理員進行對體系進行了實質(zhì)性的修正

這些條件都不算抱負，乃至可以說是不適宜的，提早聲明：我的意圖不是去發(fā)明一個合法有用的監(jiān)測鏈，而是要做混合取證，在盡可能的不終端運轉(zhuǎn)中的服務的狀況下，進行作業(yè)呼應和修正被損壞的東西。我的方針是：

斷定體系是否仍然處于風險狀況（假如是的話，刪去或阻撓與此相關(guān)的全部內(nèi)容）

檢測是否存在被修正的文件，以防止將已被感染文件遷移到新的服務器上

抱負狀況下，找出初始的侵略向量，并保證它已被阻撓。

在取得域名、IP和SSH憑據(jù)之后，我就開端作業(yè)了。

2．搜集依據(jù)

在銜接到服務器之前，我記載了自己的IP，保證今后可以在日志中辨認出它。

然后我經(jīng)過SFTP指令銜接到了服務器上。由于服務器的磁盤現(xiàn)已被加載并且正在運轉(zhuǎn)，因而我無法取得鏡像，所以我下載了全部感興趣的、能得到的日志文件。我仿制了整個/var/log目錄和存儲Apache日志文件的特定目錄，仿制了受損的PHP運用程序，以及在作業(yè)發(fā)作后不久所采納的一些備份。不幸的是，第一次被侵略和管理員做出更改之間沒有進行體系備份，因而一些要害文件可能現(xiàn)已被修正了。

敞開了Kali，針對服務器發(fā)動Nmap端口掃描和wpscan掃描。由于服務器運轉(zhuǎn)了一個老舊的WordPress實例，并且這個實例曾履行過歹意的重定向，所以WordPress很可能是侵略的初始點。但是，由于WordPress在被侵略后現(xiàn)已更新過了，wpscan沒有在當時的版別中找到任何縫隙。Nmap端口掃描的成果是敞開了FTP，SSH，HTTP和HTTPS端口，這關(guān)于一個Web服務器來說有點剩余，進犯者也可能從其間一項服務進行打破。但是，管理員的陳述里說全部的shell都是在wp-content目錄下被發(fā)現(xiàn)的，這在某種程度上暗示了進犯者可能侵略了WordPress運用程序。

我還運用VirusTotal查看了該站點是否有傳達歹意軟件的記載，但好像全部都很好。

我決議經(jīng)過控制臺登錄體系。由于不斷定服務器上的二進制文件是否被感染了，所以為了削減影響，我運用了自己的靜態(tài)鏈接二進制文件。從BusyBox下載了coreutil二進制文件并上傳到服務器上，一起還上傳了chkrootkit東西和SLEUTH東西包中的一個名為mac-robber的東西。

用靜態(tài)二進制文件查看體系，得到運轉(zhuǎn)中的進程和cronjobs等的列表信息，你可以運用

netstat-tulpen

指令得到一個監(jiān)聽（TCP和UDP）進程的列表（我沒有掩蓋全部掃描到的端口，所以得到的輸出可能是風趣的）。可以運用

netstat-taupn

指令顯現(xiàn)從服務器中輸出的活動的銜接（TCP和UDP）。但是，這兩個清單都沒有發(fā)現(xiàn)可疑的活動。

Rootkit檢測東西chkrootkit也什么都沒發(fā)現(xiàn)，運用rkhunter和ClamAV也沒有什么收成（這不意味著什么，不幸的是，ClamAV錯失了PHP shells和Windows木馬）。

我開端手藝尋覓一些不同尋常的事物，但現(xiàn)在為止全部好像都很潔凈：沒有不尋常的敞開端口、沒有不尋常的進程在運轉(zhuǎn)。我用一個管理員賬戶驗證了FTP和ssh帳戶，它們看起來不錯。在這個層面上好像沒有侵略的痕跡。

mac-robber東西協(xié)助我搜集了服務器上創(chuàng)立和修正的文件的信息（稍后可被用于創(chuàng)立作業(yè)的時刻線）：

./mac-robber / >/root/forensics/timeline.txt

現(xiàn)在，我發(fā)現(xiàn)了：

服務器上被創(chuàng)立的文件及時刻的信息

各種日志文件，其間包括Apache日志

被侵略的網(wǎng)站一些元代吧，包括一些（被修正過的）shell文件

第一次和第2次被侵略之間的備份

總的來說，還算有所收成。當然，您可能以為這些日志數(shù)據(jù)不能被信賴，由于它們可能被進犯者修正過了。但我卻沒有理由等待進犯會這么雜亂。

3. 深度查看

管理員現(xiàn)已斷定了一些被進犯者上傳的webshells文件。我開端查看這些文件，發(fā)現(xiàn)大部分文件的姓名都比較蔭蔽，如Xjrop.php，Nwfqx.php或Rwchn7.php（首字母都是大寫的），這些文件是完全相同的，渙散在正常的運用程序文件之間。但是有一個名為up.php的文件，與上述幾個文件的源代碼不同，功用也稍有不同?？梢赃\用diff指令比較兩個文件：

diff Xjrop.php Nwfqx.php

或許比較它們的MD5值：

md5sum Xjrop.php

md5sum Nwfqx.php

還有2個文件的姓名比較古怪，bjrnpf.php和jemkwl.php，全部是小寫這兩個文件是相同的，但有別于其他文件。一個可疑的可履行文件被命名為windoze.exe，我置疑一些歹意軟件可能現(xiàn)已從該主機傳達出去了。運用md5sum核算這個文件的哈希值，在VirusTotal進行查看，（留意上傳到VirusTotal的文件可以被其他研究人員看到，是公共的，所以最好不要上傳可能含有保密或靈敏信息的東西，可以首要運用哈希值進行剖析）。VirusTotal的剖析成果斷定該文件為木馬程序。因而我將它保存下來以備后續(xù)的剖析。

剖析這些PHP shell樣本，發(fā)現(xiàn)某些文件中包括如下信息：

留意它們的標題“404-server!!”。用查找引擎查找胰腺癌，發(fā)現(xiàn)了其他一些可能受感染的服務器信息：

 還有一些可疑文件中，包括了一些看似無用的代碼：

這一行代碼的意義是正則匹配“saft”字符串中的小寫字母“pageerror”，將其替換成$_POST 變量“mkf3wapa”。由于返回值被疏忽，所以我不知道這個代碼片段詳細的效果是什么。

但是，運用Google查找，發(fā)現(xiàn)一大堆的查詢成果，標明這段代碼與黑客上傳的“404-Server!!”shell腳本有聯(lián)絡(luò)，它們一起呈現(xiàn)在被侵略的服務器上。因而，假如您在服務器上找到此代碼，它可能存在被感染的要挾，您應該對服務器做進一步的查看。

查看包括“404-Server!!”的shell文件的源代碼，發(fā)現(xiàn)它們供給了上傳／查看／刪去文件以及調(diào)整權(quán)限的功用。

查看文件的全部者和用戶組，發(fā)現(xiàn)它們都是用PHP進程的全部者創(chuàng)立的，所以它們很可能是由被侵略的PHP運用程序創(chuàng)立的。

另一個被感染的文件名為way.php，它僅僅包括了來自另一個服務器的一個文件，源代碼如下所示：

這段代碼中指向的歹意服務器向咱們展現(xiàn)了一個風趣的音訊：

可能是由于我沒有運用正確的referer頭，或許是服務器不供給歹意負載了。

在一個HTML文件中，發(fā)現(xiàn)如下代碼：

尋覓更多的Shells

管理員供給的可疑的Shell文件是由于它們有比較特別的、古怪的命名，接下來，我開端經(jīng)過運用程序代碼來尋覓更多的可疑文件，尤其是，您可能期望查找在服務器上履行指令的函數(shù)，如：

passthru

exec

shell_exec

eval

system

運用以下指令查找全部包括這些函數(shù)的文件：

egrep -rin "system|passthru|exec|shell_exec|eval" /var/www/vhosts/xyz/ > ~/forensics/results_shell_grep.txt

人們常常會運用 *.php的后綴來查找可疑的PHP文件，但PHP文件其實還有其他的擴展名，如*.php5、*.php4 或 *.phps，假如只查看可能*.php的話，可能會錯失許多。所以，假如條件答應的話，可以查找一下上述全部擴展名的文件。也有一些歹意文件運用恣意擴展名，由更規(guī)矩的PHP文件加載，因而也應該測驗檢測一下這類文件。

留意，現(xiàn)在還沒有檢測那些既沒有混雜也不存在上傳Shells狀況的文件，由于這些沒有不直接履行代碼。別的，您可能還會查找一些不太可疑的函數(shù)，這樣做或許還會得到太多的成果，例如：

fputs

fwrite

fopen (特別是帶著 URLs的)

chmod

socket_*

curl_*

base64_decode

gzinflate

假如你有一個大致的主意，當侵略作業(yè)發(fā)作時，你可能會想到查找一下在那個日期之后被創(chuàng)立或修正的文件，如：

find -mtime -2 /directory

您可以遞歸地辨認出／目錄下在前2天內(nèi)或更早時刻之前修正過的全部文件。依據(jù)服務器文件上文件修正的規(guī)矩，您可以很簡單地經(jīng)過這種方法檢測到其他的Shells文件。

假如你現(xiàn)已斷定了一些歹意文件，也應該依據(jù)一些發(fā)現(xiàn)的特征尋求更多的變種，如在本例中查看字符串“404-server!!”，可能會發(fā)現(xiàn)更多可疑的文件信息。

除了傳統(tǒng)的防病毒軟件之外，還有另一種辦法，即運用OWASP出品的依據(jù)YARA規(guī)矩的WebMalwareScanner掃描儀，要做到這一點，你需求裝置YARA、Python綁定并從Github上下載WebMalwareScanner。在處理這件作業(yè)時，我在另一臺Linux機器上運轉(zhuǎn)了WebMalwareScanner對被感染的PHP運用程序的源代碼進行檢測，花了一些時刻，不過得到了許多成果，正確辨認了一些webshells。

root@DESKTOP-XXX:~# cat webmalwarescan_results.txt |grep"webshell" [2017-08-0109:24:56] Scan result for file /path/to/up.php : webshelliMHaPFtp 2 [...]

別的，有些WordPress插件也是被侵略的方針，需求被檢測，不過我不想在現(xiàn)已被損壞的體系上裝置額定的插件，所以這一次沒有測驗這種方法，下次可能就會這么做了。

依據(jù)我的經(jīng)歷，最好可以結(jié)合不同的技能去尋覓webshells。它們有時很難辨認，乍看之下一些看似合法的文件也可能具有歹意功用。你越了解被侵略的體系，就越簡單檢測到不應該存在的文件。

制止被感染的文件

搜集完全部這些信息后，不要忘掉把歹意文件整理掉。我現(xiàn)已移除了這些可疑文件的全部用戶的讀取和履行權(quán)限，體系運轉(zhuǎn)一段時刻后，沒有顯著的問題，將它們刪去。別把可疑的文件殘留在體系中，以防有人不小心激活了它們。

創(chuàng)立一個時刻線

前邊說到運用mac-robber東西檢索到了創(chuàng)立和修正文件的信息，現(xiàn)在我用mactime創(chuàng)立了一個時刻線：

mactime -b timeline.txt 2017-06-01> timeline_output.txt

得到了一個長長的條目列表，如下所示：

Fri Jun 30201715:43:02308 .a.. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30201715:51:55308 m.c. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30201716:07:4731 m.c. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/newmessage.html

這是一個與服務器上的全部文件有關(guān)的十分有用的列表，包括了文件的owner id、group id，以及文件被修正、拜訪和更改的時刻戳。

留意，在UNIX體系上，一般狀況下可疑取得文件的拜訪時刻、更改時刻和修正時刻（atime，ctime，mtime），以常見的mactime輸出為例：

a  代表一個文件被拜訪的時刻（atime）

c  代表一個文件的內(nèi)容或權(quán)限被更改的時刻（ctime）

m  代表文件內(nèi)容被更改的時刻，而不是全部者或權(quán)限被更改

b  代表文件被創(chuàng)立的時刻，不過你一般不會看到這個

所以，mtime顯現(xiàn)了文件最終被寫入的時刻。但是，咱們不能斷定這是否與文件的創(chuàng)立日期相吻合，惋惜的是這兒無法重建，所以不能必定這就是文件被上傳的時刻，但可以必定的是，上星期五，即7月07，該文件就現(xiàn)已存在于體系上了。在Linux體系上，您可以運用 stat 指令顯現(xiàn)單個文件的詳細信息。

關(guān)于這文件體系和文件的拜訪／創(chuàng)立時刻的問題，請答應我再多說一點。首要，你的文件體系在加載時假如啟用了noatime選項，那么就意味著不會記載對磁盤的拜訪時刻，這樣做可以進步拜訪速度，但明顯并不利于取證剖析。不過，某些文件體系仍然可以找出文件創(chuàng)立時刻，大多數(shù)Linux服務器上的ext4格局的文件體系就支撐這一功用，但沒有簡易的展現(xiàn)東西，mactime并不適用。

Linux下運用debugfs可以查詢文件的創(chuàng)立日期。

查看時刻線，可以核算出第一個歹意shell呈現(xiàn)在體系上的時刻，成果顯現(xiàn)是在作業(yè)被發(fā)現(xiàn)的幾周之前，這不是一個好征兆。

查看日志文件

從日志中查看調(diào)用這些腳本東西的信息，發(fā)現(xiàn)幾個首要來自于亞洲的IP地址，但由于apache日志里沒有記載POST數(shù)據(jù)的嘻嘻，因而無法承認經(jīng)過這些Shells上傳了哪些文件。

尋覓初始進犯向量

為了定位初始的進犯向量，我運用了 apache-scalp東西，盡管它有點舊了，但仍然有用。但仍在作業(yè)。經(jīng)過正則表達式它基本上能Apache日志中匹配出已知的進犯向量。

/opt/apache-scalp/scalp# python scalp.py -l /path/to/logs/access_log.processed.1_plain-f /path/to/default_filter.xml -a lfi,rfi,sqli,dt -p"25/Jun/2017;05/Jul/2017" --output /root/scalp --html

但是，沒有發(fā)現(xiàn)可疑的SQL注入或LFI / RFI縫隙使用的狀況，事發(fā)前一天也沒有可以與可疑文件相關(guān)聯(lián)的可疑作業(yè)發(fā)作。

查看WordPress插件標明，至少有一個SEO插件包括了一個嚴峻的文件上傳縫隙，這個插件是一個月前裝置的。由于運用程序裝置了許多插件，因而我寫了一個小腳正本查看WordPress插件目錄，比對wpvulndb.com已發(fā)布的縫隙（不過該體系好幾年沒更新過了）。

事實證明，存在許多的嚴峻的安全縫隙，假如沒有滿足的日志信息，很難追尋初始向量。

留意，這個腳本不查看主題或WordPress中心的縫隙，它們也可能包括嚴峻的縫隙。

做完上述作業(yè)之后，我決議花滿足的時刻為客戶供給一份開始陳述，并打開進一步的舉動。

4．成果

現(xiàn)在，咱們都知道哪些狀況了呢？