Message-ID: <7201234.1039437031@[10.3.62.6]>
From: pbieringer at aerasec.de (Dr. Peter Bieringer)
Subject: Re: Proxy vulnerability in TrendMicro InterScan-VirusWall V3.6 -
 and 3.7 Build 1190

Hi,

(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@...con.de> 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.:
http://www.aerasec.de/security/index.html?id=ae-200202-051


> 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
original e-mail.

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.

07.03.2002:
File: intscan.ini
Section: [http]
Parameter: proxy_acl=
 Prevent unauthorized clients to use the proxy (didn't really help)

23.05.2002:
File: intscan.ini
Section: [http]
Parameter: tunnel_allow=
 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
File: intscan.ini
Section: [http]
Parameter: tunnel_port=
 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.


> Solution:
> 	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):

0) 
Looks like the mailscanner issmptd is now a transparent one, no longer a
spooler version one.

1)
The new delivery daemon "/etc/iscan/isdelvd" uses a configurable sender
address, default: root@...alhost.domain.example
Adjust "localhost" here:
[notification]
# The smtp host for delivering notification messages.
server=localhost

2)
Logfile displays placeholders instead of values:

# tail -20 log.2002.11.18
11/18/2002 08:19:01 ptn[28616]: auto: Pattern up to date.
11/18/2002 08:19:01 ptn[28616]: auto: delivering notification to %s.
11/18/2002 09:19:00 ptn[10179]: auto: started ...
11/18/2002 09:19:00 ptn[10179]: auto: retry time=%dm retry count=%d.
11/18/2002 09:19:00 ptn[10179]: auto: Try %3d...
11/18/2002 09:19:00 ptn[10179]: auto: Pattern up to date.
11/18/2002 09:19:00 ptn[10179]: auto: delivering notification to %s

Answer from techsupport: this is ok
My opinion: bug


3)
Automatic pattern update sends an e-mail on every run, even if no update
was done.
Techsupport told me: will be fixed in 3.8
Workaround: deactivate "/etc/iscan/isdelvd", use following script instead:

File: "/usr/local/sbin/interscan_checkmails.sh"

#!/bin/sh
# (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"

DIR_MAILQ="/etc/iscan/mailq"
MAILADDRESSES="admin@...ain.example"

# 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"
                rm $file
                continue
        fi

        cat $file | mail -s "Pattern update information" $MAILADDRESSES
        rm $file
done


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
hotfixes...


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@...asec.de
Germany                           Internet: http://www.aerasec.de
PGP/GPG:  http://www.aerasec.de/wir/publickeys/PeterBieringer.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20021209/5d5acb8c/attachment.bin

Powered by blists - more mailing lists