IT-Sicherheit im Zeitalter von E-Business- und Web-Applikationen

Transkript

1 IT-Sicherheit im Zeitalter von E-Business- und Web-Applikationen Sicherheit auf Anwendungsebene Angriffsmöglichkeiten auf Webserver sind vor allem Probleme der Anwendungsebene. Sie beruhen auf Fehlern in der Webserver-Software, aber auch in kleinen Details aller anwendungsspezifischen Scripte und Programme. Nur mit einem guten Verständnis dieser Fehler und wie man sie ausnutzen kann, ist ein sinnvoller Schutz möglich. Im Folgenden werden daher einige Beispiele von Angriffsmöglichkeiten auf Webserver und E-Business Systeme diskutiert. Die Ansatzpunkte für Angriffe auf Anwendungsebene sind in der Regel Daten, die der Browser bzw. der Anwender an die Applikation übergibt. Fehler in den CGI- Programmen, Servlets oder sonstigen Scripten, die Formulare verarbeiten und dynamische WWW-Seiten erzeugen, erlauben es diesen Daten, das System zu manipulieren oder Befehle des Angreifers auszuführen. Die Art der Daten und ihre Funktion im Angriff bildet bei genauerer Betrachtung eine Struktur, bei der zwei Grundvarianten existieren. Im ersten Fall versteckt der Angreifer Code oder Elemente aus einer Programmiersprache in Eingabedaten bzw. Eingabefeldern von HTML-Formularen. Die Applikation interpretiert diese Code-Elemente ohne es zu bemerken. Typische Beispiele für diese Art von Angriffen sind SQL-Hacking und Stealth Commanding. Im zweiten Fall sendet die Applikation bestimmte Status-Informationen an den Browser und geht davon aus, dass diese Informationen bei der nächsten Aktion des Benutzers unverändert zum Webserver und der Applikation zurück gesendet werden. Auf diese Weise merkt sich die Applikation Dinge wie den Inhalt oder die Nummer eines Einkaufswagens bei Shopping-Anwendungen. Beliebte Mechanismen sind hier Cookies, versteckte Variablen in Eingabeformularen oder CGI-Parameter in den URLs von Links. Der Angreifer manipuliert diese Informationen und kann damit häufig auf Daten anderer Benutzer oder interne Dateien der Applikation zugreifen oder sogar Code ausführen. Typische Beispiele für derartige Angriffe nennt man Cookie-Poisoning, Parameter Tampering oder Hidden Manipulation Fehler im Webserver selbst

2 Ein klassisches Beispiel für Einbruchsmöglichkeiten in Webserver ist der Unicode- Exploit im Microsoft IIS Webserver. Er ist gleichzeitig ein auch ein Beispiel für Sicherheitslücken, die im Webserver selbst stecken und damit unabhängig von der eigentlichen individuellen Anwendungslogik sind. Beim Unicode Exploit kann ein Angreifer auf Dateien außerhalb des Web-Wurzelverzeichnisses zugreifen. Eigentlich sollten Zugriffe auf den Webbserver über http auf ganz bestimmte Verzeichnisse beschränkt sein. Damit dies auch so ist, gibt es im IIS eine Prüfroutine, die jede abgefragte URL analysiert und nur freigegebene Verzeichnisse zulässt. Leider gibt es nicht nur diese Prüfroutine, die URLs verarbeitet, sondern auch eine andere Routine, die Zeichen im Unicode-Format in normale Zeichen umwandelt. Diese Unicode-Routine wird nach der URL-Prüfroutine aufgerufen. Das Ergebnis ist, dass man unzulässige Pfade in Unicode-Darstellung abfragen kann. Die Prüfroutine versteht Unicode nicht und akzeptiert damit URLs, die später, nach der Umwandlung in normale Zeichen auf unzulässige Dateien verweisen. Kommunikation mit dem internen Netz Viele heute existierende Internet-Firewalls sind so konfiguriert, dass sie zunächst keine Zugriffe aus dem Internet auf interne Systeme zulassen. Häufig sind die einzigen Daten, die von außen akzeptiert und nach innen weitergegeben werden E- Mails und selbst diese s werden vor der Weitergabe nach Viren durchsucht. Wenn eigene WWW-Server betrieben wurden, dann wurden diese entweder vollständig extern bei Providern abgestellt oder sie befinden sich in einer DMZ der Firewall. Sie sind von innen und von außen über HTTP erreichbar, können selbst jedoch nicht auf interne Systeme zugreifen. Mit modernen E-Business-Systemen ändert sich diese Situation. Es besteht jetzt dringender Bedarf an einer Kommunikation von den WWW-Servern mit internen Systemen. Da man davon ausgehen muss, dass WWW-Server wie oben beschrieben immer ein deutliches Risiko mit sich bringen und in vielen Fällen auch geknackt werden, muss man sich fragen welche Gefahren dies für interne Server mit sich bringt, wenn ein solcher WWW-Server mit internen Systemen kommunizieren kann.

3 Innovative Schutzmaßnahmen Gute Sicherheit bei E-Business-Systemen ist ein hohes und nicht leicht zu erreichendes Ziel. Neben den etablierten Bereichen der Sicherheit wie Verschlüsselung der Daten und Authentisierung der Benutzer sind Firewalls nach wie vor nötig, um Angriffe auf der Netzwerkebene zu blockieren. Für den Schutz vor Angriffen auf der Anwendungsebene werden zusätzliche Mechanismen benötigt, die leider noch sehr selten zum Einsatz kommen. Die folgenden Mechanismen sind dabei recht viel versprechend: Kontrolle der inhaltlichen Kommunikation zwischen Browser und Webserver Kontrolle der inhaltlichen Kommunikation zwischen Webserver bzw. Applikationsserver und internen Systemen Sicherung der Plattformen aller beteiligten Systeme wie Webserver, Applikationsserver oder Datenbanken Kontrolle zwischen Browser und Webserver Die erste relativ einfache und doch effektive Schutzmaßnahme besteht im Aufbrechen der Kommunikation zwischen dem Browser und dem Webserver. Es gibt mehrere moderne Produkte, die sich auf diesen Bereich spezialisiert haben und mit beinahe automatischen und sehr einfachen Mechanismen die meisten bekannten Angriffe schon vor dem Webserver blockieren. Die bekanntesten Hersteller sind hier Sanctum Inc und KaVaDo. Die Produkte beider Hersteller kann man sich vereinfacht als Reverse-http Proxies vorstellen, die im Gegensatz zu herkömmlichen Reverse- Proxies den Status der Benutzer-Session verfolgen und dabei Angriffe erkennen und verhindern. Man kann dabei vor allem drei wichtige Grundfunktionen beobachten: Erfassen aller URL-Verweise in HTML-Seiten, die der Anwender in seiner aktuellen Session kennen und damit anklicken kann. Zugriffe auf andere URLs werden blockiert. Erfassen aller Eingabefelder in HTML-Formularen, die zum jeweiligen Anwender geschickt wurden. Inhaltliche Prüfungen je Eingabefeld werden aus dem HTML- Code und aus Default-Einstellungen abgeleitet. Verfolgen und Kennzeichnen aller Cookies, die zum Anwender gesendet wurden. Manipulierte Cookies können so erkannt und blockiert werden.

4 Kontrolle der inhaltlichen Kommunikation zwischen Webserver bzw. Applikationsserver und internen Systemen Ähnlich wie man die Kommunikation zwischen dem Browser und dem Webserver inhaltlich analysieren und filtern kann, kann man versuchen die Kommunikation zwischen dem Webserver bzw. Applikationsserver und den kritischen internen Systemen zu kontrollieren. Firewalls bzw. Proxies, wie sie bisher existieren, sind hier jedoch keine Lösung, weil sie die Kommunikation zwischen einem WWW-Server und einer internen Datenbank nicht inhaltlich prüfen können und daher nicht zwischen erlaubten Zugriffen und Angriffen unterscheiden können. Für heutige Firewalls ist eine Kommunikation über SQL ein Datenstrom, bei dem nicht einmal zwischen lesenden und schreibenden Zugriffen unterschieden werden kann. Mittlerweile sind jedoch spezialisierte Produkte auf dem Markt, die genau diese Funktionalität bieten. Solche Produkte müssen das jeweilige Protokoll auf Anwendungsebene dekodieren können und dann anhand einer Regelbasis unterscheiden, ob der Zugriff erlaubt ist oder nicht. Zusammenfassend kann man die Anforderungen an einen sicheren Proxy mit inhaltlicher Filterung folgendermaßen zusammenfassen: Er muss physikalisch von der Anwendung und von der Datenbank getrennt sein Er muss im Fall von Datenbanken nach Benutzer-ID, Tabelle und Zugriffsart filtern. Bei anderen Protokollen sollten sinngemäße Kriterien möglich sein. Er muss bei Verstößen gegen die Filterregeln Alarm auslösen können Er sollte in der Lage sein, definierbare Inhalte der Kommunikation zu protokollieren. Sicherung der Plattformen aller beteiligten Systeme wie Webserver, Applikationsserver oder Datenbanken Ein weiterer wichtiger Baustein für ein sicheres E-Business-System ist die Sicherheit der einzelnen Komponenten auf Betriebssystemebene. Hier gibt es zwei besonders wichtige Ansätze, die komplementär sind, in der Praxis jedoch oft fälschlicherweise durcheinender gebracht werden oder sogar als Alternativen bezeichnet werden: Härten eines Systems Trusted Operating Systems

5 Bei der Härtung eines Systems geht es darum, möglichst wenig Angriffsfläche zu bieten. Dazu werden alle Betriebssystemkomponenten und Programme, die nicht unbedingt benötigt werden, entfernt. Fehler in Serverdiensten wie tftp, finger oder NFS sind irrelevant, wenn diese Dienste auf dem gehärteten System gar nicht mehr vorhanden sind. Zusätzlich versucht man beim Härten die Systemkonfiguration der verbleibenden Komponenten so sicher wie möglich einzustellen. Dazu werden Patches bzw. Servicepacks eingespielt und Konfigurationsdateien angepasst. In einer idealen Umgebung würde ein gehärtetes System keine Fehler und Angriffsmöglichkeiten mehr enthalten. Leider ist dies in der Praxis allerdings eine Utopie, da neue Fehler und Angriffsmöglichkeiten mit einer relativ konstanten Regelmäßigkeit bekannt werden. Das bedeutet, dass auch ein gehärtetes System viele Angriffsmöglichkeiten enthält, die nur zum momentanen Zeitpunkt noch nicht bekannt sind. Häufig führen auch Service-Packs oder Patches neue Schwachstellen ein, die dann später mit einem weiteren Servicepack behoben werden müssen. Das bedeutet nicht, dass Härten nutzlos oder überflüssig ist. Bei einem Trusted Operating System (TOS) geht man einen anderen Weg, der sich sehr gut mit der Härtung ergänzt. Ein TOS erweitert ein Standard-Betriebssystem um stärkere Sicherheitsfunktionen, die verhindern, dass ein Angreifer aufgrund eines Fehlers in einem Programm oder Server-Dienst die komplette Kontrolle über das System bekommen kann. Wenn man dies erfolgreich verhindert, kann der Angreifer von dort aus nicht weiter interne Systeme angreifen. Damit kann man zwar nicht alle Angriffsvarianten verhindern, denn Angriffe wie SQL-Hacking wirken direkt auf die Datenbank, aber fast alle anderen Durchgriffe sind nahezu ausgeschlossen. Es wäre allerdings auch hier eine Utopie zu meinen, alle Sicherheitsprobleme mit einem TOS lösen zu können. Die Kombination aus einem TOS, das zusätzlich gehärtet ist und durch weitere Sicherheitsprodukte auf Applikationsebene ergänzt wird, kann jedoch einen sehr guten Schutz von E-Business Systemen erreichen.

6 Zusammenfassung Firewalls werden häufig durch die Einführung von solchen Systemen "durchlöchert" und verlieren damit ihre Schutzfunktion. Die Gefahr von E-Business-Systemen liegt vor allem auf der Anwendungsebene. Schutzmechanismen, die nur auf der Netzwerkebene arbeiten sind deshalb nicht ausreichend. Moderne Produkte adressieren dieses Problem mit neuen Analysemethoden und Filterung auf Anwendungsebene. Trusted Operating Systeme als sichere Plattformen können den üblichen Hacker-Methoden entgegen wirken, indem sie die auch bei Fehlern in Server-Diensten die Plattform vor dem Angreifer schützen. Ein wirksamer Schutz kann bei der Komplexität, die E-Business-Systeme mitbringen und bei der Menge der möglichen und sinnvollen Schutzmechanismen nicht mit einem einzigen Produkt erreicht werden. Eine gut durchdachte Kombination mehrerer Mechanismen, die weit über die klassischen Firewalls hinausgehen, ist dringend anzuraten und sollte von kompetenten und erfahrenen Sicherheitsexperten entworfen werden. Die Gefahr ist sonst groß, dass man viel Geld für Produkte ausgibt, die in der gegebenen Umgebung wirkungslos sind oder sich nicht miteinander vertragen. Hinweis: Dieses und weitere Themen werden in der neu erschienen 3. aktualisierten Auflage des Buches Firewalls und IT-Sicherheit von Stefan Strobel im dpunkt.verlag behandelt.