Sep 01, 2021 at 01:59:47 (UTC)

6767

Warum kann ich SPF so einfach austricksen?

Zum Spaß habe ich mit SPF mal etwas ausprobiert und zu meinem Erschrecken hat es tatsächlich funktioniert.

Normalerweise funktioniert SPF ja so:
Der Mailserver empfängt eine E-Mail mit dem Absender "admin@microsoft.com".
Daraufhin schaut er nach, ob die Domain microsoft.com einen DNS TXT SPF Eintrag hat.
Wenn er einen hat, wird dieser analysiert, die IP Adressen aufgelöst und mit der IP Adresse des einliefernden Mailservers verglichen, ob diese berechtigt ist.
Soweit so klar.

Nun habe ich folgendes ausprobiert: (die Domain Namen sind natürlich frei erfunden, auch wenn es diese ggf. gibt)
Meine Firma, firma.de hat einen SPF Eintrag. (und sogar DKIM und DMARC) Nur deren MX darf E-Mails verschicken.
Nun habe ich von meinem privaten Mailserver spielundspass.de (hat auch einen SPF Eintrag!) folgende E-Mail versendet:

From: chef@firma.de
Return-Path: postmaster@spielundspass.de
To: testaccount@gmail.com

Meine Annahme war eigenlich, Google würde den SPF Eintrag der Absender-Domain (firma.de) prüfen und feststellen, dass mein privater Mailserver keine E-Mails in dessen Namen versenden darf.
Das ist aber nicht der Fall! :o
Statt dessen wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS und ich habe lt. Gmail eine "gültige" E-Mail von chef@firma.de in meinem Postfach.

An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.

Wie kann das sein?

Please also mark the comments that contributed to the solution of the article

Content-Key: 1215659978

Url: https://administrator.de/contentid/1215659978

Printed on: April 28, 2024 at 07:04 o'clock

21 Comments

Latest comment

Hallo,

Zitat von @Bluebrain:
Nur deren MX darf E-Mails verschicken.

Du redest jetzt aber nicht vom MX Record, oder?
https://www.heinlein-support.de/blog/security/ausgehende-mailserver-habe ...
https://www.united-domains.de/help/faq-article/was-ist-ein-mx-eintrag
https://de.wikipedia.org/wiki/MX_Resource_Record

Wie kann das sein?

https://de.wikipedia.org/wiki/Sender_Policy_Framework
Sicher das dein SPF richtig ist?

Gruß,
Peter

"deren MX" war einfach nur salopp ausgedrückt, aber genau genommen, technisch nicht korrekt, da gebe ich dir Recht.
Hat aber mit meiner Entdeckung nichts zu tun.

Es geht darum, dass die empfangenen Mailserver nicht den SPF Eintrag der Domain im From-Header-Feld prüfen, sondern jene vom Return-Path.
Und die Domain im Return-Path kann ja die eigene sein, inkl. SPF Eintrag, der dann auch positiv geprüft wird.

Einige E-Mail Clients zeigen den Return-Path/Sender zwar an z.B. "gesendet über ax1.smtp.gmx.de", aber wer beachtet das schon oder hegt deshalb Zweifel?

Sagen wir mal z.B. dir gehört peter.de. Auf deinem Webserver betreibst du auch einen MTA und dein SPF-Eintrag lautet "v=spf1 a -all"
Ich kann aber jetzt ganz einfach eine E-Mail mit "From: office@peter.de" versenden und der SPF Check ist positiv, solange ich von einem lt. (meinem) SPF Eintrag berechtigten Server der Domain im Return-Path Header-Feld versende.

Moin,
ja SPF ist etwas löchrig ...

Die Domains zeigen aber nicht zufällig auf den gleichen Host oder liegen beim gleichen Hoster, oder? Bei den größeren Hostern teilen sich ja die Kunden die Server. Nehmen wir z.B. IONOS. Hier übernimmt ein Server-Verbund der als "mout.kundenserver.de" erreichbar ist den Versand aller Mails.

Alle SPF-Einträge von Domains die bei IONOS liegen (sofern kein externer Server verwendet wird) zeigen auf "mout.kundenserver.de"... Und ja, das bedeutet genau das wonach es sich anhört ...

Kunde A hat ein Webspace-Paket mit domain-a.de
Kunde B hat ein Webspace-Paket mit domain-b.de

Zwar kann Kunde A kein Mail-Postfach für @domain-b.de erstellen, was aber nicht heißt, dass man nicht in deren Namen versenden könnte ... Der SPF-Eintrag zeigt ja auf die gleichen Server (bzw. deren IPs), für dem Empfänger der den SPF auswertet, scheint alles okay zu sein.

