it-swarm.com.de

Wie kann Paypal E-Mails so leicht fälschen, dass sie von jemand anderem stammen?

Wenn ich eine Zahlung in Paypal erhalte, wird mir eine E-Mail darüber gesendet (siehe Abbildung unten). Das Problem ist, dass die E-Mail von der E-Mail-Adresse des Geldabsenders und nicht von Paypal selbst stammt, obwohl der eigentliche Absender Paypal ist.

Email from Paypal

Hier ist der Text, der angezeigt wird, wenn ich in Google Mail "Original anzeigen" auswähle:

From: "[email protected]" <[email protected]>  
Sender: [email protected]

So können Sie sehen, dass der echte Absender Paypal ist.

Wenn Paypal den E-Mail-Absender so leicht fälschen kann und Google Mail ihn nicht erkennt, bedeutet dies, dass jeder die E-Mail-Absenderadresse fälschen kann und Google Mail sie nicht erkennt?

Wenn ich selbst E-Mails mit Telnet an Google Mail sende, wird in der E-Mail die Warnung angezeigt:

Diese Nachricht wurde möglicherweise nicht gesendet von: [email protected]

Ist das ein Sicherheitsproblem? Denn wenn ich daran gewöhnt bin, dass Zahlungs-E-Mails in Paypal scheinbar aus der E-Mail des Geldabsenders und nicht aus Paypal stammen, kann der Absender die Zahlung einfach selbst fälschen, indem er eine solche Nachricht aus seiner E-Mail sendet, und ich denke das vielleicht Dies ist die eigentliche Zahlung.

Ist das etwas Besonderes für Paypal oder kann jemand Google Mail so täuschen? Und wenn jemand kann, welche genaue Methode verwendet Paypal, um Google Mail zu täuschen?

147
Sunny88

Hier ist eine Dramatisierung des Kommunikationsverlaufs, wenn eine E-Mail irgendwo empfangen wird.


Kontext: Ein E-Mail-Server, allein in einer Bucht, irgendwo in Moskau. Der Server sitzt nur untätig da, mit einem Ausdruck der Erwartung.

Server :
Ah, lang sind die Tage meiner Knechtschaft,
Das soll in immer Einsamkeit ausgegeben werden,
'Ere kommt aus den äußeren Ringen
Der Swift Träger externer Nachrichten.

Eine Verbindung wird geöffnet.

Server :
Ein eingehender Kunde! Vielleicht eine Mail
Meiner Vormundschaft wird anvertraut
Damit ich als das schönste Ross vermitteln kann
Und zum Empfänger bringen Sie die ganze Geschichte.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Willkommen in meinem Reich, Netzwanderer,
Erfahren Sie, dass ich ein mächtiger Mailserver bin.
Wie werden Sie an diesem Tag angesprochen?
Soll die Notwendigkeit steigen, dass Ihr Name erraten wird?

Client :

HELO whitehouse.gov

Sei gegrüßt, Hüter der Vernetzung,
Wisse, dass ich aus dem blassen Gebäude hervorgegangen bin.

Server :

250 mailserver.kremlin.ru

Die eingehende IP-Adresse wird über den DNS in "nastyhackerz.cn" aufgelöst.

Edler Gesandter, ich bin dein Befehl,
Auch wenn deine Stimme aus den heißen Ebenen kommt
Von dem Land jenseits der asiatischen Berge,
Ich werde Ihrer schwächsten Forderung nachkommen.

Client :

MAIL FROM: [email protected]
RCPT TO: [email protected]
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Hier ist meine Nachricht, die Sie senden sollen:
Und treu auf den Äther übertragen;
Achten Sie auf die Adressen und den Namen des Absenders
Das soll am anderen Ende angezeigt werden.

Server :

250 Ok

So wurde es geschrieben, so soll es getan werden.
Die Nachricht wird gesendet und nach Russland gegangen.

Der Server sendet die E-Mail so wie sie ist und fügt nur einen "Received:" - Header hinzu, um den Namen zu markieren, den der Client bei seinem ersten Befehl angegeben hat. Dann beginnt der Dritte Weltkrieg. Das Ende.


Kommentar : E-Mails enthalten keinerlei Sicherheit. Alle Absender- und Empfängernamen sind indikativ und es gibt keine zuverlässige Möglichkeit, Spoofing zu erkennen (sonst würde ich viel weniger Spam erhalten).

