技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 安全 --> SAE云服务安全沙箱绕过4(绕过文件权限防御)

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

浏览:3551次  出处信息
摘要

谢各位捧场,已经打到第四关了。经过几次交流,发现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足够开放,建议直接开源出来,这可以更加开放的得到安全信息。

建议继续学习:

  1. 在sae中利用SaeFetchurl进行豆瓣的OAuth授权    (阅读:3554)
  2. SAE云服务安全沙箱绕过5(强制修改class私有权限)    (阅读:3338)
  3. SAE云服务安全沙箱绕过3(绕过命令执行防御)    (阅读:3057)
  4. SAE云服务安全沙箱绕过2(利用crackClassLoader)    (阅读:2563)
  5. 从对SAE的一次授权安全评估浅谈云安全    (阅读:1767)
  6. 也来谈谈沙箱逃逸技术    (阅读:1367)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1