Joomla/Plesk Patches & Notes

Nach einem Joomla-Sicherheitsvorfall tauchten in der Google Search Console plötzlich zahlreiche URLs unter Subdomains auf, die ich selbst nie eingerichtet hatte.

Beispiele sahen sinngemäß so aus:

m.example.org/...
admin-v2.example.org/...
monitor.example.org/...
wildcard.example.org/...

Das wirkte zunächst so, als hätte jemand diese Subdomains auf dem Server angelegt.

Die eigentliche Ursache war aber eine Kombination aus zwei Dingen:

1. Die Joomla-Seite war zuvor kompromittiert worden und Google hatte dabei ungewöhnliche bzw. manipulierte URLs entdeckt.
2. Für die Domain existierte ein Wildcard-DNS-Eintrag, durch den praktisch jede beliebige Subdomain auf denselben Webserver zeigte.

Der Wildcard-DNS-Eintrag war also nicht die Ursache des Hacks. Er wirkte aber wie ein Verstärker für die unerwünschte Indexierung.

Was ist ein Wildcard-DNS-Eintrag?

Ein Eintrag wie

*.example.org   A   203.0.113.10

bedeutet:

Jede nicht ausdrücklich definierte Subdomain von example.org soll auf diese IP-Adresse zeigen.

Damit funktionieren nicht nur bewusst angelegte Hosts wie:

www.example.org
mail.example.org

sondern grundsätzlich auch:

test.example.org
abc.example.org
m.example.org
admin-v2.example.org
monitor.example.org
irgendwas.example.org

sofern dafür kein spezifischerer DNS-Eintrag existiert.

Ein Test ist einfach:

dig zufallsname-12345.example.org A +short

Wenn dort dieselbe Server-IP zurückkommt, obwohl diese Subdomain nie eingerichtet wurde, ist sehr wahrscheinlich ein Wildcard-DNS-Eintrag aktiv.

DNS allein reicht noch nicht

Ein wichtiger Punkt:

Der Wildcard-DNS-Eintrag allein sorgt noch nicht dafür, dass eine Webseite unter jeder Subdomain erscheint.

DNS beantwortet zunächst nur die Frage:

Auf welche IP-Adresse soll dieser Hostname zeigen?

Danach entscheidet der Webserver, was mit dem HTTP-Request passiert.

Wenn Apache, nginx oder die Hosting-Konfiguration unbekannte Hostnamen einfach an dieselbe Joomla-Installation weiterleitet, kann die Webseite tatsächlich auch unter beliebigen Subdomains erreichbar sein.

Dann wird aus:

https://www.example.org/artikel

möglicherweise ebenfalls:

https://m.example.org/artikel
https://monitor.example.org/artikel
https://abc.example.org/artikel

Wenn diese Varianten öffentlich erreichbar sind, können auch Suchmaschinen sie entdecken.

Der Zusammenhang mit einem Joomla-Hack

In meinem Fall war zuvor eine Joomla-Erweiterung kompromittiert worden.

Dabei waren unter anderem ungewöhnliche URLs entstanden, die von Google gecrawlt wurden.

Eine davon verwies beispielsweise auf eine hochgeladene PHP-Datei innerhalb einer Joomla-Komponente.

Google kann solche URLs unter anderem über externe Links, Crawling, Sitemaps, interne Verweise oder bereits bekannte URL-Muster entdecken.

Wenn gleichzeitig jede beliebige Subdomain auf dieselbe Joomla-Seite zeigt, vervielfacht sich die Zahl potentiell erreichbarer URL-Varianten.

Aus einer URL kann dann theoretisch eine ganze Familie werden:

example.org/pfad
m.example.org/pfad
admin-v2.example.org/pfad
monitor.example.org/pfad
foo.example.org/pfad
bar.example.org/pfad

Das bedeutet nicht zwangsläufig, dass ein Angreifer jede dieser Subdomains bewusst eingerichtet hat.

Sie können schlicht deshalb funktionieren, weil:

*.example.org

auf denselben Server zeigt.

So habe ich den Wildcard-Eintrag gefunden

Zunächst wurde die öffentliche DNS-Konfiguration überprüft.

Ein Test mit einer frei erfundenen Subdomain ist dafür besonders hilfreich:

dig diesegibtesgarantiertnicht.example.org A

Wenn die Antwort beispielsweise lautet:

diesegibtesgarantiertnicht.example.org. 86400 IN A 203.0.113.10

ist klar:

Auch nicht eingerichtete Subdomains werden aufgelöst.

Anschließend sollte man die DNS-Zone beim tatsächlichen DNS-Provider prüfen.

Gesucht wird nach einem Eintrag wie:

*

bzw.

*.example.org

mit einem A- oder AAAA-Record.

Zusätzlich prüfen, ob der Webserver die Subdomain annimmt

Nach der DNS-Prüfung sollte getestet werden, was der Webserver mit einem erfundenen Hostnamen macht.

Zum Beispiel:

curl -I https://zufall-12345.example.org/

Wenn die Seite dort normal mit:

HTTP/2 200

antwortet, wird der unbekannte Hostname tatsächlich von der Webseite bedient.

Für einen gezielten Test gegen eine bestimmte Server-IP kann curl auch ohne Änderung des öffentlichen DNS verwendet werden:

curl --resolve zufall-12345.example.org:443:203.0.113.10 \
  -I https://zufall-12345.example.org/

Damit wird für diesen einzelnen Test so getan, als würde der Name auf die angegebene IP zeigen.

Wildcard-DNS entfernen

Wenn beliebige Subdomains nicht benötigt werden, kann der Wildcard-Eintrag entfernt werden.

Danach sollte ein Test wie:

dig zufall-12345.example.org A +short

keine Server-IP mehr zurückgeben.

Wichtig ist dabei die DNS-TTL.

Bei einem Eintrag mit beispielsweise:

86400

beträgt die maximale Cache-Zeit:

86400 Sekunden = 24 Stunden

Ein bereits aufgelöster Wildcard-Eintrag kann deshalb noch eine Zeit lang in DNS-Caches vorhanden sein.

Das bedeutet nicht, dass die Änderung nicht funktioniert hat.

DNS entfernen reicht langfristig nicht immer aus

Zusätzlich zur DNS-Bereinigung ist es sinnvoll, den Webserver so zu konfigurieren, dass unbekannte Hostnamen nicht einfach dieselbe Joomla-Seite ausliefern.

Ein Server sollte idealerweise nur die ausdrücklich vorgesehenen Hosts akzeptieren, zum Beispiel:

example.org
www.example.org

Unbekannte Hosts können stattdessen:

• abgewiesen werden,
• einen Fehlerstatus liefern,
• oder kontrolliert auf die kanonische Domain umgeleitet werden.

Welche Variante sinnvoll ist, hängt von der jeweiligen Server- und Hosting-Konfiguration ab.

Der Vorteil:

Selbst wenn später versehentlich wieder ein DNS-Eintrag auf den Server zeigt, liefert der Webserver nicht automatisch die eigentliche Joomla-Seite aus.

Canonical-Tags helfen, lösen das Problem aber nicht allein

Joomla bzw. SEO-Erweiterungen können sogenannte Canonical-URLs ausgeben.

Beispielsweise:

<link rel="canonical"
      href="https://www.example.org/artikel">

Damit wird Suchmaschinen signalisiert:

Diese URL ist die bevorzugte Version des Inhalts.

Das ist hilfreich, ersetzt aber keine saubere DNS- und Webserver-Konfiguration.

Wenn hunderte oder tausende alternative Hosts öffentlich dieselben Inhalte ausliefern, sollte die Ursache behoben werden, statt sich nur auf Canonical-Tags zu verlassen.

Warum Google die alten URLs trotzdem noch zeigt

Nachdem der Wildcard-DNS-Eintrag entfernt wurde, verschwinden die betreffenden URLs nicht sofort aus der Google Search Console.

Google kennt diese Adressen weiterhin aus seinem bisherigen Crawl.

Erst wenn Google sie erneut besucht und feststellt, dass sie nicht mehr erreichbar sind oder korrekt umgeleitet werden, kann sich der Index entsprechend ändern.

Das kann deutlich länger dauern als die DNS-Umstellung selbst.

Deshalb sollte man unterscheiden:

DNS

Die Änderung kann – abhängig von der TTL – innerhalb von Stunden wirksam werden.

Google-Index

Bereits bekannte URLs können noch Tage, Wochen oder länger in Berichten auftauchen.

