INHALTSVERZEICHNIS i

Inhaltsverzeichnis   

1  Einf uhrung  1

2  Schw achen im System  3

2.1  Gefahren f ur die Netzwerksicherheit  3

2.2  Der Benutzer als Sicherheitsfaktor  4

2.3  Aktive und passive Sicherheitsm angel  6

2.4  Gefahren ung unstiger Konfigurationen  7

2.4.1  Das UNIX Dateisystem  7

2.4.2  Zugangserlaubnis auf Benutzerebene  9

3  Systematik bei der Suche nach Sicherheitsl ucken  10

3.1  Einstufung der Verwundbarkeit  10

3.2  Methoden des Angriffs  11

3.2.1  Denial-of-Service Angriffe  11

3.2.2  Angriffe von innen  14

3.2.3  Angriffe von außen  16

3.2.4  Spoofing Angriffe  17

4  Die Sicherheits-Werkzeuge  20

4.1  Der automatisierte Angriff  20

4.2  Scanner  20

4.3  Paßwortbrecher  23

4.4  Destruktive Programme  25

4.5  Sniffer  27

4.6  Intrusion Detection Systeme  29

4.6.1  Common Intrusion Detection Framework  33

5  Untersuchung der Sicherheits-Werkzeuge  35

5.1  Scanner  36

5.2  Korrektur der Systemschw achen  46

5.3  Paßwortsicherheit  49

5.4  Simulation von Angriffen  50

5.5  Sniffer  51

INHALTSVERZEICHNIS ii

5.6  Aufdecken von Sniffern und Scannerattacken  52

5.7  Intrusion Detection Systeme  54

5.8  Simulation eines erfolgten Angriffs  57

5.9  IDS nach einem Angriff  59

6  Bewertung der Untersuchungsergebnisse  62

6.1  Aufzeigen der Schw achen  62

6.2  Erkennung von Angriffen  63

7  Der Sniffer-Detektor  65

7.1  Methoden des Sniffer-Detektors  65

7.1.1  Prozeßvergleich  66

7.1.2  Namensuche  67

7.1.3  Signatursuche  68

7.1.4  Promiscuoustest  70

7.1.5  K odersuche  70

7.2  Installation des Detektors  72

8  Benutzung des Sniffer-Detektors  73

8.1  Erfahrungen mit dem Detektor  77

9  Res umee und Ausblick  79

A  Abk urzungsverzeichnis  82

B  Glossar  83

C  Verwendete Werkzeuge und Programme  85

C.1  Scanner  85

C.2  Paßwortbrecher  86

C.3  Angreifer und Trojaner  86

C.4  Sniffer  87

C.5  Intrusion Detection Systems  87

C  6 Detektoren  87

ABBILDUNGSVERZEICHNIS iii

Abbildungsverzeichnis

1 Angriffspunkte in Netzwerken . . . . . . . . . . . . . . . . . . . . . 2 2 Zugriffsrechte des UNIX Dateisystems . . . . . . . . . . . . . . . . . 7 3 Verbingsaufbau unter TCP/IP . . . . . . . . . . . . . . . . . . . . . . 12 4 Privilegien von Root unter FTP . . . . . . . . . . . . . . . . . . . . . 17 5 Beispiel f¨ ur TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6 Spoofing Angriff unter TCP/IP . . . . . . . . . . . . . . . . . . . . . 18 7 Beispiellauf von IdentTCPscan . . . . . . . . . . . . . . . . . . . . . 22 8 Netzwerk mit Sniffern . . . . . . . . . . . . . . . . . . . . . . . . . 28 9 Angriff auf einen Web-Server . . . . . . . . . . . . . . . . . . . . . . 30 10 Interne ¨ Uberwachung durch ein IDS . . . . . . . . . . . . . . . . . . 31

11 Externe ¨ Uberwachung durch ein IDS . . . . . . . . . . . . . . . . . 31 12 Fragment¨ uberlappung . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13 IDS Architekturmodell . . . . . . . . . . . . . . . . . . . . . . . . . 33 14 Auszug aus einem Strobe-Scan . . . . . . . . . . . . . . . . . . . . . 38 15 Prim¨ are Zieleigenschaften . . . . . . . . . . . . . . . . . . . . . . . 43 16 Analyse und Korrekturvorschlag im Detail . . . . . . . . . . . . . . . 44 17 Vorhandene Betriebssysteme im ¨ Uberblick . . . . . . . . . . . . . . . 46 18 chkexploit Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 19 Systemanalyse mit dem S3 . . . . . . . . . . . . . . . . . . . . . . . 48 20 Daten aus einem Snifferdurchlauf . . . . . . . . . . . . . . . . . . . 53 21 NFR-Statistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 22 RealSecure-Ereignisse mittlerer Priorit¨ at . . . . . . . . . . . . . . . . 57 23 Graphische Darstellung der Netwerkaktivit¨ at . . . . . . . . . . . . . . 58 24 Warnmeldung aufgrund der NetBus Aktivit¨ at . . . . . . . . . . . . . 61 25 Detailierte Warnmeldung . . . . . . . . . . . . . . . . . . . . . . . . 61 26 Benachrichtigung an das gescannte System . . . . . . . . . . . . . . 65 27 Methoden der Sniffersuche . . . . . . . . . . . . . . . . . . . . . . . 66 28 Installationsmodus des Detektors . . . . . . . . . . . . . . . . . . . . 74 29 K¨ oderprogramm f¨ ur das TELNET-Protokoll . . . . . . . . . . . . . . 76

Abstrakt

Ein stetiges Wachstum der Rechnernetze birgt die Gefahr in sich, daß es zu Schw¨ achen im Bereich der Netzwerksicherheit kommen kann. Um dieser Gefahr entgegen zu wirken, bietet sich der Einsatz von Sicherheits-Werkzeugen an. Hierbei handelt es sich um Programme, die durch Anwenden verschiedener Strategien Rechnersysteme auf Schwachstellen hin ¨ uberpr¨ ufen bzw. das Netzwerk ¨ uberwachen und Alarm schlagen,

