vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


24

Der entfernte Angriff

Dieses Kapitel untersucht die Anatomie eines entfernten Angriffs.

24.1 Was ist ein entfernter Angriff?

Ein entfernter Angriff (Remote-Angriff) ist ein Angriff, der gegen einen entfernten Rechner ausgeführt wird.

Ein entfernter Rechner ist jeder Rechner - ausgenommen der, an dem Sie gerade sitzen - , auf den Sie über das Internet oder ein anderes Netzwerk zugreifen können.

24.2 Die ersten Schritte

Die ersten Schritte eines entfernten Angriffs beinhalten seltsamerweise wenig oder gar keinen direkten Kontakt mit dem Ziel. Das erste Problem eines Crackers ist es, an folgende Informationen zu gelangen:

Das läßt sich schnell und unauffällig herausfinden. Üblicherweise verwendet der Cracker dazu ganz normale Netzwerk-Utilities. Das erste Ziel ist, sich nur einen Überblick zu verschaffen, eine allgemeine Vorstellung davon, wie die Zielumgebung aussieht. Sehen wir uns einmal an, welche Informationen man sammeln kann, ohne das Zielsystem aufzuschrecken.

24.3 Einen kurzen Blick auf das Netzwerk werfen

Ein Cracker könnte damit beginnen, eine Host-Abfrage zu starten. Das Host-Utility sammelt alle verfügbaren Informationen von Name-Servern. Das kann zu einer Menge Informationen führen. Für dieses Kapitel habe ich z.B. eine Host-Abfrage an der Boston University gestartet. Die Ergebnisse wuchsen auf über 1,5 Mbyte an, und ich habe die Verbindung schließlich gekappt. (Zu dem Zeitpunkt waren es ca. 35.000 Zeilen.)

Hinweis:

Der Befehl host

Der Befehl host liefert ungefähr die gleichen Informationen wie eine Kombination von nslookup und dig. host hat jedoch zusätzlich den Vorteil, daß die Informationen in einem leicht lesbaren Format ausgegeben werden, das sich zum lexikalischen Scannen eignet. Mit host können Sie eine netzwerkweite Abfrage starten, indem Sie folgenden Befehl eingeben: host -l -v -t any hostname.com

Hier ist ein Beispiel einer Ausgabe der Boston University:

CS.BU.EDU 86400 IN HINFO SUN-SPARCSTATION-10/40 UNIX
CS.BU.EDU 86400 IN A 128.197.12.2
EE.BU.EDU 86400 IN A 128.197.176.78
EE.BU.EDU 86400 IN HINFO PC WINDOWS-NT
MAESTRO.BU.EDU 86400 IN A 128.197.6.100
MAESTRO.BU.EDU 86400 IN HINFO VISUAL-CX-19-TURBO X-SERVER
DARKSTAR.BU.EDU 86400 IN A 128.197.73.84
DARKSTAR.BU.EDU 86400 IN HINFO PC-CLONE LINUX
BLACK-ROSE.BU.EDU 86400 IN A 128.197.21.54
BLACK-ROSE.BU.EDU 86400 IN MX 10 CGL.BU.EDU
BLACK-ROSE.BU.EDU 86400 IN HINFO SGI-IRIS-4D/25 UNIX
MACADAMIA.BU.EDU 86400 IN A 128.197.20.120
MACADAMIA.BU.EDU 86400 IN HINFO MACINTOSH-II MAC-OS/MacTCP
COD.BU.EDU 86400 IN HINFO DECSTATION-3100 UNIX
COD.BU.EDU 86400 IN A 128.197.160.85
BUPHYC.BU.EDU 86400 IN HINFO VAX-4000/300 OpenVMS
BUPHYC.BU.EDU 86400 IN MX 10 BUPHYC.BU.EDU
BUPHYC.BU.EDU 86400 IN A 128.197.41.41

Auf den ersten Blick sieht dies nur aus wie ein Wirrwarr von Adressen, Hostnamen und Hardware-Angaben. Für einen Cracker sind diese Daten jedoch recht informativ.

Wie Sie sehen, kann ein Cracker bereits durch die Eingabe eines einzigen Befehls an wertvolle Informationen über sein Ziel gelangen.

Sehen wir uns das etwas genauer an. Nehmen wir zum Beispiel cs.bu.edu. Durch die obigen Informationen wissen wir, daß cs wahrscheinlich unter Solaris läuft. (Ich sage wahrscheinlich, weil es auch SparcLinux sein könnte.) Vielleicht können wir an einen gültigen Benutzernamen kommen. Läuft dort finger? Aber sicher:

krazykid Ernest Kim p2 6 Tue 11:32 moria.bu.edu:0.0

