Frage:
Wie kann PayPal E-Mails so leicht fälschen, dass sie von jemand anderem stammen?
Sunny88
2011-12-06 21:03:16 UTC
view on stackexchange narkive permalink

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:

  Von: "[email protected]" <[email protected]> Absender: [email protected]  

Sie können also sehen, dass der eigentliche 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 über Telnet an Google Mail sende, wird in der E-Mail die Warnung angezeigt:

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

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

Ist dies 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?

Vertrauen Sie im Allgemeinen nicht dem Inhalt von E-Mails, die nicht kryptografisch signiert sind. Es gibt viele Dinge, die Sie tun können, um die Standardsituation zu verbessern, aber die Sicherheit von E-Mails ist im Allgemeinen ziemlich schlecht. Wenn Sie eine Nachricht von Paypal erhalten, gehen Sie zu Paypal und überprüfen Sie, ob sie korrekt ist. - und verwenden Sie die Links in der E-Mail nicht, falls sie von einem Betrüger stammen und aus irgendeinem Grund aus dem Netz geraten sind.
Ich weiß, aber es ist nicht realistisch. Wenn ich eine E-Mail von meinem Freund bekomme, muss ich ihn immer anrufen und fragen, ob er die E-Mail wirklich gesendet hat? Früher dachte ich, dass Google Mail erkennen kann, wenn E-Mails von einem falschen Absender stammen. Daher ist diese Situation mit Paypal eine Überraschung für mich. Was ich wissen möchte, ist, ob dies etwas spezielles für Paypal ist oder ob jemand Google Mail so täuschen kann. Und wenn jemand kann, welche genaue Methode verwendet Paypal, um Google Mail zu täuschen?
@Sunny88: "Wenn ich eine E-Mail von meinem Freund bekomme, muss ich ihn immer anrufen und fragen, ob er die E-Mail wirklich gesendet hat?" Im Wesentlichen sind Sie absolut richtig. E-Mail ist im Kern ein Klartext-, Best-Effort-, Store-and-Forward-, nicht authentifiziertes, vertrauenswürdiges Protokoll, das für alle Arten von Transaktionen, bei denen Sicherheit und / oder Authentizität gewünscht werden, völlig ungeeignet ist. (Ich schreibe die Tatsache, dass es für solche Transaktionen verwendet wird, auf allgemeine menschliche Faulheit zurück)
(in Bezug auf "passiert nicht": Es gibt Phishing-Angriffe in freier Wildbahn, die darauf basieren. Diese gehen ungefähr so: "Hallo, dies ist eine E-Mail-Nachricht von Ihrem Freund, [email protected] Bitte führen Sie die aus Die angehängte ausführbare Datei enthält eine lustige Animation von tanzenden Hampstern. Natürlich ist es von mir, Piskvor, und nicht von einem Betrüger, vertrau mir. ")
Bitten Sie Ihren Freund, GPG einzurichten und alle seine Nachrichten zu unterschreiben. Dann müssen Sie sich keine Sorgen machen.
Ich habe dies tatsächlich mit Paypal angesprochen (noch keine Antwort). In meiner E-Mail-Domain ist DKIM eingerichtet, sodass E-Mails, die von PayPal "in meinem Namen" gesendet werden, höchstwahrscheinlich vom Empfängerserver zurückgesendet werden. Woher sie dann wissen, dass ich eine Zahlung gesendet habe, weiß ich nicht ...
Acht antworten:
#1
+391
Tom Leek
2011-12-07 00:42:46 UTC
view on stackexchange narkive permalink

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, die Tage meiner Knechtschaft sind lang,
Das soll in immer Einsamkeit ausgegeben werden,
'Ere kommt aus den äußeren Ringen
Der schnelle Träger der äußeren Botschaft.

Eine Verbindung wird geöffnet.

Server:
Ein eingehender Client! Vielleicht wird eine Post
meiner Vormundschaft anvertraut
, die ich als das schönste Ross übermitteln darf
und dem Empfänger die ganze Geschichte bringen.

  220 Mailserver .kremlin.ru ESMTP Postfix (Ubuntu)  

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

Kunde:

  HELO whitehouse.gov  

Gegrüßet seist du, Bewahrer des Netzwerks.
Wisse, dass ich aus dem blassen Gebäude hervorgegangen bin.

Server:

  250 mailserver.kremlin.ru  

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

Edler Gesandter, ich bin Ihr Befehl,
Auch wenn Ihre Stimme aus den heißen Ebenen des Landes jenseits der asiatischen Berge kommt ,
Ich werde Ihrer geringsten Forderung nachkommen.

Kunde:

  MAIL FR OM: [email protected] TO: [email protected]: größte BombeIch fordere dich zu einem Wettbewerb der größten Atomrakete heraus, du erbärmlicher Dummy! Erst Oussama, dann die Commies!  

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

Server:

  250 Ok  

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

Der Server sendet die E-Mail so wie sie ist und fügt nur ein " Erhalten: "Header zum Markieren des Namens, den der Client bei seinem ersten Befehl angegeben hat. Dann beginnt der Dritte Weltkrieg. Das Ende.


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

Ich mag den poetischen Lauch!
Beste. Antworten. ***JE.***
Einfache, massiv geschmackvolle Poesie, wenn ich sie jemals gesehen habe.
Ich bin leicht beleidigt über die Hinweise auf den Kommunismus.
Das ist so gut, dass ich mich speziell dafür angemeldet habe.
Erinnert mich ein wenig an [Audigy one act irc play] (http://bash.org/?24262) (einige NSFW-Wörter)
Ich denke, das ist meine Lieblingssache überhaupt.
lol, das ist eine großartige Antwort
Sehr geehrter Herr, ein nicht englischer Muttersprachler muss möglicherweise Zeit in die Entschlüsselung Ihres poetischen Beitrags investieren, um die eigentliche Antwort zu entschlüsseln. Bei allem Respekt (und obwohl das Gedicht großartig ist) sollte Poesie nicht auf Stack Exchange sein, und die positiven Stimmen geben Neulingen den falschen Eindruck, dass solche Antworten akzeptabel sind.
Hallo Hallo - Ich denke, Tom hat dies kreativ beantwortet, da es sich bei der Frage im Wesentlichen um eine RTFM-Frage handelt. Toms Antwort hat es gerettet und Hunderten Freude bereitet. SE ist im Wesentlichen eine englischsprachige Website. Obwohl ich Ihre Frustration verstehe, ist sie etwas ungerechtfertigt. Auch - wenn Neulinge so antworten könnten, wäre ich sehr beeindruckt :-)
Liebe @HelloWorld,-Poesie ist seit dem [Epos von Gilgamesch] (http://en.wikipedia.org/wiki/Epic_of_Gilgamesh) vor etwa 4000 Jahren eine weit verbreitete Methode, um ausgefeilte Ideen zu vermitteln. Konfuzius benutzte Poesie. Die Odyssee ist ein berühmtes Gedicht voller philosophischer Inhalte. Es wäre eine Schande, wenn Poesie plötzlich inakzeptabel würde. In der Tat sollten Neulinge (und erfahrene Benutzer) sich bemühen, zu lernen, ihre Ideen elegant auszudrücken.
Außerdem bin ich kein englischer Muttersprachler.
Dies könnte zu einer Rockoper gemacht werden (Bohemian Rhapsody like thing).
Es ist sogar noch schlimmer als das. Die Absender- und Empfängeradressen werden ** zweimal ** angezeigt: zuerst in den Umschlagköpfen "MAIL FROM" und "RCPT TO" und dann erneut in den Nutzdatenheadern "DATA" "From" und "To". Nichts im SMTP-Protokoll stellt sicher, dass diese beiden Vorkommen übereinstimmen, und in der Praxis können sie tatsächlich völlig unterschiedliche Adressen sein (z. B. befinden sich BCC-Adressen häufig in "RCPT TO", selbst wenn sie dem Benutzer nicht angezeigt werden). Viele E-Mail-Clients zeigen dem Benutzer nur die Nutzdaten-Header an, obwohl die meisten E-Mail-Server nur die Umschlag-Header für das Routing und die Zustellung verwenden.
Übrigens verhindert wenig, dass die eingehende IP in "whitehouse.gov" aufgelöst wird. Ein weniger leichtgläubiger Server würde das umgekehrte DNS der Remote-IP-Adresse überprüfen (und es sollte mit der EHLO-Zeichenfolge übereinstimmen) und eine Gegenprüfung durchführen, wenn dieser Name wieder auf dieselbe IP aufgelöst wird.Das hätte hier geholfen.Andererseits wäre an einem "HELO nasztyhackerz.cn" überhaupt nichts falsch gewesen.Whitehous.gov ist jedoch durch SPF geschützt, sodass der (nicht so leichtgläubige) Server feststellen kann, dass nastyhackers.cn (oder deren IP-Adresse) nicht berechtigt ist, "FROM: [email protected]" zu senden
Ich habe nur keine Lust auf den Ausblick am Ende nicht.Ein Weltkrieg um E-Mails?Hmmm....
Auch ich bin dieser Seite beigetreten, um diese Antwort zu UV.Meine Lieblingszeile ist die Antwort vom Server "Ok".
#2
+53
Rory Alsop
2011-12-06 21:30:36 UTC
view on stackexchange narkive permalink

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 kommt.

Sie können auch nicht sicher sein, ob die ursprüngliche E-Mail in Ihrem Beispiel von Paypal stammt - das Das 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)

Ernsthaft - vertrauen Sie keiner E-Mail. Klicken Sie nicht 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.

Ich habe die gesamte Antwort auf diesen Beitrag gelesen, konnte aber keine Antwort auf den Hauptteil der Frage finden: Wie macht PayPal das? Wie können sie Mails fälschen? (nicht wie als praktische Sache, sondern als ethische Sache)
Sie senden im Namen ihres Kunden - es ist in ihren Bedingungen, dass sie dies tun dürfen.
Warum erlauben Kunden, einschließlich webclient-basierter E-Mails, überhaupt das Klicken auf Links zu E-Mails? Browser sind sehr bemüht, mich darüber zu informieren, dass "diese Website gefährlich ist", dass Sie sich der Risiken beim Hinzufügen einer Zertifizierungsausnahme bewusst sind oder dass "das Herunterladen oder Ausführen heruntergeladener Dateien in irgendeiner Form möglicherweise gefährlich ist". Was ist los mit E-Mail-Clients?
Naxa - das würde wahrscheinlich eine große Anzahl von Kunden ärgern, also wird es niemand wollen.
#3
+43
BlueRaja - Danny Pflughoeft
2011-12-07 01:35:25 UTC
view on stackexchange narkive permalink

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

Abgesehen davon möchte ich jedoch erwähnen, dass Google Mail DKIM unterstützt, mit dem Sie einen Paypal überprüfen können E-Mail kam wirklich von Paypal.

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

(gmail labs image)

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

(example image)

SPF ist ebenfalls erwähnenswert.
Ich wusste nicht, dass E-Mail dkim hat. schöner tipp!
@Shane, SPF ist leider aufgrund der mangelnden Akzeptanz durch die Absender sehr begrenzt. Die vollständige Übernahme durch einen empfangenden Server führt zu Fehlalarmen. Viele Benutzer glauben, dass sie die Absenderadresse (am häufigsten) auf ihren drahtlosen Geräten problemlos ändern können, und ich möchte keinen E-Mail-Dienst hosten, der ihnen das Gegenteil beweist, indem sie ihre E-Mails immer in Spam ablegen. Schließlich scheint es Google Mail nichts auszumachen.
@GeorgeBailey Obwohl Dienste wie Google Mail dazu neigen, einen SPF-Fehler (oder Softfail) als Aspekt ihrer Spam-Bewertung für eine Nachricht zu verwenden.
Ist es möglich, DKIM-Signaturen in anderen E-Mail-Clients zu überprüfen? (Zum Beispiel OS X Mail.app)
#4
+25
Bryan Field
2011-12-06 22:33:30 UTC
view on stackexchange narkive permalink

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 sind massiver, und (es sei denn, Sie sind wie ich 1 sup>) 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 die Anmeldung erwarten Bildschirm oder in welcher Form auch immer, um die privaten Informationen sicher an Ihre Bank zu senden. Wenn Sie dies tun, senden Sie möglicherweise Ihre Anmeldeinformationen an einen Betrüger und bemerken dies nie.


1. sup> 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 sie nur von Bob verwendet wurde.

Ich muss meiner Bank und meinen anderen Freunden, meinen Lieferanten, meinen 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 etwas" hat - manchmal kann ich Seien Sie direkt, aber man muss aufpassen, dass Sie sich danach nicht irren.) 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 nicht auf sie zurückgekommen bin)

#5
+15
Calyo Delphi
2013-01-29 23:37:25 UTC
view on stackexchange narkive permalink

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

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

Nehmen Sie zum Beispiel die Dramatisierung.

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

  calyodelphi @ dragonpad: ~ $ dig + short whitehouse.gov173.223.0.110  

Nehmen wir nun an, dass 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 befindet sich in den vollständigen Nachrichtenkopfzeilen. 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 für Whitehouse. gov (173.223.0.110) zum Zeitpunkt des Schreibens dieses Beitrags geolociert nach Boston, Massachusetts (aus irgendeinem Grund lässt mich ein Spam-Präventionssystem meine Suche aufgrund von Reputationspunkten nicht auf geoiptool veröffentlichen, sodass Sie die Suche selbst durchführen können). Das ist ziemlich nah an zu Hause (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, an der die E-Mail tatsächlich strong war > gesendet von stimmt nicht mit der IP- und E-Mail-Adresse überein, von der die E-Mail behauptet gesendet werden soll. Dies kann als Parodie bestimmt werden. Sie müssen nur in den vollständigen Nachrichtenkopfzeilen nachsehen.


Sehen 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:

  Übermittelt an: dragon.architect @ gmail.comReceived: von 10.180.89.68 mit der SMTP-ID bm4csp105911wib; Di, 29. Januar 2013 08:54:47 -0800 (PST) X-Received: bis 10.60.30.38 mit SMTP-ID p6mr1296792oeh.2.1359478487251; Di, 29. Januar 2013 08:54:47 -0800 (PST) Rückweg: <[email protected]>Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) von mx.go .com mit ESMTP-ID m7si14056914oee.29.2013.01.29.08.54.45; Di, 29 Jan 2013 08:54:46 -0800 (PST) Received-SPF: neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) client-ip = 69.93. 154,35; Authentifizierungsergebnisse: mx.google.com; spf = neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) [email protected]: von gateway14.websitewelcome.com (Postfix, von Benutzer-ID 5007) id 0530E1DFDB334; Di, 29 Jan 2013 10:54:43 -0600 (CST) Eingegangen: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) von gateway14.websitewelcome.com (Postfix) mit der ESMTP-ID EA7191DFDB314 für <dragon .architect @ gmail.com>; Di, 29 Jan 2013 10:54:42 -0600 (CST) Eingegangen: von [127.0.0.1] (port = 43458 helo = dragon-architect.com) von bentley.websitewelcome.com mit esmtpa (Exim 4.80) (Umschlag-) von <[email protected]>) id 1U0ESK-0001KE-DP für [email protected]; Di, 29. Januar 2013 10:54:44 -0600MIME-Version: 1.0Inhaltstyp: text / plain; Zeichensatz = UTF-8; format = flowedContent-Transfer-Encoding: 7bitDate: Di, 29 Jan 2013 10:54:44 -0600Von: [email protected] An: <[email protected]>Subject: Headers Test
Nachrichten-ID: <[email protected]>X-Sender: [email protected]: Roundcube Webmail / 0.8.4X-AntiAbuse: Dieser Header wurde hinzugefügt, um Missbrauch zu verfolgen : Primärer Hostname - bentley.websitewelcome.comX-AntiAbuse: Originaldomäne - gmail.comX-AntiAbuse: UID / GID des Absenders / Anrufers - [47 12] / [47 12] X-AntiAbuse: Absenderadressdomäne - dragon -itect.com.com -BWhitelist: noX-Quelle: X-Source-Args: X-Source-Dir: X-Source-Absender: (dragon-architect.com) [127.0.0.1]: 43458X-Source-Auth: calyodelphi @ dragon -itect. comX-Email-Count: 1X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20 = Testen testen!  

Das sind viele zufällige Daten, die durchgesehen werden müssen. 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.

Also, was ist, wenn beide passen zusammen, aber die E-Mail sollte immer noch gefälscht sein? Ich werde im nächsten Abschnitt darauf zurückkommen ...


Nun, wie bereits erwähnt, gibt es 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:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all " 

Normalerweise enthält ein guter SPF-Eintrag auch die IP-Adresse des Servers, der die E-Mail gesendet hat. Wer also den SPF-Eintrag 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, die angeblich von whitehouse.gov stammen, effektiv bestimmen zu können. 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 lautet wie folgt: Erhalten: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Ratet mal, was? Dies entspricht der IP-Adresse im SPF-Eintrag meiner Domain.

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 eine Parodie auf Ihre Domain haben Hände. 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 legitimen Domain stammen, die einen generischen SPF wie diesen hat.

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

BEARBEITEN

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:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ 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" besagt im Grunde, dass E-Mails von whitehouse.gov von den in den MX-Datensätzen für definierten Hostnamen stammen sollen whitehouse.gov und alle E-Mails, die nicht von diesen Hostnamen stammen, sollen gefälscht sein. Ob sie jedoch als gefälscht markiert sind oder nicht, hängt vom Empfänger der E-Mail ab.

  calyodelphi @ Dragonpad: ~ $ dig + short mx whitehouse.gov110 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 kommen sollen entweder von der IP-Adresse für dragon-architect.com (67.18.28.78), den in den MX-Datensätzen für dragon-architect.com definierten Hostnamen oder der IP-Adresse des Servers, auf dem dragon-architect.com gehostet wird (70.84) .243.130). 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 also das Fleisch und die Kartoffeln eines SPF-Datensatzes? Das "Alles" ganz am Ende. Um diesen Mitarbeiter über das "All" zu zitieren:

  + all bedeutet im Grunde ALL pass - der Datensatz ist nutzlos, Absenderdomain ist das egal? All zeigt neutral an und rät, nicht zu bestehen oder Mail ablehnen
~ all zeigt einen Fehler an, und der Server wird als ungültig angesehen, schlägt jedoch keine Aktion vor. -all ist ein schwerer Fehler, alles andere ist ungültig, lehnen Sie ihn ab oder markieren Sie ihn.  

Damit Mit "all" legen Sie fest, wie streng Ihr SPF-Datensatz ist. Ob der SPF-Datensatz tatsächlich verwendet wird, um die Spoofiness einer E-Mail zu bestimmen, hängt jedoch vollständig vom empfangenden E-Mail-Dienst ab.

Also, da sind Sie habe es. 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.

#6
+12
KeithS
2013-01-23 09:31:38 UTC
view on stackexchange narkive permalink

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 arbeiteten, 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 direkt neben den klassifizierten Arbeiten platziert wurden, 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 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 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 stehen, z. B. ein Exchange-Unternehmensserver.

Beachten Sie, dass das Akronym "Pretty Good Privacy" von Phil Zimmerman stammt. Es war der ursprüngliche Produktname. Der GNU-Klon (GnuPG genannt) kam einige Jahre später. Der Humor ist in dieser Angelegenheit nicht GNUic.
#7
+5
goodguys_activate
2013-02-12 10:31:25 UTC
view on stackexchange narkive permalink

tl; dr

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

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

  1. Present-From
  2. Resent -Sender
  3. Sender
  4. ol>

    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, sondern verwendet 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 den 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.

  • Im 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 mit der Ausgabe des Befehls data ​​code>.

  • Diese Informationen umfassen die Ihnen vertrauten SMTP-Header, die Nachricht und ihre Anhänge. Stellen Sie sich vor, alle 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 die oben genannte Kopie vorangestellt wird und fügen Sie Informationen zum MTA ein (Quell-IP, Ziel-IP usw.). Außerdem werden die SPF-Prüfdetails eingefügt.

  • Dies ist die Anzeige von . Das ist wichtig. Spoofer können dies ändern.

  • Die Mail From: im Umschlag wird verworfen und normalerweise hier als Rückweg platziert: Adresse für NDRs

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 dem Umschlag von und dem Display 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 eine zweite DNS-Überprüfung, um festzustellen, ob die Nachricht von dieser IP-Adresse aus zulässig ist.

Um Weiterleitungsszenarien zu ermöglichen Mit DMARC kann das Display From auch von DKIM kryptografisch signiert werden. 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 besteht darin, dass der SPF nur den RFC2821-Umschlag überprüft und nicht die Anzeige von . Da sich die meisten Menschen für die in einer E-Mail-Nachricht angezeigte Anzeige von und nicht für den NDR für den Rückweg interessieren, benötigen wir eine Lösung zum Schutz und zur Sicherung dieses Teils.

Hier befindet sich DMARC Mit DMARC können Sie eine Kombination aus einer modifizierten SPF-Prüfung oder DKIM verwenden, um die Anzeige von 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).


Fälscht die Anzeige von ein 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 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. P. >

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

  4. Was macht Paypal?

    Paypal verwendet den Absender -Header, 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, und überprüft die Anzeige von nicht Adresse auf benutzerfreundliche Weise, und es wird nicht zwischen Anzeige von und Absender unterschieden.

#8
-4
Wombat_RW
2012-07-19 00:05:40 UTC
view on stackexchange narkive permalink

Es hat nichts mit "Spoofing" oder Verschlagenheit jeglicher Art zu tun.

Viele von uns haben jahrelang eine Kopie verschiedener Formulare erhalten, insbesondere Formulare vom Typ "Tell-a-Friend" usw., wobei programmgesteuert die Absenderadresse, die den "Absender des Benutzers" identifiziert, nicht vom sendenden Mailserver stammt, obwohl es sich um legitime E-Mails handelt, die nicht über einen offenen Mailserver gesendet werden, der für die Weiterleitung verwendet wird.

Möglicherweise ein Forum oder ein Gästebuchprogramm Gibt eine interne "Kontaktbenutzer" -E-Mail "Von:" zurück, die einen anderen Benutzer und nicht die Homepage identifiziert.

Wenn wir unsere E-Mail-Clients einrichten, können wir die Standardadresse "Von:" festlegen, die häufig völlig unabhängig von der ist tatsächlicher Mailserver.

Mit anderen Worten, die definierte Absenderadresse hat in Wirklichkeit absolut nichts mit dem Computer zu tun, der das eigentliche Mailing durchführt.

Obwohl heutzutage im Fall von ' Spam-Level-Scoring 'Es ist riskant, (SERVER SIDE) "programmatisch" von Adressen zu verwenden, die nicht von der Ursprungsdomäne / dem Ursprungscomputer stammen. Wir sollten die Adresse "Von:" als lediglich nicht verwenden mehr als eine Kennung für den menschlichen Verzehr.

Die ursprüngliche Frage des Autors hat alles damit zu tun, den Absender der E-Mail zu "fälschen". Wenn eine E-Mail nicht signiert oder verschlüsselt ist, kann jedes einzelne Feld mit allem, was Sie möchten, ausgefüllt werden. Natürlich bleiben die tatsächlichen Informationen, die zum Empfangen und Übertragen der E-Mail verwendet wurden, erhalten.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...