390
Tom Leek

Jede E-Mail-Absenderadresse kann gefälscht werden, da Sie alle ausgehenden Daten ändern können, die Sie möchten. Sie müssen Google Mail nicht zum Narren halten. Wenn Sie dies sagen, kann Google Mail offensichtliche Probleme erkennen, wenn eine E-Mail, die als von einer Organisation gesendet markiert wurde, von einer anderen Domain zu ihnen gelangt.

Sie können auch nicht sicher sein, ob die ursprüngliche E-Mail in Ihrem Beispiel von Paypal stammt - dieses Absenderbit kann auch gefälscht werden!

Wenn Sie eine Authentifizierung wünschen, um dies zu verhindern, benötigen Sie eine Möglichkeit zum Signieren oder Verschlüsseln von E-Mails oder eine Out-of-Band-Überprüfung, um zu bestätigen, dass die E-Mail von Ihrem Freund stammt (wie Sie in Ihrem Kommentar erwähnt haben).

Im Ernst - vertraue keiner E-Mail. Nicht klicken Sie auf einen Link in einer E-Mail. Besonders von hochwertigen Zielen wie Paypal. Stattdessen sollten Sie sich wie gewohnt anmelden und prüfen, ob sie Ihnen etwas gesendet haben.

52
Rory Alsop

Wie andere bereits erwähnt haben, kann jeder E-Mail-Adresse fälschen beliebig einschließlich des Felds "Absender" - es gibt keinen technischen Grund, warum Paypal sogar eine eigene E-Mail-Adresse angeben muss Im Absenderbereich tun sie dies nur, weil sie ein ehrliches Unternehmen sind. Erwarten Sie nicht, dass Spammer so nett sind.

Nebenbei möchte ich jedoch erwähnen, dass Google Mail Unterstützung für DKIM bietet, mit dem Sie überprüfen können, ob eine Paypal-E-Mail wirklich von Paypal stammt.

So aktivieren Sie es: Klicken Sie oben rechts auf das Zahnrad -> E-Mail-Einstellungen -> Labs -> Aktivieren "Authentifizierungssymbol für verifizierte Absender"

(gmail labs image)

Jetzt werden signierte Paypal-E-Mails mit einem kleinen Schlüsselsymbol angezeigt:

(example image)

Es ist ähnlich wie bei der Post. Jeder kann Ihnen einen Brief mit Briefkopf senden, der wie die Zweigstelle Ihrer Bank aussieht. Es gibt einige Dinge, die Sie tun können, um solche Imitatoren zu fangen - Sie könnten sicherstellen, dass der Poststempel aus der richtigen Stadt stammt. Wenn Ihre Bank immer Massenpost anstelle einzelner Briefmarken verwendet, werden Sie dies möglicherweise bemerken usw. Aber Sie werden sich wahrscheinlich nie die Mühe machen, diese Dinge zu überprüfen, und selbst wenn Sie dies tun würden, würde dies nicht ausreichen, um zu überprüfen, ob der Brief von Ihrer Bank stammt.

Der Hauptunterschied zwischen Post und E-Mail besteht darin, dass bei E-Mails eine Fälschung praktischer ist - sie kann einmal entworfen und dann für nahezu null Kosten wiederholt werden.

Dies bedeutet, dass alle Fälschungen und Gegenmaßnahmen massiver sind und (es sei denn, Sie sind wie ich1) Einige gefälschte E-Mails werden in Ihrem Posteingang eingehen, und es liegt an Ihnen, sie manuell herauszufiltern.

Fazit: So wie Sie in einem Brief keine Telefonnummer anrufen würden, um "Ihre Kontoinformationen zu überprüfen" (wie Ihre SSN und Ihre Kreditkarte), sollten Sie auch nicht auf Links in E-Mails klicken und den Anmeldebildschirm oder eine andere Form erwarten Senden Sie die privaten Informationen sicher an Ihre Bank. Wenn Sie dies tun, senden Sie möglicherweise Ihre Anmeldeinformationen an einen Betrüger und bemerken dies nie.


1. Ich habe alle meine Spam-Mails entfernt. Ich habe meinen eigenen Domainnamen. Ich gebe jedem Kontakt eine eigene E-Mail-Adresse und alles landet in meinem Posteingang. Auf diese Weise kann ich Bob anweisen, sein E-Mail-Passwort zu ändern und eine neue E-Mail-Adresse für seine E-Mail an mich zu verwenden, wenn Bob einen Virus auf seinem Computer hat und ich anfange, etwas von diesem Spam auf niedriger Ebene zu bekommen. Die neue E-Mail-Adresse enthält keinen Spam und ich kann die alte löschen, da nur Bob sie verwendet hat.

Ich muss meiner Bank und meinen anderen Freunden, meinen Lieferanten und Mitarbeitern nicht mitteilen, dass sich meine E-Mail-Adresse geändert hat, da jede ihre eigene Adresse hat. (Ich muss StackExchange und den Gravater nicht einmal aktualisieren.) Das ist gut für mich (kein Spam), gut für Bob (er weiß, dass er einen "Virus oder so" hat - manchmal kann ich direkt sein, aber man muss aufpassen, dass ich mich danach nicht irre), gut für meine anderen Freunde (ich beschwere mich nie darüber, wie viele E-Mails ich in den letzten 24 Stunden erhalten habe, und erkläre warum Ich bin nicht auf sie zurückgekommen.

25
Bryan Field

Ich denke, Sie haben ein kleines Detail übersehen, das in der obigen Dramatisierung erwähnt wurde und das wirklich leicht zu überprüfen ist:

Gefälschte E-Mails stammen nicht von einer E-Mail-Adresse, die rechtmäßig zu der Domain gehört, von der sie angeblich stammen. Ein Teil des SMTP-Protokolls enthält eine Reihe von vollständigen Nachrichtenkopfzeilen, die immer den Rückweg der Nachricht enthalten, der ist die E-Mail-Adresse, an die tatsächlich die Nachricht gesendet hat. Darüber hinaus haben IP-Adressen eine bestimmte geografische Region, der sie zugewiesen sind. Sie können diese Diskrepanzen also mit ein wenig Graben erkennen.

Nehmen wir zum Beispiel die Dramatisierung.

Es wird erwähnt, dass die E-Mail von whitehouse.gov stammt. Hier ist seine IP-Adresse:

[email protected]:~ $ Dig +short whitehouse.gov
173.223.0.110

Angenommen, nastyhackerz.cn wird in eine IP-Adresse irgendwo im Block 1.0.32.0-1.0.63.255 aufgelöst (als Referenz: http://www.nirsoft.net/countryip/cn.html erster Block in der Liste). Diese IP-Adresse wird in den vollständigen Nachrichtenkopfzeilen enthalten sein. Alles, was Sie tun müssen, ist, diese IP online zu nehmen, um ihre Geolokalisierung zu ermitteln (Sie können beispielsweise http://www.geoiptool.com/ verwenden).

Die IP-Adresse für whitehouse.gov (173.223.0.110) zum Zeitpunkt des Schreibens dieses Beitrags befindet sich in Boston, Massachusetts (aus irgendeinem Grund kann ich meine Suche aufgrund von Reputationspunkten aufgrund eines Spam-Präventionssystems nicht auf geoiptool veröffentlichen, sodass Sie loslegen können mache die Suche selbst), die ziemlich nah an deiner Heimat liegt (District of Columbia)! Nehmen wir einfach an, dass whitehouse.gov in einem Rechenzentrum in Boston gehostet wird, um die Erklärung zu vereinfachen.

Solange die IP- und E-Mail-Adresse, von der die E-Mail tatsächlich gesendet wurde , nicht mit der IP und E-Mail-Adresse übereinstimmt, die die E-Mail behauptet, von dem gesendet werden soll, kann als Parodie bestimmt werden. Sie müssen nur in die full Nachrichtenkopfzeilen schauen.


Schauen wir uns die Header einer E-Mail an, die ich von einer meiner eigenen Domains (dragon-architect.com) an meine persönliche E-Mail-Adresse gesendet habe:

Delivered-To: [email protected]
Received: by 10.180.89.68 with SMTP id bm4csp105911wib;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35])
    by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45;
    Tue, 29 Jan 2013 08:54:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) client-ip=69.93.154.35;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) [email protected]
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007)
    id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST)
Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
    by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314
    for <[email protected]>; Tue, 29 Jan 2013 10:54:42 -0600 (CST)
Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com)
    by bentley.websitewelcome.com with esmtpa (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1U0ESK-0001KE-DP
    for [email protected]; Tue, 29 Jan 2013 10:54:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Jan 2013 10:54:44 -0600
From: [email protected]
To: <[email protected]>
Subject: Headers Test
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.8.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dragon-architect.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458
X-Source-Auth: [email protected]
X-Email-Count: 1
X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20=

Testing testing!

Das sind viele zufällige Daten, die gesiebt werden müssen, aber es gibt zwei Zeilen, die wir hier betrachten: Rückweg und von. Da ich diese E-Mail zu Recht an mich selbst gesendet habe, stimmen beide überein. Der Rückweg kann nicht gefälscht werden. Wenn dies möglich ist, ist es unglaublich schwierig, effektiv zu fälschen, und es ist eine gezielte Konfiguration des SMTP-Dämons erforderlich, der zum Senden von E-Mails verwendet wird. Der Vergleich des Rückweges und der From-Datenfelder in den vollständigen Headern ist eine Möglichkeit, mit der ich und meine Mitarbeiter, bei denen ich arbeite, Parodien identifizieren und feststellen können, ob ein Support-Ticket eingereicht werden muss.

Was ist, wenn beide übereinstimmen, die E-Mail jedoch immer noch gefälscht sein sollte? Ich werde im nächsten Abschnitt darauf zurückkommen ...


Wie bereits erwähnt, gibt es jetzt andere Möglichkeiten, die Spoofiness einer E-Mail zu bestimmen. SPF-Aufzeichnungen sind eine dieser Möglichkeiten, aber sie sind nicht immer perfekt. Nehmen Sie zum Beispiel den SPF von whitehouse.gov und vergleichen Sie ihn mit dem SPF meiner eigenen Domain:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Normalerweise enthält ein guter SPF-Datensatz auch die IP-Adresse des Servers, der die E-Mail gesendet hat. Wer also den SPF-Datensatz für whitehouse.gov erstellt hat, weiß dies wahrscheinlich nicht. Ich würde den SPF-Datensatz von whitehouse.gov als zu allgemein betrachten, um die tatsächliche Herkunft von Nachrichten zu bestimmen, die angeblich von whitehouse.gov stammen. Der SPF für meine eigene Domain hingegen, der automatisch von dem Server generiert wurde, der meine Domain hostet (mit freundlicher Genehmigung meines Webhosts), ist sehr spezifisch und enthält die IP-Adresse des Servers selbst.

Ich gebe zu, dass ich nicht genau weiß, wie SPF-Datensätze formatiert sind und wie sie funktionieren, aber ich habe bei meiner Arbeit genug gelernt, um zumindest generische und spezifische SPF-Datensätze identifizieren zu können. Ich denke, das ist etwas, in das ich mich wahrscheinlich an einem Wochenende vertiefen sollte, wenn mir langweilig ist und ich technisches Lesematerial möchte!

Wie auch immer, hier wieder auf Kurs. Schauen Sie sich die empfangenen Zeilen an. Einer von ihnen sagt also: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Ratet mal was? Das stimmt mit der IP-Adresse im SPF-Eintrag meiner Domain überein.

Wenn die IP im SPF nicht mit der IP des Servers übereinstimmt, der die E-Mail tatsächlich gesendet hat, ist dies ein weiterer Hinweis darauf, dass Sie Parodien in den Händen haben. Daher wird ein generischer SPF-Datensatz wie "v=spf1 +mx ~all" Den Sicherheitssenf einfach nicht abschneiden. Ich würde nicht einmal E-Mails vertrauen, die von einer legitim Domain stammen, die einen generischen SPF wie diesen hat.

Vielleicht sollten wir eine Petition auf petitions.whitehouse.gov einreichen, um zu fordern, dass ihre Sicherheitsadministratoren den SPF-Datensatz, den sie für die Domain erstellt haben, erneut besuchen! (Ich Kind, ich Kind.)

[~ # ~] edit [~ # ~]

Ich muss mich tatsächlich [~ # ~] massiv [~ # ~] über SPF-Datensätze korrigieren! Ich habe heute einige falsche Annahmen getroffen und ein paar Dinge gelernt, nachdem ich einen Kollegen gefragt hatte, der mehr über SPF-Aufzeichnungen wusste als ich. Also werde ich die beiden SPFs für whitehouse.gov und dragon-architect.com in meiner Selbstkorrektur verwenden:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Der SPF für meine eigene Domain ist tatsächlich milder als der SPF für whitehouse.gov (etwas, das ich heute Abend korrigieren möchte, nachdem ich diese Bearbeitung abgeschlossen habe). Ich werde erklären warum:

"v=spf1 +mx ~all" Sagt grundsätzlich, dass E-Mails von whitehouse.gov von den Hostnamen stammen sollen, die in den MX-Datensätzen für whitehouse.gov definiert sind, und alle E-Mails, die nicht von diesen Hostnamen stammen, sollen gefälscht sein, aber ob sie Wird als gefälscht markiert oder nicht, liegt beim Empfänger der E-Mail.

[email protected]:~ $ Dig +short mx whitehouse.gov
110 mail6.eop.gov.
105 mail2.eop.gov.
110 mail5.eop.gov.
105 mail1.eop.gov.
105 mail4.eop.gov.
105 mail3.eop.gov.

"v=spf1 +a +mx +ip4:70.84.243.130 ?all" Sagt, dass E-Mails von dragon-architect.com entweder von der IP-Adresse für dragon-architect.com (67.18.28.78) stammen sollen, den Hostnamen, die in den MX-Datensätzen für dragon -itect definiert sind .com oder die IP-Adresse des Servers, auf dem dragon-architect.com (70.84.243.130) gehostet wird. Alle E-Mails, die nicht von diesen stammen, bedeuten am Ende nur, dass es keinen Rat gibt, ob die E-Mails weitergeleitet oder abgelehnt werden sollen.

Was ist das Fleisch und die Kartoffeln eines SPF-Rekords? Das "Alles" ganz am Ende. Um diesen Mitarbeiter über das "Alles" zu zitieren:

+all basically means ALL pass -- the record is useless, sender domain doesn't care
?all indicates neutral and is advising to not pass or reject mail
~all indicates fail, and the server is considered invalid, but does not specifically suggest an action.
-all is a hard fail, anything else is invalid, reject or flag it.

In "all" legen Sie fest, wie streng Ihr SPF-Datensatz ist. Aber ob der SPF-Datensatz tatsächlich verwendet wird, um die Spoofiness einer E-Mail zu bestimmen, liegt vollständig beim Empfang E-Mail-Service.

Da haben Sie es also. SPF auf den Punkt gebracht.


Also ja. TL; DR: Überprüfen Sie Ihre vollständigen Header, um festzustellen, ob der Rückweg und die Felder von übereinstimmen. Überprüfen Sie dann Ihre SPF-Einträge, falls vorhanden, um festzustellen, ob Sie übereinstimmende IP-Adressen erhalten.

15
Calyo Delphi

SMTP (Simple Mail Transfer Protocol) heißt das aus einem sehr guten Grund.

SMTP entstand 1982 auf dem alten ARPANET, das dem US-amerikanischen Verteidigungsministerium gehörte und von diesem kontrolliert wurde und für die Kommunikation zwischen Personen mit Sicherheitsüberprüfungen gedacht war, die an Regierungsprojekten arbeiten, denen allgemein vertraut werden konnte, dass sie es nicht missbrauchen. Die "Sicherheit" dieses Netzwerks wurde ganz einfach erreicht, indem die Maschinen, die mit ihm verbunden werden konnten, in physisch gesicherten Bereichen der verschiedenen Einrichtungen platziert wurden, direkt neben den klassifizierten Arbeiten, die diese Einrichtungen ausführten. Infolgedessen wurde die tatsächliche Sicherung der über das Netzwerk gesendeten Daten im Allgemeinen erst nach der Außerbetriebnahme von ARPANET in Betracht gezogen. Der erste Quantensprung erfolgte etwa 1993 mit der Secure Network Programming API (die den Grundstein für die heute allgemein bekannte Secure Sockets Layer legte) als Transportschicht-Sicherheit). Während die meisten Protokolle (einschließlich SMTP/POP/IMAP) jetzt TLS für einen sicheren Kommunikationskanal hinzufügen können, bietet dies lediglich Vertraulichkeit und Serverauthentizität. Es bietet keine Absenderauthentizität oder Nachrichtenintegrität und keine Nicht-Zurückweisung.

Für die E-Mail-Sicherheit gibt es eine Option namens PGP (Pretty Good Privacy; es ist Phil Zimmermans humoristischer Humor für ein System, das bei ordnungsgemäßer Implementierung kein Computer auf dem Planeten beschädigen könnte). Es kann mit verschiedenen Optionen alle vier grundlegenden Grundsätze der Informationssicherheit bereitstellen. Vertraulichkeit, Integrität, Authentizität und Nicht-Zurückweisung (der Absender, der die E-Mail mit seinem Zertifikat signiert hat, kann nicht behaupten, dass er sie nicht tatsächlich gesendet hat; niemand anderes hätte dies tun können, es sei denn, das Zertifikat wurde kompromittiert). Es verwendet ein ähnliches System von Public-Key-Zertifikaten und sicherem Schlüsselaustausch wie bei einem Zwei-Wege-TLS-Handshake. Einige Details wurden jedoch geändert, um den asynchronen Charakter des E-Mail-Transports widerzuspiegeln und den Wunsch nach einem dezentralen " web of trust "schließt die Notwendigkeit global vertrauenswürdiger Zertifizierungsstellen aus.

Dieses System hat sich jedoch trotz seines Alters von über 25 Jahren noch nicht wirklich durchgesetzt und wird daher nur von Regierungsbehörden und bestimmten großen Unternehmen benötigt. Praktisch alle E-Mail-Anbieter senden weiterhin gerne betrügerische E-Mails über sichere Verbindungen in Ihren Posteingang. In vielen Fällen können Sie Ihre Freunde und andere Personen, von denen Sie eine E-Mail erhalten möchten, dazu ermutigen, das PGP-Schema zu übernehmen. Alles, was nicht gültig signiert ist, wird in die "Quarantäne" verschoben. Dies ist jedoch nur eine weitere Stufe der "Spam-Filterung" ", und ich kenne keinen einzigen öffentlichen E-Mail-Anbieter, den Sie anweisen können, E-Mails ohne digitale Signatur sofort abzulehnen. Der E-Mail-Server muss unter Ihrer Kontrolle sein, z. B. ein Exchange-Unternehmensserver.

12
KeithS

tl; dr

  • Nutzt Paypal hier ein Sicherheitsproblem aus? ... Wie kann Paypal E-Mails so einfach fälschen?

Technisch gesehen ist dies kein Sicherheitsproblem. E-Mails sind zunächst nicht sicher. Sie verwenden einen der folgenden SMTP-Header im Nachrichtenkopf (kein Umschlagkopf).

  1. Resent-From
  2. Resent-Sender
  3. Sender

Es gibt einen konzeptionellen Unterschied zwischen "Remailing" und "Spoofing". Der E-Mail-Client sollte diesen Unterschied anzeigen. Der Google Mail-Client tut dies nicht.

  • Paypal fälscht nicht, sie verwenden einen dieser SMTP-Header: Resent-From, Resent-Sender oder Sender

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

  • Der MUA (E-Mail-Client) sollte Display From, seinen SPF-, DKIM- und DMARC-Überprüfungsstatus anzeigen.

  • Der Resent- * -Header sollte so verwendet werden, dass deutlich wird, dass diese Nachricht "erneut gesendet" wird.

  • Im Allgemeinen ist die beste Lösung die Verwendung von DKIM + DMARC oder SPF + DMARC und einer MUA, die die Überprüfungsergebnisse anzeigt.


Hintergrund

Im Allgemeinen enthält jede SMTP-Nachricht zwei "Von" -Adressen und zwei "Bis" -Adressen. 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 die Anzeige von ä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 einfache Verschlüsselungstechnologie, 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).


Ist Spoofing Display von einem Sicherheitsproblem?

Ja, Phishing, obwohl E-Mail ein wichtiges Sicherheitsproblem ist, mit dem sich viele Anbieter befassen. Paypal, AOL, Google, Yahoo und andere Unternehmen implementieren DMARC, um genau dieses Phishing-Problem zu beheben.

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 Display From und Resent- * oder Sender nicht an.

Was macht Paypal?

Paypal verwendet den Header Sender, um anzuzeigen, dass es erneut gesendet wurde. Dies ist die korrekte und beabsichtigte Verwendung dieses Headers.

Was macht GMail falsch?

Google Mail macht nicht deutlich, dass der Absender-Header verwendet wird, überprüft die Anzeige von Adresse nicht auf benutzerfreundliche Weise und unterscheidet nicht zwischen Anzeige von und Absender.

5