sobald ein Angreifer versucht, in das System einzudringen. In dieser Arbeit werden Schw¨ achen von Rechnernetzen aufgezeigt, die sich ein Angreifer zunutze machen k¨ onnte. Auf dieser Erkenntnis basierend, findet eine Untersuchung der Sicherheits-Werkzeuge bez¨ uglich ihrer M¨ oglichkeiten statt, diese Schwachpunkte zu beheben. Desweiteren wird im Rahmen dieser Arbeit ein Werkzeug entwickelt, das zum Aufsp¨ uren von Programmen dient, die den Netzwerkverkehr abh¨ oren.

Abstract

A continuous growth of computer networks includes the danger of possible holes in the network-security. To counteract this danger security-tools offer their aid. These tools are programs, which use a variety of strategies to search for holes in computer-systems respectively watch the network traffic and sound the alarm if somebody tries to intrude the system.

In this paper weaknesses of computer networks are shown, which can be used by intruders to take control over a system. Based on this cognition, an analysis of the security-tools takes place. The analysis shows the capabilities of these tools in how far they are able to eliminate those weaknesses. Moreover in the scope of this paper a detector-tool will be developed. This tool is able to detect programs, which are used to eavesdrop the network traffic.

uhrung 1 Einf ¨

In den vergangenen Jahren fand eine zunehmende Vernetzung der Computer statt. Ein wesentlicher Beitrag hierzu wurde durch die Einf¨ uhrung desWorld Wide Web geleistet. W¨ ahrend bis Ende der 80er Jahre das Internet noch gr¨ oßtenteils f¨ ur die Forschung genutzt wurde, erh¨ alt der ” vernetzte“ Computer zusehens Einzug in den Alltag. Beispiele hierf¨ ur sind Begriffe wie Homebanking und Teleshopping . Viele Dienstleistungen k¨ onnen direkt von zu Hause aus genutzt werden, so daß hierdurch eine Erh¨ ohung des Lebensstandards erreicht werden konnte. H¨ aufig bringen Vorz¨ uge aber Nachteile auf anderer Ebene mit sich. So auch in diesem Fall, denn vernetzte Systeme k¨ onnen relativ leicht f¨ ur illegale Zwecke mißbraucht werden. Beispielsweise ist es m¨ oglich, einen ferngesteuerten ” Bank¨ uberfall“ durchzuf¨ uhren, indem mit Hilfe eines PC’s versucht wird, in das System einer Bank einzudringen.

Diese Gefahr ist nicht neu, aber dennoch gibt es zwei wichtige Punkte zu beachten. 1. Die Zahl der Nutzer ist rapide gewachsen und damit auch die Zahl potentieller Angreifer. Dieses hat zur Folge, daß Sicherheitsl¨ ucken wesentlich schneller entdeckt werden. Zudem ist durch das rasante Wachstum des Internets eine Anonymit¨ at entstanden, die zu einem ” schnellen“ Angriffsversuch verleitet.

2. Netzwerke unterliegen einem st¨ andigen Wandel, sei es durch neue Applikationen, Einbindung von Gesch¨ aftspartnern oder zur Verbesserung der Remote-Access-Verbindungsm¨ oglichkeiten der eigenen Mitarbeiter. Aber jede ¨ Anderung

kann dazu f¨ uhren, daß sich eine L¨ ucke in der Sicherheitsstruktur ¨ offnet und

wie in Abbildung 1 zu sehen ist, gibt es in einem Netzwerk viele verschiedene Angriffspunkte[6]. Beispiele f¨ ur diese Angriffspunkte werden in den folgenden zwei Kapiteln gezeigt.

Daraus ergibt sich heutzutage das Problem, das es viele potentielle Angreifer gibt und ein Großteil der Systemadministratoren sich nicht im klaren dar¨ uber ist, welche Sicherheitsl¨ ucken das eigene System hat[1]. Um diesem Sicherheitsproblem entgegen wirken zu k¨ onnen, stehen verschiedene Programme zur Verf¨ ugung. Die Auswahl reicht von Scannern, die das System nach bekannten Schw¨ achen absuchen, bis hin zu Programmen, die in der Lage sind, den Netzwerkverkehr zu ¨ uberwachen und gegebenenfalls vorher definierte Maßnahmen zu ergreifen.

Der Schwerpunkt der Diplomarbeit ist es, diese Werkzeuge aufzuzeigen und eine Untersuchung bez¨ uglich ihrer M¨ oglichkeiten durchzuf¨ uhren. Sollte sich zeigen, daß f¨ ur bestimmte Aufgaben keine geeigneten Werkzeuge zur Verf¨ ugung stehen, ist es weiterhin Aufgabe dieser Arbeit, zumindest f¨ ur einen Bereich ein entsprechendes Werkzeug zu entwickeln.

In den Kapitel 2 - 4 werden die Grundlagen zu diesem Thema vermittelt. Kapitel 2 behandelt zun¨ achst Sicherheitsm¨ angel, die haupts¨ achlich auf den Menschen zur¨ uckzuf¨ uhren sind, die technischen Details und die Einstufung der Sicherheitsm¨ angel in Kategorien folgen im Kapitel 3. Eine Darstellung der verschiedenen Werkzeugarten wird in Kapitel 4 pr¨ asentiert.

Kapitel 5 behandelt die eigentliche Untersuchung. Hier werden die Werkzeuge unter verschiedenen Bedingungen getestet und die Ergebnisse dargestellt. Eine Bewertung dieser Ergebnisse folgt in Kapitel 6.

Abschließend besch¨ aftigen sich Kapitel 7 und 8 mit der Entwicklung eines Sicherheits- Werkzeuges und dessen Einsatz.

2 Schw¨ achen im System

G¨ abe es ein sicheres System, d.h. es w¨ are keine ” L¨ ucke im System“ vorhanden, k¨ onnte

