it-swarm.com.de

Warum ist es überhaupt möglich, Absender-Header in E-Mails zu fälschen?

Warum ist es bei so vielen beliebten E-Mail-Anbietern, die Benutzer dazu zwingen, sich mit ihren SMTP-Servern anzumelden, immer noch möglich, den Header "From:" in E-Mails zu fälschen? Was hindert Benutzer daran, die E-Mails, in denen die Quelldomäne des Absenders nicht mit der Domäne des SMTP-Servers übereinstimmt, einfach zu verwerfen?

23
d33tah

tl; dr

  • Es ist sehr einfach, eine Domain zu fälschen, selbst wenn die SPF-Steuerelemente aktiviert sind.

  • Die Lösung besteht darin, DKIM + DMARC oder SPF + DMARC zu verwenden

  • Der E-Mail-Client ist dafür verantwortlich, Ihnen mitzuteilen, ob die Nachricht die DMARC Display From -Verifizierung besteht

  • Das E-Mail-Protokoll ermöglicht legitimes Spoofing mithilfe von Resent- * und Header-Headern. Der E-Mail-Client (MUA) sollte diese Ausnahme anzeigen, wann immer sie vorhanden ist.

Es gibt einige Missverständnisse über SPF, nämlich:

  1. SPF verhindert nicht das Spoofing von E-Mails.
  2. SPF allein beeinflusst, beeinflusst oder steuert den RFC 2822 Display From nicht.
  3. Standardmäßig besteht der Nutzen von SPF darin, Backscatter-Probleme und sehr einfache Spoofing-Szenarien zu vermeiden.

Microsoft hat versucht, dieses Problem mit SenderID zu lösen (SPF wird auf die Display From-Adresse angewendet), aber es war zu kompliziert und hat das gesamte Problem nicht wirklich gelöst.


Hintergrund

Stellen Sie zunächst fest, dass jede SMTP-Nachricht zwei "Von" -Adressen und zwei "Bis" -Adressen enthält. Einer ist als RFC2821-Umschlag bekannt, der andere ist die RFC2822-Nachricht. Sie dienen verschiedenen Zwecken

Der Umschlag: (RFC2821)

  • Der Umschlag besteht aus Metadaten, die nicht im SMTP-Header angezeigt werden. Es verschwindet, wenn die Nachricht zum nächsten MTA geht.

  • Mit RCPT From: Werden die NDRs abgelegt. Wenn eine Nachricht vom Postmaster oder einem Remailer-Dienst kommt, ist dies normalerweise <> Oder [email protected]. Es ist interessant zu sehen, dass Salesforce dies ähnlich wie constantContact als Schlüssel in einer Datenbank wie [email protected] Verwendet, um festzustellen, ob die Nachricht zurückgeschickt wurde.

  • Der RCPT TO: Gibt an, an wen die Nachricht tatsächlich gesendet wird. Es wird für Benutzer "to" und "bcc" gleichermaßen verwendet. Dies wirkt sich normalerweise nicht auf die "Anzeige von Adressen" im E-Mail-Client aus. In einigen Fällen wird dieses Feld jedoch von MTAs angezeigt (wenn die RFC2822-Header beschädigt sind).

Die Nachricht (RFC2822)

  • Der Nachrichtenteil beginnt, wenn der Befehl data ausgegeben wird.

  • Zu diesen Informationen gehören die Ihnen vertrauten SMTP-Header, die Nachricht und ihre Anhänge. Stellen Sie sich vor, all diese Daten werden nacheinander von jedem MTA zum nächsten kopiert und eingefügt, bis die Nachricht den Posteingang erreicht.

  • Es ist üblich, dass jedem MTA dem oben genannten Kopieren und Einfügen Informationen zum MTA (Quell-IP, Ziel-IP usw.) vorangestellt werden. Außerdem werden die SPF-Prüfdetails eingefügt.

  • Dies ist der Display From Wird platziert. Das ist wichtig. Spoofer können dies ändern.

  • Das Mail From: Im Umschlag wird verworfen und normalerweise hier als return-path: - Adresse für NDRs abgelegt

