Wie sicher ist .NET?

Es war klar, dass das große Tamtam um das .NET Framework von Microsoft auch Hacker und Cracker von neu auf den Markt gekommenen Programmen und Anwendungen auf den Plan rufen würde. Die meisten von uns hatten erwartet, dass solche Angriffe auf die Sicherheit dieses Frameworks nach dessen allgemeiner Freigabe stattfinden würden, ein paar Unruhestifter wie z.B. „Benny“ konnten es jedoch nicht abwarten.

Anfang Januar sandte ein Hacker namens Benny an mehrere Anbieter von Antivirusprogrammen eine E-Mail, in der er behauptete, den ersten .NET -Virus entwickelt zu haben. Er wolle nun beweisen, dass es möglich sei, .NET-Framework-Systeme zu infizieren. Da Microsoft ja bereits aus der Vergangenheit für die Absicherung seiner Systeme gegen Angriffe bekannt ist, rechnete Benny wohl mit einer Menge Publicity für seinen „Geniestreich“.

Er war sicher ziemlich überrascht, als dies nicht eintrat. Sein Vorhaben stellt jedoch ein gutes Beispiel für die Probleme heutiger CIOs dar, die ständig neue Technologien implementieren und dabei Unternehmens- und Kundendaten schützen müssen. Wie, wenn überhaupt, kann festgestellt werden, welche Angriffe eine echte Bedrohung darstellen und welche nicht?

Wie erkennt man einen „echten“ Virus?
Was macht einen Virus zu einem echten Virus? Sehen wir uns als Beispiel einmal den von Benny entwickelten „Virus“ an. Der W32.Donut-Virus, wie er von den Anbietern von Antivirusprogrammen getauft wurde, ist ein ausführbares Programm, das Dateien auf der Festplatte im aktuellen Verzeichnis und in bis zu 20 übergeordneten Verzeichnissen verändert. Dann befielt der Virus der .NET-CLR (Common Language Runtime) die Ausführung der infizierten .NET-Dateien. Der Virus verbreitet sich nicht selbstständig und muss daher über E-Mail oder Diskette auf dem jeweiligen Rechner installiert werden. Der Rechner selbst wird durch den Virus nicht beschädigt. Es werden jedoch ab und zu Bildschirmmeldungen mit dem Text „This cell has been infected by the dotNET virus“ angezeigt, wenn betroffene .NET-Elemente ausgeführt werden. Diese Warnmeldung erscheint jedoch nur in weniger als 10 Prozent der Fälle.

Dieser „Virus“ ändert lediglich auf der Festplatte befindliche Dateien, wie das auch schon andere, weitaus gefährlichere Viren getan haben, wobei in diesem Fall eben ausführbare .NET-Dateien befallen werden. Die Bezeichnung „Virus“ dürfte hier also kaum zutreffen.

Ein echter .NET-Virus wäre so angelegt, dass er im durch die CLR verwalteten Speicher ausgeführt würde und durch eine Sicherheitslücke im .NET-Framework auf andere Anwendungen oder Systeme überspringen und diese infizieren könnte.

Da das Framework die Urheber von Codes diese „unterzeichnen“ lässt, bevor sie in den Global Assembly Cache (GAC) installiert werden, würden die Veränderungen durch den Virus einen Prüfsummenfehler verursachen, worauf die infizierte Anwendung nicht ausgeführt würde. Im Falle des Benny-Virus bleibt Microsoft wohl noch genügend Zeit, um eine Lösung zu finden, bevor .NET-basierte Produktionssysteme allgemeine Verbreitung finden.

