it-swarm.it

In che modo Paypal può falsificare le e-mail così facilmente per dire che proviene da qualcun altro?

Quando ricevo un pagamento in Paypal, mi invia una e-mail al riguardo (nella foto sotto). Il problema è che l'email viene mostrata dall'indirizzo di posta elettronica del mittente del denaro e non da Paypal stesso, anche se il vero mittente è Paypal.

Email from Paypal

Ecco il testo che appare quando seleziono "mostra originale" in Gmail:

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

Quindi puoi vedere che il vero mittente è Paypal.

Se Paypal è in grado di falsificare il mittente della posta elettronica così facilmente e Gmail non lo riconosce, significa che chiunque può falsificare l'indirizzo del mittente della posta elettronica e Gmail non lo riconoscerà?

Quando invio e-mail a Gmail da solo utilizzando telnet, l'e-mail arriva con l'avvertimento:

Questo messaggio potrebbe non essere stato inviato da: [email protected]

È un problema di sicurezza? Perché se sono abituato al fatto che le e-mail di pagamento in Paypal sembrano provenire dall'e-mail del mittente del denaro e non da Paypal, il mittente può semplicemente falsificare il pagamento inviando un messaggio come quello dalla sua e-mail, e potrei pensare che questo è il vero pagamento.

È qualcosa di specifico per Paypal o qualcuno può ingannare Gmail in quel modo? E se qualcuno può, qual è il metodo esatto che Paypal sta usando per ingannare Gmail?

147
Sunny88

Ecco una drammatizzazione di come va la comunicazione, quando una posta viene ricevuta ovunque.


Contesto: un server di posta elettronica, solo in una baia, da qualche parte a Mosca. Il server rimane lì pigramente, con un'espressione di aspettativa.

Server:
Ah, sono lunghi i giorni della mia servitù,
Che sarà trascorso in solitudine,
'L'ere proviene dagli anelli esterni
Il Swift portatore di notizie esterne.

Viene aperta una connessione.

Server:
Un client in arrivo! Forse una mail
Alla mia tutela sarà affidato
Che io possa trasmettere come il miglior destriero
E al destinatario porta la storia completa.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Benvenuto nel mio regno, Net Wanderer,
Scopri che sono un potente server di posta.
Come verrai indirizzato in questo giorno
Sorge la necessità che il tuo nome sia indovinato?

Cliente:

HELO whitehouse.gov

Salve a te, custode della rete,
Sappi che sono generato dal pallido edificio.

Server:

250 mailserver.kremlin.ru

L'indirizzo IP in arrivo si risolve tramite il DNS in "nastyhackerz.cn".

Nobile inviato, sono tuo a comandare,
Anche se la tua voce viene dalle calde pianure
Della terra oltre le montagne asiatiche,
Rispetterò la tua richiesta più debole.

Cliente:

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

Ecco il mio messaggio, per te da inviare,
E trasmetti fedelmente sull'etere;
Fai attenzione agli indirizzi e al nome del mittente
Che deve essere visualizzato all'altra estremità.

Server:

250 Ok

Così è stato scritto, quindi deve essere fatto.
Il messaggio viene inviato e alla Russia scompare.

Il server invia l'e-mail così com'è, aggiungendo solo un'intestazione "Ricevuto:" per contrassegnare il nome che il client ha dato nel suo primo comando. Quindi inizia la terza guerra mondiale. The End.


Commento: non c'è alcuna sicurezza nell'e-mail. Tutti i nomi di mittente e destinatario sono indicativi e non esiste un modo affidabile per rilevare lo spoofing (altrimenti ci sarebbero molti meno spam).

390
Tom Leek

Qualsiasi indirizzo di posta elettronica "da" può essere falsificato, in quanto è possibile modificare qualsiasi dato in uscita che ti piace. Non devi ingannare Gmail. Nel dire ciò, gmail può individuare ovvi problemi quando un'e-mail contrassegnata come inviata da un'organizzazione arriva da un altro dominio.

Inoltre, non puoi essere sicuro che l'e-mail originale provenga da Paypal nel tuo esempio: anche quel bit del mittente può essere falsificato!

Se si desidera una sorta di autenticazione per evitare che ciò accada, è necessario un modo per firmare o crittografare le e-mail o un controllo fuori banda per confermare che l'e-mail provenga dal proprio amico (come indicato nel commento)

Seriamente, non fidarti di nessuna email. Non fare clic su qualsiasi collegamento in un'e-mail. Soprattutto da obiettivi di alto valore come Paypal. Dovresti invece accedere come faresti normalmente e controllare se ti hanno inviato qualcosa.

52
Rory Alsop

Come altri hanno già detto, chiunque può falsificare qualsiasi indirizzo email , incluso quello Campo "Mittente": non vi è alcun motivo tecnico per cui Paypal debba includere la propria e-mail nel campo del mittente, lo fanno solo perché sono un'azienda onesta. Non aspettarti che gli spammer siano così gentili.

A parte ciò, tuttavia, vorrei menzionare che gmail ha il supporto per DKIM , che ti permette di verificare che un'email di Paypal provenga davvero da Paypal.

Per abilitarlo: fai clic sull'ingranaggio in alto a destra -> impostazioni di posta -> laboratori -> Abilita "Icona di autenticazione per mittenti verificati"

(gmail labs image)

Ora le email di Paypal firmate appariranno con una piccola icona a forma di chiave accanto a loro:

(example image)

È molto simile alla posta ordinaria. Chiunque può inviarti una lettera con carta intestata che assomiglia alla filiale locale della tua banca. Ci sono alcune cose che puoi fare per catturare imitatori come questi: puoi assicurarti che il timbro postale provenga dalla città giusta. Se la tua banca utilizza sempre posta all'ingrosso anziché singoli francobolli, potresti notarlo, ecc. Ma probabilmente non ti preoccuperai mai di controllare queste cose, e anche se lo facessi, ciò non sarebbe sufficiente per verificare che la lettera provenga dalla tua banca.

La differenza principale tra posta ordinaria ed e-mail è che con la posta elettronica una contraffazione è più pratica: può essere progettata una volta e quindi ripetuta a un costo quasi zero.

Ciò significa che tutti i falsi e le contromisure sono su una scala più massiccia e (a meno che tu non sia come me1) alcuni messaggi falsi arriveranno nella tua casella di posta e spetta a te filtrarli manualmente.

In conclusione, proprio come non si chiamerebbe un numero di telefono su una lettera per "verificare le informazioni del proprio account" (come il proprio SSN e carta di credito), non si dovrebbe anche fare clic sui collegamenti nelle e-mail e aspettarsi che la schermata di accesso o qualunque modulo invia in sicurezza le informazioni private alla tua banca. Se lo fai, potresti ritrovarti a inviare le tue credenziali a un impostore e non accorgertene mai.


1. Ho eliminato tutto il mio spam. Ho il mio nome di dominio. Fornisco a ogni contatto il proprio indirizzo e-mail e tutto arriva nella mia unica casella di posta. In questo modo, se Bob riceve un virus sul suo computer e comincio a ricevere parte di quello spam di basso livello, allora posso dire a Bob di cambiare la sua password e-mail e di iniziare a utilizzare un nuovo indirizzo e-mail per la mia e-mail. Il nuovo indirizzo e-mail non riceverà alcun spam e posso eliminare quello vecchio, perché solo Bob lo stava usando.

Non devo andare a dire alla mia banca e agli altri miei amici, venditori, collaboratori che il mio indirizzo e-mail è cambiato, perché ognuno ha il proprio indirizzo. (Non devo nemmeno aggiornare StackExchange e Gravater.) Questo è un bene per me (niente spam), un bene per Bob (sa di avere un "virus o qualcosa" - a volte posso essere diretto, ma bisogna stare attenti a non sbagliarsi in seguito), buono per gli altri miei amici (non mi lamento mai di quante e-mail ho ricevuto nelle ultime 24 ore e spiega perché non sono tornato da loro)

25
Bryan Field

Penso che abbiate trascurato un piccolo dettaglio che è stato menzionato nella drammatizzazione sopra, che in realtà è davvero facile da controllare:

Le e-mail contraffatte non provengono da un indirizzo e-mail che appartiene legittimamente al dominio dal quale dichiarano di avere origine. Parte del protocollo SMTP include una serie di intestazioni di messaggio complete che include sempre il percorso di ritorno del messaggio, che è l'indirizzo email che attualmente ha inviato il messaggio. Non solo, ma gli indirizzi IP hanno anche una regione geografica definitiva a cui sono assegnati. Quindi puoi cogliere queste discrepanze con un po 'di scavo.

Prendiamo, ad esempio, la drammatizzazione.

Indica che l'e-mail proviene da whitehouse.gov. Ecco il suo indirizzo IP:

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

Ora, supponiamo che nastyhackerz.cn si risolva in un indirizzo IP da qualche parte nel blocco 1.0.32.0-1.0.63.255 (per riferimento: http://www.nirsoft.net/countryip/cn.html primo blocco nell'elenco). Quell'indirizzo IP sarà nelle intestazioni complete del messaggio. Tutto quello che devi fare è portare quell'IP online per rintracciarne la geolocalizzazione (puoi usare http://www.geoiptool.com/ per esempio)

L'IP per whitehouse.gov (173.223.0.110) al momento della scrittura di questo post geolocalizzazione a Boston, Massachusetts (per qualche motivo un sistema di prevenzione dello spam non mi consente di pubblicare la mia ricerca su geoiptool a causa di punti reputazione, quindi puoi andare fai la ricerca tu stesso) che è abbastanza vicino a casa (distretto di Columbia)! Supponiamo che whitehouse.gov sia ospitato in un data center a Boston solo per semplificare la spiegazione.

Fintanto che l'indirizzo IP e l'indirizzo e-mail da cui l'email è stata effettivamente non corrisponde all'indirizzo IP e all'indirizzo e-mail che l'e-mail rivendica da inviare, può essere determinato come parodia. Devi solo cercare nelle intestazioni dei messaggi pieno.


Diamo un'occhiata alle intestazioni di un'e-mail che ho inviato da uno dei miei domini (dragon-architect.com) al mio indirizzo e-mail personale:

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]hitect.com) 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!

Ci sono molti dati casuali da esaminare, ma ci sono due righe che stiamo osservando qui: return-path e from. Dal momento che ho legittimamente inviato questa email a me stesso, entrambi corrispondono. Il percorso di ritorno non può essere falsificato. Oppure, se è possibile, è incredibilmente difficile falsificare efficacemente e richiede una configurazione deliberata del demone SMTP utilizzato per inviare la posta. Il confronto tra il percorso di ritorno e i campi dati from nelle intestazioni complete è un modo in cui io e i miei colleghi in cui lavoro sono in grado di identificare lo spoof e determinare se è necessario inviare un ticket di supporto.

Quindi, cosa succede se entrambi corrispondono, ma l'e-mail dovrebbe essere ancora parodia? Ci arriverò nella prossima sezione ...


Ora, come accennato in precedenza, ci sono altri modi per determinare la parodia di un'e-mail. I record SPF sono uno di quei modi, ma non sono sempre perfetti. Prendi, ad esempio, l'SPF di whitehouse.gov e confrontalo con l'SPF del mio dominio:

[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"

Di solito, un buon record SPF include anche l'indirizzo IP del server che ha inviato la posta, quindi chiunque abbia creato il record SPF per whitehouse.gov probabilmente non lo sa. Considererei il record SPF di whitehouse.gov troppo generico per essere efficace nel determinare l'origine effettiva di tutti i messaggi che affermano di provenire da whitehouse.gov. L'SPF per il mio dominio, invece, che è stato generato automaticamente dal server che ospita il mio dominio (per gentile concessione del mio webhost), è molto specifico e include l'indirizzo IP del server stesso.

Devo ammettere di non avere familiarità con il modo in cui i record SPF sono formattati e come funzionano, ma ho imparato abbastanza sul mio lavoro da poter almeno identificare i record SPF generici e specifici. Immagino sia qualcosa che probabilmente dovrei scavare in qualche fine settimana quando sono annoiato e voglio del materiale di lettura tecnico!

Comunque, torniamo in pista qui. Guarda le linee ricevute. Uno di questi afferma quindi: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Indovina un po '? Che corrisponde all'indirizzo IP nel record SPF del mio dominio.

Se l'IP nell'SPF non corrisponde all'IP del server che ha effettivamente inviato l'e-mail, questa è un'altra indicazione che hai uno spoof nelle tue mani. Pertanto, un record SPF generico come "v=spf1 +mx ~all" Non taglierà la senape di sicurezza. Non mi fiderei nemmeno delle e-mail provenienti da un dominio legittimo che ha un SPF generico come questo.

Forse dovremmo presentare una petizione su petitions.whitehouse.gov per chiedere ai loro amministratori di sicurezza di rivisitare il record SPF che hanno creato per il dominio! (Io ragazzo, io ragazzo.)

[~ ~ #] modifica [~ ~ #]

In realtà devo [~ # ~] in modo massiccio [~ # ~] correggermi sui record SPF! Ho fatto alcune ipotesi sbagliate e ho imparato alcune cose oggi dopo aver chiesto a un collega che era più a conoscenza di me dei dischi SPF. Quindi, userò i due SPF per whitehouse.gov e dragon-architect.com nella mia auto-correzione:

[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"

L'SPF per il mio dominio è in realtà più indulgente dell'SPF per whitehouse.gov (qualcosa che ho intenzione di correggere stasera dopo aver finito questa modifica). Spiegherò perché:

"v=spf1 +mx ~all" Dice sostanzialmente che le e-mail di whitehouse.gov dovrebbero provenire dai nomi host definiti nei record MX per whitehouse.gov e che qualsiasi e-mail che non proviene da tali nomi host dovrebbe essere falsa, ma se il contrassegno di spoofing o meno dipende dal destinatario dell'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" Dice che le e-mail di dragon-architect.com dovrebbero provenire dall'indirizzo IP di dragon-architect.com (67.18.28.78), i nomi host definiti nei record MX per dragon-architetto .com o l'indirizzo IP del server che ospita dragon-architect.com (70.84.243.130). Eventuali e-mail che non provengono da quelle, beh, tutto ciò alla fine significa solo che non ci sono consigli su se passare o rifiutare le e-mail.

Allora, qual è la carne e le patate di un disco SPF? Il "tutto" alla fine. Per citare questo collaboratore sul "tutto":

+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 modo che "tutto" sia il punto in cui definisci quanto è rigoroso il tuo record SPF. Ma se il record SPF sia effettivamente usato per determinare la parodia di un messaggio di posta elettronica è completamente fino alla ricezione servizio di posta elettronica.

Così il gioco è fatto. SPF in breve.


Quindi si TL; DR: controlla le intestazioni complete per vedere se il percorso di ritorno e dai campi corrispondono. Quindi ricontrolla i tuoi record SPF se ce ne sono per vedere se ottieni indirizzi IP corrispondenti.

15
Calyo Delphi

SMTP (Semplice Mail Transfer Protocol) è stato chiamato così per un'ottima ragione.

SMTP è nato nel 1982 sul vecchio ARPANET, che era di proprietà e controllato dal Dipartimento della Difesa degli Stati Uniti, e destinato alla comunicazione tra persone con autorizzazioni di sicurezza che lavorano su progetti governativi di cui ci si può fidare in generale di non abusarne. La "sicurezza" di questa rete è stata ottenuta semplicemente posizionando le macchine che potevano connettersi ad essa in aree fisicamente protette delle varie strutture, proprio accanto al lavoro riservato che queste strutture stavano svolgendo. Di conseguenza, la protezione effettiva dei dati inviati lungo la rete non è stata generalmente presa in considerazione fino a dopo la disattivazione di ARPANET, con il primo salto di qualità intorno al 1993 con l'API Secure Network Programming (che ha gettato le basi per Secure Sockets Layer, ora generalmente noto come Transport Layer Security). Mentre la maggior parte dei protocolli (inclusi SMTP/POP/IMAP) possono ora aggiungere TLS per un canale di comunicazione sicuro, tutto ciò fornisce riservatezza e autenticità del server; non fornisce l'autenticità del mittente o l'integrità del messaggio e non fornisce inoltre non ripudio.

C'è un'opzione disponibile per la sicurezza della posta elettronica, chiamata PGP (Pretty Good Privacy; è l'umorismo ironico di Phil Zimmerman per un sistema che nessun computer del pianeta potrebbe rompere se implementato correttamente). Può, con varie opzioni, fornire tutti e quattro i principi fondamentali della sicurezza delle informazioni; riservatezza, integrità, autenticità e non ripudio (il mittente, che ha firmato l'e-mail utilizzando il proprio certificato, non può affermare di non averlo effettivamente inviato; nessun altro avrebbe potuto, a meno che il certificato non fosse stato compromesso). Utilizza un sistema simile di certificati a chiave pubblica e scambio di chiavi sicuro come si vede in una stretta di mano TLS a due vie, ma alcuni dettagli vengono modificati per riflettere la natura asincrona del trasporto di posta elettronica e per riflettere il desiderio di un sistema decentralizzato " web of trust "che preclude la necessità di autorità di certificazione affidabili a livello globale.

Tuttavia, questo sistema deve ancora veramente decollare nonostante abbia più di 25 anni e come tale è richiesto solo dalle agenzie governative e da alcune grandi società. Praticamente tutti i fornitori di posta elettronica continueranno comunque a spedire felicemente e-mail fraudolente tramite connessioni sicure alla tua casella di posta. In molti casi puoi incoraggiare i tuoi amici e altre persone da cui desideri ricevere e-mail per adottare lo schema PGP e tutto ciò che non è validamente firmato va in "quarantena", ma questo è davvero solo un altro livello di "filtro antispam" "e non conosco un singolo provider di posta elettronica pubblico che puoi incaricare di rifiutare le e-mail senza una firma digitale; il server di posta elettronica dovrebbe essere sotto il tuo controllo, come un server Exchange aziendale.

12
KeithS

tl; dr

  • Paypal sta sfruttando un problema di sicurezza qui? ... In che modo Paypal può falsificare le e-mail così facilmente?

Tecnicamente, non è un problema di sicurezza, l'e-mail non è sicura per cominciare. Stanno usando una delle seguenti intestazioni SMTP che si trovano nell'intestazione del messaggio (non nell'intestazione della busta)

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

C'è una differenza concettuale tra "remailing" e "spoofing". Il client di posta elettronica dovrebbe visualizza questa differenza. Il client Gmail non lo fa.

  • Paypal non sta falsificando, sta utilizzando una di queste intestazioni SMTP: Resent-From, Resent-Sender o Sender

  • È molto facile falsificare un dominio ... anche con i controlli SPF abilitati

  • Il MUA (client di posta elettronica) dovrebbe visualizzare Visualizza da, lo stato di verifica SPF, DKIM e DMARC.

  • L'intestazione Resent- * deve essere utilizzata in modo da chiarire che questo messaggio è "remailato".

  • In generale, la soluzione migliore è utilizzare DKIM + DMARC o SPF + DMARC e un MUA che visualizzi i risultati della verifica.


Alcuni retroscena

In generale, ci sono due "da" indirizzi e due "a" indirizzi in ogni messaggio SMTP. Uno è noto come busta RFC2821, l'altro è il messaggio RFC2822. Servono a scopi diversi

La busta: (RFC2821)

  • La busta sono metadati che non compaiono nell'intestazione SMTP. Scompare quando il messaggio passa al MTA successivo.

  • Il RCPT From: è dove andranno i rapporti di mancato recapito. Se un messaggio proviene da Postmaster o da un servizio di remailer, di solito è <> o [email protected]. È interessante vedere che salesforce usa questo simile a constantContact come chiave in un database come [email protected] per vedere se il messaggio è stato rimbalzato.

  • Il RCPT TO: è a chi viene effettivamente inviato il messaggio. È usato per gli utenti "to" e "bcc". Questo di solito non influisce sulla "visualizzazione degli indirizzi" nel client di posta, ma ci sono occasioni in cui gli MTA visualizzeranno questo campo (se le intestazioni RFC2822 sono corrotte).

Il messaggio (RFC2822)

  • La parte del messaggio inizia quando viene emesso il comando data.

  • Queste informazioni includono le intestazioni SMTP che conosci, il messaggio e i relativi allegati. Immagina che tutti questi dati vengano copiati e incollati da ciascun MTA al successivo, in successione fino a quando il messaggio non raggiunge la posta in arrivo.

  • È consuetudine che ciascun MTA preceda la copia e incolla sopra menzionata con informazioni sull'MTA (IP di origine, IP di destinazione, ecc.). Incolla anche i dettagli del controllo SPF.

  • Questo è il Display From è posto. Questo è importante. Gli spoofer possono modificarlo.

  • Il Mail From: nella busta viene scartato e solitamente inserito qui come return-path: indirizzo per i rapporti di mancato recapito

Quindi, come possiamo impedire alle persone di modificare il display da? Bene DMARC ridefinisce un secondo significato per il record SPF. Riconosce che esiste una differenza tra Envelope From e Display From e che esistono motivi legittimi per cui non corrispondono. Poiché SPF era originariamente definito per occuparsi solo di Envelope From, se Display From è diverso, DMARC richiederà un secondo controllo DNS per vedere se il messaggio è autorizzato da quell'indirizzo IP.

Per consentire scenari di inoltro, DMARC consente anche a Display From di essere crittografato in modo crittografico da DKIM, e se qualsiasi spammer o phisher non autorizzato dovesse tentare di assumere tale identità, la crittografia fallirebbe.

Che cos'è DKIM? DKIM è una tecnologia di crittografia leggera che firma i dati che risiedono nel messaggio. se hai mai ricevuto un messaggio da Gmail, Yahoo o AOL, i tuoi messaggi erano firmati DKIM. Il punto è che nessuno saprà mai che stai usando la crittografia DKIM e la firma a meno che non guardi nelle intestazioni. È trasparente.

DKIM di solito può sopravvivere a essere inoltrato e trasferito a diversi MTA. Qualcosa che SPF non può fare. Gli amministratori di posta elettronica possono utilizzarlo a nostro vantaggio per prevenire lo spoofing.


Il problema risiede nel fatto che SPF controlla solo la busta RFC2821 e non Display From. Poiché la maggior parte delle persone si preoccupa del Visualizza da mostrato in un messaggio e-mail, e non del rapporto di mancato recapito NDR, abbiamo bisogno di una soluzione per proteggere e proteggere questo pezzo.

È qui che entra in gioco DMARC. DMARC consente di utilizzare una combinazione di un controllo SPF modificato o DKIM per verificare Visualizza da. DKIM consente di firmare in modo crittografico il display da RFC2822 ogni volta che SPF non corrisponde a Display From (che si verifica frequentemente).


Lo spoofing Display è un problema di sicurezza?

Sì, il phishing tramite e-mail è un importante problema di sicurezza che molti fornitori stanno esaminando. Vale a dire Paypal, AOL, Google, Yahoo e altre società stanno implementando DMARC per risolvere questo problema di phishing.

Perché è ancora possibile creare l'intestazione "Da:" nelle e-mail?

Alcuni amministratori di server non hanno implementato le ultime tecnologie per impedire che questo genere di cose accada. Una delle principali cose che impediscono l'adozione di queste tecnologie è "servizi di inoltro di posta elettronica" come un software di mailing list, auto-spedizionieri o remailer di ex studenti (.forwarder). Vale a dire:

  1. SPF o DKIM non sono configurati.

  2. Non è stata impostata una politica DMARC.

  3. Il client di posta elettronica non sta visualizzando i risultati della verifica del campo Visualizza da e Risentito * * o Mittente.

Cosa sta facendo Paypal?

Paypal utilizza l'intestazione mittente per indicare che è stato effettuato il remailing. Questo è l'uso corretto e previsto di questa intestazione.

Cosa sta facendo GMail?

Gmail non chiarisce che viene utilizzata l'intestazione del mittente, non convalida l'indirizzo di visualizzazione da in un modo intuitivo e non distingue tra display e mittente.

5