FAQ: Warum helfen SPF Einträge für jede einzelne Subdomain dabei Phishing zu vermeiden?

Autor: Oliver Schranz | CTO

Der Angriffsvektor Phishing hält Sicherheitsteams weiterhin beschäftigt. Obwohl es immer wieder als große Bedrohung für Unternehmen identifiziert wurde, sind wir als IT-Sicherheitsgemeinschaft immer noch nicht an dem Punkt, das Thema auch nur ansatzweise als gelöst betrachten zu können. Ein Teil des Problems ist, dass wir als Technikexperten oft davon ausgehen, dass komplexe Probleme (vollständig?) mit Technologie gelöst werden könnten. Phishing nutzt jedoch typischerweise soziale Normen, Neugierde und andere tief verankerte, menschliche Eigenschaften aus. Hier werden gerade Menschen, nicht Maschinen, angegriffen.

Entgegen vieler Werbesprüche gibt es hier keine Wunderwaffe gegen Phishing-Angriffe. Obwohl Technologie dieses Problem nicht vollständig lösen kann, gibt es allerdings Mechanismen um das Risiko zumindest schrittweise zu reduzieren. Einer dieser Mechanismen ist das Sender Policy Framework, kurz SPF.

Was ist SPF und wie hilft es gegen Phishing?

Im Prinzip ermöglicht SPF dem Inhaber einer Domain öffentlich zu erklären, von welchen IP-Adressen legitimen E-Mails stammen. Auf technischer Seite können  wir SPF-Regeln erstellen, die eine Gruppe von IP-Adressen whitelisten, von denen unsere E-Mails stammen. Beispielsweise der E-Mail-Server meiner Firma oder des Dienstleisters, den ich damit beauftragt habe. Diese Regeln werden durch einen DNS-TXT-Eintrag veröffentlicht, den die ganze Welt sehen kann.

Wie schützt uns das jetzt vor Phishing? Die folgende Abbildung beschreibt den typischen Ablauf aus der Perspektive des empfangenden E-Mail-Servers:

Angenommen ein Angreifer möchte das Unternehmen hinter victim.com angreifen:  er könnte z.B. E-Mails an die Mitarbeiter von der gefälschten E-Mail-Adresse  ceo@victim.com (klassischer CEO-Scam) schreiben. Auf der Empfängerseite wird der E-Mail-Server des Opfers den Domain-Teil des (gefälschten) Absenders, victim.com, verwenden, den SPF DNS-TXT-Eintrag anfordern und die erlaubten IPs nachschlagen. Trotz der gefälschten Absenderadresse hat der Angreifer einen eigenen E-Mail-Server verwendet, um die Nachricht zu übermitteln. Daher sieht der Empfänger die IP-Adresse des E-Mail-Servers des Angreifers. Diese IP ist nicht die des eigentlichen E-Mail-Servers, der normalerweise vom Opfer zum Senden von E-Mails verwendet wird. In diesem Fall schlägt die SPF-Überprüfung fehl. Der Server kann dies als Hinweis darauf verwenden, dass die empfangene Nachricht als Phishing, Spam oder sonstiges unerwünschtes Verhalten betrachtet werden soll.

Cool, aber warum brauche ich das für alle meine Subdomains?

Generell sollte man einen solchen Eintrag für alle eigenen Subdomains erstellen, nicht nur für diejenigen, die man zum Versenden von E-Mails verwendet. In unserem Beispiel würde das bedeuten, dass unsere Opferorganisation nicht nur SPF-Einträge für victim.com, sondern auch für mail.victim.com, ftp.victim.com, blog.victim.com und alle anderen vorhandenen Subdomains einrichten sollte. Gleiches gilt selbstverständlich auch für andere TLDs, auch wenn sie nur umleiten (z. B. victim.rocks -> victim.com). Aber warum ist das so?

Ich bin sicher, dass euer Administratorenteam weiß, von welchen Domains das Unternehmen E-Mails sendet. Aber wissen eure Mitarbeiter das auch? Was ist mit euren Kunden? Da wir über das Spoofing von Absenderadressen sprechen, spielt es keine Rolle, ob die Domain tatsächlich verwendet wird oder nicht. Es kommt darauf an, ob es glaubhaft ist, dass die Domain verwendet werden könnte.