ein Angreifer nicht eindringen. Es ist daher notwendig, diese Schw¨ achen in der Sicherheit des Systems aufzusp¨ uren und zu eliminieren. In diesem Kapitel werden verschiedene Schw¨ achen aufgezeigt, die nicht auf Hard- oder Softwarefehler zur¨ uckzuf¨ uhren sind und mit relativ geringem Aufwand beseitigt werden k¨ onnen. Trotz der Einfachheit dieser Schw¨ achen, d¨ urfen sie nicht ¨ ubersehen werden und m¨ ussen bei der sp¨ ater folgenden Systemanalyse entdeckt werden.

2.1 Gefahren f ¨ ur die Netzwerksicherheit

Eine Untersuchung der Firmen In Touch GmbH und PSI-Net Germany GmbH[7] hat gezeigt, daß Unternehmen, und damit auch meist deren Mitarbeiter, in 90 Prozent aller F¨ alle nicht gen¨ ugend auf die Gefahren vorbereitet sind, die sich durch den Zugang zum Internet ergeben. Bei einer ¨ Uberpr¨ ufung verschiedener Firmen konnten folgende M¨ angel ermittelt werden:

• Die Sicherheitsbelange werden von der IT-Abteilung ” nebenbei“ mit erledigt,

d.h. sie werden im wesentlichen vernachl¨ assigt.

• Einmal eingerichtete Schutzmechanismen werden zu selten auf den neuesten Stand gebracht, so daß bereits ver¨ offentlichte Schw¨ achen weiterhin beibehalten werden.

• In der Annahme, das eigene Unternehmen sei kein lohnendes Ziel, werden Investitionen im Bereich der Sicherheit eingespart. Daß das Rechnersystem m¨ oglicherweise indirekt mißbraucht werden kann, wird dabei h¨ aufig ¨ ubersehen und

das Sicherheitsanliegen von Datensch¨ utzern wird leichtsinnig abgetan. Konkurrierende Firmen sind aber durchaus am Know-How anderer Firmen interessiert, z.B. um sich einen Vorteil am Markt zu verschaffen[11]. So hat eine Studie in Zusammenarbeit mit der amerikanischen Bundesbeh¨ orde FBI ergeben, daß fast zwei Drittel der untersuchten Organisationen und Unternehmen Opfer eines An- griffs waren[21].

2.2 Der Benutzer als Sicherheitsfaktor 4

• F¨ ur den Fall, daß eine Manipulation des Systems eingetreten ist, liegt in der Regel kein Notfallplan vor.

• Es wird davon ausgegangen, daß ein Angreifer ein System nur einmal heimsucht. Erfahrungen haben aber gezeigt, daß dem nicht so ist.

• Zwischen den Clients/Servern werden Informationen unverschl¨ usselt ¨ ubertragen.

Ein Abh¨ oren des Datenstroms und das Herausfiltern von Benutzernamen und Paßw¨ ortern wird dadurch stark vereinfacht.

• Es wird angenommen, daß eine einmalige Sicherheitsschulung des Netzwerkverwalters und die Anschaffung einer Firewall einen ausreichenden Schutz des eigenen Systems bieten.

Diese Untersuchung zeigt, daß zun¨ achst einmal der Faktor Mensch in die ¨ Uberpr¨ ufungen mit einbezogen werden muß, wenn es um die Feststellung von Sicherheitsl¨ ucken ¹ in den Netzwerken geht.

2.2 Der Benutzer als Sicherheitsfaktor

Eine von Robert Morris und Ken Thompson durchgef¨ uhrte Untersuchung ¨ uber Paßwortsicherheit[3]

hatte zum Ergebnis, daß die technischen M¨ oglichkeiten von den Anwendern nicht ausreichend genutzt wurden. Eine Untersuchung von 3289 Paßw¨ ortern, die ¨ uber einen

l¨ angeren Zeitraum gesammelt wurden, f¨ uhrte zu folgendem Ergebnis: 15 Paßw¨ orter bestanden aus nur einem ASCII-Zeichen

72 bestanden aus zwei ASCII-Zeichen und

464 waren nur drei ASCII-Zeichen lang

477 waren bereits vier Zeichen lang, bestanden aber nur aus alphanumerischen Zeichen

706 F¨ alle waren bereits f¨ unf Zeichen lang, aber entweder nur in Klein- bzw. Großbuchstaben

L¨ ucke“ bevorzugt wird.

”

2.2 Der Benutzer als Sicherheitsfaktor 5

605 Paßw¨ orter waren 6 Zeichen lang, leider stets klein geschrieben

492 Paßw¨ orter waren Namen oder W¨ orter, wie sie in diversen W¨ orterb¨ uchern zu finden sind.

Das bedeutet, 2831 Paßw¨ orter bzw. 86% fielen in eine dieser Kategorien. Betrachtet man Tabelle 1 so zeigt sich, wie der Berechnungsaufwand zur Entschl¨ usselung von der Wortl¨ ange und der Auswahlm¨ oglichkeit an Zeichen abh¨ angt. Die Zahl m¨ oglicher Kodierungen kann mit m n berechnet werden, wobei m die L¨ ange des Alphabets und n die L¨ ange des Paßwortes darstellt. Die Werte in Tabelle 1 geben die maximale Zeitspanne an, die f¨ ur die Ermittlung eines Paßwortes entsprechender L¨ ange ben¨ otigt wird und veranschaulichen den exponentiell anwachsenden Zeitbedarf. Als Grundlage f¨ ur diese Hochrechnung diente das Perlskript pcrack, welches auf einem Pentium 133 unter Linux 2.0.35 zum Einsatz kam.

Neben den schwachen Paßw¨ ortern hat die unter [7] beschriebene Untersuchung ergeben, daß Benutzer recht achtlos mit dem Zugangsschutz auf interner Ebene umgehen. So werden Paßw¨ orter unter das Mauspad geschrieben oder eingeloggte Rechner w¨ ahrend der Mittagspause nicht gesperrt.