Prinzipiell betrifft das jeden Server auf den mehrere Domains zeigen. Sogar Exchange-Online.
Diese Konstellation ist bei dir nicht zufällig der Fall? Das könnte deine Beobachtung erklären.

DKIM und DMARC Einträge könnten Abhilfe schaffen, aber deren Verwendung befindet sich irgendwie noch in den Kinderschuhen?

Moin,

Zitat von @Bluebrain:
An eine yahoo.com, outlook.com sowie protonmail.com Adresse hat es übrigens genauso funktioniert.
Wie kann das sein?

Eigentlich dürfte das in der Tat nicht so sein.

Ich teste SPF immer mit dieser Seite.
https://www.appmaildev.com/de/spf

Was spuckt die für Deine Fake-Mail aus?

Stefan

Zitat von @Bluebrain:

Zum Spaß habe ich mit SPF mal etwas ausprobiert und zu meinem Erschrecken hat es tatsächlich funktioniert.
... wird die Domain vom Return-Path (spielundspass.de) geprüft, das Ergebnis ist SPF=PASS
Wie kann das sein?

Hallo @Bluebrain,

leider fehlt in Deinem Post ein Auszug des Headers der eingehenden Mail, dann könnte man sich den SPF-Eintrag mal ansehen. Standardkonform, so wie ich den Standard verstehe, ist es, das "MAIL FROM" -Feld auszuwerten.

2.4
   SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check  
   either has not been performed or has not reached a definitive policy
   result by applying the check_host() function to the "MAIL FROM"  
   identity as the <sender>.

und genau das macht z.B. Google auch.

ARC-Authentication-Results: i=1; mail.testdomain.de; dkim=pass header.d=testdomain.de header.s=2017 header.b=OlltUYa6; spf=pass (mail.testdomain.de: domain of mail@testdomain.de designates 85.XXX.120.XXX as permitted sender) smtp.mailfrom=mail@testdomain.de
X-Spamd-Bar: ++
Authentication-Results: mail.testdomain.de; dkim=pass header.d=testdomain.de header.s=2017 header.b=OlltUYa6; dmarc=none; spf=pass (mail.testdomain.de: domain of mail@testdomain.de designates 85.XXX.120.XXX as permitted sender) smtp.mailfrom=mail@testdomain.de

Vielleicht zeigst Du uns mal den Header?

Allerdings:
Hier wird aber exakt das von Dir beschriebene Verhalten als Standard beschrieben. Kann ich aber mit dem RFC 7208 nicht in Einklang bringen. Dort steht klar und deutlich:

1.1.3.  MAIL FROM Definition

   ...

   As such, throughout this document the term "MAIL FROM" will be used,  
   which is defined as the RFC5321.MailFrom (reverse-path) identity
   described in [RFC5598].

Und der dort beschriebene reverse-path ist definiert in RFC5321 als aus dem MAIL FROM -Feld zu entnehmen:

3.3.  Mail Transactions

        MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

Entweder also ist der Standard bei Deinem Hoster (Server) nicht korrekt implementiert oder (wahrscheinlicher) das Verhalten beruht auf der vom Kollegen @anteNope beschriebenen Verwendung des selben Servers/DNS-Domain.

Viele Grüße, commodity

Kannst du den SPF Eintrag (ggf. anonymisiert) hier mal Posten? Wichtig ist ja wie das "all" gehandhabt wird
bei einem "+all" wirds immer gehen

Hier die Tabelle der möglichen Werte und outcomes:
https://dmarcian.com/spf-syntax-table/

Wie commodity schrieb:
Works as expected!

Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender). Per Standard wird nur das von SPF ausgewertet und wenn du dir die Mailheader ansiehst, wirst du sehen, dass auch nur das vom "Authentication-Results:"-Header erwähnt wird.
Was im "From:"-Header steht, wird von SPF nicht geprüft, nur das, was im Envelope steht.
Das war von Anfang an so implementiert, dass ein Mailserver das verifizieren kann — und für den ist der From-Header nur Payload.

Um dieses Problem zu lösen wurde DKIM+DMARC entwickelt. Das würde in deinem Szenario nicht verifizieren.

Zitat von @LordGurke:
Wie commodity schrieb:
Works as expected!

Stichwort ist allgemein SMTP-Envelop.

Wie schon geschrieben prüft SPF nur den SMTP-Envelope und nicht den Inhalt der Mail.
Dies führt (natürlich) dazu, dass der Sichtbare Absender völlig beliebig sein kann und für den Benutzer dies nicht ersichtlich ist.

Das ist dann eine Aufgabe für das Antispam-System was alle eingehenden Mails prüft und solche Mails ablehnt.

Aber das Thema ist komplex, die "unfreundlichen Leute" vielfälitig und gut ausgebildet und es geht um viel Geld.

Man kann auch einfach die Domäne firma.com buchen und eine Mail mit chef@firma.com verschicken. Die wenigsten Leute schauen darauf. Besonders Mails von Lieferanten mit Rechnungen werden kaum darauf geprüft.

Stefan

Zitat von @LordGurke:
Was du als Return-Path angegeben hast, entspricht dem "MAIL FROM" einer SMTP-Transaktion (Envelope Sender).

Danke @LordGurke für die Klarstellung. Das bringt auch die vermeintlich divergierende Fundstelle wieder in die Reihe.

Allerdings habe ich es noch nicht ganz geschnackelt. Lt. RFC 5321 ist doch der reverse-path das "MAIL FROM". Wie kommt jetzt das "REPLY TO" in den Envelope?

Viele Grüße, commodity

Alle von mir getesteten Mailserver checken die Domain im Return-Path Header, nicht aber vom From-Header.
(Return-Path! NICHT Reply-To!)
Und nein, natürlich handelt es sich nicht um den gleichen Mail-Server. Das würde ja nichts "beweisen".
Und auch der SPF Eintrag ist nicht mit "+all" gesetzt (Was den Check trotzdem fehlschlagen lassen würde. Der Mailserver wird damit nur angewiesen, die E-Mail nicht zu verwerfen)

Hier mal ein anschauliches Beispiel:

geprüft wird der return-path, der sich wiederum aus dem MAIL FROM ergibt, wie @LordGurke ja oben schreibt.
(womit auch mein obiges Missverständnis geklärt wäre)

RFC5321

When the delivery SMTP server makes the "final delivery" of a  
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.

Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?

Viele Grüße, commodity

Ja natürlich wäre es besser, wenn gegen den From-Header geprüft wird.
Das ist ja der wichtigste Indikator für einen Empfänger, von wem die E-Mail stammt.
Wer bitte schön schaut schon in den Quelltext der E-Mail und überprüft selbst den Return-Path Header und kann damit überhaupt etwas anfangen?
(ich rede hier von normalen Usern und nicht von Administratoren und Forensikern)

Aber selbst ein etwas fortgeschrittener User würde hier in die Falle tappen.
"Aha, eine E-Mail von administrator.de. Da steht "SPF PASS", scheint alles in Ordnung zu sein. Da steht auch irgendwas, dass der Server berechtigt ist, Mails zu versenden. Klingt gut."

Zitat von @commodity:

geprüft wird der return-path, der sich wiederum aus dem MAIL FROM ergibt

Da kann man aber (am eigenen) Mailserver einsetzen, was immer man möchte und wird, wie man an meinem praktischen Beispiel sieht, NICHT automatisch aus dem From-Header gebildet.

Zitat von @commodity:

Wäre es denn besser, wenn er gegen den From-Header prüfen würde? Die kann der Delivery-SMTP doch genauso fälschen?

Dann würden aber sämtliche Alarme anschlagen.
Hätte Google (oder einer der anderen Mailserver) die Domain in meinem From-Header (administrator.de) geprüft, dann wäre die E-Mail sofort blutrot markiert im Spam-Ordner gelandet. (oder sofort abgewiesen worden)

OK, jetzt habe ich das Problem verstanden, glaube ich. Und Du liegst richtig. Und bist nicht allein:
https://www.reddit.com/r/sysadmin/comments/20rnt6/smtp_question_does_spf ...
https://stackoverflow.com/questions/47572210/why-is-spf-not-validated-ag ...

spf ist wohl einfach nicht dafür gemacht, sondern soll allein verhindern, dass von nicht legitimierten Servern versandt wird. In Deinem Falle hat ja postmaster@spielundspass.de legitimiert versandt, der Server war aber eben spielundspass.de und nicht firma.de.

Das ist, wie Du ja treffend rausgearbeitet hast, kein besonderer Schutz und die Darstellung in der Grafik rechts oben bei Wikipedia ist wohl nur dann richtig, wenn Mallory nicht auch noch den Return-Path manipuliert hat.

Viele Grüße, commodity

Stimmt, bei Wikipedia steht es:

Zitat von Wikipedia:

Zu beachten ist, dass diese Überprüfung sich nicht auf die Kopfzeile From bezieht, welche normalerweise von E-Mail-Programmen als Absender angezeigt wird

Na das haben sich ja GANZ schlaue Köpfe ausgedacht! *facepalm*

Dass SPF nicht das Allheilmittel gegen Spam und zur Kontrolle des Absender ist, war mir ja klar.
Aber dass es dermaßen unnütz ist, wusste ich bisher auch nicht.

Zitat von @Bluebrain:
Aber dass es dermaßen unnütz ist, wusste ich bisher auch nicht.

Ha, das wusste ich auch noch nicht. Na herzlichen Glückwunsch 😒