Angenommen, ihr richtet einen SPF-Eintrag für victim.com ein, aber der Angreifer fälscht einen Absender ceo@mail.victim.com. Der empfangende Mail-Server wird nach einem SPF-Eintrag für mail.victim.com suchen, aber nichts finden. Die SPF-Überprüfung wird keinen Fehler produzieren, weil es keinen Eintrag gibt. Der Empfänger weiß auch nicht, wo er noch nach einem Eintrag suchen soll, außer bei der vom Absender der E-Mail angegebenen Domain. Soweit ich weiß, ist es keine gängige Praxis oder zumindest nicht weit verbreitet, von Subdomains zur Domains zu gehen um SPF Einträge zu finden.

Natürlich sind nicht alle Subdomains glaubwürdige Ziele für Phishing. Die Wahrscheinlichkeit, dass das Opfer den Angriff bemerkt, wenn der Angreifer beispielsweise 50yearscelebration.victim.com oder vpn.victim.com verwendet, ist wesentlich höher als bei mail.victim.com oder victim.com. Dennoch ist es immer noch sinnvoll, den Mechanismus zu nutzen um das Phishing-Risiko  zu reduzieren.

Zusammenfassung

In der IT-Sicherheit geht es immer darum, die Messlatte für Angreifer ein Stück höher zu legen. Wenn ihr mich fragt, macht es also absolut Sinn, einen so einfachen Mechanismus wie SPF auch einzusetzen. Beispielsweise mit einer Regel die erst mal für alle Domains und Subdomains besagt, dass keine E-Mails gesendet werden. Je nach Tool-Unterstützung könnte dies tatsächlich eine Standardeinstellung sein. Hier muss man dann nur für die wenigen Domains überschreiben, die für das Senden von E-Mails auch tatsächlich verwendet werden. Das Problem Phishing ist dadurch zwar nicht komplett gelöst, aber wir haben einen ersten Schritt getan.

Bonus FAQ

Warum schreibst du überhaupt über das Thema?

Unsere SaaS-Lösung Findalyze empfiehlt, für jede einzelne Subdomain einen SPF-Eintrag zu erstellen. Viele Menschen sind mit diesem Mechanismus nicht vertraut und stellen genau die oben genannte Frage: Brauchen wir es wirklich für alle Subdomains? In Zukunft können wir also diesen Beitrag als ausführliche Erklärung dafür verwenden, indem wir einfach den Artikel verlinken.

Kann der Angreifer nicht einfach erfundenesubdomain.victim.com verwenden? Es wird keinen SPF Eintrag geben, weil die Subdomain ja gar nicht existiert...

Gute Neuigkeiten: Man kann Wildcards in SPF-Einträgen verwenden: https://www.spf-record.com/faq/whats-about-subdomains

Wie passt das mit DKIM und DMARK zusammen?

Ähnlich wie SPF zielt DKIM darauf ab, den Ursprung einer E-Mail zu authentifizieren. Anstatt jedoch erlaubte Absender-IPs zu deklarieren, führt man hier kryptografische Signaturen auf E-Mails ein, die über einen im DNS verfügbaren öffentlichen Schlüssel verifiziert werden. Wenn also eine E-Mail mit einer gültigen Signatur ankommt, wissen wir, dass sie von einer legitimen Quelle gesendet wurde. Aber was ist mit E-Mails ohne Signaturen? Hier kommt DMARC ins Spiel, ein Mechanismus zur Festlegung und Publikation von E-Mail-Sicherheitsrichtlinien. Mit DMARC kann man öffentlich erklären, ob SPF und DKIM für E-Mails, die von der eigenen Domain stammen, verifiziert werden sollten, sowie festlegen, was mit E-Mails passiert, die die Validierung nicht bestehen, und ob man Berichte von Empfängern über "fehlgeschlagene" E-Mails erhalten möchte.

Lange Rede, kurzer Sinn: Je mehr, desto besser. Im Idealfall richtet man SPF und DKIM ein, und erzwingt beide via DMARC.