Back to list
Proxy vulnerability in TrendMicro InterScan-VirusWall V3.6
Dec 05 2002 04:00PM
Volker Tanger (volker tanger discon de)
Re: Proxy vulnerability in TrendMicro InterScan-VirusWall V3.6 - and 3.7 Build 1190
Dec 09 2002 11:30AM
Dr. Peter Bieringer (pbieringer aerasec de)
(sorry for cross-posting to full-disclosure also, perhaps it will be
rejected by bugtraq)
some comments and additional information on this note and more of the
"story" from our point of view:
--On Donnerstag, 5. Dezember 2002 17:00 +0100 Volker Tanger
<volker.tanger (at) discon (dot) de [email concealed]> wrote:
> A quite well known (i.e. ancient) type of proxy vulnerability was
> found for TrendMicro's InterScan VirusWall V3.6
In February 2002.
See also e.g.:
> This general problem
> has been known to be an issue with plain HTTP proxies like the Squid
> for ages (e.g. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html#ss10.14).
> The vulnerability can be exploited using the CONNECT method to
> connect to a different server, e.g. an internal mailserver as
> port usage is completely unrestricted by the ISVW proxies V 3.6
Yes, if no additional firewalling is prohibiting this like suggested in the
We've reported this issue to Trend Micro via our reseller on late February
for version 3.6 Build 1182.
We got some interesting but not sufficiant bugfixes or workarounds, e.g.
Prevent unauthorized clients to use the proxy (didn't really help)
Allows tunneling only for dedicated hosts/nets, others may only use port
443 (didn't also really help, sometimes SSL servers are on non standard
port like 8443).
12.06.2002: 3.6 Build 1236
Some ports can be specified now (even better)
But unfortunately, on not allowed requests, the return code was "400 Bad
Request" instead of "403 Forbidden" (like Squid does).
18.07.2002: 3.6 Build 1246
Return code on forbidden requests was fixed to "403".
Don't know wheter 5 months for fixing such issue in a correct manner is a
very good reference for the vendor.
> Update to ISVW 3.7 Build 1190 or newer (available since some
> weeks now).
This issue should be also fixed in 3.6 Build 1250 or newer, but 3.6 is no
longer really supported.
Note also: 3.7 Build 1190 has some strange issues, be warned (don't know
what's happen with QA at Trend Micro):
Looks like the mailscanner issmptd is now a transparent one, no longer a
spooler version one.
The new delivery daemon "/etc/iscan/isdelvd" uses a configurable sender
address, default: root (at) localhost.domain (dot) exam [email concealed]ple
Adjust "localhost" here:
# The smtp host for delivering notification messages.
Logfile displays placeholders instead of values:
# tail -20 log.2002.11.18
11/18/2002 08:19:01 ptn: auto: Pattern up to date.
11/18/2002 08:19:01 ptn: auto: delivering notification to %s.
11/18/2002 09:19:00 ptn: auto: started ...
11/18/2002 09:19:00 ptn: auto: retry time=%dm retry count=%d.
11/18/2002 09:19:00 ptn: auto: Try %3d...
11/18/2002 09:19:00 ptn: auto: Pattern up to date.
11/18/2002 09:19:00 ptn: auto: delivering notification to %s
Answer from techsupport: this is ok
My opinion: bug
Automatic pattern update sends an e-mail on every run, even if no update
Techsupport told me: will be fixed in 3.8
Workaround: deactivate "/etc/iscan/isdelvd", use following script instead:
# (P) & (C) 2002 by Dr. Peter Bieringer, AERAsec
# Workaround to prevent mail flodding caused by prescan.cgi
# in case of event "Pattern up to date"
# Don't forget to disable "iscandelvd"
MAILADDRESSES="admin (at) domain (dot) exam [email concealed]ple"
# Find files
find $DIR_MAILQ -type f -maxdepth 1 | while read file; do
#echo "Check file: $file"
if grep -q "B Pattern up to date." $file; then
# Unwanted information
#echo "Remove file: $file"
cat $file | mail -s "Pattern update information" $MAILADDRESSES
Startd by cron some minutes after the pattern updater call (prescan.cgi)
BTW: the build numbers of 3.6 and 3.7 are different, so 3.6 Build 1250 (the
latest one I've got) is older than 3.7 Build 1190.
BTW2: Has anyone seen any advisory from Trend Micro regarding their fixes
all the time? There were some other interesting bugs fixed (e.g. relating
to issmtp), mostly detected by looking into the changelog file of
Hope this helps,
Dr. Peter Bieringer
Dr. Peter Bieringer Phone: +49-8102-895190
AERAsec Network Services and Security GmbH Fax: +49-8102-895199
Wagenberger Straße 1 Mobile: +49-174-9015046
D-85662 Hohenbrunn mailto:pbieringer (at) aerasec (dot) de [email concealed]
Germany Internet: http://www.aerasec.de
[ reply ]
Copyright 2010, SecurityFocus