lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 1 Apr 2003 16:57:54 +0200
From: "Michael Puchol" <mpuchol@...ar-security.com>
To: "Bugtraq" <bugtraq@...urityfocus.com>,
   "C2 Security" <security-submit@...ecurity.org>,
   "PacketStorm Security" <submissions@...ketstormsecurity.org>,
   "Vulnwatch" <vulnwatch@...nwatch.org>
Subject: [VulnDiscuss] 3Com 812 ADSL router vulnerability addendum


Following our report of a vulnerability in which a 3Com 812 ADSL router will
expose an internal computer's ports to an external computer once a
connection between the two is established, it has been brought to our
attention that this is in fact a feature of the router, called "Intelligent
PAT". Quoting the 3Com manual on the CLI interface (configuration over
telnet):

// BEGIN QUOTE

Enabled by default, Intelligent PAT provides a "best guess" as to where an
incoming packet should be delivered when:
* A default PAT destination address has not been configured for a receiving
(LAN)
workstation
-AND-
* Static TCP or UDP ports have not been configured

Intelligent PAT bases this "best guess" on an analysis of recent
communication between the following:
* This remote workstation (the workstation sending this non-addressed packet
from the WAN side of the OCR 812)
* Private workstations (on the LAN side of the OCR 812) that recently
transmitted outgoing packets to this remote workstation

Upon completion of the "best guess" analysis, Intelligent PAT forwards the
packet to the last LAN workstation to transmit a packet to this remote
workstation."

// END QUOTE

The source of these quotes is the following document:

http://support.3com.com/infodeli/tools/remote/ocradsl/20/812_cli20.pdf

While it may be true that this is considered by 3Com a feature, and is
documented, the following points still make a case for exercising caution
when using this router:

1. Even if static routes have been configured in the NAT table, for example,
mapping NetBIOS ports to a non-existant internal IP address, the router will
still apply this "best guess" system, providing access to the internal
machine's NetBIOS ports to any external machine to/from which a connection
is established.

2. This feature is enabled by default, and it is NOT present or configurable
in the web interface of the router, so it will be difficult for
non-technical or experienced router administrators to: a) be aware of this
feature, documented in the CLI interface manual, b) be able to disable it
using a telnet interface, and c) be disabled by the provider of the router,
usually an ISP who includes it as a packaged deal for the ADSL line.

3. Since the router keeps the "best guess" path open for up to 2 minutes, it
would be trivial to write an attack tool that automatically infected a
visiting computer with a malicious payload. For example, receiving a HTML
email containing images resident in a malicious server would cause a total
exposure of the recipient of such email to the server.

4. The CLI documentation is misleading as it mentions only that the "best
guess" mode will forward packets to "the last LAN workstation to transmit a
packet to this remote workstation", but it also works in reverse, i.e. a web
server is completely exposed to any visiting client. Also, the document
states that this mode works when "static TCP or UDP ports have not been
configured", when it is clear that it still works when stating ports have
been configured.

Special thanks to Gonzalo López Menéndez who pointed out the information
about the CLI mode setting.


Michael Puchol
Sonar Security
mailto:mpuchol@...ar-security.com










Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