Eine alte URL in der Search Console ist deshalb nicht automatisch ein Hinweis darauf, dass sie aktuell noch funktioniert.

Stichproben nach der Änderung

Nach Ablauf der DNS-TTL lohnt sich ein erneuter Test:

dig zufall-67890.example.org A +short

Erwartetes Ergebnis:

keine Ausgabe

Danach können einige der zuvor von Google gefundenen Hosts geprüft werden.

Beispielsweise:

dig m.example.org A +short
dig admin-v2.example.org A +short
dig monitor.example.org A +short

Wenn diese Namen nie benötigt wurden, sollten sie nach der Bereinigung nicht mehr auf den Webserver zeigen.

Wildcard-DNS ist nicht grundsätzlich schlecht

Ein Wildcard-Eintrag ist kein Sicherheitsproblem per se.

Es gibt legitime Anwendungen, beispielsweise:

kunde1.example.org
kunde2.example.org
kunde3.example.org

wenn eine Anwendung dynamisch beliebige Subdomains verwendet.

Problematisch wird ein Wildcard-Eintrag vor allem dann, wenn:

• er gar nicht benötigt wird,
• niemand mehr weiß, warum er existiert,
• der Webserver jeden beliebigen Host akzeptiert,
• oder ein kompromittiertes System dadurch unter vielen Hostnamen erreichbar wird.

In einer normalen Joomla-Webseite mit wenigen fest definierten Domains gibt es häufig keinen Grund, jede denkbare Subdomain auf dieselbe Installation zeigen zu lassen.

Was der Wildcard-Eintrag nicht beweist

Bei der Untersuchung eines Hacks ist auch hier Vorsicht bei Schlussfolgerungen wichtig.

Ein Eintrag wie:

*.example.org

beweist nicht:

Ein Angreifer hat hunderte Subdomains angelegt.

Tatsächlich wurde möglicherweise keine einzige davon individuell eingerichtet.

Ebenso beweist eine bei Google auftauchende Adresse wie:

admin-v2.example.org

nicht automatisch, dass dort tatsächlich ein Administrationssystem existierte.

Der Name kann vollkommen beliebig sein.

Der entscheidende Test ist deshalb immer:

Warum löst dieser Hostname überhaupt auf und was liefert der Server bei einem Request dorthin aus?

Kurzfassung

Symptom

Google kennt plötzlich viele unbekannte Subdomains wie:

m.example.org
admin-v2.example.org
monitor.example.org

Mögliche Ursache

In der DNS-Zone existiert:

*.example.org

und zeigt auf denselben Webserver wie die eigentliche Webseite.

Zusätzliche Voraussetzung

Der Webserver akzeptiert die unbekannten Hostnamen und liefert dafür ebenfalls die Joomla-Seite aus.

Folge

Beliebig viele Hostnamen können auf dieselben oder auf kompromittierte Joomla-URLs zeigen und von Suchmaschinen entdeckt werden.

Lösung

Wenn Wildcard-Subdomains nicht benötigt werden:

1. Wildcard-DNS-Eintrag entfernen.
2. DNS-TTL abwarten.
3. Zufällige Subdomains mit dig testen.
4. Webserver so konfigurieren, dass nur vorgesehene Hostnamen akzeptiert werden.
5. Canonical-URLs kontrollieren.
6. Google die alten URLs anschließend neu crawlen lassen.

Fazit

Der Wildcard-DNS-Eintrag war in meinem Fall nicht die Ursache der Joomla-Kompromittierung.

Er erklärte aber, warum völlig frei erfundene Subdomains dieselbe Joomla-Webseite auslieferten und warum Google ungewöhnlich viele Hostvarianten kennen konnte.

Die wichtigste Erkenntnis war deshalb:

Bei merkwürdigen Subdomains nach einem Website-Hack nicht automatisch davon ausgehen, dass diese einzeln angelegt wurden. Zuerst DNS-Wildcards und die Host-Konfiguration des Webservers prüfen.

Gerade die Kombination aus kompromittierten URLs, Wildcard-DNS und einem Webserver, der unbekannte Hostnamen akzeptiert, kann einen einzelnen Vorfall im Suchmaschinenindex deutlich größer erscheinen lassen, als er technisch tatsächlich ist.