Wie verhindern wir also, dass Personen das Display From ändern? Nun, DMARC definiert eine zweite Bedeutung für den SPF-Datensatz neu. Es wird erkannt, dass es einen Unterschied zwischen mschlag von und Anzeige von gibt und dass es legitime Gründe dafür gibt, dass sie nicht übereinstimmen. Da SPF ursprünglich so definiert wurde, dass es sich nur um Envelope From kümmert, erfordert DMARC bei einer anderen Anzeige von eine zweite DNS-Überprüfung, um festzustellen, ob die Nachricht von dieser IP-Adresse aus zulässig ist.

Um Weiterleitungsszenarien zu ermöglichen, ermöglicht DMARC auch, dass das Display From von DKIM kryptografisch signiert wird. Wenn ein nicht autorisierter Spammer oder Phisher versucht, diese Identität anzunehmen, schlägt die Verschlüsselung fehl.

Was ist DKIM? DKIM ist eine leichte kryptografische Technologie, die die in der Nachricht enthaltenen Daten signiert. Wenn Sie jemals eine Nachricht von Google Mail, Yahoo oder AOL erhalten haben, wurden Ihre Nachrichten von DKIM signiert. Der Punkt ist, dass niemand Sie jemals kennen wird, wenn Sie DKIM-Verschlüsselung und -Signatur verwenden, es sei denn, Sie schauen in die Header. Es ist transparent.

DKIM kann es normalerweise überleben, weitergeleitet und an verschiedene MTAs übertragen zu werden. Etwas, das SPF nicht kann. E-Mail-Administratoren können dies zu unserem Vorteil nutzen, um Spoofing zu verhindern.


Das Problem liegt darin, dass der SPF nur die RFC2821-Hüllkurve überprüft und nicht die Anzeige von. Da sich die meisten Menschen für das Display From interessieren, das in einer E-Mail-Nachricht angezeigt wird, und nicht für den Rückweg-NDR, benötigen wir eine Lösung, um dieses Teil zu schützen und zu sichern.

Hier kommt DMARC ins Spiel. Mit DMARC können Sie eine Kombination aus einer modifizierten SPF-Prüfung oder DKIM verwenden, um Display From zu überprüfen. Mit DKIM können Sie die RFC2822-Anzeige von kryptografisch signieren, wenn der SPF nicht mit der Anzeige von übereinstimmt (was häufig vorkommt).


Deine Fragen

Warum ist es immer noch möglich, "From:" - Header in E-Mails zu fälschen?

Einige Serveradministratoren haben nicht die neuesten Technologien implementiert, um dies zu verhindern. Eines der wichtigsten Dinge, die die Einführung dieser Technologien verhindern, sind "E-Mail-Weiterleitungsdienste" wie eine Mailinglistensoftware, automatische Weiterleitungen oder ein Alumni-Remailer (.forwarder). Nämlich:

  1. SPF oder DKIM sind nicht konfiguriert.

  2. Eine DMARC-Richtlinie ist nicht eingerichtet.

  3. Der E-Mail-Client zeigt die Überprüfungsergebnisse des Felds Anzeige von und des Felds Resent- * oder Sender nicht an.

Was hindert Benutzer daran, die E-Mails, in denen die Quelldomäne des Absenders nicht mit der Domäne des SMTP-Servers übereinstimmt, einfach zu verwerfen?

Was passt nicht zusammen: der Umschlag oder der Körper? Gemäß den E-Mail-Standards sollte der Umschlag nicht übereinstimmen, wenn er einen Remailer durchläuft. In diesem Fall müssen wir die Anzeige von DKIM signieren und sicherstellen, dass die MUA dies überprüft.

Schließlich muss der MUA (E-Mail-Client) anzeigen, ob der Absender DMARC-verifiziert ist und ob jemand versucht, dies mit einem Absender oder Resent-From -Header zu überschreiben.

27

Was hindert Benutzer daran, die E-Mails, in denen die Quelldomäne des Absenders nicht mit der Domäne des SMTP-Servers übereinstimmt, einfach zu verwerfen?

Nichts. Sie dürfen und viele verwenden dies, um Spam herauszufiltern.

Wie bei vielen Technologien mit Sicherheitsmängeln wurde E-Mail nicht im Hinblick auf Sicherheit und Authentifizierung entwickelt. Der Zweck des Feldes "Von" war mehr oder weniger der gleiche wie bei einem herkömmlichen Briefumschlag. Um E-Mails angesichts der Bedürfnisse und Missbräuche des 21. Jahrhunderts nutzbar zu machen, mussten wir zusätzliche Elemente hinzufügen. Insbesondere behandelt SPF den ersten Teil Ihrer Frage:

