Make your own free website on Tripod.com


vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


18

Unix - die große Herausforderung

Ein Unix-Netzwerk zu sichern, ist sogar für erfahrene Anwender eine furchteinflößende Aufgabe. Seltsamerweise sind heutzutage sogar nicht mit Unix vertraute Anwender bereit, dies zu versuchen.

18.1 Sicherheit von Anfang an

Sicherheit beginnt bei der Installation, also werden wir auch mit dieser beginnen und uns dann weiter vorarbeiten. Dieser erste Abschnitt behandelt folgende Themen:

18.2 Die physikalische Sicherheit

Ihr Unix-Rechner ist immer nur so sicher wie sein Standort. Deshalb sollten Sie ihn vor böswilligen Anwendern abschirmen. In RFC 1244 steht folgendes:

Eine grundlegende Tatsache bei der Computersicherheit ist, daß, wenn der Rechner selbst nicht physikalisch sicher ist, das ganze System nicht mehr als sicher angesehen werden kann. Ein Nutzer mit physikalischem Zugang zum Rechner kann ihn anhalten, ihn im privilegierten Modus wieder hochfahren, die Festplatte austauschen oder verändern, Trojanische Pferde einschleusen oder eine Vielzahl anderer unerwünschter (und schwer zu verhindernder) Aktionen durchführen. Kritische Datenübertragungsverbindungen, wichtige Server und andere wichtige Rechner müssen an physikalisch sicheren Standorten stehen.

Ihr Rechner sollte so wenig wie möglich dem Kontakt mit nicht vertrauenswürdigem Personal ausgesetzt sein. Wenn das nicht machbar ist (und der Rechner in feindlichem Gebiet stehen muß), sollten Sie eines der Produkte in Tabelle 18.1 einsetzen.

Tabelle 18.1: Produkte zur Erhöhung der physikalischen Sicherheit

Produkt

Beschreibung und Adresse

DOMUS ITSS

DOMUS ITSS ist kein Produkt, sondern ein Beratungsdienst. DOMUS berät (besonders Behörden und Unternehmen) bei der Installation und Konfiguration von biometrischen Authentifizierungsgeräten. http://www.domus.com/itss/bio-adv-card.html

IrisScan

IrisScan ist ein biometrisches Authentifizierungssystem für Netzwerke, das bis zu 256 Workstations pro LAN-Abschnitt unterstützt. Anwender werden durch das einmalige Muster ihrer Iris identifiziert. http://www.iriscan.com/

PC Guardian

PC-Guardian-Produkte umfassen Diskettenschlösser und physikalische Zugriffskontrollgeräte für IBM-kompatible Rechner. Wenn Sie einen Linux-, SCO-, SolarisX86- oder Xenix-Rechner haben, sehen Sie hier nach: http://www.pcguardian.com/

Barracuda Security

Physikalische Sicherheitsvorkehrungen für IBM-Kompatible (wie z.B. automatische Pager, die Sie warnen, wenn ein unbefugter Zugriff erfolgt ist). http://www.barracudasecurity.com/

PHAZER

Entwickelt von Computer Security Products, Inc., ist PHAZER ein Glasfaser-Device, das physikalische Eingriffe erkennt. (Dann wird ein Alarm ausgelöst.) PHAZER ist gut zur Sicherung von Universitätsrechenzentren oder anderen großen Netzwerken geeignet. http://www.computersecurity.com/fiber/index.html

Wenn Sie noch keine Richtlinien für physikalische Sicherheit haben, sollten Sie welche aufstellen. Lesen Sie außerdem einige der folgenden Veröffentlichungen:

18.3 Konsolensicherheit

Die Konsolensicherheit ist ein weiteres wichtiges Thema. Zwei Dinge sind besonders bedenklich:

Wir wollen beide kurz besprechen.

18.3.1 Konsolenpaßwörter

Konsolenpaßwörter sind an Unix-Workstations üblich. Je nach Ihrer Architektur kann ein Eindringling diese Paßwörter verwenden, um unterschiedliche Ziele zu erreichen.

Bei der X86-Architektur sollten Sie das BIOS-Paßwort aktivieren. Wenn Sie dies nicht tun, können lokale Eindringlinge Denial-of-Service-Attacken ausüben oder sogar Daten zerstören. Viele BIOS-Systeme beinhalten heute Programme zur Formatierung oder Oberflächenanalyse von Festplatten, die alle Daten auf der Festplatte vernichten können. Außerdem bieten die meisten modernen BIOS-Systeme Zugriff auf serielle und parallele Schnittstellen oder andere Hardware, die zum Export oder Import von Informationen verwendet werden kann. Und wenn Sie SCSI-Geräte benutzen, werden Sie Eindringlinge daran hindern wollen, auf die SCSI-Utilities zuzugreifen. Viele dieser Utilities werden beim Booten oder beim Ansprechen des SCSI-Adapters geladen. Ein gutes Beispiel dafür sind die Adaptec-Produkte: Die SCSI-Adapter-Software ermöglicht es Eindringlingen, neue Festplatten hinzuzufügen, vorhandene zu formatieren und so weiter.

Unix-Workstations haben ähnliche Probleme. Sie sollten das PROM-Paßwort (und Konsolenpaßwort) sofort bei der Installation aktivieren. Dieses Paßwort kann Eindringlingen je nach Architektur unterschiedliche Dinge ermöglichen. Viele Systeme unterstützen Einzelplatzmodi. Bestimmte DEC-Stationen (besonders 3100) ermöglichen Ihnen, Ihre Boot- Optionen zu bestimmen:

Wenn eine DEC-Workstation ausgeliefert wird, läuft das Konsolensystem zuerst im privilegierten Befehlsmodus. Wenn Sie keine Änderungen vornehmen, gibt es keine Einschränkungen für Konsolenbefehle. Jeder, der physikalisch auf die Konsole zugreifen kann, kann beliebige Konsolenbefehle ausführen, wobei das interaktive Booten am gefährlichsten ist.

Wegweiser:

Der obige Absatz stammt aus CIAC-2303, The Console Password for DEC Workstations, von Allan L. Van Lehn. Sie finden dieses ausgezeichnete Dokument unter http://ciac.llnl.gov/ciac/documents/.

Eindringlinge können das interaktive Booten nutzen, um privilegierten Zugang zu erhalten und Daten zu zerstören oder Ihr System herunterzufahren.

Hinweis:

Einige Workstations haben auch physikalische Schwächen, die im allgemeinen mit der PC-Plattform assoziiert werden. Z.B. führt das Entfernen des nvram-Chips bei Indigo-Workstations zum Löschen des PROM-Paßworts.

18.3.2 Das Root-Paßwort

Direkt nach Abschluß der Installation sollten Sie das Root-Paßwort setzen. Viele Distributionen, wie SunOS oder Solaris, fordern Sie dazu auf. Dies ist die letzte Option vor dem Reboot (SunOS) oder Hochfahren (Solaris). Einige Distributionen (z.B. Linux Slackware oder AIX) erzwingen jedoch keine Paßwortangabe vor dem ersten Booten. Wenn Sie eines dieser Systeme verwenden, müssen Sie das Root-Paßwort sofort beim ersten Einloggen setzen.

18.4 Installationsmedien

Gleich danach sollten Sie Ihre Installationsmedien sichern, da diese sonst dazu mißbraucht werden könnten, in Ihr System einzudringen. Ein gutes Beispiel ist AT&T Unix, besonders SVR3 und V/386. Böswillige Anwender können in das System eindringen, indem sie mit einer Diskette booten und die »Magic Mode«-Option wählen, durch die sie an eine Shell gelangen.

Auch CD-ROM-Installationsmedien ermöglichen Eindringlingen den Zugang. Wenn Ihre Sun-Workstation zugänglich und das Installationsmedium verfügbar ist, kann jeder den Rechner anhalten, mit der Installations-CD booten und Ihre Festplatte überschreiben. (Dieser Angriff ist nicht auf SunOS oder Solaris beschränkt. Durch Ändern der SCSI-ID oder einfaches Abtrennen der Festplatte können Eindringlinge ein AIX-System zu einem Neustart von CD-ROM zwingen.) Sogar in Linux-Systeme kann auf diese Art eingebrochen werden; bewahren Sie Ihre Installationsmedien also unbedingt an einem sicheren Ort auf.

18.5 Default-Konfigurationen

Als nächstes müssen Sie sich den betriebssystemspezifischen Voreinstellungen zuwenden. Die meisten Unix-Versionen haben ein oder mehrere voreingestellte Accounts oder Paßwörter. (Einige haben sogar paßwortfreie Accounts.) Bevor Sie mit dem nächsten Schritt fortfahren (Systemintegrität) müssen Sie diese Sicherheitslücken schließen.

IRIX ist ein gutes Beispiel dafür. Bestimmte IRIX-Versionen haben riesige Sicherheitslöcher in ihrer Default-Konfiguration. Für die folgenden Accounts ist kein Paßwort zum Einloggen erforderlich:

Andere Systeme haben ähnliche Probleme, wie z.B. Default-Accounts, deren Paßwörter allgemein bekannt sind.

Hinweis:

Default-Accounts liefern Eindringlingen schon die Hälfte der Informationen, die sie benötigen. Ein typisches Beispiel ist der col-Account bei Caldera OpenLinux. Andere Probleme sind Test-Scripts und Muster-Benutzeraccounts, die Eindringlingen oft einen roten Teppich auslegen. Wenn Sie Linux verwenden, installieren Sie auf keinen Fall die vorgegebenen Benutzer, die mit dem sudo-Paket geliefert werden. Wenn Sie es doch tun, sollten Sie sicher sein, daß Sie richtig mit sudo umgehen können.

18.6 Paßwortsicherheit

Sie werden an Ihrem Rechner wahrscheinlich mehr als einen Benutzer arbeiten lassen (wahrscheinlich Dutzende). Bevor Sie den Rechner für das Netzwerk freigeben, sollten Sie sich der Paßwortrichtlinie zuwenden.

Jedes Paßwortsystem hat irgendeine angeborene Schwäche. Das ist bedenklich, weil Paßwörter das Herzstück des Sicherheitsschemas von Unix darstellen. Jede Gefährdung der Paßwortsicherheit kann fatale Auswirkungen haben. Deshalb sollten Sie proaktive Paßwort- Utilities, wirksame Verschlüsselungsmethoden (wann immer dies möglich ist) und Paßwort- Shadowing installieren.

Hinweis:

Beim Paßwort-Shadowing enthält die Datei /etc/passwd nur Token (oder Symbole), die als abstrakte Darstellungen der wirklichen, verschlüsselten Paßwörter der Benutzer dienen. Das wirkliche Paßwort ist an einer anderen Stelle auf der Festplatte gespeichert, auf die Cracker nicht zugreifen können.

Wenn Sie kein Shadowing verwenden, können lokale Benutzer sich den Inhalt von /etc/ passwd ansehen. Die Paßwörter sind zwar verschlüsselt, aber einfach zu knacken, wenn Ihre Benutzer keine sicheren Paßwörter verwenden.

18.6.1 Installation des Paßwort-Shadowing

Wenn Ihre Distribution Shadowing nicht von Haus aus unterstützt, empfehle ich Ihnen das John-F.-Haugh-II-Shadow-Paket. Es ermöglicht nicht nur grundlegendes Paßwort-Shadowing, sondern auch Paßwörter mit 16 Zeichen Länge (gegenüber den herkömmlichen 8 Zeichen Länge). Außerdem bietet es noch die folgenden Möglichkeiten:

Wegweiser:

Shadow finden Sie unter dieser Adresse:

http://www.assist.mil/ASSIST/policies/tools/security/unix/shadow.tar

Es gibt mehrere speziell für Linux geschriebene Tools für das Paßwort-Shadowing. Zwei davon sind:

Wenn Sie mehr über Shadow-Paßwörter erfahren wollen (und Unix-Paßwortsicherheit im allgemeinen) empfehle ich Ihnen folgende Informationsquellen:

Sie sollten jedoch wissen, daß einige Paßwort-Shadowing-Systeme auch durch andere Programme angegriffen werden können. Es gibt dafür mehrere Exploits. Bevor Sie fortfahren, sollten Sie Ihr System mit Hilfe der in Tabelle 18.2 aufgeführten Exploits überprüfen.

Tabelle 18.2: Exploits zum Überwindern von Paßwort-Shadowing

Exploit

Kurze Beschreibung und Adresse

imapd-Sicherheitsloch

imapd-Core-Dumps in Linux können Shadow-Paßwörter enthalten.

http://underground.simplenet.com/central/linux-ex/imapd_core.txt

FTP-Sicherheitsloch

Unter Solaris 2.5 hat FTP einen Fehler, der dazu führen kann, daß Shadow-Paßwörter preisgegeben werden.

http://www.unitedcouncil.org/c/wuftpd-sdump.sh

Telnet-Sicherheitsloch

Unter Linux können Sie bei Verwendung von Telnet einen Core-Dump erzwingen. Der Dump enthält Shadow-Paßwörter.

http://www.rootshell.com/archive-ld8dkslxlxja/199707/telnet_core.txt

shadowyank

Unter Ausnutzung eines weiteren FTP-Sicherheitslochs holt shadowyank sich Shadow-Paßwörter aus FTP-Core-Dumps.

http://www.asmodeus.com/archive/Xnix/SHADOWYANK.C

imapd-crash

imapd kann zum Absturz gebracht werden und der resultierende Dump Shadow-Paßwörter enthalten.

http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/imapd_4.1b.txt

