Bei der Suche nach Schwachstellen in Shared Environments muss man zwei Bereiche berüchsichtigen: Zum einen Schwachstellen in den vorhandenen Webanwendungen, die einen Angriff auf das gesamte Shared Environment erlauben. Dabei geht man genau so vor, wie bei der Suche nach Schwachstellen in einzeln gehosteten Webanwendungen. Zum anderen muss man nach Schwachstellen im Shared Environment selbst suchen.

Untersuchung eines Shared Environments

Die folgenden Schritte sind diesmal noch allgemeiner beschrieben als bei der Suche nach anderen Schwachstellen, da die "Untersuchungsobjekte" zu unterschiedlich und oft zu individuell sind, um genauer darauf einzugehen. Welche Tests jeweils angebracht sind und ob sie überhaupt durchgeführt werden können, muss von Fall zu Fall entschieden werden.

• Bei der Untersuchung der Zugriffsmechanismen sind mehrere Fragestellungen zu prüfen, die sich aus den in About Security #203 beschriebenen Angriffen ergeben:
  • Wird ein sicheres Protokoll in einer entsprechend geschützten Infrastruktur genutzt?
  • Können Benutzer auf Dateien, Daten oder sonstige Ressourcen anderer Benutzer zugreifen?
  • Können Benutzer auf Dateien, Daten oder sonstige Ressourcen des Systems zugreifen, auf die sie keinen Zugriff haben dürfen?
• Wenn eine Datenbank von mehrere Benutzern gemeinsam genutzt wird: Sind die Benutzer korrekt voneinander getrennt, oder kann ein Benutzer auf die Daten anderer Benutzer zugreifen? Ein Konfigurationsfehler oder eine Schwachstelle können sowohl von einem bösartigen Benutzer als auch über eine SQL-Injection-Schwachstelle von einem Angreifer ausgenutzt werden.
• Können die Benutzer beim Shared Hosting einen Shellzugang erlangen oder sonstwie beliebige Befehle ausführen, obwohl das nicht vorgesehen ist?
• Wenn die Administration über eine spezielle Anwendung erfolgt: Enthält diese bekannte Schwachstellen oder können neue Schwachstellen gefunden werden? Bei einer proprietären Anwendung stellt sich dementsprechend nur allgemein die Frage, ob Schwachstellen gefunden werden können.
• Wenn eine Schwachstelle das Ausführen von Shellbefehlen, SQL-Injection oder beliebige Dateizugriffe erlaubt: Kann darüber auf Dateien, Daten oder sonstige Ressourcen anderer Benutzer zugegriffen werden?
• Beim Testen eines ASP müssen die gemeinsam genutzten Komponenten daraufhin untersucht werden, ob sie den Zugriff auf die Anwendungen anderer Benutzer erlauben.

Aktive Tests sollten nur mit Zustimmung des Betreibers durchgeführt werden, da sie aus dessen Sicht einen Angriff darstellen. Die meisten Anbieter reagieren darauf zu Recht sehr ungehalten - auch wenn sie von einem Kunden ausgehen.

Absichern eines Shared Environments

Shared Environments drohen generell aus zwei Richtungen Gefahren: Zum einen durch böswillige Benutzer, zum anderen durch Schwachstellen in der Anwendung eines Benutzers, die auch die Anwendungen anderer Benutzer gefährden. Beide lassen sich aber durch die gleichen Maßnahmen abwehren, denn wenn man Zugriffe eines Benutzer auf die Anwendungen anderer Benutzer unterbindet, unterbindet man gleichzeitig die Zugriffe eines in eine Anwendung eingedrungenen Angreifers auf die Anwendungen anderer Benutzer.

Sichere Zugriffsmechanismen

Egal, wie die Benutzer auf ihren Teil des Shared Environments zugreifen: Es muss sichergestellt sein, das kein Unbefugter darauf/darüber Zugriff erlangen kann. Der Zugriffsmechanismus muss also eine sichere Authentifizierung garantieren, vor Beobachtung geschützt sein und darf keine Schwachstellen enthalten. Jeder Benutzer darf nur auf seinen Teil des Shared Environments zugreifen können, die Zugriffsrechte dürfen also nur soweit vergeben werden, wie es minimal notwendig ist. Erfolgt der Zugriff über eine spezielle Anwendung, muss diese sehr genau auf evtl. Schwachstellen untersucht werden.

Benutzer voneinander trennen

Da den einzelnen Benutzer nur bedingt vertraut werden darf (jeder Benutzer sollte aus Sicherheitsgründen als potentieller Angreifer auf andere Benutzer betrachtet werden), müssen die einzelnen Benutzer soweit wie möglich voneinander abgeschottet werden. Dazu könnte z.B. jedem Benutzer eine eigene virtuelle Maschine oder ein in einem Jail eingesperrter Webserver zugewiesen werden, zumindest aber müssen für jeden Benutzer andere Systembenutzer verwendet werden, die nur auf die dem jeweiligen Benutzer zugewiesenen Bereiche des Dateisystems zugreifen können. Ebenso sollten für die Ausführung von Programmen nur die absolut notwendigen Rechte verwendet werden. Das gleiche gilt für Datenbanken.

ASP-Komponenten voneinander trennen

Ebenso wie die Benutzer müssen auch alle Komponenten einer ASP-Anwendung, die unter der Kontrolle unterschiedlicher Benutzer stehen, voneinander getrennt werden. Anweisungen und Daten, die von einer angepassten Komponente an eine gemeinsam genutzte Komponenten weitergeleitet werden, müssen genauso wie Eingaben eines Endbenutzers behandelt werden - mit anderen Worten: Ihnen darf nicht vertraut werden und sie müssen auf bösartige Eingaben geprüft und ggf. gefiltert oder verworfen werden. Die von den Benutzern angepassten Komponenten sollten sowohl auf mögliche Schwachstellen als auch auf mögliche Böswilligkeit getestet werden.

Hiermit ist die Untersuchung der Shared Environments abgeschlossen. Ab der nächsten Folge werden mögliche Angriffe auf den Webserver und die Suche nach dafür ausnutzbaren Schwachstellen beschrieben.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #201: Schwachstellen-Suche: Vertrauensbeziehungen ausnutzen
• About Security #202: Schwachstellen-Suche: Schichtenarchitekturen angreifen
• About Security #203: Schwachstellen-Suche: Shared Environments
• About Security #204: Schwachstellen-Suche: Shared Environments (2)
• About Security #205: Schwachstellen-Suche: Shared Environments (3)