Ist .NET auch wirklich sicher?
Analysten und Presse sorgen dafür, dass Microsoft jeden seiner Schritte in Bezug auf Sicherheit genauestens beobachtet weiß. Zum Teil mag diese Vorsicht berechtigt sein, da viele Microsoft-Produkte Sicherheitslücken aufweisen. Andererseits wurde auch stark übertrieben. Microsoft hat lange vor der allgemeinen Kritik am Internet Information Server (IIS) und am Internet Explorer (IE) entsprechende Software-Patches herausgegeben. Die Wahrheit ist vielmehr, dass zahlreiche Systemadministratoren hinsichtlich der Installation solcher Patches zum Schutz ihrer Systeme nachlässig waren, und nun Microsoft beschuldigen, um von ihren Versäumnissen abzulenken.

Um in Zukunft die Virusangriffe auf seine Softwaresysteme zu minimieren, traf Microsoft eine Reihe strategischer Entscheidungen. Als Erstes wurde die Empfehlung ausgegeben, bei der IIS-Installation ab Version 4 gleichzeitig das IIS-Lockdown Tool zu installieren. Dieses Tool verhindert jeglichen Zugriff auf den Webserver bis auf das Browsen über Port 80 mit HTTP. Der Administrator muss hierbei sämtliche weiteren Systemzugriffe erst freigeben.

Zweitens wird der IIS bei der nächsten Version des Windows .NET-Servers nicht mehr automatisch installiert, wodurch ein zusätzlicher Schutz gegeben ist. Der Administrator muss die Installation des IIS ausdrücklich veranlassen, wobei dieser in einer Standard-Konfiguration erfolgt, was einem Downlevel-IIS-Server entspricht, der vom Lockdown Tool überwacht wird.

Obgleich diese Maßnahmen bereits einen gewissen Schutz der Plattform gewährleisten, auf der die Schlüsselelemente von .NET ( ASP.NET, Webdienste) basieren, bleiben die grundlegenden Sicherheitsfragen zum .NET-Framework unbeantwortet. Microsoft verfolgt in diesem Bereich eine Doppelstrategie: Zum einen werden der Plattform durch .NET grundsätzliche Sicherheitsmerkmale hinzugefügt, u. a. Code Signing und Code Access Security. Durch das Code Signing wird sichergestellt, dass der von einer Softwareentwicklungsfirma gelieferte Code auch tatsächlich vom Framework ausgeführt wird. Bei der Funktion Code Access Security handelt es sich um eine Laufzeit-gebundene Engine, welche die Berechtigung des den Code eingebenden Benutzers, des Code-Urhebers und des Codes selbst prüft, und dann entscheidet, ob der Code ausgeführt werden darf oder nicht. Dies bietet wesentlich mehr Sicherheit als der jetzige DOS/Win32-Standard, in dem jeder beliebige Benutzer Codes ausführen kann, welche Schlüsseldateien des Betriebssystems überschreiben und dieses damit lahm legen können.

Der zweite Teil der Microsoft .NET-Strategie ist die externe Überprüfung der Framework-Sicherheit. Hierfür hat sich Microsoft an die Firmen Foundstone, Inc. und Core Security Technologies gewandt. Beide Unternehmen sind für ihre Tests unerlaubter externer Zugriffe auf Systeme oder Anwendungen im Entwicklungsstadium bekannt.

Dass sich Microsoft bezüglich des Ausbaus der Sicherheit grundlegender Systemelemente an Dritte wendet, könnte einen Wendepunkt für das Unternehmen darstellen. Die Verfechter offener Standards unterstreichen stets, dass in erster Linie die Offenheit ihrer Plattformen dafür verantwortlich sei, dass keine weitreichenden Sicherheitsprobleme entstehen konnten. Die Bereitschaft, Experten aus der Sicherheitsbranche seine Quellcodes offen zu legen, um deren Prüfsiegel zu erhalten, ist ein Zeichen dafür, dass Microsoft die Sicherheit von .NET sehr ernst nimmt.

Da Steve Ballmer von Microsoft auf die .NET-Strategie sogar „das Unternehmen verwetten“ würde, hätte ich auch nichts anderes erwartet.

© 2002 TechRepublic, Inc.