[UNIX] Alteon ACEdirector Signature/Security Bug

From: support@securiteam.com
Date: 01/29/02

From: support@securiteam.com
To: list@securiteam.com
Date: Tue, 29 Jan 2002 22:41:50 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Alteon ACEdirector Signature/Security Bug


A new security bug has been discovered in the Nortel Alteon ACEdirector
product. In some circumstances, this bug raises a security issue since
HTTP clients could exploit it to determine the IP addresses of ostensibly
"hidden" web servers that are load-balanced by the ACEdirector. In more
circumstances, this bug also enables someone to determine whether a given
Internet web service utilizes ACEdirector equipment by remotely probing
that service's IP address.


The <http://www.nortelnetworks.com/products/01/acedir/> Nortel/Alteon
ACEdirector product has a feature called "Server Load Balancing" (SLB).
This feature can be used to load balance incoming HTTP requests made to
one virtual IP (VIP) address amongst the real IP (rip) addresses of
multiple HTTP servers. When enabling an additional feature called
"Cookie-Based Persistence", the ACEdirector observes the value of a
specific HTTP cookie (when it is present in client request packets) and
uses it to persistently map a series of HTTP client requests to the same
one of the real HTTP servers amongst which it is load balancing. This
results in the benefit of the same client to be directed to the same
server as long as the client keeps supplying the same cookie value. This
persistence is advantageous and sometimes necessary for particular
web-based applications that cache client session information on the web

While running Alteon WebOS 9.0 software, a couple of problems have been
identified when an ACEdirector is performing server load balancing with
cookie-based persistence enabled. (An example of such a configuration is
included below.) These problems are:

1) The ACEdirector mishandles TCP streams from HTTP clients that make use
of the TCP `half-close' feature. This errant behavior could be used as a
signature to identify ACEdirector equipment on the Internet. It is
possible for an HTTP client to craft an HTTP request which will elicit
erroneous behavior: either (a) the HTTP session will terminate with no
information being returned to client or (b) the client's session will
block indefinitely.

Current versions of commercial browsers such as Netscape and Internet
Explorer do not appear to utilize TCP's half-close feature, so users of
these applications are unlikely to experience the direct effects of this
problem. However, if elicited by an unusual web client application such as
'nc' ("netcat"), a web "spider", or a custom perl script, this erroneous
behavior essentially discloses to the client that the web service may be
load-balanced by the ACEdirector product. See the perl script below, named
"acedirector_request", for an example of how to elicit this erroneous

2) Furthermore, by crafting and sending a peculiar HTTP request to the
ACEdirector's virtual IP address (VIP), it is sometimes possible for an
HTTP client to discover the real IP address(es) of the "hidden" HTTP
server(s). During experimentation, it has been observed that it is
possible to cause the ACEdirector to erroneously forwards packets back to
that client directly from those "hidden" HTTP server(s). (Normally, in a
configuration such as that shown below, the ACEdirector would rewrite the
source IP address and port number of the packet before forwarding it back
to the HTTP client, thereby keeping the HTTP server(s) real identity

This is a potential security issue since one can theoretically determine
the IP addresses of the hidden servers that are part of a load-balanced
system, possibly opening them up to direct attack from malicious parties
unless additional firewalling policies are employed. The
"acedirector_request" perl script below, when invoked with the "-c"
(cookie) option is one example of how to elicit the erroneous behavior
described. If an appropriate cookie name or name prefix is specified for
the web service in question (e.g. often "ASPSESSIONID" for Microsoft web
server applications) the client running this script will often receive a
portion of the HTTP response as unexpected packets from one of the HTTP
servers real IP addresses. The client host's TCP implementation will
usually respond with a TCP RST (ReSeT) packet to each of these unexpected
packets because these packets headers contain a source IP address and TCP
port numbers that were previously known only to the Alteon ACEdirector.

To put it another way, the ACEdirector will sometimes "leak" packets from
a hidden web server's real IP address to a client which had previously
established a connection to the ACEdirector's virtual IP address but has
since been "half-closed" by the client. Presumably, this leak occurs
because the ACEdirector erroneously flushes an HTTP connection's state
information nearly immediately after the half-close occurs, disrupting the
web servers session. After it has "forgotten" that session, it
subsequently behaves as a normal Ethernet switch by simply forwarding
subsequent packets to the client without rewriting the IP address and port
number of the packet headers.

No solution has been determined at this time. This problem was reported to
Nortel and has been documented as Nortel Networks Case Number 011211-76677
which was opened December 11, 2001.

As of January 25, 2002, Nortel's online tracking system shows that the
case has been closed with these notes:

This is not considered a high priority bug, as most browsers that would be
affected by half open connection states do not send cookie requests in
this manner [...]

Not Applicable to any real world scenario.

When using the ACEdirector in the configuration described, it is
insufficient to merely configure server load balancing on an ACEdirector
to safely hide the identity of the HTTP servers from the clients.

If you don't wish HTTP clients to be able to discover the real IP
addresses of the "hidden" HTTP servers (so that they could attempt to
interact with those servers directly), one workaround is to introduce a
firewall between the clients and the ACEdirector which prevents HTTP
clients from sending or receiving packets directly to or from the IP
addresses of the real HTTP servers.

Example configuration (Recreation):
The following is a sample of the portions of the ACEdirector configuration
that are relevant to the problems described above:

# Enable Server Load Balancing:


# Define one or more "real" servers:

   /c/slb/real 20
   /c/slb/real 21

# Define a group of "real" servers:

   /c/slb/group 20
           metric roundrobin
           health http
           add 20
           add 21

# Define a "virtual" server:

   /c/slb/virt 20

# Configure the virtual server so that it will load balance the HTTP
# service, and enable cookie-based persistence:

   /c/slb/virt 20/service http
           group 20
           dbind ena
   /c/slb/virt 20/service 80/pbind cookie passive ASPSESSIONID* 1 24
   /c/slb/virt 20/service 80/rcount 10

When used on a "real" web server, should return the results of a "GET /".

When used on an ACEdirector, it will report:
   web_server did not response to TCP half-closed request.
   It might be an ACEdirector.

If you use the "-c COOKIE" option it will report "leaked" packets, e.g.
"-c ASPSESSIONID" for an ACEdirector configured as shown above. This
method by which this script shows leaked packets is a total kludge in that
it launches tcpdump(1). At that time, hit CTRL-C to break out of it after
a reasonable amount of time. (If one wanted to automate this exploit,
using Net::RawIP with a timeout might be preferable.)

#! /usr/local/bin/perl

# acedirector_request - trivial script to do an HTTP Simple-Request of "/"
# utilizing TCP half-close.
# This script was written to demonstrate how one can
# elicit erroneous behavior from an Alteon/Nortel
# ACEdirector which has been configured to use its
# "Server Load Balancing" (SLB) and "Cookie-Based
# Persistence" features.
# Dave Plonka <plonka@doit.wisc.edu>, Dec 20 2001

use IO::Socket;
use FindBin;
use Getopt::Std;

if (!getopts('c:') or '' eq $ARGV[0]) {
   die "usage: $FindBin::Script [-c COOKIE] web_server\n"

my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
                                 PeerPort => 'http(80)',
         Proto => 'tcp');
die unless ref($sock);

if (!$opt_c) {
   print $sock "GET /\r\n";
} else {
   print $sock "GET / HTTP/1.0\r\nCookie: ${opt_c}=X\r\n\r\n";


@response = <$sock>;

if (@response) {
   print join("\n", @response)
} else {
   if ($opt_c) {
      my $command = "tcpdump -nv tcp and port 80 and not host $ARGV[0]";
      warn "$ARGV[0] did not respond to TCP half-closed request.\n" .
           " Launching tcpdump to watch for RST...\n";
      system($command . " 2>&1");
      if (0 != ($?/256)) {
         warn "\"$command\" failed.\n"
   } else {
      warn "$ARGV[0] did not response to TCP half-closed request.\n" .
     "It might be an ACEdirector.\n"



The information has been provided by <mailto:plonka@doit.wisc.edu> Dave


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.