H¨ aufig sind zwar die Daten, die von den Benutzern gespeichert werden, f¨ ur einen Angreifer recht uninteressant, aber zum einen erleichtert dieser Zugang weitere Angriffe auf das System, so daß fr¨ uher oder sp¨ ater auch in empfindlichere Bereiche eingedrungen werden kann, zum anderen kann dieser Zugang auch als ” Sprungbrett“ benutzt werden. Dadurch ist es dem Aggressor m¨ oglich, durch auslegen falscher Spuren unerkannt zu bleiben.

2.3 Aktive und passive Sicherheitsm¨ angel 6

2.3 Aktive und passive Sicherheitsm¨ angel

Wie bereits in der Einleitung erw¨ ahnt, liegen die Gefahren f¨ ur die Systemsicherheit nicht ausschließlich bei den Benutzern, sondern vielfach auch bei den Systemadmini-stratoren und nicht zuletzt bei den Herstellern.

Es ist heutzutage nicht selten, daß es an qualifiziertem Personal mangelt. Deswegen werden bei der Installation der Rechnersysteme die Voreinstellungen des Herstellers ¨ ubernommen. Diese Einstellungen sind aber meist auf Benutzerfreundlichkeit und nicht auf Sicherheit ausgelegt. Genau dies kann sich ein Angreifer zunutze machen. Als Beispiel hierf¨ ur dient die Tatsache, daß viele Systeme (meist Sun Systems ² ) so Trusted-Host“-Datenbank ³ ein einfaches Plus steausgeliefert werden, daß sie in ihrer ”

hen haben, d.h. jeder Rechner gilt als vertrauensw¨ urdig. Dies ist ¨ uberraschender Weise vielen Administratoren nicht bekannt.[4]

In einer groben Vereinfachung kann man die Sicherheitsm¨ angel, die durch den End-Benutzer bzw. den Systemadministrator entstehen, in die Gruppe der aktiven bzw. passiven Sicherheitsl¨ ucken einordnen.

Bei den aktiven Sicherheitl¨ ucken handelt es sich meist um Hilfsmittel, die unmittelbar nach der Installation zur Verf¨ ugung stehen. Dies gilt f¨ ur auf den ersten Blick harmlos erscheinende Eigenschaften, wie die M¨ oglichkeit ¨ uber Ethernet oder Internet

einen Drucker zu betreiben, aber auch f¨ ur das oben erw¨ ahnte Beispiel, der ” Trusted-Host“-Datenbank.

Dem gegen¨ uber gibt es die passiven M¨ angel. In diesem Fall sind zwar verschiedene Hilfsmittel f¨ ur die Systemsicherheit vorhanden, diese werden aber bei der Installation nicht aktiviert. Ein h¨ aufiger Grund hierf¨ ur ist, daß Anwender ¨ uber deren

Existenz nicht informiert sind. Von Seiten der Vertreiber hingegen werden diese Hilfsmittel nicht standardm¨ aßig aktiviert, da sie beispielsweise sehr große Datenmengen erzeugen und auf Rechnern mit geringer Kapazit¨ at schnell dazu f¨ uhren, daß anderweitig ben¨ otigte Ressourcen nicht mehr zur Verf¨ ugung stehen[1]. Es wird somit dem Administrator die Entscheidung ¨ uberlassen, ob die Hardwarekonfiguration in der Lage

ist, die angebotenen Hilfsmittel und die dadurch anfallenden Daten zu verarbeiten. Die bisher genannten Sicherheitm¨ angel sind im wesentlichen bekannt. Die sp¨ ater

² Versionsnummern wurden in der Studie von L. van Doorn[4] nicht genannt.

³ Zitat[5]: ” Als Trusted-Host wird ein System bezeichnet, welches durch den Einsatz entsprechender

Soft- bzw. Hardware gew¨ ahrleistet, daß empfindliche Informationen bearbeitet werden k¨ onnen.“

2.4 Gefahren ung¨ unstiger Konfigurationen 7

zu untersuchenden Sicherheits-Werkzeuge m¨ ussen daher in der Lage sein, diese Probleme aufzuzeigen und gegebenenfalls Hinweise zur Abhilfe bereitstellen.

2.4 Gefahren ung ¨ unstiger Konfigurationen

Ein System ordentlich ⁴ zu installieren, ist kein ausreichender Schutz, um Einbr¨ uchen vorzubeugen. Wird aufgrund von Zeitmangel, Bequemlichkeit, Unwissenheit usw. das System nicht optimal konfiguriert oder m¨ oglicherweise absichtlich mißkonfiguriert, k¨ onnen sich gef¨ ahrliche Sicherheitsl¨ ucken ergeben. Einige Beispiele aus dem Bereich der UNIX-Betriebssysteme, die im Rahmen dieser Untersuchung explizite Ber¨ ucksichtigung finden, werden hier aufgezeigt.

2.4.1 Das UNIX Dateisystem

Das UNIX Dateisystem ist eine elementare Grundlage f¨ ur die Sicherheit dieses Systems. Es wirkt auf den ersten Blick leicht verst¨ andlich mit seinen Abstufungen user, group und world, die jeder Datei zugeordnet sind. Jeder Stufe werden wiederrum Zugriffsrechte zugeordnet, die das Lesen, Schreiben oder Ausf¨ uhren einer Datei gestatten. Abbildung 2 zeigt eine m¨ ogliche Einstellung. Nichts desto trotz kann es sehr schwierig sein, dieses System mit all seinen Feinheiten zu verwalten.

Es gibt beispielsweise die M¨ oglichkeit, einer neu erstellten Datei vorher festgelegte Zugriffsrechte zuzuweisen. Daf¨ ur wird von UNIX der Befehl umask zur Verf¨ ugung

⁴ Ordentlich bedeutet, eine Installation gem¨ aß Handbuch durchzuf¨ uhren.

2.4 Gefahren ung¨ unstiger Konfigurationen 8