Hinweis:

Einige Plattformen sind auch mit dem folgenden Angriff zu knacken:

$ export RESOLV_HOST_CONF=/etc/shadow
$ rlogin /etc/shadow

Die folgenden Man-Pages beinhalten Informationen zu Paßwortsicherheit und Shadowing:

18.7 Installation eines Programms zur proaktiven Paßwortprüfung

Als nächstes müssen Sie eine proaktive Paßwortprüfung installieren. Diese dient zum Eliminieren schwacher Paßwörter, bevor sie der passwd-Datei übergeben werden. Das funktioniert folgendermaßen: Wenn ein Benutzer sein Paßwort eingibt, wird es mit einer Wortliste und einer Reihe von Regeln verglichen. Wenn das Paßwort diese Prüfung nicht besteht und sich als schwaches Paßwort herausstellt, wird der Benutzer aufgefordert, sich ein neues Paßwort auszudenken.

Ist diese proaktive Paßwortprüfung wirklich erforderlich? Ja. Anwender sind faul. Wenn sie aufgefordert werden, ein Paßwort anzugeben, nehmen sie grundsätzlich eines, das leicht zu knacken ist, z.B. Namen von Kindern, Geburtsdaten oder Abteilungsnamen. Bei Systemen ohne proaktive Paßwortprüfung bleiben diese schwachen Paßwörter unentdeckt, bis der Systemadministrator »dazu kommt«, sie mit einem Tool zum Knacken von Paßwörtern zu überprüfen. Bis das soweit ist, ist es oft schon zu spät.

Passwd+

Wegweiser:

Matt Bishops passwd+ finden Sie unter:

ftp://ftp.assist.mil/pub/tools/passwd_utils/passwd+.tar.Z

Um mehr Informationen zu passwd+ (und der Theorie, die dahinter steckt) zu bekommen, sollten Sie sich A Proactive Password Checker, Dartmouth Technical Report PCS-TR90- 152, besorgen. Er ist nicht über das Internet verfügbar, aber Sie können per E-Mail einen Ausdruck anfordern: http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152.

anlpasswd

Ein weiteres gutes Programm zur proaktiven Paßwortprüfung ist anlpasswd vom Argonne National Laboratory. anlpasswd (das teilweise in Perl geschrieben ist) verwendet die Wörterbuchdatei Ihrer Wahl, und Sie können eigene Regeln aufstellen. Einige der mitgelieferten Regeln sind:

Wegweiser:

anlpasswd finden Sie unter:

ftp://coast.cs.purdue.edu/pub/tools/unix/anlpasswd/anlpasswd- 2.3.tar.Z.

Hinweis:

Wenn Sie Solaris 2.2 verwenden, werden Sie auch die Modifizierungsdateien benötigen:

ftp://coast.cs.purdue.edu/pub/tools/unix/anlpasswd/anlpasswd.solaris2.2.modifications .

npasswd

npasswd (von Clyde Hoover) ist mehr als ein einfaches Programm zur proaktiven Paßwortprüfung. Die Dokumentation beschreibt es so:

npasswd ist ein Ersatz für den passwd(1)-Befehl für Unix und Unix-ähnliche Betriebssysteme. Es unterzieht Benutzer-Paßwörter strengen Rateprüfungen, um die Gefahr zu verringern, daß Benutzer schwache Paßwörter wählen. npasswd ist dafür geeignet, die Standardprogramme zur Paßwortänderung passwd, chfn und chsh zu ersetzen.

npasswd ist eine umfassende Lösung und kann viel zu Ihrer Paßwortsicherheit beitragen. Wenn Sie Solaris 2.5 verwenden, werden Sie allerdings Funktionseinbußen hinnehmen müssen. (Sun änderte das NIS-passwd-API beim Übergang zu NIS+. Deshalb unterstützen auch die neuesten Versionen von npasswd NIS+ nicht.)

Wegweiser:

Die Dokumentation zu npasswd finden Sie unter: http://uts.cc.utexas.
edu/~clyde/npasswd/doc/
.

npasswd bekommen Sie unter:

http://uts.cc.utexas.edu/~clyde/npasswd/.

18.8 Patches

Der nächste Schritt ist, alle aktuellen Patches für Ihr Betriebssystem zu installieren. Wenn Sie brandneue Installationsmedien haben, sind die aktuellen Patches wahrscheinlich schon enthalten. Wenn Ihre Installationsdateien aber älter als 90 Tage sind, müssen Sie sich aktuellere Informationen besorgen.

In Tabelle 18.3 sind einige Adressen aufgeführt, an denen Sie Patches für populäre Unix- Plattformen finden.

Tabelle 18.3: Bezugsquellen für Patches

Plattform

Bezugsquelle

AIX (IBM)

http://www.ers.ibm.com/tech-info/index.html

FreeBSD/OpenBSD

ftp://ftp.openbsd.org/pub/OpenBSD/patches/

HP-UX

http://us-support.external.hp.com/

IRIX

http://www.sgi.com/Support/security/patches.html

NeXT

ftp://ftp.next.com/pub/NeXTanswers/Files/Patches/

SCO

ftp://ftp.sco.com/SLS/

SunOS/Solaris

http://sunsolve.sun.com/sunsolve/pubpatches/

Hinweis:

Linux-Benutzer sollten sich an ihren jeweiligen Distributor wenden.

18.9 Spezielle Sicherheitslücken

Da nicht alle Patch-Pakete vollständig sind und ältere Patches schwer zu finden sind, habe ich eine spezielle Liste zusammengestellt. Diese Liste beinhaltet die ärgsten Sicherheitslükken ausgewählter Plattformen. Bevor Sie mit dem Abschnitt über die Systemintegrität fortfahren, sollten Sie Ihr System auf die in der Liste angeführten Sicherheitslöcher überprüfen.

Hinweis:

Dies sind nur die sehr kritischen Sicherheitslücken. Die Liste ist nicht vollständig und deckt nur bestimmte Plattformen ab. Wenn Sie nach einer langen Liste aktueller Exploits suchen, ist dies nicht der richtige Ort. Eine solche Liste finden Sie am Ende dieses Kapitels.

18.9.1 Kritische Schwachstellen: AIX

bugfiler

Versionen oder Anwendung: AIX 3.x

Auswirkungen: bugfiler-Binaries werden SUID-Root installiert. Lokale Benutzer können sich Root-Privilegien aneignen.

Abhilfe: Entfernen Sie das SUID-Bit der bugfiler-Binärdateien.

Weitere Informationen: http://www.njh.com/latest/9709/970909-03.html

Beigetragen von: Johannes Schwabe

crontab

Versionen oder Anwendung: AIX 3.2

Auswirkungen: Lokale Benutzer können sich Root-Privilegien aneignen.

Abhilfe: http://service.software.ibm.com/rs6000/

Weitere Informationen: http://www.sw.com.sg/Download/cert_advisories/CA- 92:10.AIX.crontab.vulnerability

Beigetragen von: CERT

dpsexec

Versionen oder Anwendung: dpsexec

Auswirkungen: Lokale Benutzer können sich Root-Privilegien aneignen. (dpsexec ist ein PostScript-Interpreter/Kommando-Programm, mit dessen Hilfe Sie interaktiv PostScript- Code durchgehen können.)

Abhilfe: unbekannt

Weitere Informationen: http://geek-girl.com/bugtraq/1994_3/0038.html

Beigetragen von: Sam Hartman

Hinweis:

Ein Hinweis an das IBM-RS/6000-Sicherheitsteam: Wenn Sie die Adressen von Sicherheits-Patches in mehreren Sicherheitslisten posten, verschieben Sie sie bitte nicht an andere Orte (oder wenn doch, sorgen Sie für aktuelle Umleitungen). In allen möglichen Listen und Archiven taucht die Adresse ftp://software.watson.ibm.com auf, obwohl dort keine Patches mehr zu finden sind. Ähnliches geschieht unter ftp://testcase.software.ibm.com/aix/ fromibm/. Nicht jeder hat immer die neuesten Medien zur Verfügung. Auch Leute, die ältere RS/6000-Rechner mit älteren AIX-Distributionen kaufen, brauchen Patches.

dtterm

Versionen oder Anwendung: AIX 4.2 dtterm

Auswirkung: Ein Puffer-Überlauf in dtterm bringt eine Root-Shell hervor. Lokale Benutzer können sich Root-Privilegien aneignen.

Abhilfe: chmod -s /usr/dt/bin/dtterm

Weitere Informationen: http://mayor.dia.fi.upm.es/~alopez/bugs/bugtraq/0239.html

Beigetragen von: Georgi Guninski

FTP

Versionen oder Anwendung: AIX 3.2, 4.1, 4.2 FTP

Auswirkungen: Entfernte Server können beliebige Befehle auf Client-Rechnern ausführen.

Abhilfe: IBM empfiehlt, das setuid-Bit des ftp-Befehls zu entfernen. Einige Leute haben dadurch jedoch Probleme bekommen, da FTP ohne setuid nicht läuft (zumindest auf 4.2.1).

Weitere Informationen: http://geek-girl.com/bugtraq/1997_3/0626.html

Beigetragen von: Andrew Green

gethostbyname()

Versionen oder Anwendung: AIX 3.2-4.2x & gethostbyname()

Auswirkungen: Puffer-Überlaufe können eine Root-Shell hervorbringen.

Abhilfe: APAR IX60927, IX61019 oder IX62144

Weitere Informationen: http://ciac.llnl.gov/ciac/bulletins/h-13.shtml

Beigetragen von: Georgi Guninski

login

Versionen oder Anwendung: AIX 3.2-4.2x

Auswirkungen: Entfernte Benutzer können Root-Zugang erlangen. (Login wird -fuser- Befehlszeilenargumente für entfernte Clients erfolgreich parsen. Dies ist auch bei einigen Linux-Versionen ein Problem.)

Abhilfe: APAR IX44254

Weitere Informationen: http://www.xnet-consulting.argosnet.com/security/ciac/bulletins/e-fy94/ciacfy94.txt

Beigetragen von: unbekannt

18.9.2 Kritische Schwachstellen: IRIX

handler

Versionen oder Anwendung: handler

Auswirkungen: /cgi-bin/handler akzeptiert beliebige Befehle als angehängte Argumente. Jeder - lokal oder entfernt - kann auf diese Weise auf Ihrem Rechner Befehle ausführen.

Abhilfe: ftp://sgigate.sgi.com/

Weitere Informationen: http://www.geek-girl.com/bugtraq/1997_3/0148.html

Beigetragen von: Wolfram Schneider

webdist.cgi

Versionen oder Anwendung: webdist.cgi

Auswirkungen: IRIX Mindshare Outbox verwendet ein Script namens webdist.cgi bei den Routinen für Installationen über das Netzwerk. Aufgrund fehlerhafter Berechtigungen und einer fehlenden Überprüfung von Argumenten, die an das Programm übergeben werden, können lokale und entfernte Benutzer beliebigen Code mit der httpd-UID ausführen. (Sie lassen httpd doch nicht als Root laufen, oder?).

Abhilfe: ftp://sgigate.sgi.com/

Weitere Informationen: http://www.sgi.ethz.ch/secadv/msg00003.html

Beigetragen von: Grant Haufmann und Chris Sheldon

Hinweis:

Wenn Sie 6.2 frisch installiert haben, sehen Sie einmal in /cgi-bin nach. Sie werden mehr als zwei Dutzend Beispiel-cgi-Scripts finden, von denen einige setuid-Root sind. Löschen Sie diese Dateien, bevor Sie mit Ihrem Rechner ans Netz gehen, oder Sie sind garantiert verloren.

xdm

Versionen oder Anwendung: X Display Manager auf 5.3

Auswirkungen: Version 5.3 hat standardmäßig eine Xsession-Datei mit aktiviertem xhost+, wodurch der Server jeden gültigen Client akzeptiert.

Abhilfe: Deaktivieren Sie xhost+.

Beigetragen von: unbekannt

Line Printer Login

Versionen oder Anwendung: lp login - IRIX 6.2

Auswirkungen: Das Paßwort für den lp-Account ist Null.

Abhilfe: Sperren Sie das lp-Paßwort in /etc/passwd.

Beigetragen von: unbekannt

18.9.3 Kritische Remote-Schwachstellen: SunOS und Solaris

syslogd

Versionen oder Anwendung: SunOS 4.1.x

Auswirkungen: syslogd ist der Gefahr von Puffer-Überlaufen ausgesetzt, die es entfernten Angreifern ermöglichen, Root-Zugang zu erlangen.

Abhilfe: Wenden Sie sich an Sun.

Weitere Informationen: http://www.dice.ucl.ac.be/crypto/olivier/cq/msgs/ msg00089.html

Beigetragen von: 8LGM

rlogin

Versionen oder Anwendung: SunOS und Solaris (generell)

Auswirkungen: rlogin hat einen Puffer-Überlauf, der es entfernten Angreifern ermöglicht, Root-Zugang zu erlangen.

Abhilfe: Unter http://sunsolve.sun.com/sunsolve/pubpatches/patches.html finden Sie die folgenden Patches:

SunOS 5.5.1 104650-02
SunOS 5.5.1_x86 104651-02
SunOS 5.5 104669-02
SunOS 5.5_x86 104670-02
SunOS 5.4 105254-01
SunOS 5.4_x86 105255-01
SunOS 5.3 105253-01
SunOS 4.1.4 105260-01
SunOS 4.1.3_U1 105259-01

Weitere Informationen: http://ciac.llnl.gov/ciac/bulletins/h-25a.shtml

