遇到PHP服務(wù)器被黑客入侵了該如何？應(yīng)對(duì)
來(lái)源：原創(chuàng) 時(shí)間：2018-02-02 瀏覽：0 次我最近處理了一個(gè)Linux Web服務(wù)器被侵略的案件，作業(yè)的原因是客戶(hù)發(fā)現(xiàn)Web服務(wù)器上呈現(xiàn)了一個(gè)新的PHP文件，它與運(yùn)轉(zhuǎn)在服務(wù)器上的WordPress運(yùn)用程序和特定的用戶(hù)署理無(wú)關(guān)，全部的流量都被重定向到另一個(gè)站點(diǎn)。
blob.png
本文并不是一個(gè)詳細(xì)的取證攻略，也不是一個(gè)翔實(shí)的安全作業(yè)呼應(yīng)手冊(cè)。寫(xiě)作的意圖是想為您供給一些思路，碰到需求處理這類(lèi)Linux服務(wù)器被黑的Case時(shí)分，你應(yīng)該作何考慮？施行那些行為？需求預(yù)備哪些常用的東西？
1．開(kāi)端
當(dāng)管理員第一次發(fā)現(xiàn)服務(wù)器被侵略后，當(dāng)即整理了全部發(fā)現(xiàn)的歹意文件，修正了重定向的問(wèn)題，以為全部都現(xiàn)已恢復(fù)了，直到不久之后服務(wù)器再次被侵略。管理員又做了修正作業(yè)，這次還更新了體系，在決議將運(yùn)用程序轉(zhuǎn)移到一臺(tái)新服務(wù)器上之前，他們決議請(qǐng)其他人員查看以下，所以，我就上場(chǎng)了。
擺在我眼前的待取證對(duì)象是：
仍在出產(chǎn)環(huán)境中運(yùn)轉(zhuǎn)的體系
至少遭受了兩次侵略
管理員進(jìn)行對(duì)體系進(jìn)行了實(shí)質(zhì)性的修正
這些條件都不算抱負(fù)，乃至可以說(shuō)是不適宜的，提早聲明：我的意圖不是去發(fā)明一個(gè)合法有用的監(jiān)測(cè)鏈，而是要做混合取證，在盡可能的不終端運(yùn)轉(zhuǎn)中的服務(wù)的狀況下，進(jìn)行作業(yè)呼應(yīng)和修正被損壞的東西。我的方針是：
斷定體系是否仍然處于風(fēng)險(xiǎn)狀況（假如是的話(huà)，刪去或阻撓與此相關(guān)的全部?jī)?nèi)容）
檢測(cè)是否存在被修正的文件，以防止將已被感染文件遷移到新的服務(wù)器上
抱負(fù)狀況下，找出初始的侵略向量，并保證它已被阻撓。
在取得域名、IP和SSH憑據(jù)之后，我就開(kāi)端作業(yè)了。
2．搜集依據(jù)
在銜接到服務(wù)器之前，我記載了自己的IP，保證今后可以在日志中辨認(rèn)出它。
然后我經(jīng)過(guò)SFTP指令銜接到了服務(wù)器上。由于服務(wù)器的磁盤(pán)現(xiàn)已被加載并且正在運(yùn)轉(zhuǎn)，因而我無(wú)法取得鏡像，所以我下載了全部感興趣的、能得到的日志文件。我仿制了整個(gè)/var/log目錄和存儲(chǔ)Apache日志文件的特定目錄，仿制了受損的PHP運(yùn)用程序，以及在作業(yè)發(fā)作后不久所采納的一些備份。不幸的是，第一次被侵略和管理員做出更改之間沒(méi)有進(jìn)行體系備份，因而一些要害文件可能現(xiàn)已被修正了。
敞開(kāi)了Kali，針對(duì)服務(wù)器發(fā)動(dòng)Nmap端口掃描和wpscan掃描。由于服務(wù)器運(yùn)轉(zhuǎn)了一個(gè)老舊的WordPress實(shí)例，并且這個(gè)實(shí)例曾履行過(guò)歹意的重定向，所以WordPress很可能是侵略的初始點(diǎn)。但是，由于WordPress在被侵略后現(xiàn)已更新過(guò)了，wpscan沒(méi)有在當(dāng)時(shí)的版別中找到任何縫隙。Nmap端口掃描的成果是敞開(kāi)了FTP，SSH，HTTP和HTTPS端口，這關(guān)于一個(gè)Web服務(wù)器來(lái)說(shuō)有點(diǎn)剩余，進(jìn)犯者也可能從其間一項(xiàng)服務(wù)進(jìn)行打破。但是，管理員的陳述里說(shuō)全部的shell都是在wp-content目錄下被發(fā)現(xiàn)的，這在某種程度上暗示了進(jìn)犯者可能侵略了WordPress運(yùn)用程序。
我還運(yùn)用VirusTotal查看了該站點(diǎn)是否有傳達(dá)歹意軟件的記載，但好像全部都很好。
我決議經(jīng)過(guò)控制臺(tái)登錄體系。由于不斷定服務(wù)器上的二進(jìn)制文件是否被感染了，所以為了削減影響，我運(yùn)用了自己的靜態(tài)鏈接二進(jìn)制文件。從BusyBox下載了coreutil二進(jìn)制文件并上傳到服務(wù)器上，一起還上傳了chkrootkit東西和SLEUTH東西包中的一個(gè)名為mac-robber的東西。
用靜態(tài)二進(jìn)制文件查看體系，得到運(yùn)轉(zhuǎn)中的進(jìn)程和cronjobs等的列表信息，你可以運(yùn)用
netstat-tulpen
指令得到一個(gè)監(jiān)聽(tīng)（TCP和UDP）進(jìn)程的列表（我沒(méi)有掩蓋全部掃描到的端口，所以得到的輸出可能是風(fēng)趣的）?？梢赃\(yùn)用
netstat-taupn
指令顯現(xiàn)從服務(wù)器中輸出的活動(dòng)的銜接（TCP和UDP）。但是，這兩個(gè)清單都沒(méi)有發(fā)現(xiàn)可疑的活動(dòng)。
Rootkit檢測(cè)東西chkrootkit也什么都沒(méi)發(fā)現(xiàn)，運(yùn)用rkhunter和ClamAV也沒(méi)有什么收成（這不意味著什么，不幸的是，ClamAV錯(cuò)失了PHP shells和Windows木馬）。
我開(kāi)端手藝尋覓一些不同尋常的事物，但現(xiàn)在為止全部好像都很潔凈：沒(méi)有不尋常的敞開(kāi)端口、沒(méi)有不尋常的進(jìn)程在運(yùn)轉(zhuǎn)。我用一個(gè)管理員賬戶(hù)驗(yàn)證了FTP和ssh帳戶(hù)，它們看起來(lái)不錯(cuò)。在這個(gè)層面上好像沒(méi)有侵略的痕跡。
mac-robber東西協(xié)助我搜集了服務(wù)器上創(chuàng)立和修正的文件的信息（稍后可被用于創(chuàng)立作業(yè)的時(shí)刻線(xiàn)）：
./mac-robber / >/root/forensics/timeline.txt
現(xiàn)在，我發(fā)現(xiàn)了：
服務(wù)器上被創(chuàng)立的文件及時(shí)刻的信息
各種日志文件，其間包括Apache日志
被侵略的網(wǎng)站一些元代吧，包括一些（被修正過(guò)的）shell文件
第一次和第2次被侵略之間的備份
總的來(lái)說(shuō)，還算有所收成。當(dāng)然，您可能以為這些日志數(shù)據(jù)不能被信賴(lài)，由于它們可能被進(jìn)犯者修正過(guò)了。但我卻沒(méi)有理由等待進(jìn)犯會(huì)這么雜亂。
3. 深度查看
管理員現(xiàn)已斷定了一些被進(jìn)犯者上傳的webshells文件。我開(kāi)端查看這些文件，發(fā)現(xiàn)大部分文件的姓名都比較蔭蔽，如Xjrop.php，Nwfqx.php或Rwchn7.php（首字母都是大寫(xiě)的），這些文件是完全相同的，渙散在正常的運(yùn)用程序文件之間。但是有一個(gè)名為up.php的文件，與上述幾個(gè)文件的源代碼不同，功用也稍有不同?？梢赃\(yùn)用diff指令比較兩個(gè)文件：
diff Xjrop.php Nwfqx.php
或許比較它們的MD5值：
md5sum Xjrop.php
md5sum Nwfqx.php
還有2個(gè)文件的姓名比較古怪，bjrnpf.php和jemkwl.php，全部是小寫(xiě)這兩個(gè)文件是相同的，但有別于其他文件。一個(gè)可疑的可履行文件被命名為windoze.exe，我置疑一些歹意軟件可能現(xiàn)已從該主機(jī)傳達(dá)出去了。運(yùn)用md5sum核算這個(gè)文件的哈希值，在VirusTotal進(jìn)行查看，（留意上傳到VirusTotal的文件可以被其他研究人員看到，是公共的，所以最好不要上傳可能含有保密或靈敏信息的東西，可以首要運(yùn)用哈希值進(jìn)行剖析）。VirusTotal的剖析成果斷定該文件為木馬程序。因而我將它保存下來(lái)以備后續(xù)的剖析。
剖析這些PHP shell樣本，發(fā)現(xiàn)某些文件中包括如下信息：
留意它們的標(biāo)題“404-server!!”。用查找引擎查找胰腺癌，發(fā)現(xiàn)了其他一些可能受感染的服務(wù)器信息：
還有一些可疑文件中，包括了一些看似無(wú)用的代碼：
這一行代碼的意義是正則匹配“saft”字符串中的小寫(xiě)字母“pageerror”，將其替換成$_POST 變量“mkf3wapa”。由于返回值被疏忽，所以我不知道這個(gè)代碼片段詳細(xì)的效果是什么。
但是，運(yùn)用Google查找，發(fā)現(xiàn)一大堆的查詢(xún)成果，標(biāo)明這段代碼與黑客上傳的“404-Server!!”shell腳本有聯(lián)絡(luò)，它們一起呈現(xiàn)在被侵略的服務(wù)器上。因而，假如您在服務(wù)器上找到此代碼，它可能存在被感染的要挾，您應(yīng)該對(duì)服務(wù)器做進(jìn)一步的查看。
查看包括“404-Server!!”的shell文件的源代碼，發(fā)現(xiàn)它們供給了上傳／查看／刪去文件以及調(diào)整權(quán)限的功用。
查看文件的全部者和用戶(hù)組，發(fā)現(xiàn)它們都是用PHP進(jìn)程的全部者創(chuàng)立的，所以它們很可能是由被侵略的PHP運(yùn)用程序創(chuàng)立的。
另一個(gè)被感染的文件名為way.php，它僅僅包括了來(lái)自另一個(gè)服務(wù)器的一個(gè)文件，源代碼如下所示：
這段代碼中指向的歹意服務(wù)器向咱們展現(xiàn)了一個(gè)風(fēng)趣的音訊：
可能是由于我沒(méi)有運(yùn)用正確的referer頭，或許是服務(wù)器不供給歹意負(fù)載了。
在一個(gè)HTML文件中，發(fā)現(xiàn)如下代碼：
尋覓更多的Shells
管理員供給的可疑的Shell文件是由于它們有比較特別的、古怪的命名，接下來(lái)，我開(kāi)端經(jīng)過(guò)運(yùn)用程序代碼來(lái)尋覓更多的可疑文件，尤其是，您可能期望查找在服務(wù)器上履行指令的函數(shù)，如：
passthru
exec
shell_exec
eval
system
運(yùn)用以下指令查找全部包括這些函數(shù)的文件：
egrep -rin "system|passthru|exec|shell_exec|eval" /var/www/vhosts/xyz/ > ~/forensics/results_shell_grep.txt
人們常常會(huì)運(yùn)用 *.php的后綴來(lái)查找可疑的PHP文件，但PHP文件其實(shí)還有其他的擴(kuò)展名，如*.php5、*.php4 或 *.phps，假如只查看可能*.php的話(huà)，可能會(huì)錯(cuò)失許多。所以，假如條件答應(yīng)的話(huà)，可以查找一下上述全部擴(kuò)展名的文件。也有一些歹意文件運(yùn)用恣意擴(kuò)展名，由更規(guī)矩的PHP文件加載，因而也應(yīng)該測(cè)驗(yàn)檢測(cè)一下這類(lèi)文件。
留意，現(xiàn)在還沒(méi)有檢測(cè)那些既沒(méi)有混雜也不存在上傳Shells狀況的文件，由于這些沒(méi)有不直接履行代碼。別的，您可能還會(huì)查找一些不太可疑的函數(shù)，這樣做或許還會(huì)得到太多的成果，例如：
fputs
fwrite
fopen (特別是帶著 URLs的)
chmod
socket_*
curl_*
base64_decode
gzinflate
假如你有一個(gè)大致的主意，當(dāng)侵略作業(yè)發(fā)作時(shí)，你可能會(huì)想到查找一下在那個(gè)日期之后被創(chuàng)立或修正的文件，如：
find -mtime -2 /directory
您可以遞歸地辨認(rèn)出／目錄下在前2天內(nèi)或更早時(shí)刻之前修正過(guò)的全部文件。依據(jù)服務(wù)器文件上文件修正的規(guī)矩，您可以很簡(jiǎn)單地經(jīng)過(guò)這種方法檢測(cè)到其他的Shells文件。
假如你現(xiàn)已斷定了一些歹意文件，也應(yīng)該依據(jù)一些發(fā)現(xiàn)的特征尋求更多的變種，如在本例中查看字符串“404-server!!”，可能會(huì)發(fā)現(xiàn)更多可疑的文件信息。
除了傳統(tǒng)的防病毒軟件之外，還有另一種辦法，即運(yùn)用OWASP出品的依據(jù)YARA規(guī)矩的WebMalwareScanner掃描儀，要做到這一點(diǎn)，你需求裝置YARA、Python綁定并從Github上下載WebMalwareScanner。在處理這件作業(yè)時(shí)，我在另一臺(tái)Linux機(jī)器上運(yùn)轉(zhuǎn)了WebMalwareScanner對(duì)被感染的PHP運(yùn)用程序的源代碼進(jìn)行檢測(cè)，花了一些時(shí)刻，不過(guò)得到了許多成果，正確辨認(rèn)了一些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插件也是被侵略的方針，需求被檢測(cè)，不過(guò)我不想在現(xiàn)已被損壞的體系上裝置額定的插件，所以這一次沒(méi)有測(cè)驗(yàn)這種方法，下次可能就會(huì)這么做了。
依據(jù)我的經(jīng)歷，最好可以結(jié)合不同的技能去尋覓webshells。它們有時(shí)很難辨認(rèn)，乍看之下一些看似合法的文件也可能具有歹意功用。你越了解被侵略的體系，就越簡(jiǎn)單檢測(cè)到不應(yīng)該存在的文件。
制止被感染的文件
搜集完全部這些信息后，不要忘掉把歹意文件整理掉。我現(xiàn)已移除了這些可疑文件的全部用戶(hù)的讀取和履行權(quán)限，體系運(yùn)轉(zhuǎn)一段時(shí)刻后，沒(méi)有顯著的問(wèn)題，將它們刪去。別把可疑的文件殘留在體系中，以防有人不小心激活了它們。
創(chuàng)立一個(gè)時(shí)刻線(xiàn)
前邊說(shuō)到運(yùn)用mac-robber東西檢索到了創(chuàng)立和修正文件的信息，現(xiàn)在我用mactime創(chuàng)立了一個(gè)時(shí)刻線(xiàn)：
mactime -b timeline.txt 2017-06-01> timeline_output.txt
得到了一個(gè)長(zhǎng)長(zhǎng)的條目列表，如下所示：
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
這是一個(gè)與服務(wù)器上的全部文件有關(guān)的十分有用的列表，包括了文件的owner id、group id，以及文件被修正、拜訪(fǎng)和更改的時(shí)刻戳。
留意，在UNIX體系上，一般狀況下可疑取得文件的拜訪(fǎng)時(shí)刻、更改時(shí)刻和修正時(shí)刻（atime，ctime，mtime），以常見(jiàn)的mactime輸出為例：
a 代表一個(gè)文件被拜訪(fǎng)的時(shí)刻（atime）
c 代表一個(gè)文件的內(nèi)容或權(quán)限被更改的時(shí)刻（ctime）
m 代表文件內(nèi)容被更改的時(shí)刻，而不是全部者或權(quán)限被更改
b 代表文件被創(chuàng)立的時(shí)刻，不過(guò)你一般不會(huì)看到這個(gè)
所以，mtime顯現(xiàn)了文件最終被寫(xiě)入的時(shí)刻。但是，咱們不能斷定這是否與文件的創(chuàng)立日期相吻合，惋惜的是這兒無(wú)法重建，所以不能必定這就是文件被上傳的時(shí)刻，但可以必定的是，上星期五，即7月07，該文件就現(xiàn)已存在于體系上了。在Linux體系上，您可以運(yùn)用 stat 指令顯現(xiàn)單個(gè)文件的詳細(xì)信息。
關(guān)于這文件體系和文件的拜訪(fǎng)／創(chuàng)立時(shí)刻的問(wèn)題，請(qǐng)答應(yīng)我再多說(shuō)一點(diǎn)。首要，你的文件體系在加載時(shí)假如啟用了noatime選項(xiàng)，那么就意味著不會(huì)記載對(duì)磁盤(pán)的拜訪(fǎng)時(shí)刻，這樣做可以進(jìn)步拜訪(fǎng)速度，但明顯并不利于取證剖析。不過(guò)，某些文件體系仍然可以找出文件創(chuàng)立時(shí)刻，大多數(shù)Linux服務(wù)器上的ext4格局的文件體系就支撐這一功用，但沒(méi)有簡(jiǎn)易的展現(xiàn)東西，mactime并不適用。
Linux下運(yùn)用debugfs可以查詢(xún)文件的創(chuàng)立日期。
查看時(shí)刻線(xiàn)，可以核算出第一個(gè)歹意shell呈現(xiàn)在體系上的時(shí)刻，成果顯現(xiàn)是在作業(yè)被發(fā)現(xiàn)的幾周之前，這不是一個(gè)好征兆。
查看日志文件
從日志中查看調(diào)用這些腳本東西的信息，發(fā)現(xiàn)幾個(gè)首要來(lái)自于亞洲的IP地址，但由于apache日志里沒(méi)有記載POST數(shù)據(jù)的嘻嘻，因而無(wú)法承認(rèn)經(jīng)過(guò)這些Shells上傳了哪些文件。
尋覓初始進(jìn)犯向量
為了定位初始的進(jìn)犯向量，我運(yùn)用了 apache-scalp東西，盡管它有點(diǎn)舊了，但仍然有用。但仍在作業(yè)。經(jīng)過(guò)正則表達(dá)式它基本上能Apache日志中匹配出已知的進(jìn)犯向量。
/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
但是，沒(méi)有發(fā)現(xiàn)可疑的SQL注入或LFI / RFI縫隙使用的狀況，事發(fā)前一天也沒(méi)有可以與可疑文件相關(guān)聯(lián)的可疑作業(yè)發(fā)作。
查看WordPress插件標(biāo)明，至少有一個(gè)SEO插件包括了一個(gè)嚴(yán)峻的文件上傳縫隙，這個(gè)插件是一個(gè)月前裝置的。由于運(yùn)用程序裝置了許多插件，因而我寫(xiě)了一個(gè)小腳正本查看WordPress插件目錄，比對(duì)wpvulndb.com已發(fā)布的縫隙（不過(guò)該體系好幾年沒(méi)更新過(guò)了）。
事實(shí)證明，存在許多的嚴(yán)峻的安全縫隙，假如沒(méi)有滿(mǎn)足的日志信息，很難追尋初始向量。
留意，這個(gè)腳本不查看主題或WordPress中心的縫隙，它們也可能包括嚴(yán)峻的縫隙。
做完上述作業(yè)之后，我決議花滿(mǎn)足的時(shí)刻為客戶(hù)供給一份開(kāi)始陳述，并打開(kāi)進(jìn)一步的舉動(dòng)。
4．成果
現(xiàn)在，咱們都知道哪些狀況了呢？