gestellt. ¨ Ublicherweise ist der Wert, der diesem Maskierungsbefehl ¨ ubergeben wird,

auf 022 gesetzt. Das bedeutet, daß nur der Besitzer Schreibrechte auf diese Datei hat, allerdings ist sie allgemein lesbar und falls m¨ oglich auch ausf¨ uhrbar[8]. Das Problem hierbei ist, daß vielen Benutzern dieser Zustand nicht bekannt ist und ein ausspionieren von Daten somit beg¨ unstigt wird. In diesem Zusammenhang gibt es noch eine weitere Gefahr. Wird das Network Filesystem (NFS) von Sun verwendet, so reicht es sogar aus, daß entweder die Lese- oder Ausf¨ uhrberechtigung gesetzt ist, um eine Datei auszulesen, da es aus Sicht des Systems keinen Unterschied zwischen diesen Rechten gibt[8].

Der n¨ achste Aspekt betrifft haupts¨ achlich die Administration. Es handelt sich dabei um die M¨ oglichkeit, ein Programm mit den Rechten des Besitzers auszuf¨ uhren ⁵ . Dies wird erreicht, indem das SUID- oder SGID-Bit (Set User ID bzw. Set Group ID) gesetzt wird. Eine solche Maßnahme ist immer dann erforderlich, wenn ein nicht privilegierter Benutzer Anweisungen ausf¨ uhren will, die bestimmte Privilegien erfordern. M¨ ochte beispielsweise ein ” normaler“ Benutzer sein Paßwort ¨ andern, so muß er

auf die Datei /etc/passwd zugreifen. Damit dieser Benutzer aber nicht zuf¨ allig oder absichtlich Zeilen hinzuf¨ ugt oder entfernt, erh¨ alt er nur indirekt durch das Programm passwd Zugriff auf diese Datei. Um seine Aufgabe zu erf¨ ullen, muß dem Programm durch setzen des SUID-Bits dieses Privileg gew¨ ahrt werden. Da passwd einzig und allein diese Aufgabe erf¨ ullen kann, wird die Sicherheit des Systems hierdurch nicht beeintr¨ achtigt.

Bei komplexeren Programmen hingegen kann es durchaus sein, daß das Programm Funktionen beinhaltet, die auf den ersten Blick nicht ersichtlich sind. So verhielt es sich z.B. bei dem Programm /usr/lib/preserve, welches noch vor einigen Jahren eingesetzt wurde ⁶ . Das Programm wurde in seinen Zugriffsrechten nicht eingeschr¨ ankt, obwohl es seine Funktion auch mit weniger Privilegien h¨ atte erf¨ ullen k¨ onnen. Einem Angreifer bot sich so die M¨ oglichkeit, ohne große Schwierigkeiten Administratorrechte zu erlangen. Um die Sicherheit eines Systems zu gew¨ ahrleisten, ist es daher notwendig, die Privilegien der Dienstprogramme auf ein Minimum zu reduzieren. Eine weitere Schw¨ ache, die sich ein Angreifer im Zusammenhang mit dem Dateisystem zu Nutze machen k¨ onnte, ist die Tatsache, daß einige Administratoren es bevor-

⁵ Normalerweiseerh¨ alt ein Programm die Rechte des Ausf¨ uhrenden

⁶ Die ausf¨ uhrliche Darstellung hierzu befindet sich auf S.123 in [8].

2.4 Gefahren ung¨ unstiger Konfigurationen 9

zugen, das aktuelle Arbeitsverzeichnis in die Liste der ausf¨ uhrbaren Pfade einzutragen[10]. Diese kleine Bequemlichkeit birgt eine große Gefahr in sich. Ein Beispiel: Root m¨ ochte sich die Dateien eines Benutzers anschauen. Er wechselt dazu in das Verzeichnis des Benutzers und f¨ uhrt dort das Kommando ls aus. Im Normalfall w¨ urde jetzt das Programm /bin/ls ⁷ gestartet. Liegt aber folgende Skriptdatei mit dem Namen ls in genau diesem Verzeichnis, so wird folgendes ausgef¨ uhrt: chmod 4755 /bin/bash -- SUID der Shell setzen rm ls -- Beweise l¨ oschen ls -- nat¨ urlich noch den Inhalt auflisten

Jedem Anwender, der die Shell /bin/bash aufruft, stehen alle Privilegien eines Admini-strators zur Verf¨ ugung. Dieses verh¨ altnism¨ aßig leicht zu durchschauende Beispiel l¨ aßt sich noch deutlich subtiler gestalten, so daß hierdurch betr¨ achtlicher Schaden entstehen kann.

2.4.2 Zugangserlaubnis auf Benutzerebene

Unter UNIX ist es normalerweise jedem Benutzer gestattet, eine eigene .rhosts Datei anzulegen. Wenn dieses Verfahren mit bedacht eingesetzt wird, stellt es einen großen Vorteil dar, da es m¨ oglich ist, sich in die entsprechenden Systeme einzuloggen, ohne daß ein Paßwort eingeben werden muß. Desweiteren ist es erlaubt, anderen Benutzern auf die gleiche Weise, also ohne Verwendung von Paßw¨ ortern, Zugang zu dem System zu gestatten. Beispiel: Anwender 1 erlaubt Anwender 2 das Einloggen ohne Paßwort, Anwender 2 wiederum hat eine eigene .rhosts Datei, die es Anwender 3 gestattet in das System von Anwender 2 zu gelangen. Die Gefahr dieser Methode liegt darin, daß ein Angreifer, der das Paßwort von Anwender 3 ermitteln konnte, automatisch Zugang zu den Systemen von Anwender 1 und 2 hat.

Die in diesem Kapitel angef¨ uhrten Sicherheitsm¨ angel sind prim¨ ar auf den Menschen zur¨ uckzuf¨ uhren, daß heißt auf Bequemlichkeit und Unwissenheit. Bei der automatisierten Sicherheit¨ uberpr¨ ufung sollte das Aufdecken dieser Schw¨ achen kein Problem darstellen.