Warum ist es bei so vielen beliebten E-Mail-Anbietern, die Benutzer dazu zwingen, sich mit ihren SMTP-Servern anzumelden, immer noch möglich, den Header "From:" in E-Mails zu fälschen?

Die Lösung besteht darin, den Header/die IP beim Empfang zu überprüfen. Dies verhindert zwar technisch nicht das tatsächliche Fälschen des Headers, macht jedoch gefälschte Header weniger nützlich.

6
B-Con

Es gibt bereits teilweise Schutz dagegen: https://en.wikipedia.org/wiki/Sender_Policy_Framework

Alle gängigen E-Mail-Anbieter verwenden es. Sie behandeln SPF-Fehler jedoch unterschiedlich, einige Mail-Anbieter verwerfen Nachrichten basierend auf dieser Prüfung vollständig und einige Anbieter legen sie einfach in einem Spam-Ordner ab.

Jeder kann seinen eigenen E-Mail-Server erstellen und versuchen, als jeder zu senden.

Sie können Ihre Google Mail-Adresse überprüfen (falls vorhanden) und den Header einer E-Mail öffnen. Das Ergebnis der SPF-Prüfung wird oben angezeigt:

spf=pass (google.com: domain of *****@*****.com designates 174.**.**.** as permitted sender) smtp.mail=*****@*****.com;

4
sharp12345

[...] warum ist es immer noch möglich, "From:" - Header in E-Mails zu fälschen?

SMTP ist ein Protokoll, das entwickelt wurde, als Sie wahrscheinlich jeden Computer im Internet benennen konnten, und das Ausführen eines Computers, der E-Mails bereitstellte, war eine relativ große Sache, die von großen Organisationen und sehr engagierten Hobbiesten durchgeführt wurde. Es hat keinen eingebauten Schutz oder Sicherheit gegen schlechte Schauspieler und vertraut so ziemlich allem, was Sie ihm sagen.

Es gibt auch eine ganze Reihe legitimer Gründe, aus denen Sie möchten, dass sich Ihr "Von:" - Header von Ihrer Domain unterscheidet. Möglicherweise wird Ihr Mailserver für viele andere Domains (z. B. ein Web-/Mail-Hosting-Unternehmen) freigegeben. In diesem Fall für Ihren Der Rückwärtsdatensatz (PTR) und der Vorwärtsdatensatz (A/MX) unterscheiden sich zwangsläufig.

Angesichts der Tatsache, dass die Mehrheit der Benutzer in den meisten Fällen einen Mail-Dienst verwendet, der ihrer Mail-Domain entspricht. wir können eine Logik anwenden um SMTP. Dies führt zu Ihrer nächsten Frage:

Was hindert Benutzer daran, die E-Mails, in denen die Quelldomäne des Absenders nicht mit der Domäne des SMTP-Servers übereinstimmt, einfach zu verwerfen?

Die Antwort hier ist nichts , und die Leute tun es.

Es gibt eine ganze Reihe von Methoden zum Identifizieren von Spam, wie zum Beispiel:

Klassifizierungsprobleme wie das Identifizieren von Spam/Nicht-Spam sind Hauptstudienbereiche . Es ist leider nicht so einfach wie das Löschen von E-Mails, die nicht von der erwarteten Stelle stammen (Zeuge der großen Anzahl von Spam-Nachrichten, die von Google Mail-Konten zu Google Mail-Konten kommen), und die Anwendung dieser Regel wird wahrscheinlich einen großen Erfolg haben Anzahl der Snags (für den Fall, dass Ihr Mailserver auf irgendeine Weise gemeinsam genutzt wird); Sie können beziehen dies jedoch in Ihre Analyse der Nachricht ein und vertrauen ihr weniger, und wenn Sie ein gewisses Maß an Sicherheit überwunden haben, lassen Sie es einfach fallen.

E-Mails werden wahrscheinlich immer diese Art von Missbrauchsproblemen haben, da es sich inhärent um ein System handelt, mit dem Personen Nachrichten an Personen mit möglichst geringer Reibung senden und empfangen können. Es ermöglicht von Natur aus Menschen, die Sie nicht kennen, Ihnen Nachrichten zu senden, die Sie nicht erwartet haben, und genau wie beim normalen Mailsystem ist dies sowohl eine gute als auch eine schlechte Sache.

4
Bob Watson