Ernest kommt von moria.bu.edu. Aufgrund von Untersuchungen ähnlicher Listings vermuten wir einmal, daß moria sich im cs-Cluster befindet:

CS10.BU.EDU 86400 IN CNAME VIOLIN.BU.EDU
CS11.BU.EDU 86400 IN CNAME CSL.BU.EDU
CS12.BU.EDU 86400 IN A 128.197.10.111
CS12.BU.EDU 86400 IN MX 10 CS.BU.EDU
CS12.BU.EDU 86400 IN HINFO XXX UNIX
CS13.BU.EDU 86400 IN CNAME MORIA.BU.EDU
CS14.BU.EDU 86400 IN A 128.197.10.113
CS14.BU.EDU 86400 IN MX 10 CS.BU.EDU
CS14.BU.EDU 86400 IN HINFO SUN-3/75 UNIX
CS13.BU.EDU 86400 IN CNAME MORIA.BU.EDU

Vielleicht können wir moria benutzen, um seine Freunde und Nachbarn anzugreifen. Wir müssen zumindest ein paar Benutzernamen auf diesem System herausfinden. Läuft auf ihm finger? Ja:

allysony Allyson Yarbrough qterm 73 csa (BABB022-0B96AX01.BU.E
ann317 Ann Lam netscap 35 csa (PUB6-XT19.BU.EDU:0.0)
annie77 Nhi Au emacs-1 38 csa (PUB3-XT30.BU.EDU:0.0)
april jeannie lu tin *43 csa (sonic.synnet.com)
artdodge Adam Bradley pico 40 csb (cs-xt6.bu.edu:0.0)
barford Paul Barford pine *1* csb (exeter)
best Azer Bestavros tcsh 28 csb (sphinx:0.0)
best Azer Bestavros tcsh 0 sphinx (:0.0)
bhatti bhatti ghulam tin 33 csa (mail.evare.com)
brianm Brian Mancuso bash 19 csa (gateway-all.itg.net)
budd Phil Budne tcsh *5* csa (philbudne.ne.mediaone
carter Bob Carter rlogin 11 csb (liquid.bellcore.com)

Auf moria läuft nicht nur finger, sondern wir können auch sehen, was seine Benutzer gerade tun. Einige beantworten Mails (pine), andere editieren Dateien (pico) und einige gehören zum harten Kern der Unix-Fanatiker (emacs). Auch diese Informationen scheinen auf den ersten Blick nicht allzuviel zu offenbaren - außer dem letzten Eintrag natürlich. Bob Carter verwendet rlogin. Obwohl es unwahrscheinlich ist, könnte dies bedeuten, daß es irgendeine Vertrauensbeziehung zwischen moria und einem anderen Rechner gibt.

Lassen Sie uns das Ganze noch einmal rekapitulieren. Obwohl wir erst zwei Befehle eingegeben haben (host und finger), haben wir schon eine Menge herausgefunden.

Cracker beginnen im allgemeinen damit, sich auf diese Weise unauffällig ein paar Informationen zu verschaffen. Diese Informationen stellen natürlich nur Möglichkeiten dar, aber daraus könnte sich schnell einmal eine Gelegenheit ergeben.

Der Fairneß halber muß gesagt werden, daß es schwieriger sein würde, dieselben Informationen über ein privates Netzwerk zu bekommen. Die meisten privaten Netzwerke beschränken den Zugang zu ihren Name-Servern, oder sie schränken zumindest die Art der Informationen ein, die ein solcher Server der Außenwelt preisgibt. Universitäten tun dies dagegen selten. Es wäre einfach zu unpraktisch für sie.

Hinweis:

Sogar Rechnernamen können manchmal Hinweise geben. Ein mir bekannter Systemadministrator ist ein Astronomie-Fan. Als er sein Netzwerk plante, nannte er seine Rechner nach bekannten Asteroiden und Fixsternen. Die Namensgebung war so konsequent, daß Cracker sich die folgende Frage stellten: Könnte dieser Systemadministrator astronomische Namen für NIS verwendet haben? Er hatte.

Nachdem er unterschiedliche Methoden zur Abfrage von Name-Servern ausprobiert hat, wird der Cracker zu anderen Netzwerkdiensten übergehen. Einer davon ist WHOIS.

24.3.1 WHOIS

Der Service WHOIS wird von internic.net betrieben, dem Network Information Center. Die Datenbank enthält die folgenden Informationen:

Eine WHOIS-Abfrage kann auf zwei Arten durchgeführt werden:

Die Informationen, die uns interessieren, sind der Name und die Adresse der technischen Kontaktperson. Diese Informationen scheinen harmlos zu sein, sind es aber nicht. Wie Sie gleich sehen werden, kann die E-Mail-Adresse der technischen Kontaktperson ziemlich wertvoll sein. Außerdem können Sie durch whois-, nslookup- und host-Abfragen die Quelle der Internet-Anbindung des Ziels feststellen, ob das Ziel eine echte oder eine virtuelle Domain ist und so weiter.

Jede noch so kleine Information kann hilfreich sein. Obwohl diese Informationen einzeln gesehen oft wertlos sind, können sie zusammengenommen wertvolle Einblicke in ein Netzwerk liefern. Farmer und Venema haben dies in Improving the Security of Your Site by Breaking Into It so beschrieben:

Was sollten Sie tun? Zuerst sollten Sie Informationen über Ihren (Ziel-) Host sammeln. Es gibt eine Vielzahl von Netzwerkdiensten, die Sie abfragen können: finger, showmount und rpcinfo sind gute Ausgangspunkte. Aber hören Sie danach noch nicht auf. Sie sollten auch DNS, WHOIS, Sendmail (smtp), FTP, uucp und alle anderen Dienste verwenden, die Sie finden können.

Wegweiser:

Improving the Security of Your Site by Breaking Into It von Dan Farmer und Wietse Venema .finden Sie online unter http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html .

Besonders hilfreich kann es sein, Informationen über den Systemadministrator der Site zu sammeln. Wenn Sie sich die Zeit nehmen, die Adresse des Administrators durch verschiedene Suchmaschinen laufen zu lassen, können Sie wichtige Einblicke in sein Netzwerk, seine Sicherheit und seine Persönlichkeit gewinnen.

Insbesondere sollten Sie die Beiträge aufspüren, die der Administrator im Usenet oder Sicherheits-Mailing-Listen gepostet hat. Manchmal spezifizieren sie ihre Architektur, ihre Netzwerktopologie und spezielle Probleme, die sie vielleicht haben. (Hin und wieder zeichnen sie Diagramme in ASCII-Text, mit IP-Nummern und all dem.) Diese Diskussionen könnten Hinweise über die Sicherheit oder Sicherheitsrichtlinien der Site liefern.

Wenn ein Systemadministrator z.B. täglich in Sicherheitsmailinglisten auftritt und über verschiedene Sicherheits-Technologien diskutiert, ist er eindeutig vorbereitet und gut informiert. Falls seine Adresse in solchen Listen oder Foren nicht auftaucht, ist er vielleicht wie die meisten Systemadministratoren: ausreichend sorgfältig und mehr nicht.

Wie dem auch sei; sogar eine ganz geringe Präsenz in solchen Listen läßt vermuten, daß er Advisories liest. Das ist für Cracker ein schlechtes Zeichen, da sie sich zum größten Teil auf mangelndes Wissen des Administrators verlassen müssen.

Hinweis:

Oft wird das Eindringen in ein Netzwerk nicht verhindert, weil das Sicherheitspersonal nicht auf dem laufenden ist. Viele Leute haben einfach nicht die Zeit, sich alle relevanten Sicherheitsadvisories durchzulesen.

Wenn Sie keinen Hinweis darauf finden können, daß die offizielle E-Mail-Adresse des Administrators in einer Sicherheitsmailingliste auftaucht, sollten Sie ein paar alternative Adressen ausprobieren. Eine Methode ist, seinen Benutzernamen an alle Hosts des Netzwerks anzufügen. Wenn sein Benutzername z.B. walross ist und das Netzwerk auf den folgenden Rechnern untergebracht ist:

würden Sie die folgenden Adressen ausprobieren:

24.3.2 finger und rusers

Wenn finger und rusers auf dem Zielsystem laufen, können Sie sogar herausfinden, welche Accounts der Systemadministrator auf anderen Netzwerken hat. Sie können diese Informationen aus den Host-Namen-Berichten ableiten, die sowohl finger als auch rusers zur Verfügung stellt. Entweder im kurzen finger-Format:

prof vladimir kutsman tcsh 72 csa (door1.lotus.com)

im langen finger-Format:

Login name: ulvi In real life: Ulvi yurtsever
Directory: /home/ulvi Shell: /sbin/sh
On since Jun 16 10:48:17 on pts/18 from milano.jpl.nasa.gov
2 minutes 35 seconds Idle Time
Mail last read Tue Jun 16 13:34:30 1998
No Plan.

oder im langen rusers-Format:

dc31245 207.171.0.111:pts/0 Jun 16 14:51 (207.171.10.68)

Leider ist es etwas schwieriger, an diese Informationen zu kommen. Es könnte Stunden oder gar Tage dauern, bevor sich der Systemadministrator von einem fremden Netzwerk aus einloggt. (Wenn Sie nicht wenigstens einen Account auf dem Ziel offenlegen können, haben Sie keine andere Möglichkeit, die letzten Informationen zu sehen.)

Eine Lösung dieses Problems ist es, ein Script zu schreiben, das diese Informationen stündlich sammelt. Irgendwann werden Sie einen Benutzer abfangen können, der sich über Telnet von einem ISP (oder einer anderen Verbindung) aus einloggt. Die Ausgabe über Ulvi läßt z.B. vermuten, daß er einen Account auf milano.jpl.nasa.gov hat. Diese Information an sich ist vielleicht nicht sehr hilfreich. Ihn auf diesem Rechner fingern zu wollen, hat z.B. keinen Zweck, da finger dort deaktiviert wurde. Als ich Ulvis Namen jedoch durch Altavista suchen ließ, fand ich folgende Adresse:

uyurtsever@dynatec.com

Mit Hilfe dieser Adresse konnte ich ihn an anderer Stelle aufspüren.

Wenn Sie beharrlich jede Spur verfolgen, werden Sie schließlich die anderen Accounts des Systemadministrators herausbekommen. Dann können Sie ihn in Listen und Foren besser aufspüren.

24.4 Das Betriebssystem

Der nächste Schritt ist, herauszufinden, welches Betriebssystem das Ziel verwendet. Dieser Schritt kann entweder sehr einfach oder sehr schwierig sein, je nach Konfiguration des Zielsystems.

Im Idealfall ist die Identifizierung des Betriebssystems eine einfache und unkomplizierte Angelegenheit, und meistens ist das auch so. Viele Systeme geben ihr Betriebssystem an, wenn eine neue Login-Sitzung gestartet wird. Unix zeigt zum Beispiel per Voreinstellung die /etc/issue-Datei an, wenn eine neue Instanz von getty gestartet wird. In diesem Fall reicht eine einfache Telnet-Verbindung aus:

Trying 207.171.0.111...
Connected to 207.171.0.111
Escape character is '^]'.
UNIX(r) System V Release 4.0 (207.171.0.111)
login:

Wenn diese Informationen nicht sofort verfügbar sind, können Sie die Befehle host, dig und nslookup ausprobieren. Diese Anfragen bringen genau dieselben Informationen, die ich für cs.bd.edu erhalten habe. In vielen Fällen gibt die Ausgabe das Betriebssystem und die Systemarchitektur an. Diese Informationen müssen jedoch nicht unbedingt korrekt sein. Sie könnten veraltet sein, oder jemand beim Zielsystem könnte diese Listings unabsichtlich oder sogar absichtlich verändert haben.

Wenn diese Methoden alle versagen, müssen Sie es auf andere Weise versuchen. Eine Möglichkeit ist, Socket-Verbindungen zu definierten (well-known) Ports zu öffnen, auf denen spezielle Dienste laufen. Zum Beispiel läuft auf den meisten kommerziellen Betriebssystemen mindestens ein proprietärer Dienst, der auf den anderen nicht läuft. Wenn Sie diese Dienste vorsichtig austesten, können Sie schon viele Kandidaten ausschließen. (Diese Methode hat allerdings einige Nachteile. Wenn auf dem Zielsystem Linux läuft, werden Sie viele falsche Positivmeldungen erhalten. Die Linux-Gemeinde hat die meisten Dienste geklont. Deshalb kann es bei einer oberflächlichen Untersuchung so aussehen, als sei ein Linux-Host ein ganz anderes System.)

Eine weitere Methode ist die Verwendung von Suchmaschinen. In diesem Fall verwenden Sie bekannte Benutzernamen des Zielsystems. Sie suchen dann nach E-Mails oder Usenet- Beiträgen, die dort erzeugt wurden. Ihr Ziel ist es, Header zu lokalisieren, die vom Zielhost stammen. Wenn Sie welche finden, sieht das ungefähr so aus:

Newsgroups: misc.forsale.computers.workstation
Subject: Sparc LX forsale
Date: Thu, 11 Jun 1998 11:08:20 -0400
Organization: Alcatel Network Systems, Inc Raleigh, NC
Lines: 22
Distribution: world
Message-ID: <357FF2E4.C22661A9@aur.alcatel.com>
NNTP-Posting-Host: aursgw.aur.alcatel.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.04 - (X11; U; SunOS 5.6 sun4u)

In der letzten Zeile werden die Umgebung, das Betriebssystem und die Rechnerarchitektur angegeben:

X-Mailer: Mozilla 4.04 - (X11; U; SunOS 5.6 sun4u)

Damit ist der Fall schon so gut wie erledigt. Im obigen Beispiel ist der Zielhost eine Sun Microsystems Sparc Ultra, auf der Solaris und der Netscape Communicator für X laufen.

Hinweis:

Sicherlich gibt es noch andere Methoden, ein System zu knacken. Wenn Ihr Ziel ein Unternehmen ist, das den Versand von Produktinformationen über das Web anbietet, ist es kein Problem, es dazu zu bringen, Ihnen etwas zuzuschicken. Sie könnten auch verschiedene Fehler auf ihren Servern oder durch ihre E-Mail-Gateways erzwingen, die das System preisgeben könnten. Cracker wählen jedoch immer den Weg des geringsten Widerstands. Außerdem bevorzugen sie Techniken, die so wenig Spuren wie möglich hinterlassen.

Ein ernsthafter Cracker wird diesen Vorgang für alle Hosts im Teilnetz des Ziels wiederholen. Es ist für den Cracker zwar immer am besten, wenn er das Zielsystem knacken kann. Aber ein privilegierter Zugriff auf einen Host im Teilnetz des Ziels ist auch schon ein guter Anfang.

24.5 Weitere Untersuchungen

Der nächste Schritt ist, auf der Grundlage der bis jetzt gesammelten Daten weitere Informationen einzuholen. Wenn Sie bei Ihren ersten Untersuchungen ausreichend sorgfältig vorgegangen sind, beinhalten Ihre Daten Informationen über das Betriebssystem des Ziels, die Hardware, vermutliche Vertrauensstellungen und die Topologie des Netzwerks.

Mit Hilfe dieser Informationen können Sie weitere Untersuchungen durchführen, die dazu dienen, potentielle Schwachstellen des gesamten Zielsystems zu entdekken. In den meisten Fällen ist dafür kein direkter Kontakt mit dem Ziel erforderlich.

24.5.1 Hauptschwachstellen des Systems identifizieren

Es gibt mehrere Methoden, Informationen über die Schwachstellen des Zielsystems zu sammeln. Einige Leute meinen, daß Scanner wie ISS und SATAN automatisch Schwachstellen entdecken, und deshalb keine eingehenden Untersuchungen erforderlich seien. Ich bin da anderer Meinung.

Scanner sind ausgezeichnete Tools zur Prüfung Ihres eigenen Netzwerks. Sie können damit eine grobe Suche nach weitverbreiteten Sicherheitslücken vornehmen. Deshalb sparen sie Ihnen eine Menge Zeit, die Sie dazu nutzen können, sich spezielleren Problemen zu widmen.

Hinweis:

Um zu sehen, wie Sie diese Tools für sich nutzen können, sollten Sie sich »Flirting with SATAN« besorgen, eine Fallstudie von Nancy Cook und Marie Corbin. Cook und Corbin verwendeten SATAN, um eine Analyse von ca. 14.000 Hosts in ihrem Netzwerk durchzuführen. Sie finden die Studie unter http://www.trouble.org/security/auditing_course/nancy_cook.ps.

Scanner sind jedoch nicht dazu geeignet (und auch nicht vorgesehen), ein fremdes Netzwerk anzugreifen. Einen Host ohne Autorisierung zu scannen ist ungefähr das gleiche, als würden Sie ein beliebiges Haus in Ihrer Straße auswählen und bei hellichtem Tag ausprobieren, ob sich die Türen oder Fenster öffnen lassen. Das ist nicht besonders raffiniert.

Außerdem hat die starke Verbreitung von Scannern dazu geführt, daß Tools entwickelt wurden, mit denen man die Signaturen beliebter Scanner entdecken kann. Diese Signaturen (die von Log-Einträgen oder Kontrollschleifen-Mustern abgeleitet werden), sind in zu viele Systeme zur Erkennung von Eindringlingen integriert worden. Aus diesem Grund ist von einem willkürlich durchgeführten Scan unbedingt abzuraten. Der Wert der gewonnenen Daten rechtfertigt die Aufmerksamkeit nicht, die ein solcher Scan erregt.

Hinweis:

Es gibt Fälle, in denen es dennoch denkbar ist, daß Sie einen Großscan durchführen möchten. Einer ist, daß Sie über sogenannte Wegwerf-Domains verfügen. Das sind Rechner, die Sie offengelegt, aber noch für nichts verwendet haben. Von einem solchen Rechner aus könnten Sie ohne Bedenken einen Scan ausführen. Wenn Sie das jedoch getan haben, sollten Sie nicht zu lange damit warten, in das Zielsystem einzudringen. Der Systemadministrator dort wird die Sicherheit wahrscheinlich ziemlich schnell erhöhen.

Klüger ist es, sich die Informationen über potentielle Schwachstellen von anderen Quellen zu besorgen, z.B.:

Ich möchte kurz darauf eingehen, wie man an diese Informationen gelangt.

24.5.2 Sammeln von Informationen über System-Schwachstellen

Sie können auf verschiedene Arten an diese Informationen kommen. Wie Sie vorgehen, hängt hauptsächlich von Ihrem letztendlichen Ziel ab. Es gibt zwei Arten von Informationsquellen, und jede hat ihre Vor- und Nachteile. Es sind

Wir wollen uns einmal ansehen, welcher Art und Qualität die dort angebotenen Informationen sind.

24.5.3 Cracker-Sites

Wenn Sie nach einer »quick-and-dirty«-Lösung suchen, können Sie sich sofort den Cracker- Sites zuwenden. Das ist aber wahrscheinlich nicht sehr empfehlenswert.

Cracker-Sites sind ausgezeichnete Quellen für Exploits. Sie können dort oft Quellcode oder sogar kompilierte Binaries finden. Deshalb kommt es Ihnen anfangs vielleicht so vor, als seien Cracker-Sites eine tolle Sache, um schnell zum Ziel zu kommen. Daß dem leider nicht so ist, hat mehrere Gründe:

Der größte Nutzen von Cracker-Sites besteht darin, daß Sie sie benutzen können, um die potentiellen Schwachstellen des Ziels schnell zu identifizieren. Dadurch bekommen Sie einen gewissen Vorsprung vor den akkurateren, legitimen Sicherheitsinformationen.

24.5.4 Legitime Informationsquellen zu Sicherheitsfragen

Legitime Sicherheitsquellen sind ein ausgezeichneter Ausgangspunkt. Sie bieten einige Annehmlichkeiten, die den Cracker-Sites fehlen.

Zum Beispiel verfügen die legitimen Quellen meistens über eine bessere Dokumentation. Diese Dokumentation erläutert meistens besser, wie und warum ein Exploit funktioniert. Außerdem enthält sie wahrscheinlich Informationen darüber, wie man den Angriff verhindern oder entdecken kann. Diese Informationen kommen z.B. in Form von:

Um diese Daten zu sammeln, müssen Sie eine umfassende Suche durchführen. Sie könnten z.B. nach dem Lesen von ersten Advisories entdecken, daß die einzige verfügbare Information eine Beschreibung der Schwachstelle ist - was oft der Fall ist. Hersteller und Sicherheitsteams sind oft zurückhaltend mit dem Posten von detaillierten Informationen, und das ist auch verständlich. (Dies zu tun, würde nur zu weiteren Angriffen einladen.) Deshalb müssen Sie bei Ihrer Suche ein bißchen aggressiver vorgehen.

Nachdem Sie ein paar Advisories über diese oder jene Schwachstelle gelesen haben, sollten Sie nach dem allgemein üblichen Namen oder Jargon-Ausdruck für die Sicherheitslücke suchen. Ein Beispiel ist »das telnetd-Problem von Linux« (bzw. »the Linux telnetd problem«, wenn Sie nach englischen Quellen suchen), eben der Ausdruck, unter dem das Sicherheitsloch bekannt geworden ist. Um diesen Namen herauszufinden, verwenden Sie am besten die ID des Advisories als Suchausdruck.

Wenn Sicherheitsteams ein Exploit-Skript, ein Test-Skript oder einen Kommentar posten, fügen sie meistens eine vollständige Referenz auf das Original-Advisory ein. Zum Beispiel enthält ihre Nachricht etwas ähnliches wie »Hier ist ein Script zum Testen, ob Ihr System für das talkd-Problem verwundbar ist, das in CA-97.04 beschrieben wurde«.

Dieser Satz bezieht sich auf das CERT-Advisory Nummer 97.04, das am 27. Januar 1997 herausgegeben wurde. Um darauffolgende Referenzen auf das Advisory zu finden, geben Sie die CERT-Nummer als Suchausdruck ein. Nachdem Sie einige der gefundenen Dokumente durchgelesen haben, kennen Sie den üblichen Ausdruck für die Sicherheitslücke. Wenn Sie mit diesem eine neue Suche starten, können Sie sowohl legitime als auch Underground-Datenbanken aufspüren. Innerhalb relativ kurzer Zeit werden Sie alle verfügbaren Informationen über diese spezielle Sicherheitslücke gefunden haben.

Wenn Sie Folgebeiträge finden, haben Sie schon halb gewonnen. Es gibt verschiedene Methoden, diesen Prozeß zu beschleunigen. Zum Beispiel ermöglichen Ihnen einige Archive, die Nachrichten nach Diskussionsfäden (Threads) gebündelt zu lesen. Diese Archive sollten Sie bevorzugt verwenden, weil Sie damit schnell einen Überblick über den ersten Beitrag und die Folgebeiträge gewinnen können.

Die Mehrzahl der Sicherheitslisten und -archive bietet diese Möglichkeit jedoch nicht. Deshalb müssen Sie bei diesen wahrscheinlich einen Beitrag nach dem anderen durchforsten.

Eine umfassende Suche lohnt den Aufwand immer. Folgebeiträge beinhalten normalerweise Exploit- und Test-Skripte, die von Sicherheitsteams entwickelt worden sind. Diese enthalten im allgemeinen ausgezeichnete technische Informationen über die Schwachstelle. Zum Beispiel könnte ein Teilnehmer der Liste einen neuen Dreh für den Exploit gefunden haben. Andere haben vielleicht herausgefunden, daß ein verbundenes Programm, eine Include- Datei oder eine Abhängigkeit die wirkliche Ursache des Problems waren. Die Gedanken und Reflektionen dieser Leute sind Gold wert. Wenn Sie diese Informationen studieren, können Sie nicht nur die genaue Ursache der Sicherheitslücke feststellen, sondern auch sicher voraussagen, welche Auswirkungen Ihr Angriff auf das Zielsystem haben wird.

Zu diesem Zeitpunkt haben Sie folgende Informationen:

Der nächste Schritt ist ein Testlauf.

24.6 Einen Testlauf durchführen

Testläufe sind nicht unbedingt erforderlich, aber praktisch. Richten Sie einen Rechner so ein wie Ihr Ziel. Wenn Ihr Ziel z.B. eine SparcStation 2 mit Solaris 2.4 ist, besorgen Sie sich eine solche. Setzen Sie dieses System derselben Attacke aus, die Sie für Ihr Ziel planen.

Die Resultate werden Sie über zwei Dinge informieren:

Dies hat gleich drei Vorteile:

Erstens können Sie feststellen, wie das Ziel auf Ihre Angriffe reagieren wird. Das ist ein ziemlich wichtiger Punkt. Ein identisch konfigurierter Rechner (oder scheinbar identisch konfigurierter Rechner) sollte ähnlich reagieren. Wenn er dies nicht tut, sollten Sie vorsichtig zu Werke gehen. Der Systemadministrator könnte etwas in petto haben.

Wie ich in Kapitel 7, »Kriegsführung im Internet«, beschrieben habe, gibt es fortschrittliche Systeme zur Erkennung von Eindringlingen und zur Ausgabe von Falschinformationen. Diese Systeme bieten irreführende Informationen an, um den Angreifer glauben zu lassen, daß er mit einem bestimmten Betriebssystem und bestimmten Anwendungen arbeitet, obwohl dies nicht der Fall ist. Die meisten Unternehmen können sich solche Tools nicht leisten, aber man kann nie wissen.

Testläufe können dies feststellen und gewisse Anzeichen für die Integrität des Angriffs ermitteln. Bill Cheswicks Ausführungen über Berferd zeigen, daß sogar eine halbherzige Simulation eines verwundbaren Netzwerks effektiv sein kann. Wie bereits in Kapitel 7 erwähnt, ist dies der gegenwärtige Ansatz beim Krieg um Informationen.

Zweitens werden Ihnen die Log-Dateien auf dem simulierten Zielrechner zeigen, welche Fußabdrücke Sie hinterlassen. Auch das ist wichtig zu wissen. Unterschiedliche Versionen bringen unterschiedliche Log-Dateien hervor, und Sie sollten genau wissen, welche Log- Dateien durch Ihren Angriff erzeugt werden. So können Sie planen, wie Sie Ihre Spuren auf dem Ziel Ihres Eindringens verwischen könnten.

Drittens geben Ihnen Testläufe die Möglichkeit, zu sehen, welche Exploits wirklich effektiv sind. Wenn Sie den Code von jemand anderem verwenden (was meistens der Fall ist), können Sie nie sicher sein, daß er so funktioniert, wie Sie es erwarten, bevor Sie ihn nicht ausprobiert haben. Nur weil er auf der Konfiguration der Autoren funktioniert hat, muß das noch lange nicht bedeuten, daß er auch auf Ihrem Ziel funktionieren wird. Das gilt in gewissem Maße natürlich auch für Ihr Testsystem, aber nur abgeschwächt. Wenn Sie gründliche Vorarbeit geleistet haben, dürfte Ihr Testsystem der Konfiguration des Ziels schon ziemlich nahekommen. Sie können natürlich nie wissen, ob der Systemadministrator des Zielsystems selbst geschriebene Sicherheitsprogramme laufen läßt. Ein gewisses Risiko läßt sich nie ganz ausschließen.

24.7 Zusammenfassung

Der in diesem Kapitel beschriebene Prozeß umreißt die wesentlichen Bestandteile eines Angriffs. Diese beinhalten:

Weiterhin ist eine Einschätzung des Gesamtzusammenhangs erforderlich. Einzelne Exploits zu kennen, reicht nicht aus. Ein Cracker muß sein Talent kultivieren, diese Techniken kombiniert anwenden zu können. Das Knacken eines Systems ist ein dynamischer Prozeß. In neun von zehn Fällen wird der Cracker auf Bedingungen treffen, auf die er nicht vorbereitet war. Diese Probleme gilt es kreativ und schnell zu überwinden.

Sie können einen guten Einblick gewinnen, wenn Sie das Verhalten von Crackern und Techniken zur Erkennung von Eindringlingen studieren. Wenn Sie Ihren Feind kennen, haben Sie schon halb gewonnen. Die folgenden Links können Ihnen helfen, dieses Ziel zu erreichen:

Phrack Magazine. Phrack ist ein Untergrund-Journal, das sich auf die unterschiedlichen Methoden des Eindringens in fremde Systeme konzentriert. http://www.phrack.com/

2600: The Hacker Quarterly. 2600 ist ein E-Zine und ein Print-Magazin für Hakker. http:// www.2600.com/

Computer Break-Ins: A Case Study. Leendert van Doorn. http://www.alw.nih.gov/Security/FIRST/papers/general/holland.ps

An Evening With Berferd: in Which a Cracker Is Lured, Endured, and Studied. Bill Cheswick. http://www.alw.nih.gov/Security/FIRST/papers/general/berferd.ps

The Intrusion Detection Archive. Dies ist ein Archiv der Mailing-Liste zu Systemen zur Erkennung von Eindringlingen (Intrusion Detection Systems - IDS). http://www.geek- girl.com/ids/

Artificial Intelligence and Intrusion Detection: Current and Future Directions. Proceedings of the National Computer Security Conference. J. Frank, 1994. Dieses Dokument beschäftigt sich damit, wie man Rechnern beibringen kann, Eindringlinge mit Hilfe üblicher Muster zu erkennen. http://phobos.cs.ucdavis.edu:8001/papers/ncsc.94.ps.gz

An Application of Pattern Matching in Intrusion Detection. Kumar und Spafford. http:// www.raptor.com/lib/ncsc.94.ps

A Pattern Matching Model for Misuse Intrusion Detection. Kumar und Spafford. http:// www.raptor.com/lib/ncsc.pdf

Intrusion Detection in Computers. Victor H. Marshall. ftp://coast.cs.purdue.edu/pub/ doc/intrusion_detection/auditool.txt.Z

An Introduction to Intrusion Detection. Aurobindo Sundaram. http://www.eng.fsu.edu/ ~kuncick/intrusion/intrus.html

ASAX: Software Architecture and Rule-Base Language for Universal Audit Trail Analysis. Ein experimentelles System zur Erkennung von Eindringlingen. Naji Habra, Baudouin Le Charlier, Abdelaziz Mounji und Isabelle Mathieu. ftp://coast.cs.purdue.edu/pub/doc/ intrusion_detection/HabraCharlierEtAl92.ps

Distributed Audit Trail Analysis. Abdelaziz Mounji, Baudouin Le Charlier, Denis Zampunieris und Naji Habra. ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/ MounjiCharlierEtAl94.ps.gz

Michael Sobirey's Intrusion Detection Systems Page. Diese Seite führt derzeit 63 Systeme zur Erkennung von Eindringlingen auf. http://www-rnks.informatik.tu-cottbus.de/ ~sobirey/ids.html

Security Breaches: Five Recent Incidents at Columbia University. Fuat Baran, Howard Kaye und Margarita Suarez. Center for Computing Activities, Columbia University. http:// www.alw.nih.gov/Security/FIRST/papers/general/fuat.ps

The Social Organization of the Computer Underground. Gordon R. Meyer. http:// www.alw.nih.gov/Security/FIRST/papers/general/hacker.txt

There Be Dragons. Steven M. Bellovin. Beschreibung von Angriffen auf die AT&T-Firewall. http://www.alw.nih.gov/Security/FIRST/papers/general/dragons.ps

Automated Tools for Testing Computer System Vulnerability. W. Timothy Polk. http:// www.alw.nih.gov/Security/FIRST/papers/general/tools.ps



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel