Sicherheit kann trügerisch sein. Das zeigt der Bericht einer auf Sicherheit spezialisierten Firma über einen Cracker-Angriff auf den Internet-Router eines Kunden. Aus Gründen der Vertraulichkeit sind sensible Informationen im Text anonymisiert.

Ende letzten Jahres wurde unsere Firma beauftragt festzustellen, ob bei einem Kunden ein Cracker-Angriff unternommen wurde. Potenzielles Ziel war ein Linux-Rechner, der als Masquerading-Rechner zwischen internem Netz und Internet fungierte und auf dessen Konsole keine Anmeldung mehr möglich war.

Der Rechner wurde von uns ausgeschaltet und mit einem unabhängigen Notsystem mittels Boot-CD wieder in Betrieb genommen, damit der Zugriff auf die SCSI-Platte des Rechners möglich wurde. Das Passwort wurde inaktiviert, dann der Rechner in dieser Konfiguration wieder in Betrieb genommen, jedoch ohne Internet- oder LAN-Verbindung.

Untersuchung am laufenden System

Im Betrieb konnten wir feststellen, dass mit der Anmeldung als Benutzer Root der Prozess /bin/bd gestartet wurde, der einen Socket auf Port 53550 öffnet. Der Prozessname selbst wurde im Prozessstatus verharmlosend als ps /bd getarnt. Der Name ist vermutlich die Abkürzung für Back Door, also eine Hintertür ins System. Die Verbindung mit diesem Socket gelang mittels telnet localhost 53550, wurde jedoch nicht weiter untersucht. Es ist derzeit noch nicht genau geklärt, was dieser Prozess macht. Um das System vorerst zu sichern, wurde der Start des Prozesses beim Einloggen verhindert.

Untersuchung der Platte

Die eingebaute SCSI-U2W-Platte enthält 8.925.000 1-KByte-Blöcke mit einer Gesamtkapazität von 8,7 GByte. Es gibt sieben Dateisysteme, nämlich /, /usr, /var, /home, /var/log, /var/squid, /var/spool/mail, die alle noch freien Platz haben. Es gibt kein Swap-Dateisystem oder wenigstens eine Swap-Datei. Die Logdateien des Systems sind von November 1999 an vorhanden, so dass von diesem Zeitpunkt an wertvolle Informationen vorlagen.

Bei der ersten Untersuchung Ende letzten Jahres wurde unter /var ein verstecktes und getarntes Verzeichnis namens ” ..   ” (zwei Punkt und drei Leerzeichen als Verzeichnisname) gefunden, in dem einige bekannte Cracker-Programme waren. Eingehendere Untersucheungen erbrachten, dass es insgesamt sechs getarnte Verzeichnisse gab: das bereits erwähnte “/var/..   “ mit 71.006 Blöcken (Hacker-Tools), “/home/[Benutzer1]/..  “ mit 65323 Blöcken (Real-Media-Dateien), /home/[Benutzer1]/.sco mit zusammen 1.624.441 Blöcken (also fast 1,6 GByte!), “/home/[Benutzer2]/..   “ ein leeres Verzeichnis, “/home/[Benutzer2]/.z” mit zwei MP3- und MPEG-Dateien und insgesamt 35.264 Blöcken, und “/tmp/.  “. Dieses letzte Verzeichnis enthielt eine illustre Sammlung von Hacker- Tools, unter anderem einem Back-Orifice-Client, Passwort-Cracker, Passwort-Lauscher und weitere interessante Programme sowie CD-Abzügen von Windows ME und Windows ME OEM.

Zusammen waren es 872.983 Blöcke. Bei 3,6 GByte benutztem Plattenplatz wurden also etwa 2,5 GByte für Hacker-Zwecke verwendet.

Login-Programm

Das Programm /bin/login wurde an einem Tag Mitte 2000 ausgetauscht, die pam_unix session finished-Meldungen fehlen in /var/log/messages. Fünf Tage später um 0:15 Uhr wurde /bin/login gelöscht, aber später erneut hergestellt. Man kann davon ausgehen, dass der Angreifer selbst das Programm versehentlich löschte.

Bemerkenswert dabei ist noch, dass am selben Tag um 19:46 Uhr ein zweimaliger Anmeldungsversuch als rew stattfand (englische Verballhornung von root). Es handelt sich also um einen zweiten Angreifer, der noch niemals mit einem Unix-System gearbeitet und Kontakt zum ersten Angreifer hat.

Es gibt verschiedene identische Fälschungen des login-Programms, die an zum Teil ungewöhnlichen Plätzen stehen: /dev/login, /bin/login, /bin/ login.DoNotUSe, /var/.. /bin/bin/ login, /var/.. /logold (281.720 Bytes, statisch gelinkt). /tmp/login (25.000 Byte, dynamisch gelinkt, PAM-Bibliotheks-abhängig) ist vermutlich das Original.

Zeitpunkt des ersten Eindringens

Waren wir bei den ersten Untersuchungen noch der Meinung, die ersten Spuren des Einbruchs seien im Hochsommer 2000 zu entstanden, stellt sich die Sachlage nunmehr anders dar: Die älteste Datei in den getarnten Verzeichnissen, die nicht aus entpackten Archiven stammt und somit vermutlich das echte Datum des ersten Einbruchs trägt, ist vom Frühsommer 1999 ( /var/.. /logold).

Am selben Tag wurde noch ein Programm /sbin/fcii installiert, das sich selbst als FireCracker II identifiziert, geschrieben von einem Studenten an der Uni Tübingen. Der Zweck dieses Programms scheint es zu sein, Kopien bestimmter IP-Pakete durch die Firewall an eine auswärtige Adresse weiterzuleiten.

Der User-Password-Daemon (siehe Kasten “Upd”) wurde im Hochsommer 1999 erstellt. Es gab eine lange Zeit nur geringe Aktivitäten, bis ab Mitte 2000 und von nun an in verstärktem Maß Telnet- und FTP-Zugriffe zu verzeichnen waren.

An einem Tag Mitte 2000 um 22:34 Uhr meldet sich über Telnet vom Rechner eines Dial-in-Providers aus dem südeuropäischen Raum der Benutzer root an, ohne einen Fehlversuch, also mit exaktem Wissen des Passworts. Waren es zwischen Jahresende 1999 und Mitte 2000 insgesamt acht Anmeldungen über Telnet, die von ungeklärten Internet-Adressen kamen, so gab es zwischen Mitte 2000 und Jahresende 2000 insgesamt 439 Anmeldungen, wobei die meiste Aktivität ab dem Hochsommer stattfand. Ähnlich sieht es bei den FTP-Zugriffen aus.

(1) Frühsommer 2000 00:08 Uhr
 gleichzeitig (!) telnet-Login
(2) Herbst 2000 22:07 Uhr
 gleichzeitig popper (POP3-Client)
 gleichzeitig named-Abfragen (DNS)
(3) drei Tage später 22:45 Uhr
 kurz vorher telnet- und FTP-Logins
(4) 16 Tage später 17:55 Uhr
(5) zwei Tage später 14:52 Uhr

Der Benutzer2 ist besonders interessant: Erst wurde dieser Benutzer neu eingerichtet, zwei Tage später ist er als Dateiablage missbraucht worden. Einen Tag davor gab es eine Telnet-Anmeldung von einem Rechner ohne DNS-Eintrag – und ab da Telnet-Logins und FTP-Übertragungen zuhauf.

Einige Auffälligkeiten

Der Benutzer Warhead wurde Mitte 2000 eingerichtet und 42 Tage später wieder gelöscht. Das geschah um halb drei Uhr nachts per FTP über einen Universitäts-Rechner in den neuen Bundesländern.

Am selben Tag, um 01:58 Uhr: Mehrmaliger FTP-Aufruf, danach wurde upd gleichzeitig von zwei verschiedenen IP-Adressen aus gestartet. Und das innerhalb von Sekunden. Die beiden müssen also entweder identisch sein oder sich miteinander abgestimmt haben.

Die erste IP-Adresse ist im DNS auflösbar, die andere Adresse stammt wieder aus dem bereits bekannten Class-B-Netz in Südeuropa.

Weitere Gefahren

Es ist durchaus möglich, dass ein LAN-Rechner gekapert wurde. Von dort gibt es auffällige Aktivitäten um den Frühling 2000 herum, taggleich mit FTP-Aktivitäten aus dem Internet. Auch bei einem zweiten LAN-Rechner besteht die Möglichkeit, dass er von dem Angreifer übernommen wurde.

