网站地图    收藏   

主页 > 后端 > 网站安全 >

SAE云服务安全沙箱绕过4(绕过文件权限防御) - 网

来源:自学PHP网    时间:2015-04-17 13:03 作者: 阅读:

[导读] 摘要谢各位捧场,已经打到第四关了。经过几次交流,发现SAE的童鞋对安全很重视,而且持欢迎来搞的态度,对这样的态度,给予肯定,有了这样的态度,作者才有了继续下去的欲望,...

摘要

谢各位捧场,已经打到第四关了。经过几次交流,发现SAE的童鞋对安全很重视,而且持“欢迎来搞”的态度,对这样的态度,给予肯定,有了这样的态度,作者才有了继续下去的欲望,我们都相信SAE最终会变得越来越安全。

正文

前文《SAE云服务安全沙箱绕过3(绕过命令执行防御) 》,作者利用了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(绕过命令执行防御)

这是可以读的,这说明路径:

/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足够开放,建议直接开源出来,这可以更加开放的得到安全信息。
by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity

自学PHP网专注网站建设学习,PHP程序学习,平面设计学习,以及操作系统学习

京ICP备14009008号-1@版权所有www.zixuephp.com

网站声明:本站所有视频,教程都由网友上传,站长收集和分享给大家学习使用,如由牵扯版权问题请联系站长邮箱904561283@qq.com

添加评论