Bedrohung

Hacker-Angriffe

Chronologie eines Angriffs

Von Christian Weber, Mainz

Wenn die Verantwortlichen arglos genug sind, können Systeme über längere Zeit auch Eindringlingen zur Verfügung stehen, die das Prädikat "Hacker" kaum verdienen. Wie der vorliegende Fall untermauert, muss eine Attacke nicht unbedingt mit Zerstörung von Daten, öffentlichkeitswirksamer Übernahme von Webseiten oder sonstigen spektakulären Effekten einhergehen. Machmal wird ein System einfach nur als erweiterte Zwischenablage verwendet, mit allen rechtlichen und technischen Problemen.

Ende 2000, halbzehn in Deutschland: Ein Administrator versucht sich wie jeden Morgen an seinem Rechner anzumelden, ein Linux-System, das als Masquerading Router zwischen Intra- und Internet arbeitet. Nur: Heute hat er keinen Erfolg, der Computer akzeptiert sein Passwort nicht. Auch root und alle anderen Accounts funktionieren nicht mehr. Es ist schlichtweg nicht mehr möglich, sich über die Konsole einzuloggen. Zu diesem Zeitpunkt entschließt man sich, einen externen Sicherheitsexperten hinzuzuziehen, um einen eventuellen Angriff zu analysieren und das System wieder zugänglich zu machen.

Der erste Schritt durch die Helfer war die Wiederherstellung der generellen Zugriffsmöglichkeit. Um eine Anmeldung an der Linux-Maschine zu ermöglichen, musste ein unabhängiges Notsystem von einer Boot-CD gestartet werden. Damit konnte man Zugriff auf die Festplatte erlangen und das root-Passwort deaktivieren. Vor jeglicher weiterer Analyse und Wiederherstellung wurde dann ein Image der Festplatte erzeugt. Dies ist unbedingt zur späteren, detaillierten Untersuchung notwendig. Außerdem kann das Image im Falle rechtlicher Konsequenzen als Beweismittel dienen. Anschließend erfolgte die Trennung der Maschine von beiden Netzen und eine Inbetriebnahme des regulären Betriebssystems von der Festplatte im Standalone-Modus.

Analyse

Nach dem Booten wurden alle laufenden Prozesse auf unerlaubte Manipulationen hin untersucht. Es zeigte sich sehr schnell, dass mit der Anmeldung als root ein ungewöhnlicher Prozess (/bin/bd) gestartet wird. Dieser Prozess etabliert einen Socket auf Port 53550, der Telnet-Verbindungen akzeptiert. Aus Zeitgründen verfolgen die Analysten diesen Weg aber nicht weiter, da man vorrangig klären will, was genau mit der Linux-Maschine passiert ist. Daher wurde lediglich der Start dieses Prozesses deaktiviert und die Maschine erneut gebootet. Es fanden sich keine weiteren illegalen Prozesse mehr.

Als nächsten Schritt nahmen die Experten die Festplatte des Masquerading Routers unter die Lupe, eine 8,7 GB SCSI-Platte mit insgesamt sieben (legalen) Dateisystemen (/, /usr, /var, /home, /var/log, /var/squid, /var/spool/mail). Es gab weder ein Swap-Dateisystem noch eine Swap-Datei und alle Dateisysteme hatten noch ausreichend freie Kapazitäten.

Glücklicherweise waren die Log-Dateien des Systems bis zurück zum November 1999 vorhanden und unverändert, sodass es möglich war, bis zu diesem Zeitpunkt wertvolle Informationen über das System und sein Verhalten zu erlangen – eigentlich ein sehr untypischer Zustand für einen Hacker-Angriff, denn normalerweise werden gerade Systemprotokolle als erste gelöscht oder zumindest manipuliert.

Im Rahmen der ersten Sichtung des Festplatteninhalts wurde unterhalb des Dateisystems /var ein verstecktes und getarntes Verzeichnis namens ".. " (zwei Punkte und drei Leerzeichen) gefunden. Darin befanden sich 69 MB "handelsübliche" Hacker-Tools. Die Vermutung lag nahe, dass dies nicht das einzige Verzeichnis dieser Art ist. Resultat einer eingehenden Untersuchung auf versteckte Dateien und Verzeichnisse waren fünf weitere gefundene Ordner:

Bei einer Gesamtbelegung (Linux-Systemdateien und illegale Dateien) von 3,6 GB entfielen also circa 2,5 GB auf illegitime Nutzung durch den oder die Angreifer. Alle diese Dateien und Dateisysteme wurden nach Abschluss der Untersuchung gelöscht und das System erneut gestartet. Nachdem der Speicherplatzmissbrauch offengelegt war, wurden im nächsten Schritt Systemdateien untersucht um herauszufinden, ob diese manipuliert oder – wie bei den meisten Hackerangriffen üblich – sogar teilweise ersetzt wurden.

Untersuchung des Login-Programms

Wie die Log-Files verrieten, wurde bereits am 5. Juli 2000 das Programm /bin/login durch eine manipulierte Variante ersetzt. Es lässt sich allerdings nicht mehr mit Sicherheit klären, ob es zum erstenmal oder bereits zum wiederholten Male ausgetauscht worden war, da die korrespondierenden Meldungen im messages-Log fehlen ("pam_unix session finished").

Am 10. Juli 2000 um 0:15 Uhr wurde /bin/login durch einen Fehler des Angreifers gelöscht, aber kurz darauf wieder nach /bin kopiert. Interessanterweise gab es an demselben Tag gegen 19:46 Uhr zwei Versuche, sich an den Account "rew" anzumelden. Da "rew" die englische Verballhornung von "root" darstellt, ist davon auszugehen, dass es sich bei dem zweiten Angreifer um jemanden handelt, der wahrscheinlich noch nie mit einem UNIX-System gearbeitet hat, aber mit dem ersten Angreifer in Kontakt steht.

Im Rahmen der weiteren Untersuchung fanden sich noch einige identische Kopien der gefälschten Datei login an teilweise sehr ungewöhnlichen Plätzen:

Alle diese login-Dateien sind exakt 281 720 Byte groß und statisch gelinkt.

hingegen ist nur 25 000 Bytes groß und dynamisch gelinkt (PAM-bibliotheksabhängig). Bei dieser Variante handelt es sich vermutlich um die Originalversion des Systems. Weitere Änderungen an System- oder sicherheitsrelevanten Dateien konnten nicht gefunden werden.

Zeitpunkt des ersten Eindringens

Nach der ersten groben Untersuchung, bei der es im Wesentlichen darum ging, das System so schnell wie möglich wieder verfügbar zu machen, war man noch davon ausgegangen, dass die ersten Spuren des Einbruchs von Ende August 2000 waren. Nach der zweiten gründlicheren und sehr zeitaufwändigen Analyse aller Log-Dateien und der Rekonstruktion des zeitlichen Ablaufs stellte sich die Sachlage anders dar: Die älteste Datei in den getarnten Verzeichnissen, die nicht aus entpackten Archiven stammt und somit vermutlich das echte Datum des ersten Einbruchs widerspiegelt, trägt als Datum bereits den 23. Juli 1999 ("/var/.. /logold").

Bemerkenswert ist der zeitliche Zusammenhang mit Änderungen am Web-Server, der ebenfalls auf dieser Maschine lief. Hinzu kommt, dass am 23. Juli 1999 das Programm /sbin/fcii installiert wurde, dass sich selbst als "FireCracker II" identifiziert. Dieses Programm wurde aller Wahrscheinlichkeit nach lokal über die Konsole installiert.

Angriffsverlauf

Der User-Password-Dämon (upd) wurde am 23. Juli 1999 erstellt. Es gab danach über eine lange Zeit nur geringe Aktivitäten, bis dann beginnend am 5. Juli 2000 in verstärktem Maße Telnet- und FTP-Zugriffe eingingen.

Am 5. Juli 2000 um 22:34 Uhr meldete sich "root" ohne jeglichen Fehlversuch per Telnet von einer IP-Adresse eines italienischen Dial-In-Providers an; dem Angreifer war das Passwort also bekannt. Zwischen Dezember 1999 und Juni 2000 hatten die Protokolldateien insgesamt "nur" acht Anmeldungen über Telnet von ungeklärten IP-Adressen registriert. Im Zeitraum Juli 2000 bis Dezember 2000 hat sich die Zahl der Anmeldungen allerdings drastisch erhöht: Insgesamt 439 Logins waren protokolliert – ähnlich sieht es bei FTP-Zugriffen aus.

Am 22. August 2000 wurde dann für nahezu alle Benutzer "jpoppassclient" als shell eingestellt. Ein Benutzer "Warhead", der am 10.7. eingerichtet worden war, wurde am 22.8. wieder gelöscht. Außerdem wurde ein zusätzlicher Benutzer neu eingerichtet und am 24.8. zur Dateiablage gebraucht. Schon am 23.08. gab es eine Telnet-Anmeldung von einem italienischen Rechner ohne DNS-Eintrag und ab diesem Zeitpunkt Telnet-Logins und FTP-Übertragungen en masse.

Die Angreifer haben überdies reichlich Port-Scans durchgeführt, die scanlogd registriert hat. Ein kleiner Auszug:

11.07.2000 00:08 von [IP-Adresse]
gleichzeitig telnet-Login von [IP-Adresse]
07.11.2000 22:07 von [IP-Adresse]
gleichzeitig popper
gleichzeitig named-Abfragen
10.11.2000 22:45 von [IP-Adresse]
kurz vorher telnet und ftp von [IP-Adresse]
27.11.2000 17:55 von [IP-Adresse]
29.11.2000 14:52 von [IP-Adresse]
Weitere Gefahren

Zu allem Überfluss wurden auch Rechner im LAN gekapert: Von dort aus gibt es auffällige Aktivitäten um den 5. Juni 2000 herum, taggleich mit FTP-Aktivitäten aus dem Internet. Über entsprechende Einträge in Log-Dateien war zu erkennen, dass verschiedene Programme (Trojaner und Passwortspione) liefen, die Passwörter ausspähen. Außerdem ist es sehr wahrscheinlich, dass vom betroffenen System aus weitere Rechner im Internet in Mitleidenschaft gezogen und selbst zu Angreifern im Sinne einer "distributed attack" gemacht wurden. Um dies abschließend zu klären, wäre es notwendig die Log-Datei "tcp.log" auszuwerten und die dort verzeichneten Rechner einzeln zu untersuchen, was aber im Rahmen des Auftrags an die hinzugezogenen Experten nicht mehr bewerkstelligt werden konnte.

Insgesamt sind solche Szenarien nicht unüblich. Wenn ein Hacker Zugang zu einem Rechner im Netzwerk hat, wird er in aller Regel auch versuchen, mittels geeigneter Programme oder Agenten innerhalb des LAN Maschinen auszuspionieren oder aus dem gekaperten Netzwerk heraus andere Netze zu attackieren. Genau diese Verschleierungstaktik macht es häufig sehr aufwändig herauszufinden, wer von wo aus in ein System eingedrungen ist.

Konsequenzen

Die Analyse des Vorfalles zeigte deutlich, dass viele Benutzer-Passwörter zu simpel waren. So ließ sich das root-Passwort innerhalb von nur einer Stunde mittels einer Brute-Force-Attacke knacken. Insgesamt war es den Angreifern vermutlich möglich, elf Benutzerpasswörter innerhalb einer Nacht zu ermitteln.

Um für die Zukunft das Eindringen von ungeliebten Besuchern zu unterbinden, wurde LinuxWall als Firewallsystem auf Basis von Linux Kernel 2.4 installiert. Auch später wurde noch verschiedentlich versucht, per Telnet Zugriff auf das System zu erlangen, zuletzt am 11.1.2001 um 8:24 Uhr über den bereits bekannten italienischen Provider. Ebenso wurde vereinzelt versucht, per FTP Verbindungen herzustellen. Anders als bei der vorigen Firewall konnten die Angreifer aber keinerlei Zugriff erlangen.

Alle anderen späteren Angriffsversuche beschränkten sich auf das übliche Maß, das man bei Standleitungen ins Internet heute zu erwarten hat. Was sich belanglos anhören mag, handelt sich aber ohne Weiteres um fünfzig bis weit über hundert Versuche pro Tag, die die Protokolldateien "zumüllen". Da die Domäne des Betroffenen bislang durch einen nicht zuverlässig funktionierenden Nameserver verwaltet wird, waren erstaunlicherweise keine Ping-Broadcasts (smurf-Attacken) zu verzeichnen. Es steht aber zu vermuten, dass mit dem Einsatz eines zuverlässigen Nameservers auch diese Angriffe zunehmen werden.

Wer wars?

Die Frage nach dem Täter lässt sich mit den vorhandenen Informationen leider nicht abschließend beantworten. Auffällig ist der zeitliche Zusammenhang von vor Ort durchgeführten Systemarbeiten und den ersten illegalen Aktivitäten. Daraus lässt sich aber nicht sicher folgern, dass das System aktiv unterminiert worden ist – das root-Login könnte auch lediglich den Prozess "/bin/bd" und weitere Aktionen getriggert haben. Eine Durchforstung der Mail-Logs (etwa auf Übermittlung des Passworts als Mail) führte jedenfalls zu keinem Ergebnis. Auch die eindeutige Identifizierung eines Remote-Rechners kann noch nicht die Person enttarnen, die tatsächlich den Angriff durchführt, da ja auch dieser Rechner wieder gekapert sein könnte.

Als Profil ergibt sich: Die gesuchte Person spricht vermutlich italienisch, war oder ist möglicherweise bei einem Lieferanten angestellt (wegen der Installation /sbin/fcii am 23.7.1999) und versteht etwas von Angriffen auf Unix-Systeme – zumindest so weit, dass sie vorhandene Hacker-Programme installieren und tarnen kann. Der Angreifer hat mindestens einen Bekannten, der nichts von Unix-Systemen (Anmeldungsversuch als "rew") versteht und einen Flatrate-Zugang über einen italienischen Provider hat.

Fazit

Im Rahmen des hier geschilderten erfolgreichen Angriffs auf ein argloses Unternehmen, zeigen sich eine Anzahl häufig begangener Fehler: In aller Regel sind dies im Nachhinein als trivial klassifizierte Probleme wie zu schwache Passwörter, fehlende regelmäßige Inspektion der Log-Dateien, kein aktueller Stand der Security Releases des jeweiligen Betriebssystems, mangelnde Abschottung des LANs gegenüber dem Internet usw.

Alle wiedergegebenen Daten sind aus Kundenschutzgründen anonymisiert. Bedauerlicherweise lassen sich hierdurch auch einige Seiteneffekte des Angriffs nicht vollständig darstellen, da diese Rückschlüsse auf das betroffene Unternehmen zugelassen hätten. Im Wesentlichen zeigt der Vorfall jedoch wieder einmal deutlich, wie selbst wenig begabte Angreifer ein System für ihre unheiligen Zwecke missbrauchen können. Außerdem macht der Vorfall leider auch klar, wie unbedarft manche Administratoren mit ihren Systemen umgehen und wie wenig Schutzmechanismen mancherorts eingesetzt werden. Letztendlich fiel dieser über mehrere Monate fortdauernde Angriff nur deshalb auf, weil die Eindringlinge versehentlich den Systemadministrator aus dem System ausgesperrt hatten.

Dipl.-Ing. Christian Weber ist Sicherheitsberater in Mainz.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 3/2001, Seite 64