空虚浪子心的灵魂

作者：空虚浪子心

 

PS:感谢刺对本文提出建议。

 

前言

文章的开始，先诱惑下那些不研究applet的朋友。

 

Java Applet需要安装java环境才能执行。很多朋友不研究的主要原因，是自己认为普通上网用户不会安装java环境。但是大家真的知道目前都有哪些人安装了java环境么？你当然知道有这些人：“java开发人员”、“因工作需要使用java软件的人”，他们安装了java环境。但是你不知道的是，还有一群无辜的用户也在不知不觉中安装了。

 

中国使用盗版软件的人有多少？所有的人都在用（别误会，我不打击盗版）。那么你知道使用盗版操作系统的人有多少么，你知道盗版的操作系统是哪里来的么？经常安装操作系统的人，还有经常到电脑城挑盗版盘的人，都或多或少的听过以下这些名字：“雨林木风”，“番茄花园”，“电脑公司版”，“深度”等等。。。这就是那些研究如何让操作系统方便各种人群的使用，把操作系统制作成系统盘，供大家下载的一些人。而那些出盗版系统盘的商家，先从这些地方下载，之后经过刻盘，卖给普通用户。作者经过一些调查，了解到以下一些操作系统版本，自带JAVA环境：

 

雨林木风 ——-   集成微软 JAVA 虚拟机。

番茄花园 GHOST XP SP2 v 3.1   —–    集合 MS JAVA 虚拟机

深度GHOSTXP SP3快速装机专业版V9.0(NTFS)   ———-  集成MSJAVA虚拟机

GhostXP SP3电脑公司完美特别修正版 v9.1 ——-  修正JAVA虚拟机不能启动的BUG

999宝藏网 GhostXP SP3 活力版 V3.0   ——–   微软 JAVA 虚拟机

电脑市场 GhostXP SP2装机版 v3.0

小路工作室 GhostXP P2008贺岁版[装机版]

深度技术 GHOST XP SP3 快速装机专业版 V8.1

。。。。。。

 

以上操作系统都附带java虚拟机，国内的操作系统安装盘最流行的，也就这几家了，都有一些版本在支持java环境。那么你现在再回答我，中国有多少机器上安装了java环境？

 

在作者以前的文章里曾说到，研究applet安全，至少能祸害一部分人。但是总有很多朋友不喜欢研究，好像这玩意大家都不用似的。任何一个Exp的成功率都不是100%，大家只想研究如何用别人的EXP去搞站，何不自己研究点实实在在的技术呢？几天前，在“刺”的blog上看到他说“国内好像没人关注GIFAR啊，我白辛苦码这么多字了”，深感痛心，国内的人都去做什么了？刚巧作者研究了一段时间applet的安全性，看到这个漏洞很兴奋。刺在自己的blog上发了两篇GIFAR的文章，作者跟帖讨论一直跟到50多篇，可是反过来看看，好像就我们两个人在讨论相关技术。原来是刺的文章写的太专业，大多数不了解applet的朋友可能看不太懂，为了让这个东西更普及，更菜鸟化，就有了这篇GIFAR详解。

 

正文

注：本篇文章是对刺写的两篇“关于GIFAR”和“关于GIFAR的一些补充分析”的详解，同时也写了点自己对GIFAR的一些见解。

 

Applet本身的安全机制是不允许跨站的，它只允许自己访问applet标签所在页面的域。但是当applet标签中的codebase属性给定了一个URL，让当前页面的applet到另一个域获取class或jar文件时，applet会自动为自己添加一个socket permission，也就是添加一个可以到class文件所在域的权限。使用copy /B命令可以把一个jar文件捆绑到一个gif上，捆绑后，同样可以让java虚拟机把这个GIF当成applet解释执行。这个技巧为漏洞的利用提供了便利，虽然我们不能给目标服务器上传jar文件，但是我们有可能会被允许上传gif。

 

以下是一个利用GIFAR所要用到的applet标签，该标签只要在html中就会执行applet：

 

 

