记某次攻防演练通道搭建

    渗透测试 lz520520 4年前 (2021-01-14) 1830次浏览

    0x00 前言

    在一次攻防演练中,通过某RCE漏洞获取到目标系统权限,目标为linux系统 root权限,拿到系统后,就是权限维持、通道搭建,进到内网渗透环节。

    ​ 在顺利通过wget下载自制linux版CDN的cs马后,并成功上线,一切都是那么顺利,却出现了突发情况,由于linux的cs马暂时还未做socks代理功能,所以又下载了一个frp工具,但奇怪的是frp却始终无法连接到vps,本以为是vps的IP 端口不通,但通过wget测试却是正常连接vps的端口。疑惑之余,测试msf、nc反弹、其他代理工具,发现均无法正常外联,这就很奇怪了,明明wget、cs都能正常出网,难道仅允许http出网,但即使如此,你的TCP连接应该也能出网的,毕竟http基于TCP,不可能拦截TCP的三次握手的,但却无法成功。​

    在苦苦无果的时候,查看了一下网络连接,发现连接里居然没有连接 CDN IP的,而马均连向一个内网IP端口,均不是我设置的,看到这其实就明白了,该内网服务器是通过http代理出网的,这就有了后面的分析了。

    记某次攻防演练通道搭建

    0x01 代理分析

    首先确实下代理设置,确实是做了全局代理,难怪cs马自动走了代理。

    记某次攻防演练通道搭建

    记某次攻防演练通道搭建

    那么隧道怎么搭建呢,本来考虑是用http隧道包裹frp出网,但查了frp的手册,frp支持http代理出网呀。

    记某次攻防演练通道搭建

    经过本地环境测试,如下配置即可成功经过http代理连接vps。

    记某次攻防演练通道搭建

    但在目标系统上测试却还是不行。

    简单翻了下frp的源码,发现frp默认会获取系统环境变量http_proxy来自动走代理,所以应该不是设置不设置这个参数的原因导致。

    记某次攻防演练通道搭建

     

    之前也注意到frp执行提示的报错了,提示DialTcpByHttpProxy错误,因为返回的状态码403。也说明frp确实走了代理。

    记某次攻防演练通道搭建

    根据报错提示找到判断位置,在第三方代码库中,判断非200则返回错误。

    %GOPATH%\pkg\mod\github.com\fatedier\golib@v0.1.1-0.20200901083111-1f870741e185\net\proxy.go

    记某次攻防演练通道搭建

    但执行后vps未接收到任何连接,说明是和http代理服务器通信有问题,导致代理服务器直接返回403,而不是vps返回的403。

    0x02 数据包分析

    接下来怎么分析呢,我在目标系统上使用tcpdump抓包对比分析了下。

    tcpdump -i any host 10.1.1.84 -s0 -w /tmp/1.pcap

    WGET: 请求到vps成功的包,可以看到代理服务器正常是返回200,根据header也可以确认代理服务器为squid

    记某次攻防演练通道搭建

    WGET请求失败,返回403,为啥还有wget失败的,这里是请求的是非80的常用web端口,却失败,上面是请求高端口才成功,怀疑squid是做了策略,比如限制外发的http代理请求端口。

    测试下来,80端口可成功,非80常用web端口不成功,而10000以上的端口会成功。

    记某次攻防演练通道搭建

    所以我就立即测试了下frp外联vps的80端口,却并没有如想象的连接成功。其实想想也是,之前测试过高端口的wget成功而frp失败,那你80端口也不太可能有啥区别。但渗透嘛,即使知道不行也还是要测测的,就是得不断试错。

    CS: 接下来抓了cs的包,因为cs是走的CDN https上线的。也是正常返回200。

    记某次攻防演练通道搭建

    FRP: 然后frp的数据包可不能漏,也是返回403

    记某次攻防演练通道搭建

    返回错误页面其实如下,访问被拒绝了呗。

    记某次攻防演练通道搭建

    其实仔细观察可以发现WGET/CS/FRP的代理请求有些不一样。

    如果是HTTP代理,那么客户端发送的请求方法就是常规方法如GET/POST

    而如果是HTTPS代理,那么客户端会先发送一个CONNECT请求,让代理与server事先建立好一个连接,代理收到同一客户端的后续请求,只需使用事先建立好的连接即可。

    具体区别可参考这篇文章https://www.cnblogs.com/selol/p/5446965.html

    所以FRP其实模拟的是HTTPS代理请求,用WGET发送HTTP代理请求测试,结果当然不一样。

    在代码里也可以看到FRP伪造代理请求的过程。

    记某次攻防演练通道搭建

    既然已经知道了FRP是使用HTTPS代理,那么既然CS能通过HTTPS 443 上线,那么FRP也应该可以通过443代理出网的,经过测试,终于连接成功,可反向代理进目标内网了

    记某次攻防演练通道搭建

    经历千辛万苦终于成功了,根据以上测试可推荐squid的策略如下

    GET/POST代理请求:使用高端口和默认80端口可请求成功,使用常规非80 http端口均拒绝。

    CONNECT代理请求:代表https请求,使用https默认端口(443)可请求成功,使用非https端口则会拒绝。

    0x03 总结

    搭建通道是内网渗透的一个重要环节,一个通道的隐蔽性、稳定性可提升后渗透阶段的效率。

    其实在这次通道搭建过程中使用了很多方法和工具,还包括了端口复用,端口复用因为HTTP代理原因失败。可能有人会说,可以正向HTTP代理呀,因为环境是springboot,没法上传webshell,关于内存马,需要结合实时漏洞做,这个有待下一步研究吧。

    在不同场景下会需要不同工具配合,关于http代理场景,之前确实没有注意过,不过在渗透中遇到这些问题也是常事,就是不断试错呗,记录一些试错的过程其实更有意义。

    还有其他方案,比如gost+frp。在其他场景中,比如只有ping出网,还能用pingtunnel+frp,代理工具选择有很多,有人也喜欢用ew。我选择frp主要是看重他的稳定性,并且frp的隐蔽性其实蛮好了,可通过ssl tcp 完全加密,又或者使用KCP+SSL。可能有人觉得会有落地配置文件,这个其实很好做,frp本身就支持命令行,稍微改下代码增加一些扩展参数就ok了,这不算啥问题。而文件大小其实还在我的可接受范围内。

    总的来说,出网的隧道搭建,越接近正常出网流量越隐蔽,所以能使用http 80、https 443之类的默认端口就尽量用这些,后续还考虑结合CDN做反向代理增加隐蔽性看是否可行。


    Security , 版权所有丨如未注明 , 均为原创丨
    转载请注明原文链接:记某次攻防演练通道搭建
    喜欢 (12)