SAE云服务安全沙箱绕过4(绕过文件权限防御)
谢各位捧场,已经打到第四关了。经过几次交流,发现SAE的童鞋对安全很重视,而且持“欢迎来搞”的态度,对这样的态度,给予肯定,有了这样的态度,作者才有了继续下去的欲望,我们都相信SAE最终会变得越来越安全。
正文
前文《SAE云服务安全沙箱绕过3(绕过命令执行防御)》(http://www.inbreak.net/archives/426),作者利用了SAE仅仅限制EXEC命令,没有限制其他函数的漏洞,打破了整个沙盒的防御,最后给出的建议中,作者也提到了对沙盒的防御方式。SAE接受了常规的沙盒安全方案,不再局限于限制某个函数等策略。现在到处都是限制,这对于作者来说真是艰难困苦的开始,感觉SAE对于沙盒的安全限制,已经比google还要BT了,甚至有些不照顾JAVA框架了,无论如何,作者继续绕了下去。
环境探测
首先看看常规的,危险的几个函数:
crackClassLoader
还是前几篇文章专用的代码,所以本文就不再次贴出来了,直接看结果:
已经限制了createClassLoader,这样我们自定义的classLoader已经无效,这意味着,不能再走定义一个自定义权限的类,这个流程了。
连接socket测试
http://2.javasandboxtest.sinaapp.com/socket.jsp?host=www.inbreak.net&port=80&page=/
不允许socket连接,不允许XXX,不允许XXX。。。
这样绕,不是办法,都被干掉了。这时候,我们需要一种打破常规沙盒绕过的手段。
读文件测试
作者发现了一个非常有趣的情况,SAE的JAVA环境中,有个Class,叫做”com.sina.sae.security.SaeSecurity”,这个Class,像是做验证的,里面有方法“checkRead”。如果知道这个方法的验证逻辑,并且刚好开发人员实现这个方法时,出现了逻辑漏洞,才可能出现bypass。但是在这样的条件下,拿到SAE的源码,非常难,只能可以从侧面探测。
作者想到,如果让这个类,刚好在权限验证时,起效果,并且在java远程的沙盒之前run起来,最简单的架构,是让它直接继承Java.lang.SecurityManager,这个东西是java原生提供的功能,默认会根据java的policy文件中设置的权限白名单,做各种认证。一个Class继承了SecurityManager,就是所谓的自定义SecurityManager,SAE和google都使用了自定义SecurityManager。
查看这个Class的文档说明,里面有很多权限验证的方法,这些验证方法,都可以由开发人员自行实现,覆盖java原生的验证逻辑。
图中有很多验证方法,都可以由开发人员自己实现的验证方法覆盖,一旦SAE的开发人员覆盖了这些方法,比如命令执行,那么在真正java做命令执行前,会验证权限,就使用SAE开发人员写的方法,而不是JAVA原生的验证。
正常JAVA沙盒错误的信息,应该和SAE自己实现的安全认证没有关系,理论上java自己的沙盒,已经具备了文件读取等认证。但是按照前面图中所示的异常信息,作者推测,是SAE的开发人员替代了JAVA原生安全认证。从这里也看出,SAE野心不小,有替换JAVA语言本身安全沙盒的趋势,但是JAVA本身的代码,是经过很多年风吹雨打的,各种bypass都出现过,SAE新写的代码,想达到这个标准,还是比较难的。
下面可以从各种角度,测试SAE自己实现沙盒代码的安全性,checkRead方法,看名字就是验证文件读取权限的。而用户自己上传的文件,必然是可以读取的,否则沙盒的限制,就太BT了。
作者上传了一个文件,然后读取,获取文件路径的方式,见之前作者写的文章《SAE云服务安全沙箱绕过3(绕过命令执行防御)》(http://www.inbreak.net/archives/426)。
这是可以读的,这说明路径:
/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp
下的文件,都是可读的,那么文件权限验证,肯定就必须包含这个路径了。这个安全策略是否可以绕过呢?
开始bypass
这让作者想起了文件下载漏洞。绕过任意文件下载漏洞,有无数前辈的经验,最常见的思路,当然是“/../“了。
读取/etc/passwd文件内容:
http://3.javasandboxtest.sinaapp.com/down.jsp?filename=/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp/../../../../../../etc/passwd
从这个过程,也进一步验证了SAE的认证代码,checkRead方法,很可能只有一行,下面是推测出来的伪代码:
If (XXXX.startwith(/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp)) { Return true; }
这种漏洞,本来就是个经典的文件下载漏洞代码,但是放到沙盒里,却导致了沙盒被绕过。现在我们又可以读取云上用户的文件了。
关于沙盒与JSP空间友好性的问题
我们知道JAVA的web应用,只有jsp和servlet的时代,已经不存在了,无论哪个应用,多少都会有JAVA框架的影子,比如struts、spring等等。框架本身的实现,经常会涉及到getClassLoader等等操作,现在SAE限制了这个东西,作者对STRUTS2应用,能否在SAE上跑起来,表示疑问。为此,作者专门上传了struts的官方showcase上去。
结果返回503错误,不可用。
总结
即使是非常简单的STRUTS2应用都不可用,还有很多其他框架,也都有自己操作classLoader的情况,如果不支持JAVA框架,这样的SAE,还有啥存在的价值呢?所以这些权限,不止简单的禁止了事,它后面还有很多东西要做。没有可用性的安全,不是真的安全,这样的安全处理方案,早晚要在业务的压力下消失不见,要保证可用性,也要保证安全,这才是真正的安全。所以,坐等SAE对classLoader的限制消失,一切回归于0。
最好的办法,是对接管JAVA原生安全验证这部分代码,做一次整体的revuew,在代码无法保证安全之前,就去接管更加安全的东西,这本身就是一种安全隐患了,谁敢讲自己写的代码,一定比SUN(写沙盒的时候,还没到oracle)那帮人更安全,更健壮?
其实沙盒绕过技术,作者也是第一次玩,每次一定要等SAE修补之后,才会有新的办法出现,SAE肯定希望我一次性,把所有绕过的方法都给出来,但是问题是还没做好防御,谈何攻击呢?建议对SAE的代码,做一次整体的review,尤其是接管JAVA沙盒认证这块,相信还有更加严重的漏洞在里面,解决这个问题,只有由安全人员一行一行看了,如果SAE足够开放,建议直接开源出来,这可以更加开放的得到安全信息。
建议继续学习:
- 在sae中利用SaeFetchurl进行豆瓣的OAuth授权 (阅读:3554)
- SAE云服务安全沙箱绕过5(强制修改class私有权限) (阅读:3338)
- SAE云服务安全沙箱绕过3(绕过命令执行防御) (阅读:3057)
- SAE云服务安全沙箱绕过2(利用crackClassLoader) (阅读:2563)
- 从对SAE的一次授权安全评估浅谈云安全 (阅读:1767)
- 也来谈谈沙箱逃逸技术 (阅读:1367)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:空虚浪子心 来源: 空虚浪子心的灵魂
- 标签: SAE 云服务 沙箱
- 发布时间:2012-08-09 23:49:37
- [67] Oracle MTS模式下 进程地址与会话信
- [65] 如何拿下简短的域名
- [65] Go Reflect 性能
- [59] 图书馆的世界纪录
- [59] android 开发入门
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] IOS安全–浅谈关于IOS加固的几种方法
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 读书笔记-壹百度:百度十年千倍的29条法则
- [46] 界面设计速成