Code属性表示jar文件中的class名称，codebase表示jar文件所在的绝对路径（不包括文件名），archive表示jar文件的文件名，PARAM是为了灵活控制给jar代码中的一些变量传值，这里的传的名称是url，对应的值是一个网站地址。可以根据自己要跨的域来改变这个地址。

 

解释的有点抽象，看下图：

 

 

利用的环境按照上图所示，有两个域，A域和B域。我们在A域上发现了一个XSS漏洞，利用漏洞在A域的某个页面上放置一个applet标签，B域恰好有一个功能，可以上传GIF图片。要得效果是在访问A域的页面同时，访问一下B域的隐私页面，以达到辅助入侵B域的目的，但是有两个问题，一个是B域的cookie验证，另一个是浏览器不允许跨域访问。

 

利用GIFAR，就可以跨越这两个障碍。

 

下面我再详细的解释一下这个漏洞，在和刺的讨论过程中，问题集中在以下几点：

1，             session cookie，和stored cookie。

2，             跨域之后对所跨域的域名问题。

3，             跨域之后如何取COOKIE。

 

先说第一点，这两种cookie有什么区别呢？其实session cookie指的就是我们常说的session，而stored cookie就是我们常说的cookie。Session的生存周期默认是这样的：

 

当用户使用浏览器访问一个网站的任何地方时，网站的服务器会为这个链接新建一个session，为了标识这个session的单一性，通常都会有一个session id来标识。当用户关闭了浏览器，用户就不知道这个session存在了，但是服务器的内存里这个session并没有销毁。因为默认session销毁的时间是30分钟，到了时间自动销毁，或者由程序去销毁，通常程序销毁session时，用户的操作都是类似于“退出”、“注销”等等。一旦用户关闭了浏览器，浏览器并不会通知服务器销毁session，但是新打开的浏览器再次连接服务器时，服务器又会为这次浏览创建一个新session，这就导致了很多人以为浏览器关闭后，session自动消失的假象。

 

而cookie就不一样了，cookie验证通常会制定一个时间，比如我们常在论坛登录时看到的“保存一年，保存一个月，保存一天”等等。使用cookie的通知，浏览器会在“C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files”（也就是浏览器缓存文件夹）这个文件夹里建立一个文本文档，叫做“administrator@www.qq163.txt”，这个文档里记录了用户登录的信息。当用户下次打开网站时，浏览器自动去缓存取得这个cookie，并且放在每次http请求里，一起发出去，网站服务器让用户通过验证，进行某种触及隐私的操作。

GIFAR这里，使用的就是cookie，不是session，所以更容易出现CSRF攻击。

 

再说第二点，域名问题。无论是JS还是applet，都限制只能访问当前域下的内容。比如这个JS如果是aaa.sohu.com，就不能访问bbb.sohu.com的东西，如果你跨域跨到了aaa.sohu.com，就可以访问aaa.sohu.com。

 

而cookie对于域名的要求就有点暧昧了，这要看在写程序时，你的cookie制定的域名是什么。来看以下这段jsp程序。

 

 

这段cookie制定了域名为“.sohu.com”这个一级域名。就表示这个域名下所有的二级域名、三级域名、四级。。。都可以访问这个cookie。而默认的cookie域，如果不指定域，则会由程序自动制定到当前JSP文件所在的域下。例如http://www.sohu.com/a.jsp这个jsp文件所在的域是二级域名www下，那么他的cookie就只有这个二级域名下的文件才可以访问，其他的域名例如img.sohu.com就不可以访问这个cookie。

 

最后一点，其实是这个漏洞利用成功之后能做什么。跨域取cookie只是一种利用，还有很多种利用方式，比如CSRF。前文提到，cookie是有域名限制的，如果要跨域取cookie，就必须保证这段取cookie的程序要在所跨域下的文件中执行。我一直推荐一种方式，就是当IE7以下浏览器去打开JPG文件时，如果JPG文件其实是个HTML，就会执行HTML。那么取cookie得代码就可以写到这个文件上，之后上传到要跨的域，再利用applet让受害者的浏览器访问这个JPG文件。这样，无论是挂马还是取cookie都可以在这里完成。

 

