您的位置:首页 >  新闻中心 > 开发者专区
  开发者专区
 

遇到PHP服务器被黑客入侵了该如何?应对

来源:原创    时间:2018-02-02    浏览:0 次

我最近处理了一个Linux Web服务器被侵略的案件,作业的原因是客户发现Web服务器上呈现了一个新的PHP文件,它与运转在服务器上的WordPress运用程序和特定的用户署理无关,全部的流量都被重定向到另一个站点。

 blob.png

本文并不是一个详细的取证攻略,也不是一个翔实的安全作业呼应手册。写作的意图是想为您供给一些思路,碰到需求处理这类Linux服务器被黑的Case时分,你应该作何考虑?施行那些行为?需求预备哪些常用的东西?

 blob.png

1.开端

 

当管理员第一次发现服务器被侵略后,当即整理了全部发现的歹意文件,修正了重定向的问题,以为全部都现已恢复了,直到不久之后服务器再次被侵略。管理员又做了修正作业,这次还更新了体系,在决议将运用程序转移到一台新服务器上之前,他们决议请其他人员查看以下,所以,我就上场了。

 

摆在我眼前的待取证对象是:

 

仍在出产环境中运转的体系

至少遭受了两次侵略

管理员进行对体系进行了实质性的修正

 

这些条件都不算抱负,乃至可以说是不适宜的,提早声明:我的意图不是去发明一个合法有用的监测链,而是要做混合取证,在尽可能的不终端运转中的服务的状况下,进行作业呼应和修正被损坏的东西。我的方针是:

 

断定体系是否仍然处于风险状况(假如是的话,删去或阻挠与此相关的全部内容)

检测是否存在被修正的文件,以防止将已被感染文件迁移到新的服务器上

抱负状况下,找出初始的侵略向量,并保证它已被阻挠。

 

在取得域名、IP和SSH凭据之后,我就开端作业了。

 

2.搜集依据

 

在衔接到服务器之前,我记载了自己的IP,保证今后可以在日志中辨认出它。

 

然后我经过SFTP指令衔接到了服务器上。由于服务器的磁盘现已被加载并且正在运转,因而我无法取得镜像,所以我下载了全部感兴趣的、能得到的日志文件。我仿制了整个/var/log目录和存储Apache日志文件的特定目录,仿制了受损的PHP运用程序,以及在作业发作后不久所采纳的一些备份。不幸的是,第一次被侵略和管理员做出更改之间没有进行体系备份,因而一些要害文件可能现已被修正了。

 

敞开了Kali,针对服务器发动Nmap端口扫描和wpscan扫描。由于服务器运转了一个老旧的WordPress实例,并且这个实例曾履行过歹意的重定向,所以WordPress很可能是侵略的初始点。但是,由于WordPress在被侵略后现已更新过了,wpscan没有在当时的版别中找到任何缝隙。Nmap端口扫描的成果是敞开了FTP,SSH,HTTP和HTTPS端口,这关于一个Web服务器来说有点剩余,进犯者也可能从其间一项服务进行打破。但是,管理员的陈述里说全部的shell都是在wp-content目录下被发现的,这在某种程度上暗示了进犯者可能侵略了WordPress运用程序。

 blob.png

我还运用VirusTotal查看了该站点是否有传达歹意软件的记载,但好像全部都很好。

 

我决议经过控制台登录体系。由于不断定服务器上的二进制文件是否被感染了,所以为了削减影响,我运用了自己的静态链接二进制文件。从BusyBox下载了coreutil二进制文件并上传到服务器上,一起还上传了chkrootkit东西和SLEUTH东西包中的一个名为mac-robber的东西。

 

用静态二进制文件查看体系,得到运转中的进程和cronjobs等的列表信息,你可以运用

 

netstat-tulpen

 

指令得到一个监听(TCP和UDP)进程的列表(我没有掩盖全部扫描到的端口,所以得到的输出可能是风趣的)。可以运用

 

netstat-taupn

 

指令显现从服务器中输出的活动的衔接(TCP和UDP)。但是,这两个清单都没有发现可疑的活动。

 

Rootkit检测东西chkrootkit也什么都没发现,运用rkhunter和ClamAV也没有什么收成(这不意味着什么,不幸的是,ClamAV错失了PHP shells和Windows木马)。

 

