Für Schwachstelle in und Angriffe auf bzw. durch Anwendungen, die die gleiche Infrastruktur nutzen, gibt es eine Reihe von Möglichkeiten. Im Gegensatz zu einzeln gehosteten Anwendungen stellen nicht nur externe Angreifer, sondern auch böswillige Mitbenutzer eine potentielle Gefahr dar.

Hintertür durch die Vordertür

In Shared-Hosting-Umgebungen gibt es ein grundsätzliches Problem, das bei einzeln gehosteten Anwendungen nicht auftritt: Die verschiedenen Betreiber der gemeinsam gehosteten Anwendungen können beliebige Skripte bzw. Programme hochladen und ausführen. Da das eine Grundvoraussetzung für den Betrieb von Webanwendungen ist, lässt sich das gar nicht vermeiden.

Selbst wenn Shellzugriffe nicht vorgesehen sind, kann ein Benutzer Shellbefehle ausführen, indem er ein entsprechendes Skript hochlädt. Einige Vorschläge für sehr einfache entsprechende Skripte in verschiedenen Sprachen gibt es z.B. hier. Für PHP könnte auch eine der auch von Angreifern genutzten, komfortablen PHP-Shells verwendet werden, und auch für andere Sprachen gibt es inzwischen schon entsprechende Shells.

Diese Skripte erlauben die Ausführung beliebiger Shellbefehle mit den Rechten des Webservers. Der darf sehr wahrscheinlich auch auf die Dateien aller anderen Benutzer des betroffenen Shared-Hosting-Systems zugreifen. Wenn der Pfad zum Webroot der eigenen Anwendung bekannt ist und z.B. /var/www/1234567/public_html/ lautet, liegen die Dateien anderer Benutzer logischerweise in den Verzeichnissen /var/www/[Benutzerkennzeichnung]/public_html/. Der Benutzer muss also nichts weiter tun, als sich ins Verzeichnis /var/www/ zu begeben, irgend ein anderes Benutzerverzeichnis auszuwählen und dann darin nach Herzenslust zu stöbern. Dabei kann er z.B. aus Konfigurationsdateien die Datenbankpasswörter ausspähen, die manchmal gleichzeitig die FTP-Passwörter sind, usw. usf..

Zur Abwehr solcher Angriffe gibt es mehrere Möglichkeiten, z.B. in PHP die Einstellungen disable_functions zum Sperren von Funktionen z.B. zum Aufruf externer Programme und open_basedir zur Beschränkung der Dateioperationen auf vorgegebene Verzeichnisse. Auch das Einsperren der Webserver der einzelnen Benutzer in eigene Umgebungen, die sog. Jails, verhindert einen Zugriff auf die Daten anderer Benutzer. Auf die Absicherung von Shared-Hosting-Umgebungen wird in einer zukünftigen Folge von About Security ausführlich eingegangen.

Während es bisher um einen bösartigen Benutzer ging, der das in ihn gesetzte Vertrauen ausnutzte, geht es im folgenden wieder um Schwachstellen, die durch Angreifer ausgenutzt werden können. Dazwischen aber noch eine Warnung: Beim Einsatz einer aus dem Netz heruntergeladenen PHP-Shell besteht grundsätzlich die Gefahr, eine präparierte Shell zu erwischen, die einem Angreifer eine Hintertür öffnet. Selbst wenn ein nichts Böses beabsichtigender Benutzer sie nur zur bequemeren Administration der eigenen Anwendung und nicht zum Zugriff auf fremde Daten einsetzt, kann sie ein Sicherheitsrisiko sein.

Angriffe durch Schwachstellen in Anwendungen

Auch wenn sich alle Benutzer der Shared-Hosting-Umgebung korrekt verhalten und nicht absichtlich bösartigen Code hochladen, kann eine Schwachstelle in der Anwendung eines Benutzers Auswirkungen auf die Anwendungen und Daten anderer Benutzer haben. Die meisten bisher vorgestellten Schwachstellen erlauben eine entsprechende Ausweitung des Angriffs. Dazu einige Beispiele:

• Eine Schwachstelle, die die Ausführung beliebigen Codes erlaubt, egal ob z.B. durch Shell Command Injection oder Remote File Inclusion, kann zur Kompromittierung des gesamten betroffenen Servers führen, einschließlich der Anwendungen der anderen, unbeteiligten Benutzer.
• Eine Directory-Traversal- oder Local-File-Inclusion-Schwachstelle in einer Anwendung erlaubt den Zugriff auf beliebige Dateien irgendwo im Dateisystem - einschließlich denen, die einem anderen Benutzer gehören.
• Eine SQL-Injection-Schwachstelle in einer Anwendung erlaubt dem Angreifer das Ausführen beliebigen SQL-Codes auf der Datenbank dieser Anwendung. Wird die gleiche Datenbank auch von anderen Anwendungen genutzt und sind die Benutzerkonten nicht ausreichend getrennt, kann auch auf deren Daten zugegriffen werden - ohne, das diese Anwendungen selbst eine Schwachstelle enthalten.

Angriffe auf und durch ASP-Anwendungen

Die oben beschriebenen Schwachstellen bzw. Angriffe betreffen auch von ASPn betriebene Anwendungen, wenn ein Benutzer im Rahmen seiner Anpassungen eine entsprechende Schwachstelle einführt: Über Schwachstellen in der angepassten Anwendung eines Benutzers können außer den Daten dieses Benutzers u.U. auch die der anderen Benutzer ausgespäht bzw. manipuliert werden.

Bösartige Benutzer können das Zusammenspiel der verschiedenen Komponenten der gemeinsam genutzten Anwendung und der Benutzeranpassungen für weitere Angriffe ausnutzen. Unzureichend getrennte Datenbankbenutzer könnten z.B. den Zugriff auf die Daten anderer Benutzer erlauben. Für die Administration der Benutzeranpassungen sind i.A. besondere Rechte notwendig, die evtl. z.B. Cross-Site-Scripting- oder Cross-Site-Request-Forgery-Angriffe auf die Administratoren anderer Benutzer erlauben, die einem externen Angreifer nicht möglich sind.

In der nächsten Folge werden die Suche nach entsprechenden Schwachstellen sowie einige mögliche Gegenmaßnahmen 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 Hosting