Falls es um Spamschutz geht: Ich habe den Mailserver von Thomas Leister am Laufen und ganz exakt 0 unerkannten Spam. Habe bei keinem Provider bislang bessere Werte gesehen. - Thomas Baukästen sind aber auch auf der Höhe der Zeit

Viele Grüße, commodity

"exakt 0 unerkannten Spam" kann ich mir irgendwie nicht vorstellen. Allein schon deshalb, weil es manchmal reine persönliche Vorlieben sind, ob man etwas als Spam sieht oder nützliche Info.

Ich nutze Google mit meiner eigenen Domain und bin äußerst zufrieden.

zurück zum Thema:
die Tatsache, dass offensichtlich nicht der From-Header ausgewertet wird, macht natürlich auch DKIM mehr oder weniger nutzlos.
Denn wie in meinem Test, wird die Domain vom From-Header erst gar nicht auf einen DKIM/DARMC Eintrag geprüft.

Jetzt wäre es noch interessant, ob man das ganze auch noch auf die Spitze treiben könnte, indem man mit dem Key von der Return-Path Domain eine DKIM Signatur einfügt.
Wenn der empfangene Mailserver nämlich die DKIM Domain nicht mit der Domain vom From-Header vergleicht, hätte man auch noch eine gültige DKIM Signatur mit fremder From-Domain. :D

Ich muss mal schauen, wie ich das testen kann. Zumindest opendkim lässt sich nicht so ohne weiteres dazu überreden, denn das liest die Domain aus dem From-Header aus.
Also entweder muss ich mich durch tausende Zeilen Source Code wühlen, oder die Signatur selbst programmieren.

Okay, jetzt wird es wirklich lächerlich!

Ich habe mal ein bisschen was programmiert und konnte nun erfolgreich eine E-Mail versenden die SPF und DKIM valide ist, mit einem Absender/From, der eigentlich seine eigene SPF und DKIM Implementierung hat und mit dem ich rein gar nichts zu tun habe!

Vielleicht sollte ich ja ins Spammer-Geschäft einsteigen. :D

Dadurch, dass ich das ganze selbst programmiert habe, konnte ich natürlich auch jedes Detail exakt selbst bestimmen, was wie wo steht und signiert wird.
Normalerweise verwehrt ja jeder DKIM Milter die Signatur, wenn die From und DKIM Domain unterschiedlich sind.

also, Zusammenfassung:
meine Domain
mein MTA
mein SPF Eintrag
meine DKIM Signatur/Keys
ABER: ein ganz anderer Absender (der sich eigentlich auch mit SPF und DKIM "geschützt" hat - oder es zumindest glaubt)

P.S. Nein, ich nehme keine Aufträge an. ;)

Zitat von @Bluebrain:

Okay, jetzt wird es wirklich lächerlich!

Ich habe mal ein bisschen was programmiert und konnte nun erfolgreich eine E-Mail versenden die SPF und DKIM valide ist, mit einem Absender/From, der eigentlich seine eigene SPF und DKIM Implementierung hat und mit dem ich rein gar nichts zu tun habe! ...

Mein Bauchgefühl hatte mir irgendwie schon immer gesagt, dass der globale Mail-Verkehr "irgendwie kaputt" ist. Aber das sprengt jetzt doch irgendwie die Grenzen des erwarteten Ausmaßes ...

Vielleicht sollte ich ja ins Spammer-Geschäft einsteigen. :D

Spammer? Wohl eher Richtung Scammer. Das Ausmaß an "Schabernack" welches man damit treiben könnte, ist ja quasi unermesslich.

Jetzt mal ohne Witz, dokumentiere das und schick das an die großen Internet-Konzerne. Für so etwas gibt es vermutlich eine schöne große Belohnung?

Hast du über den Envelope-Sender einen SPF-Pass provoziert?
Falls die DMARC-Policies des Spoofing-Opfers erlauben, dass positives SPF ausreicht (aspf), könnte das erklären, warum die Policy nicht gezogen hat.

Zitat von @LordGurke:

Falls die DMARC-Policies des Spoofing-Opfers erlauben, ...

Damit hat es ja gar nichts zu tun.
Die Mailserver kümmern sich alle nicht um die Domain im From-Header, sondern gleichen SPF und DKIM nur mit der Domain im Envelope-Sender bzw. SMTP "MAIL FROM" bzw. Return-Path ab.
... und das ist eben die Domain von meinem MTA und von dem(!) werden die SPF und DKIM Infos gezogen und passen natürlich auch.
Was die Domain im From-Header eingerichtet hat, ist egal, weil es wie gesagt gar nicht abgefragt und behandelt wird.

German General E-Mail Internet

Hotly discussed

Developer diary: Release 6.1admtech

End of availability for classic Teams clientDani