In diesem Kapitel behandeln wir unser entwickeltes Verfahren. Der erste Abschnitt führt zunächst die Analyse der Problemstellung aus. Darin definieren wir den Bedrohungsgegenstand, um daraus resultierende Sicherheitsziele zu definieren. Im nächsten Abschnitt präsentieren wir die kontrollierte Software-Installation auf Linux-Systemen. Zu Beginn stellen wir die Systemvoraussetzung zusammen. Weiter schildern wir den Lösungsweg einer kontrollierten Software-Installation. Hinweise zu einzelnen Bestandteilen geben wir im Anschluss, die wir mit einer Übersicht der Benutzerschnittstelle abrunden. Dem folgt ein Abschnitt zur Evaluierung, den wir nachdem üblichen Schema durchführen. Im letzten Abschnitt halten wir eine kritische Diskussion über den gewählten Ansatz.

Zu Beginn der Analyse grenzen wir den Begriff „Software-Installation“ näher ein. Dies ist zum einen hilfreich bei der Annährung des Problems. Zum anderen treten dadurch die bestehenden Mängel deutlich sichtbar hervor, wie wir sehen werden.

Grundsätzlich bezeichnet „Software-Installation“ die Erweiterung eines Betriebssystems um die jeweilige Softwarekomponente. Dieser Vorgang kann sowohl manuell durch den Benutzer, als auch automatisiert mit Werkzeugen erfolgen. In unserer Ausarbeitung betrachten wir die automatisierte Variante und konzentrieren uns auf die Programme. Im anderen Fall müsste der Benutzer überwacht werden. Denn bei manuellen Installationen obliegt die Kontrolle des Installationsprozesses trivialer Weise dem ausführenden Benutzer. Er hat das Wissen über die Verzeichnisse im System, in denen neue Dateien erstellt werden. Er weiß von jeder durchzuführenden Änderung der Systemkonfiguration, denn letzten Endes führt der Benutzer die Operationen selbst aus. Unter dem Aspekt der Kontrolle ist diese Variante einer automatisierten Installation gegenüber weit voraus. Anzumerken ist der sicherliche Komfortverlust unter einer manuellen Installation.

Im Vergleich zwischen händischer Vorgehensweise und der Benutzung von Paketmanagern ergeben sich die bestehenden Mängel: es existiert weder eine Kontrolle noch Übersicht der tatsächlich vollzogenen Modifikationen am System. Gegenwärtig wird diese Schieflage durch automatisierten Bedienkomfort und Vertrauen in die Software Hersteller und Repositories aufgewogen. Wir zeigen folgend unter welchen Umständen das Vertrauen zur Bedrohung wird.

Bei näherer Betrachtung stellt sich heraus, dass Software-Installationen aus externen Quellen stets eine potentielle Bedrohung darstellen. In unserem angenommenen Bedrohungsszenario stehen dem Angreifer viele Wege und Werkzeuge zur Verteilung seiner schädlichen Installationspakete offen.

Bei einer aggressiven Taktik kann er zuerst Zugang zu bestehenden Repositories erlangen. Durch geeignete Methoden wandelt er dort bereitgestellte Softwarepakete in Schädliche um. Bis zur Aufdeckung dient die eroberte Quelle somit als Schadcodeverteiler für eine Vielzahl an Benutzern. Diese Annahme ist realistisch, denn eine feindliche Übernahme der Drittanbieter von Paketquellen können wir nicht ausschließen. Es gibt keine einheitlichen Mindestanforderungen an nachzuweisenden Sicherheitsmechanismen. Hingegen gelten Distributionsquellen allgemein als „sicher“. Diese Aussage beruht jedoch auf Vertrauen in die angewandten Schutzfunktionen der Betreiber. Bei unserem Szenario kann es dem Angreifer durchaus gelingen Zugriff auf Distributionsquellen zu erlangen. Daher sind auch diese Quellen vor Manipulation nicht gesichert.

Eine andere passive Herangehensweise des Angreifers verleitet den Anwender zu einer Fehlhandlung. Mit Zugang zu Webressourcen kann er ein eigenes Repositorie erstellen und betreiben[Iso07]. Durch gezielte Täuschung bringt er Benutzer dazu, seine manipulierten Pakete zu installieren. Hierbei sind zwei Varianten möglich. Entweder bietet er den Benutzern Pakete mit eigenen Programmentwicklungen an; diese erfüllen die versprochenen Funktionen jedoch nicht, sondern enthalten Schadcode. Oder der Angreifer erstellt einen „bösen Zwilling“. Dabei kopiert er eine andere Quelle identisch in Aussehen, Inhalt und Programmangebot. Die bereitgestellte Software ist jedoch manipuliert.

Neben den diversen Möglichkeiten schädliche Pakete zu verteilen, hat der Angreifer eine große Auswahl an Schadprogrammen, die er einsetzen kann. Mit Definitionen nach Skoudis et al.[SZ03] geben wir diesbezüglich einen Überblick:

