当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2015-0132270

漏洞标题：搜狐某云平台API接口SSRF续集(一种新姿势)

相关厂商：搜狐

漏洞作者： Wulala

提交时间：2015-08-07 11:34

修复时间：2015-09-21 12:16

公开时间：2015-09-21 12:16

漏洞类型：设计缺陷/逻辑错误

危害等级：高

自评Rank：15

漏洞状态：厂商已经确认

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2015-08-07： 细节已通知厂商并且等待厂商处理中
2015-08-07： 厂商已经确认，细节仅向厂商公开
2015-08-17： 细节向核心白帽子及相关领域专家公开
2015-08-27： 细节向普通白帽子公开
2015-09-06： 细节向实习白帽子公开
2015-09-21： 细节向公众公开

简要描述：

搜狐SSRF连续剧
第一集
http://www.wooyun.org/bugs/wooyun-2015-0129588
第二集
http://www.wooyun.org/bugs/wooyun-2015-0132243

详细说明：

1. 在第一集 SSRF挖掘和利用
WooYun: 搜狐某云服务API接口导致SSRF/手工盲打到Struts2命令执行
2. 今天有时间就去复测一下(在好好学习一下), 原来的漏洞已经被修复了(其实第二天的时候测试就已经修复了).
3. 测试了 @、 IP转换的方式、内网域名(monitor.sohu.com)、xip.io都没能绕过. 别人能绕过,为啥我不能.
4. 分析了一下这个API的运行机制, 充当HTTP客户端去访问WEB页面. 并且对修复的方式进行了判断, 内网IP和内网域名都不可以, 对内网IP端做了过滤，内网域名也不可以则证明是对解析后的IP进行判断(这里做出这个判断的依据太SB了,因为干扰因素太多了)
5. 在第一章中我通过SSRF探测到了Struts2漏洞, 这里我用到了一个统计的方法,
POC: http://10.11.150.158/login.action:%25{3*4} -> 200 OK -> Return True
POC: http://10.11.150.158/login.action:redirect:http://SERVER/%25{3*4} -> 302->403 _> Return False
这里使用上面POC是可以的，但是使用下面的POC是不可以的. 因为采用下面的POC我的服务器会返回403. 所以这里我记忆非常深刻. 因为这里Struts的redirect是通过302跳转,我们无法判断到底是因为302 还是403 导致返回的False.
6. 要判断这个问题可以通过 login.action:redirect:http://www.baidu.com的返回结果来判断，因为baidu.com肯定返回200，如果结果返回True证明，SendCloud的返回状态是302跳转的目标的返回结果. 但是现在我们现在无法访问http://10.11.150.158，这里我们可以将Struts反向使用,我们自己搭建一个存在Struts漏洞的网站即可.
7. 测试结果返回True，即 SendCloud是根据302跳转后目标地址的返回状态判断的
8. 那么我们现在就可以尝试绕过SendCloud
这是我存在Struts2的网站

1.png


测试127.0.0.1

2.1.png


测试10.11.150.158

2.2.png


Tomcat日志

3.png


测试Struts2

4.png


4.1.png


9. 支持完全可以绕过已经修复的搜狐SSRF,并且可以将第一集Struts2命令执行重来一下
10. 回过头来想, 总结一下,其实就是通过外部服务器302跳转绕过
11. 但是这是一种新的姿势
12. SSRF防护思路:
判断TARGET是否为IP->如果不是则解析为IP地址->通过正则判断是否属于内网IP地址
13. 对于上面的防护思路,我们可以通过302跳转的方式进行SSRF攻击
14. 短网址 VS 302.SSRFJump
->1. 短网址对于上面的场景不适用
->2. 短网址不适于通过程序去探测内网
->3. 短网址无法加载某些攻击Payload，如Struts2命令执行

6.png


7.png


当然，短网址也有好处, 就是不会出现内网IP地址, 不过我们可以将这两种方式进行一个结合.

5.png


http://dwz.cn/yXSk 原网址为http://127.0.0.1

漏洞证明：

上面说过了 这里反向使用Struts2其实核心就是通过302跳转, 这里我用PHP写了一个302 ssrfjump.php的服务端程序来实现这样一个功能

<?php
/*
Usage: ssrfjump.php?u=http://IP
Desc: 通过HTTP 302 跳转绕过SSRF过滤
这里IP也可以用短网址代替
*/
if(isset($_GET['u']) && !empty($_GET['u'])){
	header("location: ".$_GET['u']);
}else{
	echo "<pre>Usage: ssrfjump.php?u=http://IP     
	Desc: 通过HTTP 302绕过SSRF
	->^_^ By Wooyun.Wulala		
	</pre>";
}
?>

修复方案：

修复建议:
对这是发送请求的目的进行判断过滤而不是用户输入的数据
或者
对这个TARGET通过正则判断是否存在内网IP
其实是先通过这个方法绕过目前的检测,后面思考了一下, 然后验证了一下短网址. 虽然这两个的核心都是302跳转, 但是这两种姿势是不同的, 所以防护也有一些差别. 一起提了,希望修复的时候可以将两方面都考虑进去, 别拆东墙，补西墙.
其实上面的很多步骤可以说是很蠢的, 但是我就想记录一下我当时的想法，曲径通幽有时会有一些意外的收获..
以上测试仅仅是为了学习, 无任何非法操作...

版权声明：转载请注明来源 Wulala@乌云

漏洞回应

厂商回应：

危害等级：中

漏洞Rank：10

确认时间：2015-08-07 12:14

厂商回复：

虽然和之前的漏洞重复了，但是还是确认给10分吧

最新状态：

暂无

漏洞评价：

评论

  1. 2015-08-07 12:30 | Wulala ( 普通白帽子 | Rank:223 漏洞数:24 | ^..^ ^..^ ^↓^ ^..^ ^..^)

    @搜狐 我也不是想提两个, 如果你了解你们的修复的方案, 上一个绕过你们修复后, 用这个绕过方法还是可以绕过的. 如果你认为这两个一样，那么肯定还是可以被绕过的. 建议修复方案: 对真实请求的地址做验证，而不是用户的输入(你们就是这么做的，而且匹配内网的正则使用这种方式是没有匹配上的)，可以参考一下.

  2. 2015-09-11 15:30 | Mr .LZH ( 普通白帽子 | Rank:583 漏洞数:75 | 非妹子勿扰···)

    点赞

  3. 2015-09-21 15:17 | phantomer ( 路人 | Rank:8 漏洞数:4 | 菜比一个。求勿喷。)

    666