Beigetragen von: CERT

statd

Versionen oder Anwendung: SunOS und Solaris (generell)

Auswirkungen: statd ist der Gefahr eines Puffer-Überlaufs ausgesetzt. Dadurch können entfernte Angreifer Root-Privilegien zum Erzeugen und Löschen von Dateien erhalten. Das ist äußerst gefährlich, und der Exploit-Code hat schon die Runde gemacht. Einige Leute berichten jedoch, daß dieser Bug auf SPARC-Plattformen nicht annähernd so kritisch ist wie auf X86.

Abhilfe: Patch-ID# 104167-02 vom November 1997

Weitere Informationen: http://rtfm.ml.org/archives/bugtraq/Nov_1997/msg00181.html

Beigetragen von: anonym

18.9.4 Kritische Schwachstellen: Linux

rcp

Versionen oder Anwendung: Red Hat und Slackware

Auswirkungen: Benutzer nobody kann ein Sicherheitsloch in rcp ausnutzen, das entfernten Angreifern Root-Zugriff gibt. (Läuft bei Ihnen NCSA-httpd?).

Abhilfe: Ändern Sie die UID von Nobody.

Weitere Informationen: http://www.geek-girl.com/bugtraq/1997_1/0113.html

Beigetragen von: Miro Pikus

ftp

Versionen oder Anwendung: Slackware und AIX

Auswirkungen: Ein seltsames Sicherheitsloch: Entfernte FTP-Server können lokale FTP- Clients dazu bringen, beliebige Befehle auszuführen.

Abhilfe: Für Linux keine bekannt. Für AIX siehe URL.

Weitere Informationen: http://www.unitedcouncil.org/sploits/ftp_mget.html

Beigetragen von: ers@VNET.IBM.COM

imapd

Versionen oder Anwendung: Red Hat und Slackware

Auswirkungen: Entfernte Benutzer können das lokale Root-Paßwort in White Space ändern, indem sie ein Sicherheitsloch von imapd ausnutzen.