⁷ Der genaue Pfad ist systemabh¨ angig und kann variieren.

10

3 Systematik bei der Suche nach Sicherheitsl ¨ ucken

Um ein Rechnersystem auf Sicherheitsl¨ ucken hin zu untersuchen, muß zum einen festgestellt werden, wo ¨ uberhaupt Schwachstellen zu finden sind, durch die Angreifer in das System eindringen und es manipulieren k¨ onnen. Zum anderen sollten die Mittel und Vorgehensweisen, die bei einem Einbruchsversuch ¨ ublicherweise verwendet

werden, bekannt sein, um sie besser abwehren zu k¨ onnen. Im ersten Teil dieses Kapitels werden die Schw¨ achen bez¨ uglich ihrer Risikostufe in Kategorien eingeteilt. Im zweiten Teil folgt dann eine eingehende Beschreibung der unterschiedlichen Bedro-hungsformen.

3.1 Einstufung der Verwundbarkeit

Um ein System optimal vor einem Angriff sch¨ utzen zu k¨ onnen, ist es ein Vorteil zu wissen, in welchem Bereich er stattfinden k¨ onnte. Dazu teilt man die Sicherheitsl¨ ucken in drei Gefahrenkategorien ein[1]. Dadurch lassen sich im Falle eines erkannten Angriffs schneller gezielte Gegenmaßnahmen treffen und bei der Beseitigung der M¨ angel kann dies in der Reihenfolge ihrer Risikostufe geschehen, so daß die gr¨ oßten Bedrohungen als erstes entfernt werden k¨ onnen. Auf der untersten Stufe, der Kategorie C, sind die ” Denial-of-Service“ Angriffe (DoS) angesiedelt, wobei es Angriffe gibt, die

• die Ressourcen des Systems besch¨ adigen oder zerst¨ oren,

• das System ¨ uberlasten, so daß es f¨ ur prim¨ are Aufgaben oder f¨ ur andere Nutzer nicht mehr zur Verf¨ ugung steht. Angriffe dieser Art gew¨ ahren dem Angreifer ¨ ublicherweise keinen weiteren Zugriff auf

das System. F¨ ur gr¨ oßere Netzwerke ist diese Form des Angriffs meist von geringerer Bedeutung[1].

Im Gegensatz zur Kategorie C existiert f¨ ur die Kategorien A und B kein Oberbegriff. Sicherheitl¨ ucken der Kategorie B beziehen sich auf Angriffe von innen, die es lokalen Benutzern erm¨ oglichen, ohne Autorisation ihre Privilegien zu erweitern. W¨ ahrend Denial-of-Service Angriffe meist betriebssystemabh¨ angig sind, liegen die Schwachstellen der Kategorie B typischerweise bei den Anwendungen.

3.2 Methoden des Angriffs 11

Die gr¨ oßte Bedrohung geht von einer Sicherheitsl¨ ucke der Kategorie A aus, die es einem Angreifer erm¨ oglicht, das System von außen direkt zu manipulieren. F¨ alle dieser Art sind meist auf schlechte Systemadministration bzw. Mißkonfiguration zur¨ uckzuf¨ uhren[1]. Ein Beispiel, das allerdings auf einen Applikationsfehler zur¨ uckzuf¨ uhren ist, wird in der Zeitschrift Network Computing[6] erw¨ ahnt: ” [. . . ]So weist der Internet-Information-Server 3.0 von Microsoft die Sicherheitsl¨ ucke auf, daß auf ihm (fremder) Code ausgef¨ uhrt werden kann, wenn nach einer vom Server aktiv gepushten URL ein Punkt ( ” .“) eingef¨ ugt wird.“

3.2 Methoden des Angriffs

Neben den Angriffsmethoden der jeweiligen Kategorie, werden soweit vorhanden, verschiedene L¨ osungsstrategien gezeigt, die zur Abwehr eingesetzt werden k¨ onnen. In der sp¨ ater folgenden Untersuchung der Sicherheits-Werkzeuge kann daran eine Bewertung nachvollzogen werden, inwieweit diese Werkzeuge einen Administrator nicht nur ¨ uber m¨ ogliche Sicherheitsm¨ angel aufkl¨ aren, sondern auch Vorschl¨ age zur Verbesserung machen k¨ onnen.

3.2.1 Denial-of-Service Angriffe

Die Angriffsmethoden der Kategorie C lassen sich in weitere vier Gruppen unterteilen. Service Overloading tritt ein, sobald innerhalb einer kurzen Zeitspanne eine Vielzahl von Netzwerkanfragen an einen Serverd¨ amon eines einzelnen Rechners gestellt werden. Die genauen Werte h¨ angen von den zur Verf¨ ugung stehenden Systemressourcen ab. Sobald diese Ressourcen ersch¨ opft sind, ist der Rechner nicht mehr in der Lage, in angemessener Zeit auf weitere Anfragen zu reagieren bzw. neu hinzu kommende Anfragen werden verworfen. Hatte das System beispielsweise die Aufgabe, Loginversuche von außerhalb zu protokollieren, f¨ uhrt das Service Overloading dazu, daß keine Aufzeichnung mehr stattfindet. Message Flooding ist im Prinzip dem Service Overloading ¨ ahnlich. In diesem Fall

wird das System mit Anfragen wie z.B. rlogin oder echo request geflutet. Ein großer Teil der Ressourcen muß f¨ ur die Bearbeitung dieser Anfragen zur Verf¨ ugung gestellt werden. In Extremf¨ allen kann es zu einem Puffer¨ uberlauf kommen, der

3.2 Methoden des Angriffs 12

