In Umgebungen, in denen verschiedene Anwendungen die gleiche Infrastruktur nutzen, können Schwachstellen in bzw. Angriffe auf eine der Anwendungen entweder zur Kompromittierung der Infrastruktur und/oder aller anderen Anwendungen führen. Typische Fälle solcher Umgebungen sind das Shared Hosting und Application Service Provider.

Unabhängig davon, ob eine Website auf einem eigenen Server bei einem Colocation-Provider, im Rahmen von Shared Hosting auf einem Server eines ISPs oder ganz- oder teilweise von einem Application Service Provider betrieben wird: Wenn sie nicht im eigenen Rechenzentrum, sondern in dem eines Dritten betrieben wird, hat der meist mehrere Kunden, die sich die gleiche Infrastruktur oder zumindest eng miteinander verknüpfte Infrastrukturen teilen. Dann kann ein bösartiger Kunde des Anbieters versuchen, auf die Anwendungen und Daten anderer Kunden zuzugreifen, und Schwachstellen in der Anwendung eines Kunden können evtl. ausgenutzt werden, um auf die Anwendungen und Daten anderer Kunden zuzugreifen.

Websites auf Shared-Hosting-Systemen sind besonders für zwei Gruppen von Angreifern interessant: Skriptkiddies können darüber möglichst viele eigentlich voneinander unabhängige Websites auf einmal defacen, während Cyberkriminelle JavaScript-Code für Drive-by-Infektionen auf möglichst viele Websites verteilen können.

Virtual Hosting

Beim einfachsten Aufbau einer Shared-Hosting-Umgebung wird ein Webserver so konfiguriert, das er mehrere virtuelle Websites mit unterschiedlichen Domainnamen bereitstellt. Zur Unterscheidung der verschiedenen Domains wird der Host-HTTP-Header verwendet, der ab HTTP 1.1 in jedem HTTP-Request enthalten ist. Werden mehrere Domainnamen zu der selben IP-Adresse aufgelöst, erkennt der Webserver mit dieser IP-Adresse die gewünschte Domain anhand des HOST-Headers. Im Fall des Webservers Apache erfolgt die Konfiguration für die Unterstützung mehrerer Websites z.B. folgendermaßen:

<VirtualHost *>
  ServerName website.example
  DocumentRoot www/website
</VirtualHost>
  
<VirtualHost *>
  ServerName andere-website.example
  DocumentRoot www/anderewebsite
</VirtualHost>

Shared Applications

Application Service Provider (ASP) stellen fertige Anwendungen bereit, die an die Bedürfnisse ihrer Kunden angepasst werden. Dieser Ansatz ist besonders dann günstig, wenn viele Kunden eine komplexe Anwendung mit grundsätzlich immer gleichen Funktionen benötigen, wie z.B. einen Webshop: Die Grundfunktionen sind immer gleich, lediglich das Aussehen und einige Feinheiten unterscheiden sich. Ein weiteres Beispiel sind Kreditkartenabrechnungen, die von einem darauf spezialisierten Anbieter für viele verschiedene Kunden durchgeführt werden können.

Angriffe auf Shared Environments

Gemeinsam genutzte Infrastrukturen erlauben eine Reihe von Angriffen, bei denen die Besonderheiten der gemeinsam genutzten Infrastruktur ausgenutzt werden.

Angriffe auf die Zugiffsmechanismen

Da viele verschiedene Organisationen auf die Anwendungen im Shared Environment zugreifen müssen, werden dafür meist möglichst einfach zu nutzende Mechanismen verwendet. Im einfachsten Fall des Virtual Hostings kann das z.B. die Nutzung von FTP für das Heraufladen von Dateien sein. Umfasst das Angebot eine Datenbank, gibt es meist eine Webbasierte Administrationsoberfläche, zum Teil auch einen direkte Verbindung zwischen Datenbank und Internet, über die die Datenbank dann mit eigenen Tools der Benutzer administriert werden kann. ASP verwenden meist speziell angepasste Administrationstools, oft mit einer webbasierten Oberfläche. Der Zugriff erfolgt dabei meist über ein VPN (Virtual Private Network).

Je nach vorhandenen Zugriffsmechanismen gibt es verschiedene mögliche Angriffe auf das Shared Environment:

• Der Zugriffsmechanismus selbst kann unsicher sein.
  Beim unverschlüsselten FTP kann ein Angreifer in einer günstigen Position die Zugangsdaten belauschen. Der Zugriffsmechanismus kann ungepatchte Schwachstellen enthalten oder unsicher konfiguriert sein. Im Fall des prinzipiell sicheren SSH sei an die unsicheren Schlüssel erinnert, die eine Zeit lang durch einen Fehler in Debian-Systemen erzeugt wurden und die einen Zugriff auf damit geschützte SSH-Zugänge erlauben.
• Die Trennung zwischen verschiedenen Benutzern kann unzureichend sein.
  Zum Beispiel könnte Benutzern, die eigentlich nur Dateien herauf - und herunterladen müssen, ein vollständiger Shellzugang gewährt werden. Oder statt nur Dateizugriffe auf die eigenen Daten zuzulassen, sind auch Zugriffe auf die Dateien anderer Benutzer möglich.
• Die Trennung zwischen verschiedenen Datenbanken bzw. Datenbankbenutzern kann unzureichend sein.
  Z.B. könnten Benutzer auch auf die Datenbanken anderer Benutzer zugreifen können. Unverschlüsselte Datenbankverbindungen können von Angreifern in einer günstigen Position belauscht werden.
• Die Zugriffskontrolle in der Administrationsoberfläche bzw. dem Administrationstool kann fehlerhaft sein.
  Eine Schwachstelle könnte den Zugriff auf die Anwendungen anderer Benutzer oder das Umgehen der Authentifizierung erlauben.

In der nächsten Folge werden Angriffe auf und durch die Anwendungen 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