Heute meldete sich ein Kunde mit einem Shared-Webhosting System bei uns undbat uns um Hilfe bei der Aufkl\u00e4rung eines vermutlich gehackten Web-Accounts f\u00fcr eine Domain seines Endkunden (nennen wir diese „test.de“).<\/p>\n\n\n\n
Dieser Web-Account enthielt pl\u00f6tzlich 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.<\/p>\n\n\n\n
Wir begannen daraufhin zuerst, den Server auf m\u00f6gliche Hacks zu pr\u00fcfen, 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.<\/p>\n\n\n\n
Nach genauerer Pr\u00fcfung des Servers stellten wir fest, dass unser Kunde seinen Endkunden eine One-Click Installation diverser CMS-Systeme (inklusive Joomla) anbietet. Diese Installationen k\u00f6nnen \u00fcber die folgende URL gestartet werden:
http:\/\/\/<domain.tld>\/<cms>-install<\/p>\n\n\n\n
Beispiel: http:\/\/www.test.de\/joomla-install<\/p>\n\n\n\n
Unser Kunde hat diese URLs entsprechend in den Apache2-Vhosts definiert,in diesem Fall lautete der VHost Eintrag:<\/p>\n\n\n\n
Alias \/joomla-install \/usr\/local\/cms\/joomla\/install.php<\/p>\n\n\n\n
Dies bedeutet, dass beim Aufruf der entsprechenden Seite http:\/\/www.test.de\/joomla-install das Script \/usr\/local\/cms\/joomla\/install.php ausgef\u00fchrt wird. Um mit der Installation fortzufahren, wird aus Sicherheitsgr\u00fcnden jedoch eine Authentifizierung durchgef\u00fchrt, der Endkunde hatte jedoch mehrfach betont, dass er die Installation nicht durchgef\u00fchrt hat.<\/p>\n\n\n\n
Was war also passiert?<\/p>\n\n\n\n
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\u00fcft dieser den \u00fcbermittelten Host (Domain-Namen) im HTTP-Protokoll-Header. Anhand dieses Hostnamens wird ermittelt, zu welchem VHost der entsprechende Request geroutet werden soll:<\/p>\n\n\n\n
http:\/\/www.test1.de -> Vhost: „test1.de“
http:\/\/www.test2.de -> Vhost: „test2.de“<\/p>\n\n\n\n
Was passiert aber, wenn eine Domain auf den Webserver zeigt, auf diesem aber kein VHost f\u00fcr 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\u00e4hlt.<\/p>\n\n\n\n
Es wird z. B. gepr\u00fcft, ob es einen default-VHost gibt, sprich einen VHost keinen ServerName beinhaltet:<\/p>\n\n\n\n
<VirtualHost *:80>
…
<\/VirtualHost><\/p>\n\n\n\n
Dies war auf dem Server unseres Kunden leider nicht der Fall, so dass der VHost f\u00fcr die Domain „test.de“ ausgew\u00e4hlt wurde obwohl der urspr\u00fcngliche Request als HTTP-Host die Domain „beispiel.de“ enthalten hat. Anscheinend hatteein anderer Endkunde (beispiel.de) versucht, ein Joomla zu installieren -der VirtualHost f\u00fcr 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.<\/p>\n\n\n\n
Dort musste sich der Endkunde zwar authentifizieren – was auf Grund von g\u00fcltigen Zugangsdaten aber m\u00f6glich war. Nach der Authentifizierung hat der Endkunde dann die Installation von Joomla gestartet, diese wurde allerdings im Verzeichnis des anderen Endkunden (test.de) durchgef\u00fchrt und die dortigen Inhalte \u00fcberschrieben.<\/p>\n\n\n\n
Lessons learned:<\/p>\n\n\n\n
Bei der Konfiguration des Apache2-Webservers sollte sichergestellt werden,dass das Virtual Host Matching wie erwartet funktioniert, hierzu sollten am besten Default-Vhosts (f\u00fcr HTTP und HTTPS) definiert werden, die immer aufgerufen werden, wenn keine anderen VHosts gefunden werden.<\/p>\n\n\n\n
![https:\/\/www.apache.org\/foundation\/press\/kit\/APACHE_20th_anniversary.png<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Heute meldete sich ein Kunde mit einem Shared-Webhosting System bei uns undbat uns um Hilfe bei der Aufkl\u00e4rung eines vermutlich gehackten Web-Accounts f\u00fcr eine Domain seines Endkunden (nennen wir diese …<\/p>\n","protected":false},"author":1,"featured_media":180,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,4],"tags":[30,28,31,29],"_links":{"self":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/179"}],"collection":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/comments?post=179"}],"version-history":[{"count":6,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/179\/revisions"}],"predecessor-version":[{"id":193,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/179\/revisions\/193"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/media\/180"}],"wp:attachment":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/media?parent=179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/categories?post=179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/tags?post=179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/www.apache.org\/foundation\/press\/kit\/APACHE_20th_anniversary.png\"){kind=link}