Keine Software ist wirklich sicher. Wie die jüngsten Hacker-Aktionen beweisen, gibt es immer Mittel und Wege, sich Zugang zum Betriebssystem oder zu bestimmten Informationen zu verschaffen. Walter Meyer* stellt einige Methoden des Eindringens in DV-Systeme vor und zeigt gleichzeitig, wie man sich dagegen schützen kann. Speziell nimmt er dabei Sicherheitslücken von Unix unter die Lupe.
Sicherheit ist zum neuen Schlagwort in der DV-Welt geworden. Doch nicht der ausfallsichere Betrieb einer Anlage oder die Zuverlässigkeit verwendeter Software stehen dabei im Vordergrund. Vielmehr sind das Absichern von Rechenanlagen gegen unberechtigten Zugriff und der Schutz vor böswilligem oder zufälligem Zerstören von Daten und Programmen beziehungsweise deren Diebstahl gemeint.
Die Tatsache, daß Computer heute Eingang in nahezu alle Bereiche des täglichen Lebens gefunden haben, bringt mit sich, daß zunehmend auch vertrauliche Informationen auf Rechenanlagen gespeichert werden. Gleichzeitig ist damit die Gefahr gegeben, daß Personen, die sich berechtigt oder unberechtigt Zugang zu einem System verschaffen, an diese Informationen gelangen können, wenn nicht entsprechende Schutzmaßnahmen existieren oder geeignete Gegenmaßnahmen getroffen worden sind.
Schutzvorkehrungen werden zum Verkaufsargument
Garantierter Schutz vor unberechtigtem Systemzugang und nachgewiesener Schutz vor unbefugtem Zugriff auf Datenbestände werden somit häufig zum Verkaufsargument von Rechner-Herstellern. Gerade dieser Aspekt erklärt die zunehmende Bedeutung des Begriffs "Sicherheit" in jüngster Zeit. Daß auch Unix-Systeme von dieser Entwicklung nicht unberührt geblieben sind, liegt auf der Hand.
Das Betriebssystem Unix wurde schon relativ früh entwickelt. Es entstand in einer "freundlichen" Umgebung, in welcher der Aspekt des Datenschutzes eher eine sekundäre Rolle spielte. Im Vordergrund stand das Ziel, Mitgliedern eines Entwicklungs-Teams die Möglichkeit zu geben, auf einfache Weise Daten und Programme auszutauschen. Gleichzeitig sollte aber auch jeder Entwickler seine eigene private Umgebung haben, in der er ungestört von anderen Benutzern seiner Arbeit nachgehen konnte. Dieses Mittelmaß zwischen offener und restriktiver Entwicklungs-Umgebung ist charakteristisch für Unix.
Unkenntnis über vorhandene Schutzmechanismen und "schlampige" System-Administration haben gelegentlich dazu geführt, daß Unix als "unsicheres" Betriebssystem bezeichnet wurde. Tatsache ist, daß Unix vom Design her bereits eine ganze Menge an Möglichkeiten bietet, das System sicher zu gestalten. Hinzu kommt, daß mit jeder neuen
Version zusätzliche Sicherheits-Mechanismen in das System eingebaut wurden. Beispiele hierfür sind der Passwort-Alterungsmechanismus bei System V, oder die erweiterten Accounting-Möglichkeiten. Gleichzeitig muß aber auch erwähnt werden, daß Unix eine Reihe von Schwachstellen aufweist, die nicht mehr allein durch pure Anwendung von vorhandenen Sicherheitsmechanismen behoben werden können.
Ein Benutzer, der mit einem Rechner-System arbeiten will, muß sich normalerweise diesem System gegenüber identifizieren. Neben einem Kennungs-Namen muß (sollte) bei Unix-Systemen auch noch ein Passwort angegeben werden. Dieses ist die wichtigste und wohl auch die einzige Hürde, die ein unberechtigter Eindringling nehmen muß, um den Zugang zu einem Unix-System zu finden.
Allerdings wurde gerade bei Unix einiges an Aufwand und Überlegung investiert, um den Passwort-Mechanismus so sicher wie nur möglich zu gestalten. Ein wichtiger Punkt dabei ist, daß das Passwort Paßwort nur in verschlüsselter Form im System gespeichert wird. Bei jedem Login-Versuch eines Benutzers wird das Passwort erneut verschlüsselt und mit dem verschlüsselt im System hinterlegten Passwort verglichen. Stimmen beide Zeichenfolgen überein, ist die Anmeldung erfolgreich. Der Vorteil dieses Verfahrens liegt darin, daß das Passwort selbst nirgendwo im System in lesbarer Form gespeichert wird.
Bislang sind keine Verfahren bekannt, die es erlauben, das Passwort aus der verschlüsselten Zeichenfolge zu rekonstruieren. Die einzige Möglichkeit ist, es zu erraten. Nichttriviale Passworte, bestehen aus Ziffern, Sonderzeichen, Groß- und Kleinbuchstaben; so wird das zufällige Erraten oder Durchprobieren von Passworten ganz erheblich erschwert, Hinzu kommt, daß bei vielen Systemen nach mehreren erfolglosen Login-Versuchen die entsprechende Terminal- oder Datenleitung deaktiviert wird. Erst nachdem der Systemadministrator davon in Kenntnis gesetzt worden ist und er entsprechende Vorkehrungen getroffen hat, kann die Leitung wieder benutzt werden.
Aber nicht nur Eindringlinge können für ein System gefährlich werden. Benutzer, die eine ganz legale Kennung auf einem System haben, könnten Interesse daran haben, eine andere Kennung, insbesondere die des "Super-Users", zu benutzen, um so an Informationen zu gelangen, die für sie sonst nicht zugänglich wären. Bedingt durch die Tatsache, daß die Passwortdatei für alle Benutzer lesbar ist, bietet sich die Möglichkeit, systematisch und ohne Beschränkung so lange Passworte durchzutesten, bis ein Treffer gelingt. Solche Programme, sogenannte "Password Crackers", waren vor fünf Jahren noch nahezu unbekannt; heute gehören sie zum Standardrepertoire eines Hackers.
Die Wahl nichttrivialer Passworte macht es nahezu unmöglich, Passworte zu knacken. Werden Passworte zudem noch regelmäßig geändert, hat ein Password-Cracker überhaupt keine Chance.
Legitime Benutzer haben das Nachsehen
Der Einbruch in ein System kann außer über das Passwort auch auf andere Weise erfolgen. Das Abhören von Übertragungsleitungen - sei es vom Bildschirm zum Rechner oder im Netzwerk von Rechner zu Rechner - ist relativ einfach. Das Verschlüsseln der zu übertragenden Daten erschwert zwar einen Abhörangriff, vollständig sicher ist diese Methode aber auch nicht. Sobald ein Benutzer Zugang zu einem Rechnersystem gefunden hat, gibt es viele Möglichkeiten, um an geschützte Daten heranzukommen, das System zu manipulieren oder zu zerstören.
Eine davon ist das "Trojanische Pferd". Darunter versteht man ein Programm, das neben der gewünschten Funktion noch Aktionen ausführt, die sich zum Nachteil des überlisteten Benutzers auswirken beziehungsweise dessen Sicherheit beeinträchtigen. All dies geschieht unbemerkt vom Aufrufer des Programms. Typisch dabei ist, daß die legitime Berechtigung des überlisteten Benutzers ausgenutzt wird; er selbst führt schließlich das Programm aus, das ihm Schaden bringt.
Ein Programm, das neben der gewünschten Kopie einer Datei noch eine zusätzliche Kopie für den unberechtigten Benutzer erstellt, ist ein typisches Beispiel. Der Betroffene bleibt dabei arglos. Wenn sich das "Trojanische Pferd" nach erfolgter Aktion sogar noch selbst löscht, ist es praktisch unmöglich, es zu entdecken oder nachzuweisen.
Die Schwierigkeit für den Ersteller eines "Trojanischen Pferdes" ist, daß er dafür sorgen muß,- daß sein Programm ausgeführt wird, und nicht das echte System-Programm. Jeder einzelne kann sich also relativ einfach vor "Trojanischen Pferden" schützen, indem er sicherstellt, daß er nur solche Programme ausführt, die "sicher" sind. Dies kann durch folgende Maßnahmen erreicht werden:
- Überprüfung des eigenen Suchpfades für Dienstprogramme und Kommandos;
- kein Ausführen unbekannter Programme in allgemein beschreibbaren Dateiverzeichnissen;
- Schutz der eigenen Umgebung durch Setzen restriktiver Zugriffsrechte.
Programme, die ähnlich wie ein. "Trojanisches Pferd" wirken, aber im Gegensatz dazu nicht vom überlisteten Benutzer, sondern vom Ersteller ausgeführt werden, sind als sogenannte "Spoofs" bekannt. Ein typisches Beispiel dafür ist ein vorgetäuschtes Login-Programm für ein allgemein zugängliches Terminal. Das Programm wartet, bis sich ein ahnungsloser Benutzer einzuloggen versucht, und teilt, bevor es sich entfernt und die Sitzung startet, dem Ersteller des Spoofs den Benutzernamen inklusive Passwort mit.
Computerviren breiten sich schnell im System aus
Eine weitere gefährliche Variante sind Computer-Viren. Computer-Viren sind Programme, die analog zu biologischen Viren, andere Programme infizieren und sich selbst reproduzieren können. Ein infiziertes Programm läuft nach wie vor korrekt ab, kann aber zusätzlich, genau wie ein "Trojanisches Pferd", Aktionen ausführen, die die Sicherheit eines Systems beeinträchtigen oder Daten des Benutzers zerstören. Realisiert wird ein Virus durch ein Stück zusätzlichen Codes, das in ein vorhandenes Programm eingehängt ist (meist am Anfang oder am Ende). Dieser Virus-Teil wird zusätzlich zum eigentlichen Programm durchlaufen.
Das Einschleusen eines Virus in ein System ist relativ einfach. Ein "allgemein nützliches" Virus-Programm, wird in einem Directory abgelegt, auf das jeder zugreifen kann. Wer dann dieses Programm einmal benutzt, infiziert damit seine eigenen Programme.
Viren breiten sich sehr schnell im System aus. Wird ein infiziertes Programm auch noch vom System-Administrator, der normalerweise höhere Berechtigung hat, ausgeführt, kann es auch in geschützte Systembereiche eindringen und schnell das gesamte System zerstören.
Ein Virus ist nur schwer zu entdecken. Die geringfügig erhöhte Laufzeit fällt bei der Programmausführung nicht auf, und der etwas größere Speicherbedarf der Programme kann nur durch permanente Kontrolle der Größe nachgeprüft werden.
Eine der Schwachstellen liegt - wie bereits weiter oben beschrieben - im Passwortmechanismus selbst. Für einen Benutzer, der noch keinen Zugang zum System gefunden hat, ist das Passwort eine echte Barriere. Ist es einem unberechtigten Benutzer aber erst einmal gelungen, in das System einzudringen, etwa über eine "Gast"-Kennung, kann er jederzeit die Passwortdatei lesen und kopieren, da derzeit in allen Unix-Systemen die Datei /etc/passwd für jeden Benutzer lesbar ist. Niemand kann den Eindringling daran hindern, ein Cracker-Programm laufen zu lassen, notfalls auf einer anderen Maschine.
Abhilfe schaffen kann der System-Administrator, der streng darauf achten sollte, daß alle Kennungen, also auch allgemein zugängliche, mit nicht zu einfachen Passworten belegt werden. Weiterhin sollten öffentliche Kennungen, wie zum Beispiel "gast", nur mit beschränkten Rechten ausgestattet werden (resticted shell). Weiterreichend ist der Vorschlag, Passworte in einer gesonderten, nur dem System zugänglichen Datei zu verwalten. Der Zugriff wäre in diesem Fall nur über eine kontrollierte Systemschnittstelle möglich. Diese Lösung ist allerdings nicht Bestandteil von Standard-Unix. Ein weiterer schwacher Punkt in Unix-Systemen ist die Tatsache, daß eine Kennung mit der user id "0", der sogenannte Super-User, praktisch uneingeschränkte Privilegien hat. Falls ein Benutzer also an das Super-User-Passwort herankommt, stehen ihm Tür und Tor offen. Es wäre sinnvoller, die Befugnisse des Super-Users auf mehrere Kennungen mit unterschiedlichen Einfluß- und Aufgabenbereichen zu verteilen, etwa
- Hardware-Konfiguration und Maschinen-Betreuung;
- Betriebssystem- und Software-Betreuung;
- Administration, Accounting und Datenverwaltung.
Der Zugang zu allen Bereichen des Systems wäre damit für einen Eindringling oder unlauteren Benützer des Systems ganz erheblich erschwert.
Einstieg kann auch über gelöschte Files erfolgen
Als weitere Lücke sind die Spezialdateien /dev/mem beziehungsweise /dev/kmem anzusehen, die dem Hauptspeicher zugeordnet sind. Sie lassen sich normalerweise von jedem Benutzer lesen. Wer also über entsprechende Kenntnisse der jeweiligen Systemstruktur verfügt, kann durchaus auf diesem Weg an Informationen gelangen, die ihm anderweitig nicht zugänglich wären.
Ähnlich verhält es sich mit gelöschten Dateien. Aus Performance-Gründen wird durch das "remove"-Kommando rm lediglich der zur Datei gehörige "i-node" (Identifikation der Datei) gelöscht. Die Daten auf dem Speichermedium bleiben jedoch unverändert erhalten. Auch der Directory-Eintrag wird nicht gelöscht, sondern lediglich der "i-node" mit 0 überschrieben. Prinzipiell sind also Dateiname und der Datei-Inhalt nach dem Löschen noch zugreifbar.
Das Problem ist relativ einfach behebbar durch ein eigenes "remove"-Programm, das sowohl den Directory-Eintrag als auch die Programmdaten vor dem logischen Entfernen aus dem Filesystem explizit mit Nullen überschreibt. Verständlicherweise dauert das Löschen einer Datei dann entsprechend länger.
Externe Datenträger sind nicht zu vernachlässigen
Doch nicht nur die Daten auf der Maschine selbst müssen besser geschützt werden, sondern auch die externen Datenträger wie Magnetband oder Floppy. Was nützt ein sicheres Unix-System, wenn die Sicherungsbänder von jedermann gelesen oder kopiert werden können? Die einfachste Abhilfe ist ein strenger Operating-Betrieb. Alle externen Datenträger müssen also stets versperrt aufbewahrt werden und sind nur für den Operator zugänglich. Denkbar wäre auch, Daten in verschlüsselter Form auf externen Datenträgern abzuspeichern. Das ist allerdings mit großem Zeitaufwand verbunden, und für Boot-Bänder oder Floppies sogar unmöglich. Eine weitere Möglichkeit wäre auch, externe Datenträger mit Zugriffsmechanismen und Passworten zu versehen. Doch auch diese Methode wird bislang noch von keinem Unix-System unterstützt.
Ein mächtiges Werkzeug, aber auf einigen Systemen auch die größte Sicherheitslücke, stellt das "s-Bit" dar. Ist das Attribut "s" (s-Bit) für Eigentümer oder Gruppe einer Datei gesetzt, wird während der Ausführungszeit des Programms die effektive Benutzer- (beziehungsweise Gruppen-) Identifikation des Prozesses auf den Eigentümer (beziehungsweise die Gruppe) der Datei gesetzt. Das bedeutet, daß der Prozeß während seiner Laufzeit über die gleichen Rechte wie der Datei-Eigentümer verfügt, unabhängig davon, wer den Prozeß startet.
Ein böswilliger Benutzer könnte demnach ein Programm erstellen, das Aktionen ausführen soll, die für ihn selbst verboten sind. Anschließendes Setzen des s-Bits und Änderung des Datei-Eigentümers auf "root" würde bewirken, daß das Programm zur Ausführungszeit "Super-User"-Privilegien besäße: Ist im Programm selbst nochmals ein "setuid"-Aufruf eingebaut, kann die Identität jedes beliebigen Benutzers angenommen werden. Die gleiche Vorgehensweise gilt übrigens auch für die Gruppenkennung.
Dieses Sicherheitsloch wurde schon vor längerer Zeit erkannt und ist in fast allen Unix-Systemen bereits behoben. In System V beispielsweise wird das s-Bit vor einem Chown-Aufruf zurückgesetzt und auf einigen anderen Systemen wird ein Chown-Aufruf nur von privilegierten Benutzern ausgeführt.
Bereits in den frühen 70er Jahren hatte man erkannt, daß in Rechnersystemen Schutzmechanismen eingebaut werden müssen/ um geheimhaltungsbedürftige
Informationen wirksam vor unberechtigtem Zugriff zu schützen. Auf Betreiben des US-Verteidigungsministeriums fanden erste Aktivitäten statt, um Richtlinien für den Entwurf und die Gestaltung sicherer Systeme zu erarbeiten Ziel dieser Bestrebungen war es, den Entwurf von Rechnersystemen zu fördern, die zur Verarbeitung "geheimhaltungsbedürftiger, vertrauenswürdiger oder anderer schutzwürdiger Daten" geeignet sind.
Als Ergebnis wurde im August 1983 eine Studie (DoD 5200.28-STD) mit dem Titel "Kriterien für die Bewertung vertrauenswürdiger DV-Anlagen" herausgegeben. Diese Untersuchung, die auch unter dem Namen "Orange Book" bekannt ist, entstand unter der Mitarbeit des National Bureau of Standards und der Firma Mitre. Dort werden in abstrakter Form Sicherheitskriterien für Betriebssysteme beschrieben, die in vier hierarchische Gruppen untergliedert sind:
- Gruppe D: minimaler Schutz;
- Gruppe C: benutzerbestimmbarer Schutz;
- Gruppe B: vorgeschriebener Schutz;
- Gruppe A: verifizierter Schutz.
Die Gruppen C und B selbst sind wieder in Klassen unterteilt (C1, C2
beziehungsweise B1, B2 und B3), wobei aufsteigende Nummern indizieren, daß höherwertige Sicherheits-Qualifikationen erreicht werden. Für Unix sind vor allem die Gruppen C und B interessant. Standard-Unix-Systeme können durch nachträgliche Änderungen, also ohne das Design des Kerns grundlegend zu ändern, zu Klasse-C-Systemen "aufgerüstet" werden.
Systeme der Klasse B hingegen leiten ihren Sicherheitsanspruch davon
ab, daß bereits vom Design her konsequent Sicherheits-Konzepte berücksichtigt werden (Objekt-Subjekt-Beziehungen, Referenzmonitor). Die Realisierung (Implementierung) von B-Systemen muß weitgehend mit Hilfe formaler Methoden durchgeführt werden, damit jederzeit nachweisbar bleibt, daß das zugrundeliegende Sicherheitsmodell auch erfüllt wird.
Ein System, das die Spezifikation A1 (Gruppe A kennt nur Klasse AD erfüllt, unterscheidet sich von einem S B3-System dadurch, daß es verifiziert ist. Das heißt, es kann und muß zusätzlich ein formal-theoretischer Beweis erbracht werden, daß dieses System vom Konzept her frei von Sicherheitslücken ist, und allen spezifizierten Sicherheitsansprüchen gerecht wird.
Standard-Unix weist vom Design her bereits viele Eigenschaften auf, die als Voraussetzung für ein sicheres Betriebssystem angesehen werden können. Wenn sich alle Benutzer des Rechners, insbesondere aber der System-Administrator, der Gefahr eines zu lockeren Umgangs mit Zugriffsrechten sowie Passworten bewußt sind, und alle vorhandenen Möglichkeiten, die Unix bietet, konsequent ausgeschöpft werden, um gegebene Sicherheitslücken zu schließen, kann bereits ein Standard-Unix-System in einen relativ sicheren Zustand gebracht werden.
Viele Unternehmen haben diese Tatsache erkannt und bieten Software-Pakete an, die den System-Administrator und die Benutzer dabei unterstützen, Sicherheitslücken aufzufinden und zu beheben. Angefangen von der Kontrolle, ob jede Kennung mit einem nicht zu trivialen Passwort gesichert ist, bis hin zum Aufspüren "verdächtiger" Programme mit Namen shell, su im Benutzerbereich beziehungsweise dem Lokalisieren von Dateien mit Eigentümer root und gesetztem s-Bit gibt es eine ganze Reihe von Möglichkeiten, um bereits mit relativ einfachen Mitteln eine Vielzahl von Sicherheitslücken aufzudecken. Kommandos zum physikalischen Löschen von Dateien, oder erweiterte Protokoll-Funktionen bringen zusätzlichen Schutz.
Die mittlerweile schon zahlreich angebotenen Sicherheitspakete für Unix sind ein erster erfreulicher Schritt auf dem Weg zu sicheren Systemen. Doch auch Rechner- und Systemhersteller sowie internationale Gremien arbeiten schon seit längerer Zeit daran, Unix-Systeme sicherer zu gestalten.
So haben AT&T und Gould Anfang 1987 das "Secure Unix System White Paper" herausgegeben, in dem sie gemeinsam Vorschläge zur Gestaltung von sicheren Unix-Systemen unterbreiten. In Europa arbeitet die X/Open-Arbeitsgruppe "Security" an konkreten Richtlinien für die Auslegung sicherer Unix-Systeme. Darüber hinaus haben einige Unternehmen System-Implementierungen der Stufen C2 beziehungsweise B1 realisiert.