一个CSRF示例：

先说明一下测试环境，有两台计算机，一台linux+apache下面简称APACHE域，一台windows+iis下面简称IIS域。APACHE域下的某个文件出现了XSS漏洞。利用该XSS漏洞可以在页面上插入applet标签。IIS域下有上传gif文件功能，于是上传了一个gif文件，还有一个需要cookie验证才能执行其他操作的隐私页面。最终要达到的效果是，IIS域的管理员（可以通过cookie验证的人）访问APACHE域下的XSS漏洞页面，同时悄悄的访问到IIS域下的隐私页面（CSRF）。

 

 

IIS域下的页面a.asp，目的用来建立一个cookie，这个cookie可以通过b.asp的验证。这里模拟了相当于管理员登陆成功的过程。

 

a.asp代码：

 

作用是新建一个cookie。

IIS域下的b.asp代码:

 

通过了cookie验证后，会在当前目录下新建一个kxlzx.txt，最后看到这个文档时，意味着CSRF成功。

IIS域下的2.gif文件，编译前Ghost.java代码：

 

 

这个文件就是applet的代码，代码从applet标签的PARAM中取到url的值，之后访问这个URL。我们要把这个文件编译成jar，然后使用copy /B 附加到一个gif中。

APACHE域下的Test.php代码：

 

 

下面开始测试：

1，  首先使用jar cvf a.jar Ghost.class把class打到jar包里。

2，  输入命令copy a.gif /b + a.jar 2.gif把jar文件追加到a.gif，生成一个新文件2.gif。

 

 

3，  访问APACHE域下的a.asp，保存cookie，并弹出保存的内容。

 

 

 

4，  访问APACHE域下的test.php。

 

 

5，  查看结果，看到kxlzx.txt中记录了cookie信息。

 

下面是在整个过程中抓到的几个包：

 

第一个包：

GET /a.asp HTTP/1.1

Host: 192.168.0.88

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

输入地址访问IIS域，访问IIS域的包颜色为蓝色

 

第二个包

GET /wwwroot/test.php HTTP/1.1

Host: 192.168.0.222

Accept-Encoding: gzip,deflate

输入地址访问APACHE域，访问APACHE的包颜色为红色

 

第三个包

GET /2.gif HTTP/1.1

content-type: application/x-java-archive

User-Agent: Mozilla/4.0 (Windows 2003 5.2) Java/1.6.0_03

Host: 192.168.0.88

Cookie: Cookie1=kxlzx=testok;

 

第四个包

GET /Ghost.class HTTP/1.1

Host: 192.168.0.88

Cookie: Cookie1=kxlzx=testok;

 

第五个包

GET /b.asp HTTP/1.1

User-Agent: Mozilla/4.0 (Windows 2003 5.2) Java/1.6.0_03

Host: 192.168.0.88

Cookie: Cookie1=kxlzx=testok;  

 

第一个包是访问a.asp的，可以看到在这个向IIS域的请求中，没有cookie，但是访问过该文件之后就有了。

 

再看第二个包，访问了APACHE域的test.php，后面的包都是由applet自动发送的。

 

test.php里的applet又访问了gif文件，可以看到第三个包的Agent已经变成了“Java/1.6.0_03”，说明该包是java去访问的。

 

最后的包，就是CSRF的包，这个包成功的访问了b.asp，并且带有可以通过验证的cookie，成功的在根目录下生成了一个kxlzx.txt文件。CSRF的整个过程中，在用户访问APACHE域的同时，跨域访问了IIS域，并且带着IIS域的COOKIE。

 

结尾：

GIFAR就写到这里，其实GIFAR真正能做的事情，不止CSRF这么简单，它的作用是调用appet，之后都交给applet来完成。所以，要研究GIFAR，首先要研究applet的安全性。推荐作者之前写的文章《Java applet安全性探究》，请去google找找。