Donnerstag, 25. Juni 2009


Topthema

Donnerstag, 30. April 2009 | Topthema

About Security #202: Schwachstellen-Suche: Schichtenarchitekturen angreifen

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/048608)

Außer der Ausnutzung von Vertrauensbeziehungen gibt es in Schichtenarchitekturen für Webanwendungen zwei weitere mögliche Angriffe: Über eine Schwachstelle in einer Schicht können Schutzmaßnahmen einer anderen unterlaufen werden, oder nach der der Kompromittierung einer Schicht erfolgen interne Angriffe auf die anderen Schichten. Beide Fälle werden im folgenden beschrieben.

Angriffe durch andere Schichten

Sind die verschiedenen Schichten nicht ausreichend getrennt, kann eine Schwachstelle in einer Schicht ausgenutzt werden, um die Schutzmaßnahmen einer anderen zu unterlaufen. Derartige Schwachstellen kommen besonders häufig in Umgebungen vor, in denen mehrere Schichten auf einem physikalischen Rechner laufen. Ein typisches Beispiel sind LAMP-Server: Linux, Apache, MySQL und PHP laufen auf einem Rechner. Erlaubt eine Schwachstelle in der Webanwendungsschicht den Zugriff auf lokale Dateien, z.B. durch eine Directory-Traversal-Schwachstelle (siehe About Security #177 - #182), ist das für die Webanwendungsschicht selbst nicht unbedingt gefährlich. Die Schwachstelle wird aber gefährlich, wenn dadurch auch auf Dateien anderer Schichten zugegriffen werden kann, wie es auf LAMP-Servern der Fall ist. Typisches Beispiel dafür sind Zugriffe auf Konfigurationsdateien, hier ist aber ein anderer Fall interessanter: Auch die Daten der MySQL-Datenbanken werden in normalen, lesbaren Dateien gespeichert. Ist der Webanwendung der Zugriff auf diese Dateien erlaubt, kann der Angreifer auf die gesamten Datenbankinhalte zugreifen - obwohl die Datenbankschicht selbst keine Schwachstelle in ihrer Zugriffskontrolle enthält. Die Schutzmaßnahmen der Datenbankschicht werden durch die Schwachstelle in der Webanwendungsschicht unterlaufen.

Angriffe auf andere Schichten

Nach der Kompromittierung einer Schicht sind Angriffe auf die anderen Schichten oft einfacher durchzuführen oder überhaupt erst möglich, da dabei auf die vorhandene interne Infrastruktur zurückgegriffen werden kann. Kann der Angreifer z.B. auf einem Server beliebige Befehle ausführen, kann er danach im internen Netz nach weiteren Servern suchen, die darauf laufenden Dienste ermitteln und nach Schwachstellen darin suchen.

Ein Angreifer, der das Betriebssystem eines Servers kompromittiert hat, kann danach jede auf dem Server laufende Anwendung kompromittieren. Gelingt es z.B. einem in den Server der Webanwendungsschicht eingedrungenen Angreifer, das Betriebssystem des Servers der Datenbankschicht zu kompromittieren, erlangt er damit i.A. auch die vollständige Kontrolle über die Datenbankschicht.

Außer der Übernahme aller Schichten der Webanwendung kann ein erfolgreich eingedrungener Angreifer auch weitere Teile der internen Infrastruktur angreifen. Hat ein übernommener Server in einer Demilitarisierten Zone z.B. eine Verbindung zu einem internen Datenbankserver, kann der Angreifer darüber in das lokale Netz eindringen.

Schwachstellen finden

Liegt eine Schichtenarchitektur vor, muss bei jeder gefundenen Schwachstelle geprüft werden, ob darüber Angriffe auf andere Schichten möglich sind. Können Vertrauensbeziehungen ausgenutzt oder Schutzmaßnahmen anderer Schichten unterlaufen werden? Können auf einem Bestandteil der Webanwendung beliebige Befehle ausgeführt werden, ist zu prüfen, ob Netzwerkverbindungen zu anderen lokalen Servern aufgebaut werden können.

Schwachstellen verhindern

Bei einer sorgfältigen Implementierung erhöht eine Schichtenarchitektur die Sicherheit der Webanwendung, da ein erfolgreicher Angreifer meist nur einen Teil der Daten und Anwendungslogik kontrollieren kann. Idealerweise werden für die verschiedenen Schichten verschiedene Server verwendet.

About Security: Alle Folgen

Um Angriffe über Vertrauensbeziehungen zu verhindern, müssen diese minimiert werden. Jede Schicht muss eigene Schutzmaßnahmen enthalten und darf sich nicht auf Schutzmaßnahmen anderer Schichten verlassen, wenn sie diese selbst übernehmen kann:

  • Die Appplication-Server-Schicht kann für bestimmte Ressourcen rollenbasierte Zugriffskontrollen implementieren und z.B. dafür sorgen, das Zugriffe auf das Verzeichnis /administration nur Administratoren möglich sind.
  • Die Datenbankschicht kann für verschiedene Aktionen unterschiedliche Accounts mit abgestuften Rechten verwenden. Je nachdem, ob ein Benutzer nur lesend oder auch schreibend auf die Datenbank zugreifen darf, werden dann andere Accounts verwendet, die auch nur auf die jeweils benötigten Daten zugreifen dürfen.
  • Alle Schichten laufen unter Betriebssystem-Accounts mit den minimal möglichen Rechten, so das ein Angriff möglichst geringe Auswirkungen hat.

Um Angriffe durch bzw. auf andere Schichten zu verhindern, müssen die Schichten so weit wie möglich getrennt werden:

  • Keine Schicht darf auf die Dateien der anderen Schichten zugreifen können. Z.B. darf die Anwendungsschicht nicht auf die Dateien der Datenbankschicht zugreifen können.
  • Netzwerkverkehr zwischen den Infrastruktur-Komponenten müssen so gefiltert werden, das nur zulässige Verbindungen möglich sind. Z.B. darf der Server mit der Webanwendung nur über den für die Datenbankabfragen vorgesehenen Port mit dem Datenbank-Server kommunizieren. Dadurch sind zwar immer noch Angriffe über Datenbankabfragen möglich, aber keine Angriffe auf andere Dienste auf dem Datenbankserver.

In der nächsten Folge werden Angriffe auf Shared Hosting und Application Service Provider beschrieben, d.h. Umgebungen, in denen verschiedene Anwendungen die gleiche Infrastruktur nutzen.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren