行业报告 AI展会 数据标注 标注供求
数据标注数据集
主页 > 数据挖掘 正文

安全运维看过来!某 Nginx 后门分析与重现

背景
前几天,接到一个 nginx 后门样本,本着就分析和复现的思路,完整的将整个过程做一次复现,不料最终还获取到了后门的核心代码部分,遂将其整理发布,仅供学习研究之用。
 
在后续分析之前先来了解下 nginx 后门的功能。通过在 Cookie 中包含特征字符串lkfakjfa,并填写需要反弹的ip和端口,完成shell反弹,这就是后门的一个大致情况。
 
样本分析
1.在已有的分析情报的帮助下,得知nginx后门位于ngx_http_header_filter,IDA装载样本,发现样本带有符号信息,如下所示:

 

2.找到ngx_http_header_filter函数,找到了关键字符串lkfakjf,如下所示:

 

3.F5之后,发现之后调用了一个connect_shell的函数,如下所示:

 

4.通过对connect_shell进行分析发现,是一个反弹shell的功能,利用socket编程完成shell反弹,如下所示:

 

后门复现
1.首先启动后门 nginx 文件,由于nginx会绑定80端口,如果多次启动会提示80端口被占用而无法启动,如下所示:

 

2.接着进行本地监听9999,如下所示:

 

3.使用curl来触发漏洞,如下所示:

 

4.此时nc里已经得到了shell,如下所示:

 

 

原理分析
1.通过gdb调试和IDA分析发现,要判断cookies中是否存在特征字符串lkfakjf,用到了一个这样的结构体ngx_http_request_t,使用source insight打开nginx源码,定位到ngx_http_header_filter,发现参数就是ngx_http_request_t,查看该结构体的情况,如下所示:

 

 
2.该结构体相对比较大,这里截图只留下要使用的部分header_in,如下所示:

 

 
3.通过header_in的结构继续寻找,找到cookies的定义,如下所示:

 

4.最后找到关于cookies的结构体情况,如下所示:

 

5.结合IDA中代码分析,v4就是cookies结构体,通过结构体偏移+32字节定位到输入的特征字符串,在这里我也没有分析的特别清楚,初步判断应该是ngx_pool_t结构体,如下所示:

 

 
重现后门
1.首先,我们要先获取cookies的结构,通过r->headers_in.cookies.elts即可获得,然后取到void *elts的内容,最后通过32字节偏移得到存储输入特征码的地址,取其值即可拿到输入的特征字符串的值,最后的代码形式,如下所示:

 

 
对这代码做个解释,首先v1和v2是long *的指针。
第一句代码(long *)r->headers_in.cookies.elts;将void *的elts指针转化为long *的指针。
第二句代码v2=(long *)*v1;*v1是取其值,在将其值转化为long*的指针。
第三句代码cookie =(char )(v2+4);v2+4是表示在v2的基础上,偏移4个long *个字节,如果你的v2定义为char *这里就是v2+32;*(v2+4)取该偏移的内容,最后转化为char *的指针。
 
以上代码只适用于64位,以上代码只适用于64位linux,以上代码只适用于64位linux,重要的事情说三遍。
 
2.使用nginx的configure配置,只需要配置—prefix=/root/nginx即可,当configure运行完成后会生成Makefile文件。配置过程中,可能缺少很多的依赖,逐个安装即可,如下所示:

 

3.然后修改位于objs里的Makefile文件,修改为如下配置,否则编译会报错,如下所示:

 

4.此时使用make编译,等待编译完成,如下所示:

 

5.make install安装一下,安装的位置为之前配置的prefix路径,如下所示:

 

6.运行和调试nginx文件,能够成功获取输入的特征字符串,如下所示:

 

7.其中rsi为触发漏洞的输入,rdi为内置特征字符串,这里选择了printf打印,能够成功获取到输入的特征字符串,如下所示:

 

 
8.接下来准备复现反弹shell,添加功能代码,代码只能适用于带有nc命令的系统,编译后进行复现操作,如下所示:

 

9.现在的特征字符串被修改为123456,现在来触发该后门,如下所示:

 

10.成功接收到反弹的 shell,如下所示:

 

自此后门重现成功,整个分析和复现过程到此结束。
 
后门排查
目前后门排查只能针对特定的版本,如果出现新 nginx 后门,排查手段大概率会失效。
1.本地验证 通过 grep 命令判断当前运行对 nginx 里面是否存在“/bin/sh”可疑字符串
$ which nginx |xargs grep "/bin/sh" –la
 
2. 将nginx文件提取出来,使用IDA分析查找ngx_http_header_filter,下载nginx源码和IDA F5做对比判断是否存在后门。
较好的效果是下载nginx对应的源码对比是否有增加或改动的地方,但是这份方法比较耗时耗力,但是效果比较好。
 
 
 
声明:文章收集于网络,版权归原作者所有,为传播信息而发,如有侵权,请联系小编删除,谢谢!
 
 

微信公众号

声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。

网友评论:

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
SEM推广服务

Copyright©2005-2028 Sykv.com 可思数据 版权所有    京ICP备14056871号

关于我们   免责声明   广告合作   版权声明   联系我们   原创投稿   网站地图  

可思数据 数据标注

扫码入群
扫码关注

微信公众号

返回顶部