Da verschiedene Programme auf dem Rechner liefen, die das Ausspähen von Passwörtern ermöglichen und entsprechende Logs gefunden wurden, ist es ebenfalls nicht ganz unwahrscheinlich, dass weitere Rechner im LAN und auch im Internet in Mitleidenschaft gezogen wurden. Sie dienen jetzt selbst vielleicht als Sprungstellen für weitere Angriffe. Hier müssen die Logdatei tcp.log ausgewertet und die dort verzeichneten Rechner einzeln durchgecheckt werden.

Viele Benutzer-Passwörter waren zu einfach. Das Root-Passwort wurde innerhalb von einer Stunde mit einer Brute-Force-Attacke gefunden, insgesamt elf Benutzerpasswörter konnten innerhalb einer Nacht erkannt werden.

Im Mail-System waren keine Auffälligkeiten zu erkennen, Sendmail verhinderte zuverlässig den Missbrauch als Mail-Relay.

Angriffe auf Linux Wall

Ein Angreifer versuchte gelegentlich, sich per Telnet auf der neu installierten Linux Wall anzumelden. Zuletzt passierte das Anfang 2001, von dem bereits bekannten südeuropäischen Provider aus. Ebenso wurde vereinzelt versucht, per FTP eine Verbindung herzustellen.

Alle anderen Angriffe beschränken sich auf das übliche Maß bei Kunden mit Festverbindungen, wobei erstaunlicherweise Ping-Broadcasts (Smurf-Attacken) bis jetzt nicht vorkamen. Da die Domäne bis jetzt durch einen nicht immer funktionierenden Nameserver verwaltet wird, werden die Angriffe vermutlich zunehmen, wenn der Server zuverlässig läuft. Einige Internet-Rechner scheinen Nameserver-Einträge für die alte Firewall zu haben, sie stellen nach wie vor DNS-Anfragen.

Wer war’s?

Eine genaue Antwort auf diese Frage ist mit den vorhandenen Informationen zur Zeit nicht möglich.

Auffällig ist das zeitliche Zusammentreffen von Systemarbeiten und illegalen Aktivitäten. Daraus lässt sich aber nicht schließen, dass jedes Mal aktiv das System unterminiert worden wäre. Es könnten durch das Root-Login der Prozess /bin/bd und weitere Aktionen gestartet worden sein. Auch die Kompromittierung durch einen anderen Rechner (siehe Kasten “Upd”) ist möglich. Das Durchforsten des Mail-Logs (etwa auf Übermittlung des Passworts als Mail) führte zu keinem Ergebnis. Auch die eindeutige Identifizierung eines Rechners kann noch nicht die Person enttarnen, die tatsächlich angreift, der Rechner könnte auch gekapert sein.

Die Person, die gesucht wird, versteht von Angriffen auf Unix-Systeme zumindest so viel, dass sie die vorhandenen Hacker-Programme installieren und tarnen konnte. Die Person hat mindestens einen Bekannten, der nichts von Unix-Systemen versteht und einen Flatrate-Zugang über einen südeuropäischen Provider hat.

Die Chance, diesen Angreifer dingfest zu machen, steht schlecht. Selbst wenn Ermittlungen ergeben, dass bestimmte Rechner in Einbrüche einbezogen waren, muss immer noch die Beziehung zwischen Rechner und Benutzer hergestellt werden. Solange sich dieser Angreifer nicht selbst belastet, ist die Beweiskette lückenhaft.

Die Moral

In der Rückschau muss man sich wundern, dass nicht mehr passiert ist. Das kann darauf zurückzuführen sein, dass diese Domain nicht in Suchmaschinen eingetragen und nur Insidern bekannt ist. Auch nach Installation der Linux Wall sind Angriffe relativ selten und rangieren eher unter Fehlkonfigurationen. Der Erfahrungswert des Autors liegt bei durchschnittlich zwei Angriffen pro Tag und Kunde, hier kommt auf zwei Tage nur ein Angriff. Nicht jeder Zugriff den SMB-Port muss gleich eine Attacke sein.

Der Masquerading Router war ohne jeden Paketfilterschutz, von Firewalling-Funktion ganz zu schweigen. Kritische Dienste wie Telnet oder FTP waren aktiviert, ebenso wie NFS und SMB. Ganz offensichtlich war das Problembewusstsein bei allen Beteiligten stark unterentwickelt, Schutz besteht eben nicht nur aus der Installation eines Virenscanners auf den Workstations. Hoffen wir, dass andere Firmen aus diesem Bericht lernen. ( tfr)n