So werden Hacker-Angriffe begünstigt.
Eine "Sicherheitsschwachstelle" ist ein Sicherheitsproblem, das durch fehlerhafte Sicherheitsadministration, durch Programm-Design oder Programm-code hervorgerufen wird und die normale Integrität der Betriebssystemumgebung und die Sicherheit der auf dem betreffenden Computersystem gespeicherten Informationen beeinträchtigt. Obwohl es auch Sicherheitsschwachstellen gibt, die absichtlich geschaffen wurden, sind die meisten dieser Sicherheitslücken jedoch unbeabsichtigt entstanden. Die Gefahr, die von diesen unbeabsichtigten Sicherheitsschwachstellen ausgeht, besteht darin, dass sie einem Unbefugten das Eindringen in die Systeme ermöglichen können. Oft bleibt auch unklar, inwieweit die Geschäftsleitung über den tatsächlichen Sicherheitszustand des Großrechners aufgeklärt ist. Dies ist jedoch für die Unternehmensleitung nicht unwesentlich, da sie nach dem KonTraG-Gesetz (s. a. KES 99/6) unter Umständen persönlich für Folgeschäden haftbar gemacht werden kann.
So werden Hacker-Angriffe begünstigt.
Die Möglichkeiten, mit denen man in die Integrität und Sicherheit eines Betriebssystems eingreifen kann, sind beeindruckend: Vom versehentlichen Überschreiben des für das Betriebssystem reservierten Speichers bis zum uneingeschränkten Lesezugriff für die Sicherheitsdatenbank. Wer sich mit der entsprechenden Plattform auskennt, kann alle Sicherheitsfunktionen auf Anwendungsebene umgehen und sich nach Lust und Laune kryptographische Schlüssel verschaffen, Datenbankdateien lesen und ändern, eigene Transaktionen starten und alle Spuren solcher Transaktionen in Audit-Trails beseitigen. Großrechner-Systeme, an denen zwischen 2.000 und 100.000 Personen arbeiten, verwalten Datenmengen, die man sich kaum mehr vorstellen kann - häufig Hunderte von Terabyte.
Verschiedene Schwachstellen haben Hacker-Angriffe in den letzten Jahren begünstigt. Zu beachten ist dabei, dass in allen Fällen Nicht-IBM-Anwendungen betroffen sind. Obwohl sie den Herstellern mitgeteilt wurden, sind einige bis heute nicht korrigiert worden. Reagiert die Software-Branche immer so schnell?
Im Gegensatz dazu wurden alle an IBM gemeldeten Fehler innerhalb kurzer Zeit beseitigt. Dazu ein immer noch gültiges Zitat aus dem Brief eines Software-Herstellers aus dem Jahre 1985: "Wir haben viele Benutzer mit sehr hohen Sicherheitsanforderungen, zum Beispiel die CIA, die das Risiko akzeptieren und das derzeitige Sicherheitsniveau für ausreichend halten."
Vermutlich wurde der CIA nicht mitgeteilt, dass man mit überschaubarem Aufwand in ihre auf mehreren Ebenen gesicherte Systeme eindringen kann. Dieses Leck existiert heute noch.
----------Anfang Textkasten----------
Kurt Meiser, Gründer von ITSS und ehemaliger Mitarbeiter von Coopers & Lybrand hat bei seinen Großrechner-Sicherheit-Checks die Anfälligkeit der Systeme in die folgenden Kategorien unterteilt:
Aus diesen vier Kategorien setzt sich das Akronym "ECHO" zusammen. Die folgende Abbildung zeigt die Ergebnisse für den Bereich "Autorisierung und Zugriffsrechte", die auf der Untersuchung von 71 Systemen in 41 Installationen basieren.
Dieser Bereich lässt sich noch weiter aufteilen in Qualität der Passworte (PWD), SVCs, RACF-Benutzerzugriffsrechte (RACF), Program Property Table (PPT), TSO Authorization Tables(TSO) und APF Libraries (APF).
Auch hier wird deutlich, dass eine unsachgemäße Zuordnung von Zugriffsrechten und Privilegien im Falle eines Missbrauchs zu einer höchst gefährlichen Angelegenheit für die betroffenen Unternehmen und ihre Verantwortlichen werden kann.
Weitere unabhängige Studien
Peter Goldis, ein Experte auf diesem Gebiet, hat über 200 Untersuchungen im Bereich MVS/TSO durchgeführt, bei denen er immer mindestens einen sicherheitskritischen SVC fand. Auch bei über 20 Penetrationtests in UNIX-Systemen war er zu 100% "erfolgreich". Goldis hat die Ergebnisse für 60 der durchgeführten MVS-Tests mit Anzahl der Systeme und Grad der Sicherheitsprobleme dokumentiert:
Finn Thunbo Christensen, Sicherheitsexperte bei IBM Denmark, erläutert, dass Einbruchsversuche im Allgemeinen innerhalb eines Tages erfolgreich sind und verweist besonders auf die Rolle von "Subroutinen mit Programmaufruf" als Ursache für Sicherheitsschwachstellen [Christensen, 98].
----------Ende Textkasten----------
Nachfolgend einige Erkenntnisse, die bei den Checks von 350 Großrechner-Systemen mit dem IBM-Betriebssystem MVS bzw. OS/390 und einer installierten Anwendungsbasis von zehn bis 500 Produkten unterschiedlicher Hersteller gemacht wurden. Betroffen waren eine ganze Reihe international tätiger Finanzinstitute sowie weltweit operierende Großunternehmen. Gewicht bekommen die Ergebnisse vor allem in Anbetracht des verstärkten Anschlusses dieser Systeme an das Internet und der Geldmengen, die täglich über diese Systeme übertragen werden sowie der Tatsache, dass das Eindringen in fremde Systeme zunehmend für betrügerische Zwecke genutzt wird [Sterling 92 S. 77].
Zum einen waren alle 350 Großrechner-Sicherheits-Checks "erfolgreich"; das heißt, es konnte in jedem Fall unerkannt in die Systeme eingedrungen und die höchste Autorisierungsstufe erschlichen werden. Zum anderen wurden in allen Fällen weniger als zwei Tage benötigt, um in das System einzudringen. Das Minimum lag bei zehn Minuten - nicht nur ein "Schock" für den Systemverwalter.
Die Aussage, alle Versuche, unerkannt einzudringen, seien "erfolgreich" gewesen, ist ein wenig irreführend - berücksichtigt werden muss auch, welche Ausgangsbasis nötig war, um Trusted Computing Base, das heißt die höchste Systemautorisierung, zu erhalten. Tabelle 1 zeigt die Wahrscheinlichkeit des unerkannten Eindringens als Funktion der Systemautorisierung, die wir zum Zeitpunkt des Versuchs besaßen.
Tabelle 1
Diese allgemeinen Statistiken geben jedoch keine Auskunft über die Variantenbreite, die die einzelnen Ergebnisse aus drei unterschiedlichen Prüfungsansätzen widerspiegeln. Anstatt die Gemeinsamkeiten darzustellen, werden die einzelnen Ansätze nacheinander vorgestellt.
Offensichtliche Systemlücken
In der Grafik wurden die Sicherheitsschwachstellen, über die erstmals in das System eingedrungen werden konnte konnte, in Kategorien eingeteilt. Dies ist jedoch keine vollständige Aufstellung aller Sicherheitsschwachstellen, die bei den Checks gefunden wurden. Es gibt viele weitere Kategorien, z. B. global zu beschreibende Speicher und Program Call (PC)-Routinen. Die Tabelle zeigt lediglich die besonders "effektiven" Sicherheitsschwachstellen:
SVCs oder SuperVisor Calls sind Routinen, die einem nicht autorisierten Anwender autorisierten Code zur Verfügung stellen. Dies ist deswegen besonders riskant, weil der Binärcode im global lesbaren Speicher geladen und dort nach Belieben untersucht werden kann, um Fehler im Design aufzuspüren. PC- oder Program-Call-Routinen, die moderneren Entsprechungen der SVCs, sind häufig ebenso problematisch. Erschwerend hinzu kommt, dass viele Softwareanbieter ihre Produkte mit SVC-Routinen ausliefern, die schon seit Jahren nicht mehr verbessert wurden.
| Ø Analysedauer | Max. Zeit bis zum 1. Leak | Prozentsatz | |
|---|---|---|---|
| Kein Leak gefunden | 6h | 22% | |
| Mindestens ein Leak | 2h20 | 2h | 78% |
| Zeit pro Leak | 1h | 2h |
Tabelle 2
Der Versuch des unerkannten Eindringens endet in der Regel nicht mit der ersten genutzten Sicherheitsschwachstelle. In der Regel wird in der verbleibenden Zeit eine Analyse kritischer Systemkomponenten wie SVC- und PC-Routinen durchgeführt. Tabelle 2 fasst Ergebnisse aus mehr als 40 SVC-Audits zusammen. Pro SVC wurden nicht mehr als 8 Stunden investiert. In dieser Zeitspanne wurde der SVC mittels Quellcode-Prüfung, Disassemblierung oder Hex Browsing untersucht; ein tatsächliches Eindringen fand nicht statt. Die Tabelle zeigt, dass 78% der analysierten SVC-Routinen mindestens eine Sicherheitsschwachstelle enthielten. Da in den meisten Fällen mehrere Sicherheitsschwachstellen gefunden wurden, ist pro Schwachstelle ein geringerer Durchschnittswert zu veranschlagen. Die geprüften SVC-Routinen sind nicht auf Zufallsbasis ausgewählt worden, sondern nur solche Routinen haben eine Berücksichtigung gefunden, bei denen bereits ein Anfangsverdacht bestand.
Ein weiteres Einbruchsszenario, das in den zuvor genannten Statistiken nicht berücksichtigt wurde, jedoch zunehmend Verbreitung findet, ist die Verwendung eines Sniffer-Tools im LAN, mit dem die Großrechner-Paßwörter ausspioniert werden. Darüber sammeln die Tester seit kurzem auch Statistikdaten, die vergleichende Aussagen zur Sicherheit verschiedener Systeme an einem Standort ermöglichen. Dabei hat sich herausgestellt, dass das neueste System aufgrund fehlerhafter Zugriffsregeln im Allgemeinen das anfälligste ist, jedoch häufig weniger sicherheitskritische SVCs aufweist.
19% aller erfolgreichen unerkannten Einbruchsversuche wurden durch ungenaue Zugriffsregeln ermöglicht. Dieser Wert würde bei nicht angekündigter Systemprüfung wahrscheinlich noch höher liegen, da viele Standorte ihre Einstellungen vor einem Penetrationstest überprüfen, um das Ergebnis positiv zu beeinflussen. Darüber hinaus ist festzuhalten, dass mancherorts zu viele der im System definierten Anwender in der Lage gewesen wären, die Produktion auf dem Großrechner zum Stillstand zu bringen. In einigen wenigen Fällen war sogar die Gesamtheit der Anwender dazu in der Lage. Nicht immer war nachzuvollziehen, ob die Unternehmensleitung tatsächlich Kenntnis von dieser für die betroffenen Unternehmen existenzbedrohlichen Situation hatte oder hat.
Häufig wird behauptet, Sicherheitslücken ließen sich durch die Programmierung in einer höheren Sprache besser vermeiden [CC 96]. Die Erfahrungen bestätigen dies nicht. Hinzu kommt, dass in C geschriebene Betriebssysteme eine höhere Fehlerrate aufzuweisen scheinen als Systeme, die in Assembler geschrieben wurden (siehe dazu [bugtraq] und [cert]) - und dass PC-Betriebssysteme wie OS/2 und Windows NT (bei denen große Teile in C geschrieben sind) eher zu Abstürzen neigen als die alten Großrechner-Systeme. Unerklärliche Abstürze sind häufig Symptome eines schwerwiegenden Integritätsproblems. Die Häufigkeit solcher Abstürze ist daher einer von mehreren Gradmessern für die Systemintegrität.
Andererseits lässt sich die Absturzfrequenz auch durch Designmängel des zugrunde liegenden Systems (z. B. UNIX) bzw. durch bessere Qualitätskontrolle der Hersteller erklären. Korrektes Design und angemessene Sicherheitstests sind hier von vorrangiger Bedeutung und die Art der Programmiersprache irrelevant.
Hans Schoone ist einer der drei Gründer der Consul Risk Management B.V. Nach dem Studium der Elektrotechnik und Mathematik an der Technischen Universität Delft arbeitete er für Inter Access Consultancy B.V. und später für seine eigene Firma Consul sowie als Systemprogrammierer, Performance-Spezialist und Sicherheitsberater für zahlreiche Großunternehmen. Er führte Projekte zur Performance-Verbesserung in MVS-Umgebungen sowie Systempenetrations-Tests und technische Audits auf den Plattformen MVS, VM, VMS und MPE durch. Er ist Mitglied der Dutch Informatics Society, die internationale Standards zur Sicherheitsevaluation prüft.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 2000/1, Seite 78