我开端手艺寻觅一些不同寻常的事物,但现在为止全部好像都很洁净:没有不寻常的敞开端口、没有不寻常的进程在运转。我用一个管理员账户验证了FTP和ssh帐户,它们看起来不错。在这个层面上好像没有侵略的痕迹。

 

mac-robber东西协助我搜集了服务器上创立和修正的文件的信息(稍后可被用于创立作业的时刻线):

 

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

 

现在,我发现了:

 

服务器上被创立的文件及时刻的信息

各种日志文件,其间包括Apache日志

被侵略的网站一些元代吧,包括一些(被修正过的)shell文件

第一次和第2次被侵略之间的备份

 

总的来说,还算有所收成。当然,您可能以为这些日志数据不能被信赖,由于它们可能被进犯者修正过了。但我却没有理由等待进犯会这么杂乱。

 

3. 深度查看

 

管理员现已断定了一些被进犯者上传的webshells文件。我开端查看这些文件,发现大部分文件的姓名都比较荫蔽,如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,我置疑一些歹意软件可能现已从该主机传达出去了。运用md5sum核算这个文件的哈希值,在VirusTotal进行查看,(留意上传到VirusTotal的文件可以被其他研究人员看到,是公共的,所以最好不要上传可能含有保密或灵敏信息的东西,可以首要运用哈希值进行剖析)。VirusTotal的剖析成果断定该文件为木马程序。因而我将它保存下来以备后续的剖析。

 

剖析这些PHP shell样本,发现某些文件中包括如下信息:

 


 

留意它们的标题“404-server!!”。用查找引擎查找胰腺癌,发现了其他一些可能受感染的服务器信息:

 


 

 还有一些可疑文件中,包括了一些看似无用的代码:

 


 

这一行代码的意义是正则匹配“saft”字符串中的小写字母“pageerror”,将其替换成$_POST 变量“mkf3wapa”。由于返回值被疏忽,所以我不知道这个代码片段详细的效果是什么。

 

但是,运用Google查找,发现一大堆的查询成果,标明这段代码与黑客上传的“404-Server!!”shell脚本有联络,它们一起呈现在被侵略的服务器上。因而,假如您在服务器上找到此代码,它可能存在被感染的要挟,您应该对服务器做进一步的查看。

 



 

查看包括“404-Server!!”的shell文件的源代码,发现它们供给了上传/查看/删去文件以及调整权限的功用。

 

查看文件的全部者和用户组,发现它们都是用PHP进程的全部者创立的,所以它们很可能是由被侵略的PHP运用程序创立的。

 

另一个被感染的文件名为way.php,它仅仅包括了来自另一个服务器的一个文件,源代码如下所示:

 


这段代码中指向的歹意服务器向咱们展现了一个风趣的音讯:

 


可能是由于我没有运用正确的referer头,或许是服务器不供给歹意负载了。

 

在一个HTML文件中,发现如下代码:

 


 

寻觅更多的Shells

 

管理员供给的可疑的Shell文件是由于它们有比较特别的、古怪的命名,接下来,我开端经过运用程序代码来寻觅更多的可疑文件,尤其是,您可能期望查找在服务器上履行指令的函数,如:

 

passthru

exec

shell_exec

eval

system

 

运用以下指令查找全部包括这些函数的文件:

 

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

 

人们常常会运用 *.php的后缀来查找可疑的PHP文件,但PHP文件其实还有其他的扩展名,如*.php5、*.php4 或 *.phps,假如只查看可能*.php的话,可能会错失许多。所以,假如条件答应的话,可以查找一下上述全部扩展名的文件。也有一些歹意文件运用恣意扩展名,由更规矩的PHP文件加载,因而也应该测验检测一下这类文件。

 

留意,现在还没有检测那些既没有混杂也不存在上传Shells状况的文件,由于这些没有不直接履行代码。别的,您可能还会查找一些不太可疑的函数,这样做或许还会得到太多的成果,例如:

 

fputs

fwrite

fopen (特别是带着 URLs的)

chmod

socket_*

curl_*

base64_decode

gzinflate

 

假如你有一个大致的主意,当侵略作业发作时,你可能会想到查找一下在那个日期之后被创立或修正的文件,如:

 

find -mtime -2 /directory

 

您可以递归地辨认出/目录下在前2天内或更早时刻之前修正过的全部文件。依据服务器文件上文件修正的规矩,您可以很简单地经过这种方法检测到其他的Shells文件。

 

