Apache2 VHosts – Aufgepasst!

Heute meldete sich ein Kunde mit einem Shared-Webhosting System bei uns undbat uns um Hilfe bei der Aufklärung eines vermutlich gehackten Web-Accounts für eine Domain seines Endkunden (nennen wir diese „test.de“).

Dieser Web-Account enthielt plötzlich eine (defekte) Joomla-Installation,die bisherigen Daten des Web-Accounts befanden sich als Backup in dem Verzeichnis /home/test.de/backups. Die Dateien der Joomla-Installation hatten einen Timestamp vom 20. Januar 2021 gegen 14:36 Uhr.

Wir begannen daraufhin zuerst, den Server auf mögliche Hacks zu prüfen, konnten aber in keinen der entsprechenden Log-Dateien (xferlog, apache2 logs, syslog, etc.) entsprechende Hinweise auf das Verzeichnis „/home/test.de/“ finden, insbesondere gab es keine FTP/SSH-Logins oder Web-Zugriffe auf die Domain „test.de“ um den oben genannten Zeitraum.

Nach genauerer Prüfung des Servers stellten wir fest, dass unser Kunde seinen Endkunden eine One-Click Installation diverser CMS-Systeme (inklusive Joomla) anbietet. Diese Installationen können über die folgende URL gestartet werden:

http:///<domain.tld>/<cms>-install

Beispiel: http://www.test.de/joomla-install

Unser Kunde hat diese URLs entsprechend in den Apache2-Vhosts definiert,in diesem Fall lautete der VHost Eintrag:

Alias /joomla-install /usr/local/cms/joomla/install.php

Dies bedeutet, dass beim Aufruf der entsprechenden Seite http://www.test.de/joomla-install das Script /usr/local/cms/joomla/install.php ausgeführt wird. Um mit der Installation fortzufahren, wird aus Sicherheitsgründen jedoch eine Authentifizierung durchgeführt, der Endkunde hatte jedoch mehrfach betont, dass er die Installation nicht durchgeführt hat.

Was war also passiert?

Um dies zu verstehen, muss man einen genaueren Blick auf den Apache2-Webserverund insbesondere auf die VHost-Konfigurationen werfen. Wenn HTTP (oder auch HTTPS) Requests durch den Webserver empfangen werden, so prüft dieser den übermittelten Host (Domain-Namen) im HTTP-Protokoll-Header. Anhand dieses Hostnamens wird ermittelt, zu welchem VHost der entsprechende Request geroutet werden soll:

http://www.test1.de -> Vhost: „test1.de“
http://www.test2.de -> Vhost: „test2.de“

Was passiert aber, wenn eine Domain auf den Webserver zeigt, auf diesem aber kein VHost für diese Domain konfiguriert ist? In diesem Fall wird mit Hilfe einiger Regeln (siehe auch „Virtual Host Matching“ unter https://httpd.apache.org/docs/2.4/vhosts/details.html) der entsprechende VHost ausgewählt.

Es wird z. B. geprüft, ob es einen default-VHost gibt, sprich einen VHost keinen ServerName beinhaltet:

Dies war auf dem Server unseres Kunden leider nicht der Fall, so dass der VHost für die Domain „test.de“ ausgewählt wurde obwohl der ursprüngliche Request als HTTP-Host die Domain „beispiel.de“ enthalten hat. Anscheinend hatteein anderer Endkunde (beispiel.de) versucht, ein Joomla zu installieren -der VirtualHost für dessen Domain beispiel.de war jedoch nicht konfiguriert, so dass der Apache Server dann letztlich die PHP Seite der Domaintest.de/joomla-install ausgeliefert hat.

Dort musste sich der Endkunde zwar authentifizieren – was auf Grund von gültigen Zugangsdaten aber möglich war. Nach der Authentifizierung hat der Endkunde dann die Installation von Joomla gestartet, diese wurde allerdings im Verzeichnis des anderen Endkunden (test.de) durchgeführt und die dortigen Inhalte überschrieben.

Lessons learned:

Bei der Konfiguration des Apache2-Webservers sollte sichergestellt werden,dass das Virtual Host Matching wie erwartet funktioniert, hierzu sollten am besten Default-Vhosts (für HTTP und HTTPS) definiert werden, die immer aufgerufen werden, wenn keine anderen VHosts gefunden werden.

Bildquelle:
https://www.apache.org/foundation/press/kit/APACHE_20th_anniversary.png