zu einem Systemabsturz f¨ uhrt[8]. Ein Systemabsturz hat dabei nicht die alleinige Konsequenz, daß der Rechner nicht mehr zur Verf¨ ugung steht. Unter bestimmten Bedingungen, die auch provoziert werden k¨ onnen, wird der Arbeitsspeicher in eine Datei ausgelagert. Nach einem Absturz kann ein Angreifer diesen Speicherauszug nach wichtigen Informationen wie Benutzerpaßw¨ orter durchsuchen[20].

Da sich beide Methoden recht ¨ ahnlich sind, trifft dies auch auf die Gegenmaßnahmen zu. Laut Simson Garfinkel und Gene Spafford[8] kann man leider recht wenig gegen diese Angriffe unternehmen. Ein Vorschlag den sie geben, ist es, ein großes Netzwerk in mehrere kleine Subnetze aufzuteilen, so daß eine Attacke lediglich einen kleinen Bereich betrifft.

Eine weitere Gegenmaßnahme w¨ are im Falle eines Angriffs, mit Hilfe eines Netzwerkmonitors die Art und Herkunft festzustellen. Gelingt es z.B. die Hardwareadresse einer lokalen Ethernet Karte heraus zu bekommen, kann unter Umst¨ anden der Verursacher ermittelt werden.

Ebenfalls hilfreich kann es sein, wenn der angegriffene Dienst vom Internet-D¨ amon inetd initiiert wurde. Dieser bietet mit der nowait Option die M¨ oglichkeit, zu viele Anfragen, die in sehr kurzer Zeit eintreffen, abzulehnen und eine Nachricht an den Syslog-D¨ amon zu ¨ ubergeben, daß dieser Dienst nicht mehr zur

Verf¨ ugung steht. Dadurch kann zwar gezielt ein einzelner Dienst ausgeschaltet werden, der Server selbst bleibt aber in Betrieb und kann zumindest den Vorfall protokollieren.

Clogging Eines der bekanntesten Beispiele hierf¨ ur ist das Synflooding unter Verwendung von TCP/IP. Soll eine Verbindung aufgebaut werden, so geschieht dies uber ein Drei-Wege-Handshake, wie in Abbildung 3 zu sehen ist ⁸ . Der Client ¨

⁸ Die Funktion der Initial Sequence Numbers (ISN) wird in Abschnitt 3.2.4 beschrieben.

3.2 Methoden des Angriffs 13

schickt eine SYN Nachricht an den Server. Dieser reagiert, indem er ein SYN-ACK zur¨ ucksendet und darauf wartet, daß der Client dies wiederum mit einem ACK beantwortet. Genau hier setzt der Synflooder an. Er schickt zwar viele SYN Anfragen zum Server, beantwortet aber kein einziges SYN-ACK. Der Server muß aber f¨ ur einen gewissen Zeitraum ⁹ alle Verbindungen bzw. deren Anfragen im Speicher halten. Diese Form des Angriffs f¨ uhrt also dazu, daß der Kernel-Puffer ¨ uberl¨ auft. Sobald dies geschehen ist, kann der Server keine weiteren Anfragen mehr bearbeiten, im schlimmsten Fall kann es zum Systemabsturz kommen.

Um diesem Angriff entgegen zu wirken, bietet sich der Einsatz von Filtern an, die zumindest teilweise in der Lage sind, gef¨ alschte Absenderadressen zu erkennen und zu verwerfen[12]. Eine weitere Teill¨ osung stellen SYN-Cookies dar, die z.B. unter Linux angeboten werden. Bei den SYN-Cookies handelt es sich um eine Signatur, die eine Authentifikation des Client erm¨ oglicht. Zur Erzeugung der Signatur werden u.a. Quelladresse, Quellport und ein geheimer Zahlenwert als Eingaben f¨ ur eine kryptographische Hash-Funktion verwendet. Laut Erik Schenk kann der Server nun anhand dieser Signatur und den Paketdaten ¨ uberpr¨ ufen, ob die Absenderadresse gef¨ alscht ist oder nicht. Um einen unn¨ otigen Verbrauch der Rechenkapazit¨ at durch die Berechnung der Signatur zu vermeiden, wird dieses Verfahren erst dann angewendet, sobald ein Synflooding stattfindet[28]. Nicht eindeutig aus dieser Quelle geht hervor, wie die Authentifizierung der verwendeten Geheimzahl durchgef¨ uhrt wird.

Das Verfahren stellt in sofern eine Teill¨ osung dar, daß w¨ ahrend eines Angriffes zwar Verbindungen zu authentifizierten Rechnern aufgebaut werden k¨ onnen, da diese Anfragen ¨ uber einen eigenen Pufferbereich abgearbeitet werden. F¨ ur Rechner, die keine SYN-Cookies verwenden, gibt es weiterhin keine M¨ oglichkeit, den angegriffenen Rechner zu kontaktieren.

Signal Grounding Bei dieser Methode handelt es sich um einen physikalischen Angriff, bei dem beispielsweise das Signal eines Netzwerkkabels geerdet wird. Diese Form des Angriffs ist hier nur der Vollst¨ andigkeit halber aufgef¨ uhrt und wird nicht weiter ber¨ ucksichtigt, da die im folgenden untersuchten Werkzeuge auf eine ¨ Uberpr¨ ufung der Software ausgelegt sind.

⁹ Sofern eine Verbindung nicht genutzt wird mindestens bis zum Timeout.

3.2 Methoden des Angriffs 14

3.2.2 Angriffe von innen

H¨ aufig handelt es sich bei diesen M¨ angeln um fehlerhafte Software, die es einem louber das System zu erlangen ¹⁰ . kalen Benutzer erm¨ oglicht, unautorisierte Kontrolle ¨

Lokal“ bedeutet in diesem Fall nicht, daß der Benutzer physisch in der unmittelba-”

ren Umgebung des Systems sein muß, sondern vielmehr, daß er die M¨ oglichkeit hat, sich in das System beispielsweise ¨ uber rlogin einzuloggen. Es spielt dabei keine Rolle,

ob dieser Zugang auf legalem Wege erreicht oder mit Hilfe einiger Sicherheitsm¨ angel der im Folgenden beschriebenen Kategorie A etabliert wurde. In letzterem Fall kann aber eventuell durch sorgf¨ altige Beobachtung, z.B. durch eine Monitorfunktion eines Sicherheits-Werkzeuges, bereits im Vorfeld ein m¨ oglicher Angriff entdeckt werden. Erfolgt beispielsweise ein remote login aus einem anderen Land oder auf einem selten genutzten Account werden verst¨ arkt Programme gestartet, die Informationen ¨ uber

das Netzwerk und seine Benutzer bereitstellen, so sollte das Monitorprogramm einen entsprechenden Warnhinweis an den Administrator geben.

Um die Gefahren zu veranschaulichen, die sich durch Sicherheitsl¨ ucken der Kate-gorie B ergeben, wird exemplarisch ein sendmail Fehler besprochen, desweiteren wird ein Programmierfehler gezeigt, welcher h¨ aufig zu Sicherheitsrisiken f¨ uhrt. Sendmail ist eines der wichtigsten Programme und sollte jedem Benutzer zur Verf¨ ugung stehen, da es dieses Programm erst erm¨ oglicht Mails zu verschicken[1]. Weil sendmail auf einen privilegierten Port (Port 25) zugreift, darf es nur von einem Administrator gestartet werden. Durch einen Programmfehler ist es jedoch m¨ oglich, die Prozedur der Benutzeridentifikation zu umgehen, so daß jeder Benutzer sendmail im D¨ amon-Modus starten kann. Des weiteren ist es m¨ oglich, durch senden eines SIGHUP Signals ein Neustart des Programms zu erzwingen. Dieser Neustart wird mit Administratorrechten durchgef¨ uhrt. Wenn die Umgebungsvariablen entsprechend manipuliert wurden, kann ein Angreifer diese Privilegien zum Ausf¨ uhren anderer Programme nutzen.[13]. Bei vielen Programmen, die vom Benutzer eine Eingabe unbestimmter L¨ ange er-fordern, besteht die Gefahr, das es zu einen Puffer¨ uberlauf kommt. F¨ ur Standardeingaben wie beispielsweise Namen, Adressen usw. ist es ¨ ublich, vorher ein Feld fester

L¨ ange zu definieren, in dem der Text eingetragen wird. Aus verschiedenen Gr¨ unden,

¹⁰ In einigen F¨ allen ist hierf¨ ur aber auch eine schlechte Systemkonfiguration veranwortlich, die bereits in Abschnitt 2.4 angesprochen wurde.

3.2 Methoden des Angriffs 15

uber die hier nur Vermutungen angestellt werden k¨ onnten, wird auf eine ¨ ¨ Uberpr¨ ufung

der L¨ ange des eingegebenen Textes verzichtet. Mit dem entsprechendem Wissen ist es nun m¨ oglich, einen ¨ Uberlauf zu erzwingen. Die ¨ uberz¨ ahligen Zeichen einer Eingabe werden vom Angreifer so gew¨ ahlt, daß vorhandene Befehlsfolgen des Programms durch neue, vom Angreifer gew¨ ahlte Befehlsfolgen ersetzt werden. Es erfordert zwar einen sehr hohen Kenntnisstand, um derartige Angriffe durchzuf¨ uhren, andererseits sind viele Programme gegen¨ uber dem Puffer¨ uberlauf anf¨ allig[1]. Eines der bekanntesten Beispiele d¨ urfte der Internetwurm sein. Von dem Wurm wurde unter anderem ausgenutzt, daß der Finger-D¨ amon fingerd den Eingabestrom ¨ uber die C-Routine gets erhielt. Wie bei einer ganzen Reihe von I/O-Routinen ¨ alterer

C-Bibliotheken wird hierbei ein Puffer¨ uberlauf nicht ber¨ ucksichtigt. Obwohl vielen erfahrenen Programmierern dieses Problem bekannt ist, wird wenig an dieser Programmiertechnik ge¨ andert, so daß die Routinen weiterhin benutzt werden und deren Gefahr nach und nach wieder in Vergessenheit ger¨ at[14].

Es bleibt die Frage, welche Maßnahmen zur Verf¨ ugung stehen, um diese Sicherheitsm¨ angel zu beheben. Die wahrscheinlich effektivste aber wohl auch aufwendigste Methode f¨ ur die Systemsicherheit w¨ are die sorgf¨ altige Programmierung mit einer anschließenden Softwarepr¨ ufung. Erst danach folgt die Suche nach Schwachstellen mit den Sicherheits-Werkzeugen.

Bez¨ uglich von Programmierfehlern, wie dem sendmail-Problem, bleibt wohl nur die ¨ Uberpr¨ ufung aller wichtigen Programme anhand einer versionsabh ¨ angigen Fehlerliste, die stets dem neusten Stand der Erkenntnis entsprechen sollte. Diese Methode hat zwar den Nachteil, daß sie erst funktioniert, nachdem ein Fehler bekanntgegeben wurde, daf¨ ur ist sie aber auf alle Formen von Sicherheitsl¨ ucken anwendbar, so auch im Fall des Puffer¨ uberlaufs.

Um das potentielle Sicherheitsrisiko des Puffer¨ uberlaufs aufzudecken, ist eine weitere Maßnahme denkbar. Dem zu untersuchenden Programm wird ein viel zu großer Eingabestrom angeboten. Wird diese Eingabe ohne L¨ angenpr¨ ufung direkt ¨ ubernommen, werden daf¨ ur nicht vorgesehene Datenbereiche ¨ uberschrieben. Je gr¨ oßer der ¨ uberschriebene Bereich ist, desto gr¨ oßer ist auch die Wahrscheinlichkeit, daß das Programm zum Absturz gebracht wird. Ist der Versuch, das Programm zum Absturz zu bringen, erfolgreich, kann von einer Anf¨ alligkeit gegen¨ uber einem Puffer¨ uberlaufan- griff ausgegangen werden.