假如你现已断定了一些歹意文件,也应该依据一些发现的特征寻求更多的变种,如在本例中查看字符串“404-server!!”,可能会发现更多可疑的文件信息。

 

除了传统的防病毒软件之外,还有另一种办法,即运用OWASP出品的依据YARA规矩的WebMalwareScanner扫描仪,要做到这一点,你需求装置YARA、Python绑定并从Github上下载WebMalwareScanner。在处理这件作业时,我在另一台Linux机器上运转了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插件也是被侵略的方针,需求被检测,不过我不想在现已被损坏的体系上装置额定的插件,所以这一次没有测验这种方法,下次可能就会这么做了。

 

依据我的经历,最好可以结合不同的技能去寻觅webshells。它们有时很难辨认,乍看之下一些看似合法的文件也可能具有歹意功用。你越了解被侵略的体系,就越简单检测到不应该存在的文件。

 

制止被感染的文件

 

搜集完全部这些信息后,不要忘掉把歹意文件整理掉。我现已移除了这些可疑文件的全部用户的读取和履行权限,体系运转一段时刻后,没有显着的问题,将它们删去。别把可疑的文件残留在体系中,以防有人不小心激活了它们。

 

创立一个时刻线

 

前边说到运用mac-robber东西检索到了创立和修正文件的信息,现在我用mactime创立了一个时刻线:

 

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

 

 

这是一个与服务器上的全部文件有关的十分有用的列表,包括了文件的owner id、group id,以及文件被修正、拜访和更改的时刻戳。

 

留意,在UNIX体系上,一般状况下可疑取得文件的拜访时刻、更改时刻和修正时刻(atime,ctime,mtime),以常见的mactime输出为例:

 

a  代表一个文件被拜访的时刻(atime)

c  代表一个文件的内容或权限被更改的时刻(ctime)

m  代表文件内容被更改的时刻,而不是全部者或权限被更改

b  代表文件被创立的时刻,不过你一般不会看到这个

 

所以,mtime显现了文件最终被写入的时刻。但是,咱们不能断定这是否与文件的创立日期相吻合,惋惜的是这儿无法重建,所以不能必定这就是文件被上传的时刻,但可以必定的是,上星期五,即7月07,该文件就现已存在于体系上了。在Linux体系上,您可以运用 stat 指令显现单个文件的详细信息。

 

关于这文件体系和文件的拜访/创立时刻的问题,请答应我再多说一点。首要,你的文件体系在加载时假如启用了noatime选项,那么就意味着不会记载对磁盘的拜访时刻,这样做可以进步拜访速度,但明显并不利于取证剖析。不过,某些文件体系仍然可以找出文件创立时刻,大多数Linux服务器上的ext4格局的文件体系就支撑这一功用,但没有简易的展现东西,mactime并不适用。

 

Linux下运用debugfs可以查询文件的创立日期。

 

查看时刻线,可以核算出第一个歹意shell呈现在体系上的时刻,成果显现是在作业被发现的几周之前,这不是一个好征兆。

 

查看日志文件

 

从日志中查看调用这些脚本东西的信息,发现几个首要来自于亚洲的IP地址,但由于apache日志里没有记载POST数据的嘻嘻,因而无法承认经过这些Shells上传了哪些文件。

 

寻觅初始进犯向量

 

为了定位初始的进犯向量,我运用了 apache-scalp东西,尽管它有点旧了,但仍然有用。但仍在作业。经过正则表达式它基本上能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

 

但是,没有发现可疑的SQL注入或LFI / RFI缝隙使用的状况,事发前一天也没有可以与可疑文件相关联的可疑作业发作。

 

查看WordPress插件标明,至少有一个SEO插件包括了一个严峻的文件上传缝隙,这个插件是一个月前装置的。由于运用程序装置了许多插件,因而我写了一个小脚正本查看WordPress插件目录,比对wpvulndb.com已发布的缝隙(不过该体系好几年没更新过了)。

 

事实证明,存在许多的严峻的安全缝隙,假如没有满足的日志信息,很难追寻初始向量。

 


 

留意,这个脚本不查看主题或WordPress中心的缝隙,它们也可能包括严峻的缝隙。

 

做完上述作业之后,我决议花满足的时刻为客户供给一份开始陈述,并打开进一步的举动。

 

4.成果

 

现在,咱们都知道哪些状况了呢?