Date: Mon, 13 Mar 2000 11:49:22 +1100
From: Andrew van der Stock <ajv@greebo.net.>
To: [email protected]Subject: Advisory Update: ServerIron TCP/IP predictability fixed
Topic: Foundry Networks ServerIron (and possibly other Foundry products)
have extremely poor TCP/IP sequence predictability
Version: 5.1.10T12 (tested), and probably other versions including 6.0
(untested)
Severity: High without workarounds
Abstract
========
Foundry Networks sell a range of layer 2-7 switches, "ServerIron" and
closely related products "BigIron", "FastIron II", "TurboIron", "FastIron
Workgroup", "FastIron Backbone", and "NetIron". The main use for ServerIrons
is to sit in front of one or more hosts and provide scalable, fault tolerant
service, such as SMTP or DNS by faking IP addresses and distributing load
among a farm of servers.
The vulnerability is the ServerIron's management IP address exposes the
ServerIron's rather poor TCP/IP implementation. The nmap rating for sequence
predictability is "0 - trivial joke". Hosts behind the Foundry are NOT
affected by this advisory. An "early" paper on this issue dates back to 1985
(Morris [4]), and is the subject of a five year old CERT advisory [5].
With common IP spoofing/hijacking tools like "hunt", it is possible to craft
an easy DoS; a more determined attacker can use commonly known techniques
[1] to spoof or hijack sessions.
Technical Details
=================
The ServerIron management address exposes telnet and snmp access, and
starting with version 6.0 of the firmware, a web management interface on
port 80. Regardless of the security concerns posed by clear text management
protocols, the management IP stack is poorly implemented. In fact, the
increase in sequence numbering is not RFC compliant ([2],[3]) - even though
the initial RFC [2] has inherently predictable ISN and not a desirable
implementation.
The ISS is incremented by 1 for each connection, and is thus easily
spoofable and hijackable. The predictability exposes sideband information
about when the switch is being used by other (possibly legitimate) users.
The hosts behind the switch are NOT affected by this issue. The faked IP
addresses offer the predictability of the hosted platform (ie Linux 2.2.14
== good luck!, Win9x == trivial joke).
Solutions and Workarounds
Foundry acted quickly after the bugtraq posting, and will be revising all
affected Foundry products in the near future. For Foundry ServerIron owners,
there is a new firmware image, 6.0.03, which fixes a small number of other
bugs which are definitely worth the upgrade. Please see the Foundry support
web site for the release notes and to grab a copy of the new firmware image.
This firmware revision also has support for the new native sshd
implementation add-on. ssh support in a router is an excellent security
feature, and one I hope the other network vendors take careful note of.
Additional security for your core network:
Get the new Foundry ssh implementation and use it. Filter off telnet, http
and SNMP access to the Foundry devices to only those management IP addresses
you trust; or better yet, disable SNMP and the web interface (6.0 firmware),
and completely filter off telnet access. Remote management access is then
only available via serial console (which is hopefully secured from
unauthorized access). Use an unroutable private address on the same wire or
a new interface for all your management traffic and block it on your border
routers. Use Access Rate control to stop DoS-levels of packets to your
management IP addresses. Use TACACS[+]/RADIUS to move authentication to a
trusted host.
Vendor contacted: Yes
Sent first message: 3 Feb 2000
Reply received: 4 Feb 2000
Incident "closed": 8 Feb 2000
Sent offer to add to this advisory: 24 February 2000
Contact re-opened: 1 March 2000
Foundry's upper management contacted me by e-mail and phone and we've had
very productive conversations since the bugtraq posting.
Revision History
================
2000/03/13 - Clarified the vulnerability section
Added the solution, plus new work arounds suggested by
Foundry
Revised Vendor contact section
2000/02/28 - First release
2000/02/22 - initial draft
More Information
================
[1] Information about ISS and ISR sequence prediction
Excellent article by daemon9/route/infinity
http://www.signaltonoise.net/library/ipsp00f.htm
[2] RFC 793: TRANSMISSION CONTROL PROTOCOL
http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/7xx/793
[3] RFC 1948: Defending Against Sequence Number Attacks
http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/19xx/1948
[4] R.T. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software",
CSTR 117, 1985, AT&T Bell Laboratories, Murray Hill, NJ.
[5] A 1995 CERT advisory, cites a 1989 paper by Morris based on his 1985
work
http://www.cert.org/advisories/CA-5.01.IP.spoofing.attacks.and.hijacked.term
inal.connections.html
[6] Information about the hardware concerned:
http://www.foundrynet.com/serverironspec.html
Andrew van der Stock, Security Architect e-Secure Pty Ltd
"Secure in a Networked World" Phone: +61 2 9438 4984 Fax: +61 2
9438 4986
Suite 201, 2-4 Pacific Hwy, Mobile: +61 412 532 963
St. Leonards NSW 2065 Australia http://www.e-Secure.com.au/
ACN 086 248 419
e-mail:[email protected]
