Re: TESO advisory - BinTec router

[aleph1 () securityfocus com (aleph1 () securityfocus com)]

----- Forwarded message from Thomas Schmidt <ts () bintec de> -----

Message-ID: <01BFA3AE.955250A0.ts () bintec de>
From: Thomas Schmidt <ts () bintec de>
Reply-To: "ts () bintec de" <ts () bintec de>
To: "'sholtwis () MUENSTER DE'" <sholtwis () MUENSTER DE>,
        "'aleph1 () securityfocus com'" <aleph1 () securityfocus com>
Cc: "'brick-users () tlk com'" <brick-users () tlk com>,
        "'teso () coredump cx'"
         <teso () coredump cx>
Subject: RE: TESO advisory - BinTec router
Date: Tue, 11 Apr 2000 12:08:01 +0200
Organization: BinTec Communications AG

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Concerning a Security Advisory called "BinTec ISDN router
family issues" recently published at http://teso.scene.at/ as
"TESO Security Advisory 9" (Author: Stephan Holtwisch)
BinTec as the router manufacturer want?s to make the
following statement:

The following points were mentioned in this Security Advisor
as vulnerabilites of a BinTec Router.

>     1. By using SNMP brute-force-techniques for SNMP community-names
>     one is able to gain the management accounts passwords, which are
>     the same as the SNMP community names.

>     2. Additionally the MIB-Tree holds security related information
>     which should not be accessible through read-only/SNMP.

>     2. These routers also offer services which can be abused rather
>     easily, like dialing out and getting full line access via a CAPI
>     interface, or a debugging interface which gives you all
information
>     which is sent over the BRI-lines.(Those services are open as
default
>     and the debugging service is barely documented)

1. Detecting and defending SNMP-Brute Force Access

Scanning the management account passwords of a Bintec Router with
a brute force attack via SNMP access can be detected and prevented
in the following ways:

Detection:

Every system access with an invalid management account
password is detected by the router and logged (local, via
console and via syslog to one or more external hosts).
In addition to that, SNMP requests with illegal community
passwords cause an SNMP Trap.

Defense:

We recommend using one or more of the following three methods
to deny SNMP access from untrusted WAN interfaces or to
restrict SNMP access to trusted IP addresses.

a) Use of Network Address Translation.
    The use of NAT will allow outgoing connections but deny any
    incoming connections from hosts on the other side of the
    WAN interface. This is also the default configuration for internet
    access, when the Bintec Router is configured via the Wizard.
    Bintec routers also can offer a special NAT mode without
    Address Translation, i.e. packets traveling through the router
    are not modified but connections from outside are still denied.

b) Use of Access Lists
    Filters and access lists can be defined for every interface.
    They can be used to grant access to local services via
    trusted IP addresses and/or trusted interfaces only, and
    deny the access to all others.

c) Use of "Local Service" Access Lists
    There are also two SNMP tables on the system to specify
    the trusted IP addresses to connect to any local service
    (localtcpallowtable and localudpallowtable). These tables
    are easier to handle and set up than access lists.
    Beginning with release 5.2.1, this configuration will
    be accessible via the built-in SETUP-Tool.

2. Defending SNMP Access to security related information

To defend SNMP-Access to security related information in
the private MIBs, the SNMP access has to be restricted.
Again we recommend using one or more of the three methods
mentioned in section 1a) to 1c)

3. Detecting and Defending abuse of other local services

The abuse of other local services like CAPI, TAPI and TRACE
can be detected and prevented in the following ways:

Detection:

Every CAPI, TAPI and trace connection is detected and
logged (local, via console and via syslog to one or more
external hosts). The syslog includes timestap,
source IP address/port and type of service.
If connections are established or accepted via CAPI
and/or TAPI, the timestamp, duration, number, charging
information are logged together with source IP address
of the TAPI/CAPI-user.

Defense:

We recommend using one or more of the following three methods
mentioned in section 1a) to 1c) to defend CAPI/TAPI or
TRACE access from untrusted WAN interfaces or to restrict
the access to trusted IP addresses.

References
=========

     [1] BinTec Communications
         http://www.bintec.de

     [2] User Documentation on "Access Security"
        http://www.bintec.de/download/brick/doku/70000b.pdf german, pg. 248
        http://www.bintec.de/download/brick/doku/71000b.pdf english, pg. 240
        (includes description of all methods mentioned above)
        The printed version of the user manual is delivered
        with every Bintec router.

     [3] Additional Documentation of "NAT"
         http://www.bintec.de/download/brick/doku/71040a.pdf english, pg. 282

     [4] Additional Documentation of "Access lists"
         http://www.bintec.de/download/brick/doku/71040a.pdf english, pg. 277

     [5] Additional Documentation of "Local Access lists"
         http://www.bintec.de/download/brick/doku/RN_XL482.pdf english, pg.
10

     [6] TESO
         http://teso.scene.at/ or https://teso.scene.at/

     [7] Stephan Holtwisch
         sholtwis () muenster de

# Thomas Schmidt - Productlinemanager
# BinTec Communications AG
# Suedwestpark 94 , 90449 Nuernberg
# Phone: +49-911-9673-0 , Fax: +49-911-6880725

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBOPLrU1uDFIQcc8vNEQKZ2gCfWLewpO3bQQf6hIEOpQfbvmtZDmsAoO0M
7PtfiocOVpdDGkU5ro6VXRtk
=MpNz
-----END PGP SIGNATURE-----

----- End forwarded message -----

--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/