DNS Propagation

Zugegeben, ich musste eine Weile überlegen, ob ich diesen Beitrag unter “Kurioses” oder “Sicherheit” schreibe. Aber das Kuriosum überwiegt den Sicherheitsaspekt, zumindest diesmal.

Wer meine Beiträge im HiSolutions Research-Blog verfolgt, erinnert sich vielleicht noch an meinen Artikel XSS auf Abwegen. Damals hatte ich an diversen Stellen in DNS-Einträgen und Server-Headern Javascript versteckt, das leider viel zu häufig auf Webseiten, die die entsprechenden Datenfelder anzeigten, zu Popups führten. Das bedeutete: Die Seite war verwundbar, bösartige Aktoren hätten Menschen mit Links zu vermeintlich vertrauenswürdigen Seiten angreifen können. Die Schwachstellen wurden den jeweiligen Anbietern gemeldet und größtenteils behoben und ich dachte, mit dem Writeup sei es dann auch getan gewesen. Oh boy, was I wrong!

Abgesehen davon, dass einige Anbieter bis heute keine Anstalten gemacht haben, die Sicherheitslücke zu schließen, holte mich heute die Vergangenheit ein. Und das war so:

Ich bekam morgens kurz nach acht Uhr eine Mail von web.de. Das ist nichts sonderlich ungewöhnliches, denn ich habe DMARC für meine Webseite aktiviert und es so eingestellt, dass ich von Mailservern, die in irgendeiner Weise mit meinem Server Kontakt haben, Reports bekomme. Darin steht meistens, dass meine DKIM- und SPF-Records valide sind und Mails daher entweder eindeutig meinem Server zugeordnet werden können oder ebenso eindeutig als Fake entlarvt und verworfen werden können. Nichts anderes tun diese DNS-Einträge, sie erlauben es externen Servern, festzustellen, ob eine Mail wirklich von mir und meinen verwendeten Mailservern kommt oder nicht.

Aber diese Mail war anders. In einer Zip-Datei steckte wie üblich die XML-Datei mit dem üblichen Report. Doch diesmal sah sie anders aus. Mir sprang ein <spf>fail</spf> und im SPF-Block ein <result>temperror</result> entgegen. Was war da passiert?

Da SPF zu 100% am entsprechenden DNS-Record hängt, war der erste Weg zu meinem Domain-Anbieter hosting.de, bei dem die Domain ichbinein.org verwaltet wird. Dort schnell in die DNS-Einträge geschaut… sah alles gut aus. IPv4- und IPv6-Adresse meines Mailservers stimmten, der Include-Flag fügte zudem die tuta-Mailserver als berechtigt hinzu, die Einstellungen sagten “von denen und sonst keinem anderen stammen valide Mails”. Da mein MX allerdings schon länger zu tuta zeigt und mein Hauptserver nur noch Mails sendet, aber nicht mehr von extern empfängt, checkte ich auch dort schnell die Einstellungen, doch auch hier passte alles.

Was war da los? Der nächste Weg führte mich zu DNS Checker. Domain eingegeben, auf den ersten Blick sah auch da alles gut aus. Doch standardmäßig werden dort die A-Records geprüft, dass die stimmen wusste ich, denn ich erreichte ja meine Domain problemlos und eine Nichterreichbarkeit hätte bereits eine Reihe von Warnmechanismen ausgelöst. Da ich wusste, dass das Problem bei den SPF- und damit den TXT-Records lag, stellte ich die Prüfung auf TXT um… und staunte Bauklötze! Rund 70% der bei Check DNS hinterlegten DNS-Server zeigten nicht den erwarteten grünen Haken, sondern ein rotes X an. Nur eine Handvoll Server schien meine aktuellen TXT-Records abgeholt zu haben, der Rest hatte sie schlichtweg vergessen.

Nach einigem Hin und Her, verschiedenen kleinen Änderungen an DNS-Einträgen und der erfolgreichen Prüfung der anderen Domains, die ebenfallsbei hosting.de liegen, rief ich beim Support an und hatte schon nach wenigen Sekunden jemanden am Ohr, der sich mein Problem anhörte. Wir schauten gemeinsam die DNS-Einträge durch, doch auch zwei Augen fanden keinen offensichtlichen Fehler, auch wenn wir gemeinsam über den Inhalt einiger Einträge schmunzelten. Nach einigen Minuten verständigten wir uns darauf, dass ich ein Support-Ticket aufmachen solle und jemand mit tieferem technischen Wissen noch einmal draufschauen sollte. Gesagt, geten, die Mail abgeschickt und gewartet.

Die Antwort kam einige Zeit später. Ich wurde belehrt, dass die DNS Propagation noch im Gange sei, da ich kürzlich Änderungen vorgenommen hatte kam das wenig überraschend. Da aber die vorigen Änderungen keine Veränderung gebracht hatten, war ich mir sicher, dass dieser Versuch ebenfalls ins Leere laufen würde und las weiter. Und dann kam der Hinweis, der auch in Rücksprache mit Freunden und Bekannten schon geäußert wurde, mir aber nicht sonderlich logisch erschien: Offenbar schlug auf Seiten vieler DNS-Akteure seit kurzem ein Blockiermechanismus an, der sich an meiner vor drei Jahren angelegten DNS-XSS-Payload störten. Ich fragte noch einmal nach, erörterte meine Überlegungen, wieso ich das für unwahrscheinlich hielt und bat um Verifizierung, dass dieser Eintrag tatsächlich die Ursache ist. Die Antwort war kurz und knackig: “Die Antwort kommt vom jeweiligen Resolver. Diesen kontrollieren wir nicht.” Offenbar war also beim Versuch, die DNS-Änderungen an weitere Server durchzureichen, eine Meldung aufgetaucht, die offenbar den besagten Eintrag als böswillig klassifizierte und daraufhin die Synchronisierung der TXT-Records gnadenlos abbrach.

Was mich wundert ist: Nicht der vermeintlich maliziöse Eintrag wurde geblockt, sondern alle TXT-Records, während alle anderen Records anstandslos übernommen wurde. Ob das ein Fehlverhalten oder erwünscht ist weiß ich nicht, aber ich werde versuchen, das in Erfahrung zu bringen. Kurios ist es auf jeden Fall.

Das Ende der Geschichte: Das Entfernen des entsprechenden Eintrages führte schon nach wenigen Sekunden dazu, dass alle Einträge propagiert wurden und mein Mailserver wieder arbeiten konnte, wie er soll.

Was bleibt ist ein etwas bitterer Nachgeschmack. Zum einen begrüße ich Bemühungen, Bedrohungen dieser Art (DNS wird teilweise für vielfältige Angriffe und Exfiltrationen genutzt) zu unterbinden. Zum anderen sehe ich aber auch das Problem, dass diese Maßnahmen vermutlich vorerst nur von einigen großen Anbietern umgesetzt werden und kleinere Anbieter weiterhin alles durchschleusen, was sie reinbekommen. Das Problem aus meiner Sicht ist, dass nun Sicherheitsforscher kaum noch sinnvoll auf solche Schwachstellen prüfen können, während diese bei den DNS-Anbietern ohne entsprechende Maßnahmen nun quasi unter dem Radar ausgenutzt werden können. Ich bin daher sehr zwiegespalten, was ich von der aktuellen Entwicklung halten soll.

Ein Shoutout jedenfalls an den Support von hosting.de, der mir schnell und unkompliziert die Scheuklappen abgenommen und zur Lösungsfindung maßgeblich beigetragen hat. Danke auch an meine Leute, die mir den entscheidenden Hinweis noch deutlich früher gegeben haben; hätte ich direkt auf euch gehört, wäre das Problem schnell gelöst gewesen. :) Hab’ euch lieb!