Websicherheit: Verwaiste Domains als Sicherheitsrisiko

Domains von Webservices, die aufgegeben wurden, können ein Sicherheitsrisiko für Webseiten darstellen. Mittels einer nicht mehr genutzten Azure-Subdomain hätte der Autor des Artikels die Kontrolle über zahlreiche Webseiten erlangen können.

Artikel von Hanno Böck veröffentlicht am 7. September 2017, 8:26 Uhr

Ein "freundliches Defacement", um auf ein Sicherheitsproblem aufmerksam zu machen (Bild: Screenshot)

Im modernen Web ist es üblich, dass Inhalte von Dritten geladen werden. Ob man ein Youtube-Video einbindet, einen Facebook-Button nutzt oder ein Werbebanner einblendet - in all diesen Fällen wird üblicherweise Javascript-Code von Dritten geladen und im Kontext einer Webseite ausgeführt.

Doch was passiert eigentlich, wenn der Service, dessen Code hier geladen wird, den Dienst einstellt? Falls die genutzte Domain gekündigt wird, können Angreifer dies ausnutzen - und die verwaiste Domain einfach selbst registrieren. Damit können sie dann die Kontrolle über Webseiten übernehmen, die den entsprechenden Skript-Code einbinden.

Um einen Überblick über dieses Risiko zu bekommen, hat der Autor dieses Textes einen Scan der Alexa-Top-1-Million-Liste durchgeführt. Bei allen HTML-Tags mit src-Attribut wurde überprüft, ob sich die dort abgerufene Domain auflösen lässt.

Ein nicht aufgelöster Domainname ist alleine noch kein Sicherheitsrisiko, denn in vielen Fällen gehört die Domain noch dem ursprünglichen Besitzer, nur der jeweilige Service wurde eingestellt. Das führt dann lediglich dazu, dass der Seitenaufbau unnötigerweise geringfügig verzögert wird.

Flickr bindet Code von vor fünf Jahren eingestelltem Service ein

Flickr, der Foto-Service von Yahoo, nutzte ein Skript von Yahoo Web Analytics. Der Yahoo-eigene Statistikservice wurde allerdings schon 2012 eingestellt, das Skript und die zugehörige Subdomain gibt es nicht mehr. Ganze fünf Jahre scheint davon bei Flickr niemand etwas mitbekommen zu haben. Da die zugehörige Domain weiter im Besitz von Yahoo war, handelte es sich aber wie erwähnt um kein Sicherheitsproblem.

Auf einer Reihe von Webseiten fand sich Code, der ein Skript von einer Subdomain namens piwiklionshare.azurewebsites.net einband - eine Subdomain des Microsoft-Cloud-Services Azure. Die Subdomain war bei Azure nicht registriert. Um Kontrolle über die Domain zu erlagen, reichte ein kostenloser Azure-Testaccount.

Ein Blick in die Logfiles verriet, dass circa 20 verschiedene Webseiten diesen Code nutzten. Bei allen handelte es sich um Lokalzeitungen aus den USA. Die meisten der betroffenen Webseiten befanden sich auf zwei benachbarten IPs. Das erleichterte es, die Betroffenen zu informieren. Zwar erhielt ich auf eine Mail mit einem Hinweis an die Betreiberfirma keine Antwort, der entsprechende Javascript-Code war aber kurz darauf von fast allen betroffenen Webseiten verschwunden.

Doch eine der betroffenen Webseiten - und zwar die mit den meisten Zugriffen - lieferte weiterhin Javascript-Code von der nun uns gehörenden Subdomain aus: Der Saline Courier, ebenfalls eine Lokalzeitung. Mehrere Versuche, die Zeitung selbst oder deren Redakteure darüber zu informieren, wurden ignoriert. Ein Dilemma, denn ewig würde ich die Subdomain natürlich nicht behalten und dafür bezahlen wollen. Doch sobald sich jemand anderes diese Domain greift, könnte das Ganze zu einem Sicherheitsrisiko für den Saline Courier und dessen Webseitenbesucher werden.

"Freundliches Defacement" zur Kontaktaufnahme

Doch ich hatte natürlich eine weitere Möglichkeit zur Kontaktaufnahme: Schließlich konnte ich Javascript-Code auf der betroffenen Webseite ausführen. Ich entschied mich also für ein "freundliches Defacement". Der Betrieb der Webseite wurde dabei nicht direkt gestört, mittels eines pinken Hintergrundes und einer gelben Infobox teilte ich den Besuchern der Webseite mit, dass hier ein Sicherheitsrisiko besteht und der Betreiber der Webseite den entsprechenden Javascript-Code entfernen sollte.

Das führte wohl zu einigen Panikreaktionen bei den technisch Verantwortlichen. Kurze Zeit später war das CSS der Webseite defekt und das Layout zerstört. Danach zeigte die Seite für einige Zeit nur eine PHP-Fehlermeldung, nur um kurz darauf wieder im ursprünglichen Zustand - samt meinem eingebundenen Javascript - zu erscheinen. Doch nach einigen Stunden war die Seite wieder normal erreichbar und der fragliche Javascript-Code entfernt.

Die meistbesuchte betroffene Seite hat das Problem damit behoben, doch weiterhin wird der entsprechende Javascript-Code regelmäßig abgerufen. Überzeugen kann man sich davon etwa auf der Webseite des Columbia Missourian - jeder Artikel dort hat einen Link "Report an error", hinter dem sich ein Formular verbirgt, das den fraglichen Javascript-Code nach wie vor einbindet. Trotz einer sehr penetranten Warnung, der ich inzwischen auch etwas Sound hinzugefügt habe, hat dort nach mehreren Wochen niemand reagiert.

Verwaiste Domains werden meist schnell wieder registriert

Es spricht einiges dafür, dass die von uns gefundenen Beispiele nur die Spitze des Eisbergs eines größeren Problems sind. Denn wenn Domains gekündigt werden dauert es meist nicht lange, bis jemand anderes versucht, die Domains umgehend wieder zu registrieren.

Ein Angreifer, der versucht, die Kontrolle über möglichst viele Webseiten zu erlangen, könnte gezielt nach Domains suchen, deren Javascript-Code von vielen Seiten eingebunden wird und die gekündigt werden.

So gibt es beispielsweise eine Reihe von Seiten, die den Code eines Statistikservices namens Compete einbinden. Die entsprechende Subdomain existiert nicht mehr, auf der Hauptdomain compete.com findet sich eine Meldung, dass der Service 2016 seinen Dienst eingestellt hat. Vermutlich wird die Domain irgendwann gekündigt oder verkauft. Wer auch immer sie danach besitzt, hat die Möglichkeit, die Kontrolle über zahlreiche Webseiten zu übernehmen.

Hostile Subdomain Takeover und andere Angriffsszenarien

Die beschriebenen Szenarien ähneln anderen Domain-Takeover-Angriffen, die in jüngerer Zeit beschrieben wurden. Unter dem Namen Hostlile Subdomain Takeover wird ein Szenario bezeichnet, bei dem Firmen mittels DNS-CNAME-Einträgen die Verwaltung einer Subdomain an einen externen Service auslagern. Beispiele dafür sind etwa Github oder Heroku.

Wird ein entsprechender CNAME-Eintrag angelegt und der Service anschließend wieder gekündigt - ohne dass der zugehörige CNAME gelöscht wird -, kann jeder die entsprechende Subdomain bei Github oder Heroku registrieren und den Inhalt kontrollieren. Ähnliches gilt wenn der CNAME auf eine Domain verweist, die gekündigt wurde.

Das Szenario mag etwas abstrakt klingen, aber es tauchen immer wieder derartige Lücken auf. So fand ein Sicherheitsforscher beispielsweise zahlreiche Subdomains von Mozilla-Domains, die er mittels Github übernehmen konnte.

Code einbinden: Auch eine Frage des Vertrauens

Generell sollte man sich immer im Klaren darüber sein, dass das Einbinden von externem Javascript-Code oder auch das Abgeben der Kontrolle über einzelne Subdomains ein Sicherheitsrisiko darstellen kann. Wer Code von Dritten einbindet, muss diesen insoweit vertrauen, dass diese das nicht ausnutzen, um die Webseite zu verändern, Malware auszuliefern oder in sonstiger Weise diese Möglichkeit mißbrauchen.

Webmaster sollten zumindest darüber Bescheid wissen, wem sie erlauben, Code in der eigenen Webseite auszuführen. Und wenn der entsprechende Service eingestellt wird, sollte man den Code umgehend entfernen.

Eine englischsprachige Beschreibung dieser Sicherheitslücke findet sich im Blog des Autors.