• Virus: infiziert eine ausführbare Zieldatei, reproduziert sich bei deren Aufruf
• Trojanisches Pferd: tarnt sich als nützliches Programm, versteckt schädliche Absichten
• Wurm: verteilt sich über das Netzwerk, nutzt bekannte Schwachstellen in Systemen
• Rootkit: überschreibt oder modifiziert Systemdateien, manipuliert den Kernel

Die aufgeführten Schädlinge sind Oberbegriffe und es existieren viele Unterarten, die teilweise große Unterschiede in ihrem Handeln aufweisen. Im Rahmen unseres Bedrohungsszenarios nehmen wir Schadprogramme an, die kritische Systemdateien und-verzeichnisse betreffen. Dies beinhaltet das Löschen und Modifizieren jener Dateien, sowie das Erstellen neuer Dateien in Systemordnern.

Es ist uns wichtig, das angenommen Zeitfenster der Bedrohung klar herauszustellen. Dies ist während der Installation, da der Angreifer davon ausgeht root-Privilegien zuhaben. Denkbar sind manipulierte Installationen, deren schadhafte Auswirkung sich erst mit Ausführung des installierten Programms erweist. Diese sind nicht Bestandteil des Untersuchungskontextes, da diese Variation sich aus dem Fokus der kontrollierten Software-Installation hinausbegeben.

Das dargelegte Szenario weist viele Möglichkeiten bei einem Angriff durch manipulierte Software-Installationen auf. Trotzdem lassen sich in Verbindung mit den zuvor erkannten Mängeln grundlegende Sicherheitsziele ableiten.

Als wesentliches Sicherheitsproblem identifizieren wir die Ausführung des Installationsprozesses mit root-Privilegien. Dies ist aber nur unter der Bedingung der fehlenden Kenntnis über die tatsächliche Auswirkung der Software-Installation. Wir erkennen daher zwei Ansatzpunkte, um eine Antwort auf die beschriebene Bedrohung zufinden. Wir versuchen zu Beginn eine Trennung der Privilegien.

Der erste Ansatz zielt darauf ab den Installationsprozess ohne Superuser-Privilegien durchzuführen. Unter der Kennung eines normalen Benutzers ausgeführt, kann so kein Schaden an kritischen Systembereichen entstehen. Jedoch zeigen sich die Schwächen dieser Vorgehensweise schnell. Manipulationsversuche durch Schadprogramme am echten Betriebssystem werden kalkuliert in Kauf genommen. Die greifende Zugriffskontrolle für normale Benutzer soll sie abwehren. Mit der normalen Benutzerkennung müssen jedoch unter Umständen Änderungen an wichtigen Systemdateien erfolgen. Wie unterscheidet man legitime Änderungen von schädlichen Manipulationen? Während letzteres noch bestimmbar scheint, endet die Frage nach dem Bezug der legitimen Modifikationen in einem Widerspruch. Diese können einzig vom Softwarehersteller selbst stammen und sind dem Softwarepaket beizufügen. Das aufgestellte Bedrohungsszenario beschreibt die Gefahr manipulierte Pakete zu beziehen. Eine schädliche Veränderung der legitimen Zugriffsdatei ist daher nicht auszuschließen. Dieser Ansatz ist somit nicht ausreichend.

Ein zweiter Ansatzpunkt mündet im fehlenden Wissen über die Auswirkung einer durchgeführten Installation. Wir sind der Überzeugung, dass die eigenständige, unabhängige Gewinnung dieses Wissens der wahre Schlüssel zur Beherrschung der aufgestellten Bedrohung ist. Die damit verbundenen Sicherheitsziele lauten:

1. Kenntnis der Auswirkung: Generiere das Wissen um die Modifikationen am Betriebssystem, welche durch die Ausführung der Installation entstehen.
2. Schutz des Betriebssystems: Dauerhafte Schädigungen sind während der Wissenserzeugung vom System fernzuhalten. Änderungen an den Systemdateien sind nicht erlaubt.
3. a) Unprivilegierte Ausführung: Ausführung der Installationspakete erfolgt niemals mit root-Privilegien.
   b) Heraufstufung Verhindern: Der Installationsprozess soll niemals Superuser-Privilegien erhalten können.
4. Risikobewertung: Führe anhand des generierten Wissens eine Einschätzung des Risikos durch.
5. Emulierung: Die Installationsroutine soll so verlaufen, als wäre sie in einer echten Betriebssystemumgebung und hätte root-Privilegien.

Unter Einhaltung dieser Richtlinien lösen wir die benannte Bedrohung auf. Wir präsentieren im anschließenden Abschnitt unsere Lösung zur Umsetzung dieser Sicherheitsziele.

• Zusammenfassung
• Einführung
• Vergleichbare Arbeiten
• Hintergrund
• Kontrollierte Installation
• Ausblick und Schlusswort

• Page:
•  1 
•  2 
•  3 
•  4 
•  5