Abhilfe: Wenden Sie sich an Red Hat (http://www.redhat.com/support/docs/errata.html). Sie haben einen Fix herausgegeben.

Weitere Informationen: http://www.njh.com/latest/9706/970624-07.html

Beigetragen von: Tetsu Khan

18.10 Der nächste Schritt: Überprüfung der Dienste

Wir nehmen jetzt einmal an, daß Sie die Workstation gesichert haben. Das Shadowing ist aktiviert und nur starke Paßwörter werden akzeptiert. Nun ist es Zeit, zu überlegen, wie Ihre Workstation mit der Welt außerhalb Ihres Netzes zurechtkommen wird.

18.10.1 Die r-Utilities

rlogin und rsh sind für Sicherheitslöcher bekannt. Einige Linux-Distributionen beherbergen z.B. ein kritisches rlogin-Sicherheitsloch, das es sowohl lokalen auch als entfernten Benutzern erlaubt, sich privilegierten Zugang zu verschaffen:

In dem rlogin-Programm von NetKitB-0.6 existiert eine Schwachstelle. Diese Schwachstelle betrifft mehrere verbreitete Linux-Distributionen, einschließlich Red Hat Linux 2.0, 2.1 und abgeleitete Systeme wie Caldera Network Desktop, Slackware 3.0 und andere. Die Schwachstelle ist nicht auf Linux oder andere freie Unix-Systeme beschränkt. Sowohl die Informationen über diese Schwachstelle als auch die Methoden für ihre Ausnutzung sind über das Internet verfügbar gemacht worden.

- Alan Cox, Marc Ewing (Red Hat), Ron Holt (Caldera, Inc.) und Adam J. Richter, Official Update of the Linux Security FAQ; Alexander O. Yuriev, Moderator, Linux Security und Linux Alert Mailing Lists. (CIS Laboratories, Temple University, Philadelphia, PA.)

Das Problem betrifft nicht nur Linux, sondern auch viele »echte« Unix-Distributionen haben ähnliche Bugs, darunter bestimmte Distributionen von AIX. Der folgende Hinweis betraf Zehntausende von AIX-Systemen:

IBM ist gerade eine AIX-Sicherheitslücke bekannt geworden, die es ermöglicht, sich entfernt in jedes System mit AIX Version 3 als Root ohne Paßwort einzuloggen. IBM hofft, daß seine Bemühungen, schnell auf dieses Problem zu reagieren, den Kunden eine schnelle Behebung dieser Sicherheitslücke ohne größere Störungen ermöglichen wird.

Bei den betroffenen Versionen konnte jeder entfernte Benutzer diesen Befehl eingeben:

rlogin AIX.target.com -l -froot

und erhielt umgehend Root-Berechtigung auf dem Zielrechner. AIX ist nicht das einzige Unix, das Probleme mit den r-Utilities hatte. Ich empfehle Ihnen, sie ganz zu entfernen und durch Secure Shell (SSH) zu ersetzen.

SSH bietet wirksame Authentifizierungs- und Verschlüsselungsverfahren für Remote-Sitzungen. Es ist ein ausgezeichneter Ersatz für rlogin und sogar Telnet. Darüber hinaus verhindert SSH auch IP- und DNS-Spoofing-Angriffe.

Viele Administratoren schlagen vor, die Dateien /etc/host.equiv und .rhosts zu entfernen, wenn man keine r-Utilities anbietet. Beachten Sie jedoch, daß der SSH-Client die Authentifizierung über .rhosts und /etc/host.equiv unterstützt. Achten Sie also bei der Konfiguration des sshd darauf, daß Sie genau wissen, wozu diese beiden Dateien benutzt werden, wenn Sie sie verwenden. Bevor Sie SSH auf Ihrem System installieren, sollten Sie den entsprechenden RFC zu diesem Thema studieren. Es heißt »The SSH (Secure Shell) Remote Login Protocol«.

Wegweiser:

»The SSH (Secure Shell) Remote Login Protocol« von T. Ylonen (Helsinki University of Technology) ist online unter http://www.cs.hut.fi/ssh/RFC/ verfügbar.

Die Quellen für SSH sind für die meisten Unix-Varianten und für Linux frei verfügbar. Für Microsoft-Betriebssysteme und für MacOS gibt es kostenpflichtige Anwendungen zu kaufen. Bei http://www.cs.hut.fi/ssh/ finden Sie weitere Informationen.

18.10.2 finger

Der finger-Dienst kann beträchtliche Sicherheitsrisiken beherbergen und kann verwendet werden, um die Privatsphäre Ihrer Anwender zu verletzen. Ich rate eindeutig davon ab, finger-Dienste der Außenwelt anzubieten.

Wenn Sie dennoch der Meinung sind, daß Sie finger-Dienste anbieten müssen, empfehle ich Ihnen ein verbessertes finger-Paket, wie sfingerd von Laurent Demailly. Eine Haupteigenschaft von sfingerd ist, daß es Zugang zu .plan-Dateien über ein chrooted-Verzeichnis gewährt. sfingerd (dem fast immer der Quellcode beiliegt) ist erhältlich unter:

ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz

In Tabelle 18.4 sind weitere alternative finger-Daemonen aufgeführt.

Tabelle 18.4: Alternative finger-Daemonen

Daemon

Adresse und Beschreibung

fingerd-1.0

ftp://ftp.foobar.com/pub/fingerd.tar.gz. Bietet eine umfassende Protokollierung und erlaubt Beschränkungen der Weiterleitung. (Diese Version wurde auch für den @-Bug gepatcht.)

cfinger

ftp://sunsite.unc.edu:/pub/Linux/system/network/finger/cfingerd-1.3.2.tar.gz. Kann verwendet werden, um selektive finger-Dienste anzubieten, die einen Benutzer akzeptieren und einen anderen nicht. Bei Anfragen von autorisierten Benutzern können Scripts ausgeführt werden.

rfingerd

ftp://coast.cs.purdue.edu/pub/tools/unix/rfingerd.tgz. Eine interessante Verflechtung: ein Perl-Daemon. Ermöglicht eine Menge bedingter Ausführungen und Beschränkungen, z.B. if {$user_finger_request eq 'foo'} {perform_this_operation}. Leicht anzuwenden und klein (schließlich ist es Perl).

Hinweis:

An verschiedenen Stellen, einschließlich den Arts and Sciences Unix System Administrator Guidelines der Duke University, wird davon abgeraten, die GNU-fingerd-Version 1.37 zu verwenden. Offensichtlich ermöglicht ein Sicherheitsloch in dieser Version Benutzern privilegierten Dateizugriff.

18.10.3 Telnet

Telnet ist an sich kein gefährlicher Dienst. Dennoch können sogar »sichere« Versionen von Telnet externen Benutzern Zugriff auf wertvolle Informationen gewähren.

Hinweis:

Ein gutes Beispiel eines verwundbaren Telnet kommt von Red Hat Linux 4.0. Angenommen, Sie haben finger, die r-Utilities und den EXPN-Befehl in Sendmail deaktiviert. Bei dieser Konfiguration sind Sie sich ziemlich sicher, daß niemand gültige Benutzernamen auf Ihrem System herausfinden kann. Aber ist das auch so? Leider nein. Das Telnet-Paket von Red Hat 4.0 kappt zwar die Verbindung, wenn ein ungültiger Benutzername angegeben wird. Wenn der Benutzername jedoch gültig ist (aber das Paßwort falsch), gibt der Server einen Login-Prompt für einen weiteren Versuch aus. So kann ein Crakker mit Hilfe einer Gewaltattacke gültige Benutzer-IDs auf Ihrem System herausfinden.

Telnet hat noch ein paar weitere erwähnenswerte Sicherheitslöcher. Eines wurde von Sam Hartman vom Kerberos-Entwicklungsteam am MIT entdeckt (mit Bestätigung und Hilfe bei der Programmierung von John Hawkinson, ebenfalls MIT). Dieses Sicherheitsloch war ziemlich verborgen, aber es könnte einem entfernten Benutzer Root-Zugang verschaffen. Hartman beschreibt es in »Telnet Vulnerability: Shared Libraries« so:

Am Sonntag, dem 15. Oktober, entdeckte ich auf mehreren Plattformen einen Bug in einigen Versionen von telnetd, der es einem entfernten Benutzer ermöglicht, login dazu zu bringen, eine andere C-Bibliothek von einem beliebigen Ort des Dateisystems des Rechners zu laden, auf dem telnetd läuft. Bei Rechnern, die verteilte Dateisysteme wie AFS oder NFS mounten, die von der Öffentlichkeit schreibbare, anonyme FTP-Verzeichnisse haben, oder zu denen der Benutzer bereits einen Nicht-Root-Zugang hat, ist es möglich, Root-Zugriff zu erlangen.

Das von Hartman entdeckte Sicherheitsloch betraf folgende telnetd-Versionen:

Wegweiser:

Sie können »Telnet Vulnerability: Shared Libraries« online unter http:// geek-girl.com/bugtraq/1995_4/0032.html lesen.

Wenn Sie nach einem Ersatz für Telnet suchen, haben Sie einige Auswahl. Secure Shell ist gut, aber nicht die einzige Möglichkeit. Hier sind zwei andere, sehr gute Alternativen:

Hinweis:

Ein erwähnenswertes Sicherheitsloch ist die Übergabe-Methode von Umgebungsvariablen. Dieses Loch kam im November 1995 zum Vorschein und betraf sogar viele »sichere« Versionen von Telnet, die eine auf Kerberos basierende Authentifizierung verwendeten. Die Methode übergab lokale Umgebungsvariablen an das entfernte Ziel unter Verwendung der ENVIRONMENT -Option in allen Telnet-Versionen, die RFC 1408 oder RFC 1572 entsprachen. Die vollständige Dokumentation finden Sie unter: http:// ciac.llnl.gov/ciac/bulletins/g-01.shtml.

Tip:

Squidge von Infonexus hat einen Exploit-Code für den Umgebungsvariablen-Angriff geschrieben. Wenn Sie den Angriff in Aktion sehen möchten, besorgen Sie sich den Code unter: http://users.dhp.com/~fyodor/sploits/ telnetd.LD_PRELOAD.enviropassing.html.

18.11 FTP

Es gibt einige Gründe, anonymes FTP zu ermöglichen. Obwohl FTP kein kritisches Sicherheitsrisiko darstellt, sollten Sie sich einiger Probleme bewußt sein. Dabei geht es hauptsächlich um die Interaktion von FTP mit anderen Programmen oder Servern:

Bei einigen Protokollen ist es von Natur aus schwierig, sie sicher zu filtern (z.B. RPC-basierte UDP-Dienste), wodurch das interne Netzwerk weiter geöffnet wird. Dienste, die auf demselben Rechner laufen, können auf katastrophale Weise interagieren. Wenn man z.B. erlaubt, daß anonymes FTP auf demselben Rechner läuft wie der Web-Server, kann ein Eindringling eine Datei im Anonymous-FTP-Bereich plazieren und den HTTP-Server dazu bringen, sie auszuführen.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus Barbara Frasers Site Security Handbook (aktualisierter Draft, Juni 1996, CMU), das Sie online unter http:// info.internet.isi.edu:80/in-drafts/files/draft-ietf-ssh-handbook- 04.txt finden können.

Anonymes FTP mit einem schreibbaren Verzeichnis macht Sie außerdem zu einem beliebten Angriffspunkt für Bösewichte, die FTP-Bounce-Attacken ausüben.

Bei FTP-Bounce-Attacken wird ein FTP-Server verwendet, um Zugang zu einem anderen zu erlangen, der dem Cracker zuvor die Verbindung verweigert hat. Meistens ist der Zielrechner dabei so konfiguriert, daß er Verbindungsanforderungen von einer bestimmten IP-Adreßmaske ablehnt. Der Rechner des Crackers hat aber eine IP-Adresse innerhalb dieser Maske, so daß er nicht auf die FTP-Verzeichnisse des Zielrechners zugreifen kann. Um dies zu umgehen, benutzt der Cracker einen anderen Rechner (den »Vermittler«), um auf den Zielrechner zuzugreifen. Dazu schreibt er eine Datei in das FTP-Verzeichnis des Vermittlers, die Befehle enthält, damit dieser eine Verbindung zum Zielrechner herstellt und Dateien von diesem lädt. Wenn der Vermittler die Verbindung eingeht, geschieht dies unter seiner eigenen Adresse (und nicht der des Crackers). Der Zielrechner erlaubt also die Verbindung und liefert die gewünschte Datei.

FTP-Bounce-Attacken sind kein Problem besonders hoher Priorität, da sie selten vorkommen und meistens keine Einbruchversuche beinhalten. Die meisten dieser Angriffe kommen von außerhalb der USA. Viele Produkte, die mit einer High-Level-Kryptographie versehen sind, dürfen nicht aus den USA ausgeführt werden. Deshalb werden Bounce-Attacken verwendet, um diese Einschränkungen von FTP-Sites in den USA zu umgehen.

Hinweis:

Umfassende Informationen zu Bounce-Attacken finden Sie unter: http:// www-jcr.lmh.ox.ac.uk/rootshell/hacking/ftpBounceAttack/.

Warnung:

Unter bestimmten Umständen kann ein Cracker FTP als eine Startrampe für Scan-Dienste hinter Firewalls verwenden. Mehr Informationen über diese Attacke finden Sie unter: http://www.society-of-shadows.com/security/ ftp-scan.c.

FTP beherbergt noch weitere, subtilere Probleme. Z.B. ist in wu-ftpd 2.4.2-beta-13 die Default-umask 002, so daß Dateien von jedem geschrieben werden können. Das kann zu ernsten Sicherheitsgefährdungen führen. Noch schlimmer ist aber, daß dieses Sicherheitsloch auch dann noch bestehen bleibt, wenn Sie die umask manuell ändern. Nur eine Änderung in der Datei inetd.conf schafft Abhilfe. Weitere Informationen finden Sie unter: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wuftpd_umask.txt.

18.12 FTP im allgemeinen

Bestimmte Versionen von FTP sind fehlerhaft oder können leicht falsch konfiguriert werden. Wenn Sie eine Version von wu_ftpd verwenden, die vor April 1993 herausgekommen ist (nicht gerade wahrscheinlich, aber möglich, wenn Sie eine ältere Ausrüstung gekauft haben), müssen Sie sie sofort updaten. Denn laut CERT-Advisory 93:06 (»Sicherheitslücke wuarchive ftpd«):

Das CERT Coordination Center hat Informationen über eine Sicherheitslücke in Versionen von wuarchive ftpd erhalten, die vor dem 8. April 1993 ausgeliefert wurden. Verwundbare Versionen von wuarchive ftpd waren unter ftp://wuarchive.wustl.edu/packages/wuarchive-ftp/ und vielen anderen anonymen FTP-Sites zu bekommen... Jeder Benutzer (lokal oder entfernt) konnte Zugriff auf jeden Account einschließlich Root auf einem Host erlangen, auf dem diese Version von ftpd lief.

Soviel zu den älteren Versionen von wu_ftpd. Und nun zu den neueren: Am 4. Januar 1997 wurde ein Bug in Version 2.4 entdeckt (von Aleph1 und David Greenman). Das ist bedenklich, da Version 2.4 sehr verbreitet ist. Wenn Sie 2.4 momentan verwenden (und noch nichts von diesem Bug gehört haben), sollten Sie sich den Patch so bald wie möglich besorgen. Sie finden ihn unter: http://www.landfield.com/wu-ftpd/mail-archive/1996/Feb/0029.html.

Zur Auseinandersetzung mit der allgemeinen Sicherheit von FTP ist es das beste, sich das FTP-Protokoll einmal genauer anzusehen. Die FTP-Technologie hat sich seit ihrer Einführung stark verändert. Die eigentliche FTP-Spezifikation wurde ursprünglich im RFC 959 »File Transfer Protocol (FTP)« aufgestellt, und das ist über zehn Jahre her. Seitdem ist viel getan worden, um die Sicherheit dieser kritischen Anwendung zu verbessern.

Das maßgebliche Dokument ist »FTP Security Extensions« von M. Horowitz (Cygnus Solutions) und S. J. Lunt (Bellcore). Dieser Internet-Draft wurde im November 1996 verfaßt, und es heißt in der Zusammenfassung:

Dieses Dokument definiert Erweiterungen der FTP-Spezifikation RFC 959, »File Transfer Protocol (FTP)« vom Oktober 1985. Diese Erweiterungen sorgen für eine starke Authentisierung, Integrität und Vertraulichkeit des Kontroll- und Datenkanals.

Wegweiser:

»FTP Security Extensions« finden Sie unter http://info.internet.isi.edu/ 0/in-drafts/files/draft-ietf-cat-ftpsec-09.txt.

Das Dokument beginnt mit dem allgemein mit FTP verbundenen Problem - nämlich daß die Paßwörter in Klartext übermittelt werden. Es beschreibt einige Fortschritte bei der Protokollsicherheit und ist ein guter Ausgangspunkt, um etwas über Sicherheit bei FTP zu lernen.

Wenn Sie die folgenden Punkte beachten, können Sie Ihren FTP-Server besser absichern:

18.12.1 TFTP

Der beste Rat, den ich Ihnen zu TFTP geben kann, ist, es zu deaktivieren. TFTP ist ein selten genutztes Protokoll und birgt erhebliche Sicherheitsrisiken, selbst wenn Sie eine als sicher angesehene Version verwenden.

Hinweis:

Einige Versionen sind eindeutig nicht sicher. Darunter fällt der in AIX Version 3.x enthaltene TFTP. Die Patch-Kontrollnummer ist ix22628. Es ist zwar sehr unwahrscheinlich, daß Sie eine so alte Version von AIX verwenden. Aber falls Sie eine ältere RS/6000 erworben haben, sollten Sie sich dieses Problems bewußt sein. Es ermöglicht entfernten Benutzern, an /etc/ passwd zu gelangen.

In Kapitel 10, »Scanner«, habe ich TFTP und einen Scanner behandelt, der speziell zum Aufspüren von TFTP-Sicherheitslöchern entwickelt wurde (CONNECT). Da das Wissen um die Schwachstellen von TFTP weit verbreitet ist, verwenden die meisten Systemadministratoren es erst gar nicht.

Hinweis:

Sogar unter Windows 95 gibt es Tools, mit denen Sie TFTP-Server knacken können. Sehen Sie sich einmal den TFTPClient32 für Windows 95 an. Dieses Tool kann einem Cracker (mit minimalen Unix-Kenntnissen) helfen, Ihren TFTP-Server zu knacken. Sie erhalten es unter http://papa.indstate.edu:8888/ftp/main!winsock-l!Windows95!FTP.html .

TFTPD zu deaktivieren ist einfach. Sie müssen es nur in inetd.conf auskommentieren, so daß es beim Booten nicht mehr geladen wird. TFTP wird hauptsächlich beim Booten von plattenlosen (diskless) Workstations verwendet, um dem bootenden Rechner Konfigurationsdaten oder auch auszuführende Programme zu übergeben. Auf jeden Fall sollten Sie die folgenden Hinweise beachten:

18.13 Gopher

Gopher ist ein antiquiertes, aber schnelles und effizientes Protokoll. Wenn Sie es verwenden: Hut ab vor Ihnen! Ich bin ein großer Gopher-Fan. Gopher liefert mir Informationen sofort auf den Tisch, ohne die lästige Werbung, die einen im WWW überall nervt.

Gopher hatte traditionell keine großen Sicherheitsprobleme, aber einige Punkte sind dennoch erwähnenswert. Der Gopher-Server der University of Minnesota ist wahrscheinlich der populärste Gopher-Server, der je geschrieben wurde (erhältlich unter boombox.micro.umn.edu ). Ich schätze, daß er heute noch auf über der Hälfte aller Gopher-Server läuft. Von diesen sind ca. 10 Prozent für einen alten Bug anfällig.

Dieser Bug betrifft sowohl Gopher als auch Gopher+ in allen Versionen, die vor August 1993 erhältlich waren. Im CERT-Advisory CA-93:11, »UMN Unix Gopher und Gopher+ Sicherheitslücken«, heißt es:

Es ist bekannt, daß Eindringlinge diese Sicherheitslücken ausgenutzt haben, um an Paßwortdateien zu gelangen... Jeder (entfernt oder lokal) kann uneingeschränkten Zugang zu dem Account erhalten, auf dem der öffentlich zugängliche Client läuft. Dadurch kann er alle Dateien lesen, die diesem Account zugänglich sind (darunter möglicherweise /etc/passwd oder andere sensible Dateien)... Bei bestimmten Konfigurationen kann jeder (entfernt oder lokal) Zugriff auf jeden Account erhalten, einschließlich Root, auf einem Host, der als Server konfiguriert ist, auf dem gopherd läuft.

Über dieses Sicherheitsloch wurde auch in einem Defense Data Network Bulletin (DDN Security Bulletin 9315, 9. August 1993) berichtet, das unter http://nic.mil/ftp/scc/sec- 9315.txt eingesehen werden kann.

Gopher kann auch als Proxy für eine FTP-Sitzung dienen, so daß Sie eine Bounce-Attacke mit Gopher als Startrampe durchführen können. Dies ist ein Problem, das die Firewall- Sicherheit betrifft. Wenn z.B. Ihr FTP-Server hinter der Firewall liegt, aber Ihr Gopher-Server nicht, hat das Sperren des Zugangs zu dem FTP-Server in diesem Fall keinen Zweck.

Schließlich ist noch anzumerken, daß Gopher in seinem Default-Zustand verglichen mit anderen Netzwerkdiensten sehr schwache Protokollierungsmöglichkeiten bietet.

18.14 NFS (Network File System)

NFS sorgt für einige Sicherheitsprobleme. Exportierte Dateisysteme können ein Risiko darstellen oder nicht, je nachdem, wie sie exportiert werden. Dabei spielen Berechtigungen eine große Rolle. Wenn Sie befürchten müssen, daß Ihre Anwender ihre eigenen .rhosts-Dateien erzeugen (was Sie ausdrücklich untersagen sollten), ist das Exportieren von HOME-Verzeichnissen keine gute Idee, da diese Verzeichnisse natürlich Lese-/Schreibberechtigungen enthalten.

Einige Tools können Ihnen helfen, den Prozeß der Überprüfung (und Schließung) von NFS- Sicherheitslücken zu automatisieren. Eines davon ist NFSbug, geschrieben von Leendert van Doorn. NFSbug ist ein Scanner für allgemein bekannte NFS-Sicherheitslöcher. Bevor Sie mit Ihrem Sicherheits-Audit abschließen und Ihren Rechner für die Öffentlichkeit freigeben, empfehle ich Ihnen, Ihr System mit diesem Utility zu prüfen (bevor Cracker es tun). NFSbug finden Sie unter: ftp://ftp.cs.vu.nl/pub/leendert/nfsbug.shar.

Tip:

Eine tolle Erläuterung der Art und Weise, wie Cracker NFS angreifen, finden Sie in »Improving the Security of Your Site by Breaking Into It« (Dan Farmer und Wietse Venema). Dieses Dokument enthält eine Schritt-für- Schritt-Analyse einer solchen Attacke. Sie erhalten es unter: http:// www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html.

Warnung:

Richten Sie niemals einen NFS-Zugang mit Schreibberechtigung für privilegierte Dateien oder Bereiche ein und geben Sie diesen über das Netz frei. Wenn Sie das tun, handeln Sie sich viel Ärger ein. Lassen Sie nur Leseberechtigungen zu.

NFS ist eine vielgenutzte Eingangstür für Cracker. In einem Defense Data Network Advisory von 1995 heißt es:

ZUSAMMENFASSUNG: Anstieg der Berichte über Root-Verletzungen durch Eindringlinge, die Tools zur Ausnutzung verschiedener NFS-Sicherheitslücken verwendet haben... Mit Hilfe solcher Tools verschaffen Eindringlinge sich unautorisierten Zugang zu Netzwerkressourcen. Diese Tools und Informationen darüber sind in zahlreichen Internetforen verbreitet worden.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus dem DDN Security Bulletin 9501, das Sie online unter ftp://nic.ddn.mil/scc/sec-9501.txt finden.

Ein weiteres Problem ist, daß Sie, selbst wenn Sie »verbesserte« oder »sichere« NFS verwenden (im wesentlichen NFS plus DES), immer noch nicht sicher sind. Der DES-Schlüssel wird von dem Benutzerpaßwort abgeleitet, und dies ist ein offensichtliches Problem. Die Installation von Shadowing ist vielleicht ein Weg, einen Cracker daran zu hindern, an die passwd-Listen zu gelangen. Der einzige wirkliche Vorteil der um DES erweiterten Versionen besteht darin, daß die Routine die Uhrzeit aufzeichnet. Timestamp-Verfahren schließen die Möglichkeit aus, daß ein Cracker den Austausch abhören und später wiedergeben kann.

Hinweis:

Eine Möglichkeit ist, den NFS-Traffic auf Router-Ebene zu blockieren. Das machen Sie, indem Sie Filter für Port 111 und 2049 einrichten. Das hat allerdings wenig Einfluß auf Cracker, die sich innerhalb Ihres Netzwerks befinden. Deshalb bevorzuge ich eine Kombination beider Techniken. D.h., wenn Sie NFS verwenden müssen, verwenden Sie eine verbesserte Version mit DES-Authentifizierung und zusätzlich eine Blockade auf Router-Ebene.

Ich empfehle Ihnen, die folgenden Links zur NFS-Sicherheit aufzusuchen. Jede Site bietet eine andere Sicht des Problems und mögliche Lösungen oder wichtige Informationen über NFS- und RPC-Aufrufe:

18.15 HTTP

HTTP hat vielfältige Sicherheitsprobleme, von denen die meisten in Kapitel 28, »Sprachen, Erweiterungen und Sicherheit«, behandelt werden. Einige wichtige Punkte sollen jedoch auch hier angesprochen werden.

Zuerst einmal dürfen Sie httpd nie als Root laufen lassen. Wenn Sie es doch tun, werden Sie ein sehr unglücklicher Systemadministrator sein. Schwachstellen in CGI-Programmen ermöglichen entfernten Angreifern die Ausführung beliebigen Codes mit der UID des httpd- Servers. Wenn dieser Server als Root läuft, ist Ihr gesamtes System gefährdet.

Sie könnten in Erwägung ziehen, httpd als einen chrooted-Prozeß laufen zu lassen. Viele Ratgeber sind der Meinung, daß dies eine größere Sicherheit bietet.

Hinweis:

Wenn Sie http in einer chrooted-Umgebung laufen lassen, werden Ihre Anwender jedoch nicht mehr in der Lage sein, CGI-Scripts auszuführen, es sei denn, sie tun dies ebenfalls in einer chrooted-Umgebung. (Normalerweise können Anwender CGI-Programme von einem Unterverzeichnis ihres eigenen Verzeichnisses aus ausführen - z.B. ~usr/public_html/cgi-bin.) Wenn Sie Ihren Anwendern zugesichert haben, daß sie CGI verwenden können, ist das ein Problem.

Es hängt viel davon ab, ob Sie Ihren Anwendern Zugriff auf den Web-Server und dessen Dienste (einschließlich CGI) gewähren oder nicht. Viele ISPs verweigern einen solchen Zugriff. Das typische Angebot ist 10 M Byte Speicherplatz mit FTP, aber ohne CGI. Die meisten ISPs stellen noch nicht einmal einen Shell-Zugang zur Verfügung. Ich persönlich würde damit nicht zurechtkommen.

Wenn Sie solche Dienste anbieten, sollten Sie Richtlinien aufstellen. Ich kenne z.B. einen ISP, der CGI nur erlaubt, wenn seine Entwickler den Code prüfen können, bevor er ans Netz geht. Diese Methode hat Vor- und Nachteile. Der Vorteil ist, daß Sie jede Zeile Code zu sehen bekommen, die auf Ihren Server kommt. Der Nachteil ist, daß Sie jede Zeile Code zu sehen bekommen, die auf Ihren Server kommt. Wer möchte schon all den Code nach Sicherheitslöchern überprüfen?

Die Lösung könnte sein, ein Programm wie CGIWRAP zu verwenden. CGIWRAP automatisiert den Prozeß, indem es folgende Funktionen ausführt:

CGIWRAP wurde von Nathan Neulinger geschrieben und 1995 herausgegeben. Es ist an verschiedenen Stellen im Netz erhältlich. Ich habe gute Erfahrungen mit ftp:// ftp.cc.umr.edu/pub/cgi/cgiwrap/ gemacht.

CGIWRAP funktioniert nachgewiesenermaßen auf den folgenden Plattformen:

Leider kann CGIWRAP nicht alle Sicherheitsprobleme von HTTP beheben. Sie werden im einzelnen in Kapitel 26 näher erläutert, aber ein paar Punkte möchte ich hier schon ansprechen. Sie sollten wenigstens diese grundlegenden Vorkehrungen treffen:

Beachten Sie auch NCSAs Warnung in bezug auf DNS-basierte Authentifizierung:

Die Zugriffskontrolle durch Hostnamen und die grundlegenden Einrichtungen zur Benutzer-Authentifizierung von HTTPd sind relativ sicher, aber nicht wirklich kugelsicher. Die Benutzer-Authentifizierung sendet Paßwörter in Klartext über das Netz, so daß sie leicht gelesen werden können. Die DNS-basierte Zugriffskontrolle ist nur so sicher wie DNS selbst; das sollten Sie nicht vergessen, wenn Sie sie benutzen. Fazit: Wenn er absolut sicher nicht von externen Benutzern gesehen werden kann, sollten Sie HTTPd besser nicht zu seinem Schutz verwenden.

»NCSA Tutorial Pages: Making Your Setup More Secure«, http://hoohoo.ncsa.uiuc.edu/docs/tutorials/security.html .

18.15.1 HTTP-Sicherheit im allgemeinen

Bei der Sicherheit von HTTP hat sich besonders in den letzten zwei Jahren viel getan. Die größte Verbesserung war die Entwicklung von sicheren Protokollen. Von diesen Protokollen ist das Secure Sockets Layer Protocol das vielversprechendste.

18.15.2 Das Secure Sockets Layer Protocol

Secure Sockets Layer (SSL) wurde von Netscape Communications entwickelt. Das System verwendet RSA- und DES-Authentifizierung und zusätzlich dazu noch eine Überprüfung der MD5-Integrität. Um mehr über SSL zu erfahren, sollten Sie sich die Homepage von SSL ansehen. Das Dokument mit Namen »The SSL Protocol« (Internet-Draft) wurde von Alan O. Freier und Philip Karlton (Netscape Communications) zusammen mit Paul C. Kocher verfaßt. Sie finden es unter: http://home.netscape.com/eng/ssl3/ssl-toc.html.

18.16 Sicherung des Dateisystems

Als nächstes sollten Sie, bevor Sie mit Ihrem Rechner ans Netz gehen (lokal oder weltweit), Ihr Dateisystem sichern. Sie werden diese Sicherheitskopie später verwenden, um die Datenintegrität zu prüfen, womit wir wieder bei TripWire wären.

18.16.1 TripWire

TripWire ist ein Tool, das Integritätsprüfungen von Dateisystemen mit Hilfe kryptographischer Prüfsummen vornimmt. Mit TripWire können Sie jede Manipulation aufspüren, die vorgenommen worden ist. Sie können TripWire auch verwenden, um Ihre Festplatten nach Dateien zu durchforsten, die dort nichts verloren haben. Am Ende dieses Kapitels finden Sie eine umfassende Liste von Exploits. Für jeden Exploit gebe ich eine URL an, unter der Sie seinen Quellcode finden. Wenn Sie die Exploits herunterladen und kompilieren - und dann MD5-Werte für jeden erzeugen - können Sie diese Werte in Ihre wöchentliche oder monatliche Festplattenanalyse miteinbeziehen.

Da ich TripWire in vorangegangenen Kapiteln bereits behandelt habe, möchte ich hier nicht näher darauf eingehen. Ich habe bereits darauf hingewiesen, wo Sie das Tool finden können. An dieser Stelle möchte ich Ihnen empfehlen, sich die folgenden Dokumente zu besorgen:

18.17 Über X-Window

Das X-Window-System ist ein weiterer Punkt, der Sie eventuell betreffen könnte. Wenn Ihr Rechner ein Web-Server ist, besteht überhaupt kein Grund dafür, X-Window zu installieren. Wenn Sie X-Window jedoch einsetzen, gibt es einige wichtige Dinge zu beachten.

Die Hauptschwachstelle von X-Window - das xhost-Sicherheitsloch - läßt sich leicht beheben. Wenn ein X-Server keine Zugriffskontrolle aktiviert hat, kann jeder von überall her im Internet ein zusätzliches X-Window öffnen und beliebige Programme starten. Als generelle Lösung können Sie dieses Loch schließen, indem Sie den xhost-Eintrag von Xsession von xhost + in xhost - ändern.

Wenn Sie ein Unix-Neuling sind, denken Sie vielleicht, daß X nur eine weitere grafische Oberfläche ist, aber es steckt sehr viel mehr dahinter. G. Winfield Treese und Alec Wolman schrieben in »X Through the Firewall and Other Application Relays«:

Beim X-Window-System ermöglicht es das grundlegende Sicherheitsmodell den Benutzern, die Hosts selbst festzulegen, denen eine Verbindung zu dem X-Server gewährt wird. Das betrifft nur neue Verbindungen, nicht die bereits existierenden. Viele Benutzer deaktivieren die Zugriffskontrolle aus Bequemlichkeit ganz, sobald sie mehr als ein paar Hosts benutzen.

X-Window ist keine grafische Benutzeroberfläche, auch wenn es so aussehen mag. Verbindungen werden an den X-Server gesendet. Der X-Server kann jeden gültigen X-Client bedienen, egal, ob dieser sich auf demselben Rechner befindet oder Kilometer entfernt ist. John Fisher schreibt in seinem Artikel »Securing X Windows«:

X-Window ist auf seiner untersten Ebene eigentlich ein Kommunikationsprotokoll, das X-Protokoll. Dieses Protokoll wird innerhalb eines einzelnen Computers oder über ein Netzwerk von mehreren Computern benutzt. Es ist nicht an das Betriebssystem gebunden und daher auch für eine Vielzahl anderer Plattformen erhältlich. X- Window verwendet ein Client-Server-Modell der Netzwerkkommunikation. Dieses Modell ermöglicht es einem Benutzer, ein Programm an einem Ort laufen zu lassen, aber von einem anderen Ort aus zu steuern.

X-Window ist deshalb genau wie alle anderen Protokolle unter Unix. Es arbeitet nach dem Client-Server-Modell und stellt Zugang über das Internet und zu einer Vielzahl von Systemen und Architekturen zur Verfügung. Wenn eine gültige Verbindung gestartet wird, ist alles möglich (wie in der X11R5-Xserver-ManPage beschrieben):

Das X-Protokoll an sich weiß nichts von Berechtigungen für Fenster-Operationen oder irgendwelchen Beschränkungen dessen, was ein Client machen darf. Wenn ein Programm eine Verbindung zu einem Display herstellen kann, hat es freien Zugang zu dem Bildschirm.

Sobald eine Verbindung steht, kann der Angreifer Fenster zerstören, neue Fenster erzeugen, Tastatureingaben und Paßwörter abhören und wirklich jede mögliche Aktivität in der X- Umgebung ausführen.

Die X-Authentifizierung basiert auf einem sogenannten Magic Cookie. Das ist ein 128-Bit- Wert, der durch eine Pseudo-Zufallsauswahl erzeugt wird. Er wird an die Clients verteilt und in der Datei .Xauthority gespeichert. Dieses Authentifizierungsschema kann theoretisch überwunden werden. Es wird aus folgendem Grund als schwach angesehen:

Obwohl der XDM-Authorization-1-Mechanismus ausreichenden Schutz vor Leuten bietet, die versuchen, sich Authentifizierungsdaten aus dem Netzwerk zu fischen, hat er ein großes Problem: Der ganze Sicherheitsmechanismus steht und fällt mit dem Schutz der Datei .Xauthority. Wenn Fremde sich Zugang zum Inhalt Ihrer .Xauthority -Datei verschaffen können, kennen sie den für die Verschlüsselung der Daten verwendeten Schlüssel, und mit der Sicherheit ist es vorbei.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus einem Artikel von Francois Staes mit dem Titel »Security«, der in The X Advisor erschienen ist.

Wenn Sie die Zugriffskontrolle aktivieren, besteht zwar wenig Gefahr, daß ein Eindringling an Ihre .Xauthority-Datei gelangen kann. Dennoch sollten Sie sich nicht auf die einfache Zugriffskontrolle verlassen. Man hat sich bemüht, die X-Sicherheit zu verbessern, und es gibt keinen Grund, warum Sie nicht von diesen Bemühungen profitieren sollten. Sie sollten schon deshalb zusätzliche Sicherheitsmaßnahmen ergreifen, weil sich in der Vergangenheit gezeigt hat, daß die grundlegenden X-Sicherheitsschemata fehlerhaft sind. So steht im CERT-Bulletin »X Authentication Vulnerability«:

Zwei weit verbreitete Authentifizierungsschemata für das X-Window-System haben Schwachstellen bei der Sample Implementation. Diese Schwächen könnten es unautorisierten Benutzern ermöglichen, sich mit X-Displays zu verbinden. Davon betroffen sind X11 Release 6 und ältere Releases der X11-Sample-Implementation. Es wurde berichtet, daß unter Ausnutzung zumindest einer dieser Schwächen in Systeme eingebrochen wurde, und daß in Cracker-Kreisen inzwischen Exploits verfügbar sind.

Außerdem automatisieren viele verfügbare Programme (wie xkey, xscan, xspy und watchwin) die Aufgabe entweder des Knackens des X-Servers oder des Ausnutzens des Servers, sobald er geknackt wurde.

Experten raten zur Verwendung einer Kerberos-basierten Xlib oder des in RFC 1413 definierten Authentifizierungsprotokolls. Ihre Wahl hängt natürlich von Ihrer speziellen Netzwerkkonfiguration ab. Hier sind einige grundlegende Tips zur X-Sicherheit:

18.18 Checklisten und Leitfäden

Bevor Sie mit der Planung Ihres Netzwerks beginnen, sollten Sie sich einige der im folgenden aufgeführten Dokumente besorgen. Sie sind eine gute Hilfe zum besseren Verständnis der Struktur eines Netzwerks, und Sie lernen, wie Sie gute Sicherheitsvorkehrungen implementieren können.

18.19 Ausgewählte Exploits für Unix (allgemein)

Der nächste Abschnitt enthält eine umfangreiche Sammlung von Angriffen und Sicherheitslöchern bei Unix. Um den größten Nutzen aus dieser Liste zu ziehen, sollten Sie folgendermaßen vorgehen:

1. Laden Sie die Liste in eine Textdatei.

2. Extrahieren Sie die URLs.

3. Schreiben Sie ein Script, um die einzelnen Dateien zu bekommen.

4. Kompilieren Sie jede Datei und berechnen Sie ihren MD5-Wert.

5. Scannen Sie Ihr Netzwerk nach den resultierenden Signaturen ab.

Wenn unter Ihren Anwendern ein Cracker ist, werden Sie ihn möglicherweise finden.

abuse.txt

Zweck: Red Hat Linux hat ein Sicherheitsloch im Spiel Abuse. Diese Datei beschreibt, wie man dieses Loch ausnutzen kann.

URL: http://main.succeed.net/~kill9/hack/os/linux/linabuse.txt

Autor: Dave M.

aix_dtterm.c

Zweck: Öffnet eine Root-Shell durch Ausnutzung eines Puffer-Überlaufs in dtterm.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07%26before/aix_dtterm.c

Autor: Georgi Guninski

AIX_host.c

Zweck: Öffnet eine Root-Shell in AIX durch Ausnutzung eines Puffer-Überlaufs in gethostbyname.

URL: http://www.asmodeus.com/archive/Aix/AIX_HOST.C

Autor: unbekannt

AIX_mount.c

Zweck: Nutzt einen Puffer-Überlauf in mount bei AIX 4.x aus.

URL: http://samarac.hfactorx.org/Exploits/AIX_mount.c

Autor: Georgi Guninski

aix_ping.c

Zweck: Erlaubt Root-Zugriff auf AIX durch Ausnutzung eines Puffer-Überlaufs in gethostbyname.

URL: http://www.society-of-shadows.com/security/aix_ping.c

Autor: Georgi Guninski

aix_xlock.c

Zweck: Erlaubt Root-Zugriff auf AIX durch Ausnutzung eines Puffer-Überlaufs in xlock.

URL: http://www.society-of-shadows.com/security/aix_xlock.c

Autor: Georgi Guninski

amod.tar.gz

Zweck: Ermöglicht Crackern, beliebigen Code in SunOS-Kernel zu laden.

URL: http://www.sabotage.org/rootshell/hacking/amod.tar.gz

Autor: unbekannt

arnudp.c

Zweck: UDP-Spoofing-Utility.

URL: http://www.asmodeus.com/archive/IP_toolz/ARNUDP.C

Autor: Arny (cs6171@scitsc.wlv.ac.uk)

ascend.txt

Zweck: Attackiert Ascend-Router von einem Linux-Rechner aus.

URL: http://www2.fwi.com/~rook/exploits/ascend.txt

Autor: The Posse

asppp.txt

Zweck: SolarisX86-Exploit, der zu für jeden schreibbaren .rhosts-Dateien führt.

URL: http://www.unitedcouncil.org/c/asppp.txt

Autor: unbekannt

autoreply.txt

Zweck: Modifizierte .rhosts-Dateien können zur Root-Berechtigung führen. (Die Ursache ist ein Sicherheitsloch in der elm-mail-Distribution.)

URL: http://samarac.hfactorx.org/Exploits/autoreply.txt

Autor: unbekannt

bdexp.c

Zweck: Nutzt einen Puffer-Überlauf in einem Spiel (bdash) unter Linux aus.

URL: http://oliver.efri.hr/~crv/security/bugs/Linux/bdash.html

Autor: Nicolas Dubee

bind.txt

Zweck: Anleitung für eine DoS-Attacke gegen Bind.

URL: http://www.asmodeus.com/archive/SunOS/BIND.TXT

Autor: unbekannt

block.c

Zweck: Denial-of-Service durch Aufhebung der Benutzer-ttys.

URL: http://www.plato-net.or.jp/usr/vladimir/ugtxt/unix/OddsEnds.txt

Autor: Shooting Shark

breaksk.txt

Zweck: Wordlist-Attacke gegen Netscape-Server.

URL: http://www.society-of-shadows.com/security/breaksk.txt

Autor: unbekannt

brute_web.c

Zweck: Dies ist eine Gewaltattacke auf Web-Server. Das Programm sendet in schneller Abfolge Benutzernamen und Paßwörter aus.

URL: http://www2.fwi.com/~rook/exploits/brute_web.c

Autor: BeastMaster V

cfexec.sh

Zweck: Attackiert GNU-cfingerd und führt beliebige Befehle aus.

URL: http://www2.fwi.com/~rook/exploits/cfexec.sh

Autor: east (east@l0ck.com)

cloak.c

Zweck: Cracker beseitigen ihre Spuren mit diesem Utility, indem sie ihre Aktivitäten aus den System-Logs entfernen.

URL: http://www2.fwi.com/~rook/exploits/cloak.c

Autor: Wintermute von -Resist-

color_xterm.c

Zweck: Mit diesem Programm erhält man Root-Zugang in Linux durch Ausnutzen eines Puffer-Überlaufs in dem Color-Xterm-Paket.

URL: http://ryanspc.com/exploits/color_xterm.c

Autoren: Ming Zhang und zgv

convfontExploit.sh

Zweck: Erlaubt Root-Zugriff durch Ausnutzen der Prozeß-ID von convfont. (Funktioniert nur mit Linux.)

URL: http://www.space4less.com/usr/teknopia/security/convfontExploit.sh

Autor: Squidge (squidge@onyx.infonexus.com)

cxterm.c

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Puffer-Überlaufs in cxterm auf Linux- Systemen.

URL: http://ryanspc.com/exploits/cxterm.c

Autor: Ming Zang

dec_osf1.sh

Zweck: Nutzt eine Schwachstelle in top unter DEC Unix aus. (Führt zu Root-Zugang.)

URL: http://www.asmodeus.com/archive/DEC/DEC_OSF1.SH

Autor: unbekannt

demonKit-1.0.tar.gz

Zweck: Trojanisches Pferd zum Eindringen in Linux-Systeme durch eine Hintertür.

URL: http://www.net-security.sk/unix/rootkit/demonKit-1.0.tar.gz

Autor: unbekannt

dgux_fingerd.txt

Zweck: Anleitung zum Angreifen von finger auf Digital Unix.

URL: http://www.unitedcouncil.org/c/dgux_fingerd.txt

Autor: unbekannt

dipExploit.c

Zweck: Dieser Code nutzt dip aus, ein Einwähl-Utility unter Linux.

URL: http://www2.fwi.com/~rook/exploits/dipExploit.c

Autor: unbekannt

doomsnd.txt

Zweck: Ergibt Root-Zugriff auf Linux durch Ausnutzen einer Lücke in Dooms sndserver- Paket.

URL: http://www.asmodeus.com/archive/Xnix/DOOMSND.TXT

Autor: unbekannt

dosemu.txt

Zweck: Auf Debian Linux kann das DOS-Emulationspaket verwendet werden, um Dateien zu lesen, die Root gehören.

URL: http://pcisys.net/~bpc/work/dosemu.txt

Autor: unbekannt

dumpExploit.txt

Zweck: Beschreibung eines Sicherheitslochs in Red Hat 2.1-4.1 /sbin/dump. (Es ist in suid- root installiert und ermöglicht lokalen Benutzern das Lesen aller Dateien.)

URL: http://www.unitedcouncil.org/c/dumpExploit.txt

Autor: David Meltzer

eject.c

Zweck: Exploit für Puffer-Überlauf in dem Programm eject auf Solaris 2.4.

URL: http://www.asmodeus.com/archive/slowaris/EJECT.C

Autor: unbekannt

elm_exploit.c

Zweck: Nutzt einen Puffer-Überlauf in elm unter Linux aus.

URL: http://www.chaostic.com/filez/exploites/elm_exploit.c

Autor: BeastMaster V

eviltelnetd

Zweck: Trojanisches Pferd für den Telnet-Daemon, das eine Root-Shell ermöglicht.

URL: http://samarac.hfactorx.org/Exploits/telnetd-hacked.tgz

Autor: unbekannt

expect_bug.txt

Zweck: Erläutert eine Schwachstelle in Expect, einer beliebten Programmiersprache zur Automatisierung von Terminal-Sitzungen.

URL: http://www.society-of-shadows.com/security/expect_bug.txt

Autor: unbekannt

fdformat-ex.c

Zweck: Erlaubt Root-Zugriff auf Solaris 2.x durch Ausnutzen des Utilitys zur Disketten- Formatierung.

URL: http://www.asmodeus.com/archive/slowaris/FDFORMAT-EX.C

Autor: unbekannt

ffbconfig-ex.c

Zweck: Nutzt einen Puffer-Überlauf in dem FFB Graphics Accelerator aus und erzielt Root- Zugriff.

URL: http://www.asmodeus.com/archive/slowaris/FFBCONFIG-EX.C

Autor: unbekannt

finger_attack.txt

Zweck: Beschreibung einer Denial-of-Service-Attacke durch Bombardieren von fingerd.

URL: http://www.sabotage.org/rootshell/hacking/finger_attack.txt

Autor: unbekannt

FreeBSDmail.txt

Zweck: Exploit zum Angriff von sendmail auf Rechnern mit FreeBSD 2.1.x.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/FreeBSDmail.txt

Autor: Alexey Zakharov

FreeBSD-ppp.c

Zweck: Erlaubt Root-Zugriff auf FreeBSD durch Ausnutzen eines Puffer-Überlaufs in pppd.

URL: http://www.rasputin.net/~itamae/outernet/filez/FreeBSD-ppp.c

Autor: Nirva

ftpBounceAttack

Zweck: Die beliebte FTP-Bounce-Attacke.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/ftpBounceAttack

Autor: unbekannt

ftp-scan.c

Zweck: Nutzt FTP als Startrampe zu Scan-Diensten, die hinter Firewalls liegen.

URL: http://www.society-of-shadows.com/security/ftp-scan.c

Autor: Kit Knox

getethers1.6.tgz

Zweck: Scannt Netzwerke und erhält Hostnamen und Hardware-Adressen aller Hosts in einem LAN.

URL: http://www.rootshell.com/archive-ld8dkslxlxja/199707/getethers1.6.tar.gz

Autor: unbekannt

glimpse_http.txt

Zweck: Nutzt ein Sicherheitsloch im Suchtool Glimpse aus und führt auf dem Zielrechner beliebige Befehle aus.

URL: http://www.unitedcouncil.org/c/glimpse_http.txt

Autor: unbekannt

gpm-exploit.txt

Zweck: Nutzt ein Sicherheitsloch in Linux' Mausunterstützung aus, um Root-Rechte zu erlangen.

URL: http://www.asmodeus.com/archive/linux/GPM-EXPLOIT.TXT

Autor: unbekannt

h_rpcinfo.tar.gz

Zweck: Stiehlt Speicherauszüge von RPC-Diensten von einem entfernten Host.

URL: http://www.jammed.com/~jwa/Security/h_rpcinfo.tar.gz

Autor: unbekannt

hide.c

Zweck: Erlaubt unautorisiert Lese- und Schreibberechtigung für /etc/utmp.

URL: http://irdu.nus.sg/security/softwares/hide.c

Autor: unbekannt

hpjetadmin.txt

Zweck: Erläuterung eines Exploits in hpjetadmin, der zu Root-Berechtigung führt.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/hpjetadmin.txt

Autor: r00t

identd_attack.txt

Zweck: Denial-of-Service-Attacke durch Bombardieren von identd.

URL: http://www2.fwi.com/~rook/exploits/identd_attack.txt

Autor: Corinne Posse

ident-scan.c

Zweck: Erhält UID und Namen von Daemonen, die auf entfernten Hosts laufen.

URL: http://users.dhp.com/~fyodor/nmap/scanners/ident-scan.c

Autor: Dave Goldsmith

iebugs.tar.gz

Zweck: HTML-Distribution von sechs Internet-Explorer-Bugs.

URL: http://users.dhp.com/~fyodor/sploits/internet_explorer_bug_collection.html

Autor: Viele (siehe Installationshinweise.)

imapd_exploit.c

Zweck: Nutzt ein Sicherheitsloch in Red Hat Linux aus, das es entfernten Angreifern ermöglicht, über imapd Root-Zugang zu erhalten.

URL: http://mayor.dia.fi.upm.es/~alopez/bugs/bugtraq2/0263.html

Autor: Akylonius

innd_exploit.c

Zweck: Erzielt eine Shell durch Ausnutzen eines Puffer-Überlaufs in innd auf bestimmten Linux-Systemen.

URL: http://www.unitedcouncil.org/c/innd_exploit.c

Autor: Method (method@arena.cwnet.com)

ipbomb.c

Zweck: Wirft einen Host aus dem Netz, indem es ihn mit einer Vielzahl von Paketen bombardiert (von denen einige sehr groß sind).

URL: http://www.truelink.net/user/mtoole/Linux/ipbomb.c

Autor: unbekannt

IPInvestigator.tgz

Zweck: Sniffer (neu).

URL: http://www2.fwi.com/~rook/exploits/IPInvestigator.tgz

Autor: unbekannt

ipspoof.c

Zweck: Spoofing-Code für Linux (wobei Linux die Kompilierungsplattform ist).

URL: http://www.rat.pp.se/hotel/panik/archive/ipspoof.c

Autor: unbekannt

IP-spoof.txt

Zweck: Ausgezeichneter kleiner Leitfaden zum Spoofing (Code und Beispiele für Linux.)

URL: http://www.unitedcouncil.org/c/IP-spoof.txt

Autor: Brecht Claerhout

irix-buffer.txt

Zweck: Eine Sammlung von Pufferüberlauf-Exploits für IRIX.

URL: http://sunshine.sunshine.ro/FUN/New/hacking/irix-buffer.txt

Autor: Last Stage of Delirium (aus Polen)

irix-csetup.txt

Zweck: Kurze Beschreibung des Exploits von csetup in IRIX.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/irix-csetup.txt

Autor: unbekannt

irix-dataman.txt

Zweck: Exploit für dataman auf IRIX-Systemen, der es Angreifern ermöglicht, unautorisiert Shell-Befehle auf dem Zielsystem auszuführen.

URL: http://www.asmodeus.com/archive/Irix/IRIX-DATAMAN.TXT

Autor: unbekannt

irix-df.c

Zweck: Exploit zum Öffnen einer Root-Shell auf IRIX mit Hilfe von df.

URL: http://samarac.hfactorx.org/Exploits/irix-df.c

Autor: DCRH

irix-fsdump.txt

Zweck: Ergibt Root-Zugriff auf IRIX über einen Puffer-Überlauf in fsdump.

URL: http://www.sabotage.org/rootshell/hacking/irix-fsdump.txt

Autor: unbekannt

irix-iwsh.c

Zweck: Nutzt einen Puffer-Überlauf in iwsh (auf IRIX) aus, um Root-Rechte zu erhalten.

URL: http://www.unitedcouncil.org/c/irix-iwsh.c

Autor: DCRH

irix-login.c

Zweck: Erlaubt Root-Zugriff durch Ausnutzung eines Puffer-Überlaufs in login auf IRIX.

URL: http://www.chaostic.com/filez/exploites/irix-login.c

Autor: David Hedley

irix-login.txt

Zweck: IRIX-login ermöglicht Ihnen die Erzeugung beliebiger Dateien durch Angabe von Pfaden, Verzeichnisnamen und Dateinamen anstelle von Login-Namen. Dieser Text erläutert, wie man dieses Sicherheitsloch ausnutzen kann.

URL: http://www.chaostic.com/filez/exploites/irix-login.txt

Autor: unbekannt

irixmail.sh

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Sicherheitslochs in mail auf IRIX.

URL: http://www.asmodeus.com/archive/Irix/IRIXMAIL.SH

Autor: unbekannt

irix-xhost.txt

Zweck: Bei frisch installierten IRIX-Versionen kann jeder auf den X-Server zugreifen. Dieser Text beschreibt dieses Problem.

URL: http://www.unitedcouncil.org/c/irix-xhost.txt

Autor: unbekannt

irix-xlock.c

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Puffer-Überlaufs in xlock unter IRIX.

URL: http://www.unitedcouncil.org/c/irix-xlock.c

Autor: unbekannt

irix-xterm.c

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Puffer-Überlaufs in xterm unter IRIX.

URL: http://www.sabotage.org/rootshell/hacking/irix-xterm.c

Autor: unbekannt

jakal.c

Zweck: Scannt hinter Firewalls durch Aussenden halboffener Verbindungsanforderungen.

URL: http://pages.ripco.com:8080/~flyght/old/jakal.zip

Autoren: Halflife, Jeff Fay und Abdullah Marafie.

jizz.c

Zweck: DNS-Spoofing-Utility (automatisiert Cache-Spoofing).

URL: http://dewmed.ml.org/online/jizz.c

Autor: Nimrood (basierend auf Code von Johannes Erdfelt)

jolt.c

Zweck: Wirft Windows-95-Rechner durch Aussenden sehr großer, fragmentierter Pakete aus dem Netz. Führt manchmal auch zum Reboot oder schlichten Stehenbleiben des Windows- 95-Rechners.

URL: http://www.tomco.net/~nomad/files/mine/jolt.c

Autor: Jeff w. Roberson

kcms.txt

Zweck: Ergibt durch einen Exploit Root-Berechtigung auf Solaris.

URL: http://www.sabotage.org/rootshell/hacking/ksolaris.txt

Autor: JungSeok Roh (Korea)

kill_inetd.c

Zweck: Denial-of-Service-Attacke durch Bombardieren von inet.d (für Linux geschrieben).

URL: http://www2.fwi.com/~rook/exploits/kill_inetd.c

Autor: unbekannt

kmemthief.c

Zweck: Exploit zum Erlangen von Root-Rechten auf Systemen, wo kmem für die ganze Welt lesbar ist.

URL: http://www2.fwi.com/~rook/exploits/kmemthief.c

Autor: unbekannt

ld.so.c

Zweck: Durch Ausführen einer dynamisch gelinkten setuid-Binary kann ein Benutzer einen Fehler des Laufzeit-Linkers (ld.so) erzwingen und schließlich beliebige Root-Befehle ausführen. (ELF ld-linux.so ist ebenfalls verwundbar.)

URL: http://smash.gatech.edu/archives/ale/9707/0138.html

Autor: KSR[T] (ksrt@DEC.NET) und Patch von Alan Cox.

lemon25.c

Zweck: Erlaubt Root-Zugriff auf Solaris durch Ausnutzen eines Puffer-Überlaufs in passwd.

URL: http://www.geek-girl.com/bugtraq/1997_1/0211.html

Autor: Cristian Schipor (Budapest)

lilo-exploit.txt

Zweck: Erlaubt Root-Zugriff auf Linux durch Ausnutzen eines Sicherheitslochs im Laufzeit-Linker. (Erfordert eine geknackte libc.so.5, verfügbar unter http://www.rootshell.com/ .)

URL: http://www.asmodeus.com/archive/linux/LILO-EXPLOIT.TXT

Autor: BeastMaster V

lin_probe.c

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Puffer-Überlaufs in SuperProbe unter Linux.

URL: http://www.unitedcouncil.org/c/lin_probe.c

Autor: Solar Designer

lin-pkgtool.txt

Zweck: Das Linux-Software-Installationstool pkgtool schreibt seine Log-Dateien mit den Rechten 666, so daß lokale Benutzer Schreibzugriff haben. Das kann es Angreifern ermöglichen, eine neue .rhosts-Datei zu schreiben (und schließlich Root-Rechte zu erlangen.)

URL: http://www.society-of-shadows.com/security/lin-pkgtool.txt

Autor: Sean B. Hamor (hamors@LITTERBOX.ORG)

linux_httpd.c

Zweck: NCSA auf Linux-Systemen hat einen Bug. Entfernte Angreifer können eine Remote-Shell erlangen, indem sie dieses Utility verwenden. (Das ist ein ziemlich schwerwiegender Fehler.)

URL: http://www2.fwi.com/~rook/exploits/linux_httpd.c

Autor: savage@apostols.org

linux_lpr.c

Zweck: Erlaubt Root-Zugriff über lpr, das einen Puffer-Überlauf hat.

URL: http://www.unitedcouncil.org/c/linux_lpr.c

Autor: unbekannt

linux_rcp.txt

Zweck: Der Benutzer nobody kann Root-Privilegien erhalten. (Passen Sie auf Ihren HTTP- Server auf.)

URL: http://www.sabotage.org/rootshell/hacking/linux_rcp.txt

Autor: unbekannt

locktcp.c

Zweck: Killt entfernte Solaris-X86-2.5x-Hosts.

URL: http://www.geek-girl.com/bugtraq/1996_4/0338.html

Autor: Unbekannt. Advisory von Todd Vierling (tv@pobox.com)

logarp.tar.gz

Zweck: Findet Rechner anhand der Hardware-Adresse der Netzkarte, die eine falsche IP- Adresse haben.

URL: http://www.jammed.com/~jwa/Security/logarp.tar.gz

Autor: unbekannt

lquerylv.c

Zweck: Öffnet eine Root-Shell durch Überschreiben eines Puffers in /usr/sbin/lquerylv (nur für AIX).

URL: http://samarac.hfactorx.org/Exploits/lquerylv.c

Autor: Georgi Guninski

lquerypv.txt

Zweck: Lokale Benutzer können alle Dateien (einschließlich der Paßwort-Dateien) lesen, indem sie lquerypv auf AIX verwenden. Folgender Text zeigt wie:

URL: http://samarac.hfactorx.org/Exploits/lquerypv.txt

Autor: unbekannt

minicom.c

Zweck: Nutzt einen Puffer-Überlauf im beliebten Linux-Terminalprogramm Minicom aus.

URL: http://linuxwww.db.erau.edu/mail_archives/server-linux/Sep_97/0451.html

Autor: Gustavo Molina (gustavo@molina.com.br)

mod_ldt.c

Zweck: Speicher-Exploit für Linux. Diese Attacke erzielt Root-Rechte.

URL: http://www.society-of-shadows.com/security/mod_ldt.c

Autor: QuantumG und Morten Welinder

mount-ex.c

Zweck: Linux' mount hat einen Puffer-Überlauf: Dieser Code automatisiert den Exploit.

URL: http://www.asmodeus.com/archive/linux/MOUNT-EX.C

Autor: Bloodmask & Vio Covin

nfsbug.c

Zweck: Nutzt einen Bug in unfsd 2.0 und älteren Versionen. (Errät ein Datei-Handle.)

URL: http://www.klaphek.nl/files/nfsbug_hpux.patch

Autor: Olaf Kirch

octopus.c

Zweck: Killt einen entfernten Host durch Aussenden Tausender Verbindungsanforderungen (für Linux).

URL: http://www.tomco.net/~nomad/files/dos/octopus.c

Autor: unbekannt

oracle.txt

Zweck: Denial-of-Service-Attacke gegen Oracle-Web-Server.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/oracle.txt

Autor: unbekannt

pepsi.c

Zweck: Tool für UDP-Flooding und Denial-of-Service-Attacken (Linux als Kompilierungsplattform).

URL: http://www.society-of-shadows.com/security/pepsi.c

Autor: Soldier@data-t.org

perl-ex.sh

Zweck: Root-Exploit für SUIPERL.

URL: http://www.asmodeus.com/archive/Xnix/PINE_EXPLOIT.SH

Autor: unbekannt

phf.c

Zweck: Scannt nach Hosts, die durch das PHF-Sicherheitsloch verwundbar sind.

URL: http://www.asmodeus.com/archive/web_java/PHF.C

Autoren: Alhambra von Infonexus und The Guild (GOODFELLAS).

phobia.tgz

Zweck: Noch ein Scanner. Sucht nach einer Vielzahl von Sicherheitslöchern.

URL: http://www.sabotage.org/rootshell/hacking/phobia.tgz

Autor: unbekannt

pine_exploit.sh

Zweck: Nutzt eine Schwachstelle im Mail-Client pine aus. (Erzeugt falsche .rhosts- Dateien.)

URL: http://www.unitedcouncil.org/c/pine_exploit.sh

Autor: e-torres@uniandes.edu.co

pingexploit.c

Zweck: Sendet riesige ping-Pakete von einem Unix-Rechner aus. (DoS-Tool.)

URL: http://pxpx.com/underground/dwm/windoze/pingexploit.c

Autor: Bill Fenner

pingflood.c

Zweck: Das beliebte DoS-Tool überschwemmt einen Host mit ping-Paketen. (Nur fünf Zeilen Code.)

URL: http://samarac.hfactorx.org/Exploits/pingflood.c

Autor: unbekannt

pmcrash.c

Zweck: Wirft einen Livingston-Portmaster-Router aus dem Netz. (Pufferüberlauf-Programm.)

URL: http://www.sec.de/sven/pmcrash.c

Autor: The Doc

pop3.c

Zweck: Gewaltattacke gegen POP3-Server.

URL: http://www.asmodeus.com/archive/Xnix/POP3.C

Autor: unbekannt

portscan.c

Zweck: Noch ein Port-Scanner. Identifiziert auf einem entfernten Host laufende Dienste. Klein, leicht, schnell.

URL: http://www.asmodeus.com/archive/IP_toolz/PORTSCAN.C

Autor: pluvius@io.org

psrace.c

Zweck: Nutzt eine Race-Condition in Solaris aus und erzielt Root-Rechte.

URL: ftp://ftp.enslaver.com/pub/exploits/solaris/sun-psrace.c.asc

Autor: Scott Chasin

puke.c

Zweck: Spoofing eines ICMP Destination/Port Unreachable, wodurch eine bestehende IP- Verbindung unterbrochen wird (Denial-of-Service).

URL: http://www.mesopust.com/jogurt/puke.c

Autor: Cowzilla und Pixel Dreamer

qmail_exploit.c

Zweck: Killt ein Qmail-System durch Bombardieren.

URL: http://www2.fwi.com/~rook/exploits/qmail_exploit.c

Autor: Wietse Venema

rdist-ex.c

Zweck: Erzielt eine Root-Shell unter FreeBSD.

URL: http://www.society-of-shadows.com/security/rdist-ex.c

Autor: unbekannt

reflscan.c

Zweck: Scannen Sie mit diesem Utility hinter Firewalls; es öffnet nur halboffene Verbindungen und verhindert dadurch eine Protokollierung, wenn SYN-Pakete nicht explizit durch einen Daemon geloggt werden.

URL: http://lhq.com/~tont0/reflscan.c

Autor: Reflector

resolv+.exp

Zweck: Liest die Shadow-Paßwortdatei.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/resolv+.exp

Autor: unbekannt

rexecscan.txt

Zweck: Umgekehrter Scan, bei dem ein Server eine rsh des Clients benutzend gescannt wird. Interessantes Tool, das die normalen Authentifizierungsprozeduren in rsh und rshd umgeht. Gute Dokumentation.

URL: http://www2.fwi.com/~rook/exploits/rexecscan.txt

Autor: jaeger

rlogin_exploit.c

Zweck: Öffnet eine Root-Shell auf Solaris 2.5.x durch Puffer-Überlauf von gethostbyname.

URL: http://www.netcraft.com/security/lists/gethostbyname.txt

Autor: Jeremy Elson

rpc_chk.sh

Zweck: Scanner-Shellscript, das Listen vielversprechender Hosts durch Abfrage von Name- Servern erzeugt.

URL: http://irdu.nus.sg/security/softwares/rpc_chk.sh

Autor: Yo

rsucker.pl

Zweck: Stiehlt Benutzernamen von r-Clients.

URL: http://www.unitedcouncil.org/c/rsucker.pl

Autor: Lionel Cons

rxvtExploit.txt

Zweck: Erzielt eine Root-Shell durch Ausnutzen eines falschen popen()-Aufrufs in RXVT.

URL: http://www.unitedcouncil.org/c/rxvtExploit.txt

Autor: Dave M. (cmu.edu)

screen.txt

Zweck: Screen auf BSDI hat eine Sicherheitslücke, die es Benutzern ermöglicht, Paßwortdateien zu lesen.

URL: http://www.sabotage.org/rootshell/hacking/screen.txt

Autoren: Jürgen Weigert, Michael Schröder und Oliver Laumann.

sdtcm_convert.txt

Zweck: Tutorial zum Erlangen von Root-Rechten durch Ausnutzen von sdtcm_convert auf Solaris.

URL: http://www.asmodeus.com/archive/slowaris/SDTCM_CONVERT.TXT

Autor: unbekannt

secure_shell.txt

Zweck: Normale Benutzer können sich mit privilegierten Ports verbinden und diese umleiten.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/secure_shell.txt

Autor: unbekannt

sendmail-ex.sh

Zweck: Erlaubt Root-Zugriff auf Linux über sendmail 8.7-8.8.x.

URL: http://ryanspc.com/sendmail/sendmail-ex.sh

Autor: Leshka Zakharoff

seq_number.c

Zweck: Errät TCP-Sequenznummern.

URL: http://irdu.nus.sg/security/softwares/seq_number.c

Autor: Mike Neuman

sgi_html.txt

Zweck: Angreifer können Remote-Code auf SGI-Zielsystemen ausführen.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sgi_html.txt

Autor: Arthur Hagen

sgi_systour.txt

Zweck: Erlaubt Root-Zugriff durch Ausnutzen eines Sicherheitslochs in der Standardinstallation des systour-Pakets auf IRIX 5.3 und 6.2.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07%26before/sgi_systour.txt

Autor: unbekannt

slammer

Zweck: Verwendet yp-Daemonen, um Befehle auf entfernten Hosts auszuführen.

URL: http://www.sabotage.org/rootshell/hacking/slammer.tar.gz

Autor: unbekannt

sol_mailx.txt

Zweck: Exploit für ein Sicherheitsloch in mailx auf Solaris.

URL: http://www.asmodeus.com/archive/slowaris/SOL_MAILX.TXT

Autor: 8LGM (Eight Little Green Men)

sol2.5_nis.txt

Zweck: /usr/lib/nis/nispopulate schreibt Dateien mit Mode 777. Damit könnte ein Benutzer auf alle Dateien schreiben.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sol2.5_nis.txt

Autor: runeb@td.org.uit.no

SolAdmtool.txt

Zweck: Exploit zur Verwendung von Admintool (nur Solaris), um unautorisiert .rhosts- Dateien zu schreiben.

URL: http://www.sabotage.org/rootshell/hacking/SolAdmtool.txt

Autor: unbekannt

solaris_lp.sh

Zweck: Exploit, der lp verwendet, um Root-Rechte auf Solaris zu erzielen.

URL: http://samarac.hfactorx.org/Exploits/solaris_lp.sh

Autor: Chris Sheldon

solaris_ping.txt

Zweck: Killt ein Solaris-2.x-System.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/solaris_ping.txt

Autor: bpowell

solaris_ps.txt

Zweck: Erlaubt Root-Zugriff durch Ausnutzen einer Sicherheitslücke in ps.

URL: http://www.sabotage.org/rootshell/hacking/solaris_ps.txt

Autor: J. Zbiciak

solaris_telnet.c

Zweck: Killt ein entferntes Solaris-System.

URL: http://www.unitedcouncil.org/c/solaris_telnet.c

Autor: unbekannt

sol-license.txt

Zweck: Der Solaris License Manager hat einen Bug, der zu Root-Rechten führt. Der Text in dieser Datei erklärt, wie das geht.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/sol-license.txt

Autor: Grant Kaufmann

sperl.tgz

Zweck: Nutzt einen Puffer-Überlauf in sperl aus. (Das führt zu Root-Zugriff.)

URL: http://www2.fwi.com/~rook/exploits/sperl.tgz

Autor: unbekannt

splitvt.c

Zweck: Puffer-Überlauf in usr/bin/splitvt auf Linux führt zu Root-Berechtigung.

URL: ftp://ftp.enslaver.com/pub/exploits/linux/linux-splitvt.c.asc

Autor: unbekannt

startmidi.txt

Zweck: Startmidi auf IRIX ist suid-root installiert.

URL: http://www.sabotage.org/rootshell/hacking/startmidi.txt

Autor: unbekannt

sunos-ovf.tar.gz

Zweck: Testet SunOS-4.1.x-Binaries auf Puffer-Überläufe.

URL: http://users.dhp.com/~fyodor/sploits/sunos.xterm.resource_manager.overflow.html

Autor: Willy Tarreau

sushiPing.c

Zweck: Erlaubt Root-Zugriff auf SunOS 4.1.x

URL: http://www.unitedcouncil.org/c/sushiPing.c

Autor: SMI von UCB

synk4.c

Zweck: SYN-Flooding-Programm mit per Zufallsgenerator erzeugten IP-Absenderadressen.

URL: http://www.rat.pp.se/hotel/panik/archive/synk4.c

Autor: Zakath, trurl_ und Ultima

SYNpacket.tgz

Zweck: Denial-of-Service-Tool.

URL: http://www2.fwi.com/~rook/exploits/SYNpacket.tgz

Autor: unbekannt

syslogFogger.c

Zweck: Gibt Angreifern Zugriff auf Log-Dateien.

URL: http://samarac.hfactorx.org/Exploits/syslogFogger.c

Autor: panzer@dhp.com

talkd.txt

Zweck: Ermglicht Root-Zugriff durch einen Puffer-Überlauf in talkd.

URL: http://www.asmodeus.com/archive/IP_toolz/TALKD.TXT

Autor: unbekannt

tcpprobe.c

Zweck: Port-Scanner; findet aktivierte Ports auf dem Zielsystem.

URL: http://www.zerawarez.com/main/files/csource/tcpprobe.c

Autor: unbekannt

telnetd_ex.tar.gz

Zweck: Umgebungsvariablen können über eine Telnet-Sitzung übermittelt werden. Die folgende Datei enthält Exploit-Code für diese Attacke (SunOS und Linux).

URL: http://users.dhp.com/~fyodor/sploits/telnetd.LD_PRELOAD.enviropassing.html

Autor: Squidge von Infonexus

tlnthide.c

Zweck: Verbirgt Telnet-Sitzungen, so daß der Angreifer schwerer aufzuspüren und zu verfolgen ist.

URL: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/07%26before/tlnthide.c

Autor: Chaos

ttysurf.c

Zweck: Spioniert Login-Namen und Paßwörter von tty-Sitzungen aus.

URL: http://www.deter.com/unix/software/ttysurf.c

Autor: unbekannt

udpscan.c

Zweck: Scannt Zielsysteme nach offenen UDP-Ports ab.

URL: http://kropf.raex.com/warez/proggies/Unix/udpscan.c

Autor: shadows@whitefang.com

utclean.c

Zweck: Verwischt die Spuren eines Crackers durch Löschen seiner Anwesenheit aus den Log-Dateien.

URL: http://www.kki.net.pl/shmasta/clean/utclean.c

Autor: undrtaker

vixie.c

Zweck: Überschreibt einen Puffer in crontab auf Linux-Systemen (führt zu Root-Zugriff).

URL: http://www.space4less.com/usr/teknopia/security/vixie.c

Autor: Dave G.

web_sniff.c

Zweck: Fängt Benutzernamen und Paßwörter ab, die über die Basis-HTTP-Authentifizierung gesendet werden (mit htpasswd-Paßwortschutz).

URL: http://www.unitedcouncil.org/c/web_sniff.c

Autor: BeastMaster V

wipehd.asm

Zweck: Entfernt die ersten 10 Sektoren einer Festplatte.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wipehd.asm

Autor:unbekannt

wuftpd_umask.txt

Zweck: Die Voreinstellung von umask für wu-ftpd 2.4.2-beta-13 ist 002, wodurch Dateien für jeden schreibbar sind.

URL: http://www-jcr.lmh.ox.ac.uk/rootshell/hacking/wuftpd_umask.txt

Autor: unbekannt

Xfree86 Exploit

Zweck: 3.1.2-Server werden suid root installiert. Dieses Dokument beschreibt, wie man das ausnutzen kann.

URL: http://www.madness.org/hack/hacking/xfree86-ex.txt

Autor: Dave M. (CMU)

xkey.c

Zweck: Ausspionieren von X-Sitzungen.

URL: http://www.paranoia.com/~ice9/xkey.html

Autor: Dominic Giampaolo

xsnoop.c

Zweck: Ausspionieren von X-Sitzungen (ähnlich wie XKEY).

URL: http://www.society-of-shadows.com/security/xsnoop.c

Autor: Peter Shipley

ypsnarf.c

Zweck: Automatisiert die Ausnutzung von Sicherheitslücken in yp und NIS (yellow pages).

URL: http://www.plato-net.or.jp/usr/vladimir/ugtxt/unix/ypsnarf.c

Autor: (David A. Curry). Basierend auf Code von Casper Dik und Dan Farmer.

18.20 Informationsquellen

Im folgenden sind einige Publikationen und Webseiten aufgeführt, die wertvolle Informationen zur Unix-Sicherheit enthalten.

18.21 Bücher

A Guide to NetWare for Unix. Cathy Gunn. Prentice Hall, 1995. ISBN: 0133007162.

Audit Trail Administration, Unix Svr 4.2. Unix Systems Lab. Prentice Hall, 1993. ISBN: 0130668877.

Practical Unix and Internet Security. Simson Garfinkel und Gene Spafford. O'Reilly & Associates, 1996. ISBN: 1565921488.

The Cuckoo's Egg. Cliff Stoll. Doubleday, 1989. ISBN: 0-385-24946-2.

Unix Installation Security and Integrity. David Ferbrache und Gavin Shearer. Prentice Hall, 1993. ISBN: 0130153893.

Unix Security. Miller Freeman. Miller Freeman, 1997. ISBN: 0879304715.

Unix Security: A Practical Tutorial. N. Derek Arnold. McGraw-Hill, 1993. ISBN: 0-07- 002560-6.

Unix System Security. David A. Curry. Addison-Wesley Publishing Company, Inc., 1992. ISBN: 0-201-56327-4.

Unix System Security. Rick Farrow. Addison-Wesley Publishing Company, Inc., 1990. ISBN: 0-201-57030-0.

Unix System Security. Patrick H. Wood und Stephen G. Kochan. Hayden Books, 1985. ISBN: 0-8104-6267-2.

Windows NT Server and Unix: Administration, Co-Existence, Integration and Migration. G. Robert Williams und Ellen Beck Gardner. Addison-Wesley Publishing Company, 1998. ISBN: 0201185369.

18.22 Online-Publikationen

COAST Watch Newsletter. Veraltete, aber dennoch interessante Publikation, die sich auf das Thema Internet-Sicherheit konzentriert. http://www.cs.purdue.edu/coast/coast-news.html

Journal of Internet Security. Zweimonatlich erscheinendes Elektronik-Magazin und Mailing-Liste. Gute Quelle für Informationen von EDI-Sicherheit bis zu neuen Zertifizierungs-/ Audit-Diensten. http://www.csci.ca/

SC Magazine. Monatlich erscheinende Zeitschrift, die sich mit Produkten und Techniken zur Computersicherheit befaßt. http://www.infosecnews.com/

Seven Locks Software's SecurityDigest. Ausführlicher Ratgeber zu verschiedenen Sicherheitsproblemen von Seven Locks. http://www.sevenlocks.com/SecurityDigest.htm

SunWorld Online. Internet- und Unix-Sicherheit von den Leuten bei Sun. http:// www.usec.sun.com/sunworldonline/

18.23 Zusammenfassung

Dieses Kapitel kratzt nur an der Oberfläche der Unix-Sicherheit. Wenn ich ein Buch zu diesem Thema empfehlen sollte, wäre es Practical Unix and Internet Security von Simson Garfinkel und Gene Spafford.



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel