Einführung
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:
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: /* ---------------------------------------------------------------------
#include <stdio.h>
char *chassis;
void connect_to_chassis(char *name)
host = gethostbyname(name); if(!host) {
sockfd = socket(AF_INET, SOCK_STREAM, 0); if(sockfd < 0) {
remote.sin_family = AF_INET;
connect(sockfd, (struct sockaddr *)&remote, sizeof(remote)); return;
void send_iacs()
for(k = 0; k < num_of_tries;
k++) {
int main(int ac, char **av)
if(ac < 3) {
chassis = av[1];
fprintf(stderr, "Beginning
attack on chassis %s [%d packets]\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:
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
sub GenMAC
$a = new Net::RawIP; die "usage: $0 [options]\
# set default values
# choose network card
# Loop
|