Spoofing via email con ID messaggio SMTP?

1

Molti dei miei utenti oggi hanno ricevuto email da docs#@mydomain.com (dove docs # era tra docs0 e docs8 o così, e mydomain.com è ovviamente cambiato dal mio vero nome di dominio), con il nome del mittente di "Administrator ". Il messaggio conteneva oggetto "Nuovo messaggio vocale" e messaggio: "Hai ricevuto un messaggio vocale La lunghezza del messaggio è 00:06:11." È stato inviato a molti diversi utenti e gruppi di distribuzione, uno strano mix di diversi dipartimenti che normalmente non avrebbe senso (e-mail al nostro gruppo di servizio clienti, oltre al nostro CFO, oltre a un membro IT casuale? C'era un allegato: ATT00001..txt, un file di testo.

Alcune ricerche online mostrano che si tratta di un tentativo di virus probabilmente da CryptoLocker (yikes !!!), e il file di testo rimanente è ciò che è rimasto dopo essere stato spogliato all'arrivo, o dal nostro servizio di filtraggio dello spam (non credo quindi, in base ai registri), il nostro gateway SonicWALL (credo sia questo che ci ha salvato) o uno scanner antivirus integrato in Outlook (no, Webmail mostra lo stesso allegato). Utilizziamo Postini per il nostro servizio di filtro antispam, quindi i nostri record MX indirizzano tutte le email lì e il nostro server proxy squid accetta solo posta da Postini, esegue alcuni filtri e la trasmette al nostro server Exchange.

In base all'intestazione dell'e-mail, ho individuato questa rotta presumibilmente presa dall'email (il dominio e il nostro IP pubblico sono stati modificati):

docs9718.mydomain.com (10.139.106.94) --> smtp.mydomain.com (10.0.0.18)

docs844.mydomain.com (10.0.0.18) --> mydomain.com (10.0.0.147)

ABTS-KK-dynamic-175.185.172.122.airtelbroadband.in ([122.172.185.175]) --> exprod5mx283.postini.com ([64.18.4.10])

psmtp.com (exprod5mx283.postini.com [64.18.0.107]) --> proxy2.mydomain.com

proxy2.mydomain.com ([127.0.0.1]) --> localhost (proxy2.mydomain.com [127.0.0.1])

localhost (localhost.localdomain [127.0.0.1]) --> proxy2.mydomain.com

proxy2.mydomain.com (12.7.13.46) --> proteus.mydomain.com (192.168.200.3)

Postini stava permettendo l'accesso a questi messaggi, anche se c'erano un paio di cose strane su di loro. Ad esempio, l'ID messaggio SMTP è una stringa univoca impostata dal primo server di messaggi che gestisce il messaggio e che normalmente non è incasinata da alcun server successivo. Tuttavia, l'ID messaggio di questa e-mail era [email protected] invece che, per esempio, se ricevevo qualcosa da Dell, si diceva [email protected]. Ha il mio dominio nel suo ID messaggio.

Ma in quel momento ho capito che i primi server a gestire il messaggio avevano il mio nome di dominio! È così che l'ID messaggio SMTP è stato falsificato, presumo. In effetti, quell'indirizzo residenziale in India (ABTS-KK-dynamic ...) è probabilmente un utente domestico con un virus e quel virus ha costituito i primi indirizzi.

Il problema è che gli indirizzi 10.xxx non sono solo nell'intervallo privato ARPA IP, ma ovviamente non corrispondono realmente al nostro dominio (modificato, ma in questo esempio il mio IP "reale" è 12.7.13.46) . Un altro problema è che c'è un divario tra il falso mydomain.com e il computer indiano.

In che modo i nostri server di posta non rappresentano una grande lacuna nelle intestazioni? E non verifica nulla sul server di origine, prende solo le sue parole per questo? Perché non solo non è un IP valido, non corrisponde ai record DNS per quel dominio che dice, in più il dominio di origine è lo stesso del dominio di destinazione! Normalmente non avrebbe senso, dato che quella posta sarebbe interna.

Inoltre, ho ragione su questa tecnica di spoofing del Message ID ID SMTP? Non riesco a trovare nulla di simile online. Ma la tattica ha senso - Se dico che proviene da alcuni falsi server di mydomain.com e i server centrali non lo verificano mai, il server finale crederà che provenga davvero dal mio dominio. Semplice MAIL DA: lo spoofing su un relay aperto non funzionerà sul nostro server, ma qualcosa del genere a quanto pare può. Non sono sicuro che sia quello che si sta facendo qui.

Ecco l'intero file di intestazioni fittizie (rinominato IP pubblico, dominio e A: solo indirizzi di posta elettronica): collegamento Pastebin

    
posta armani 21.01.2014 - 23:00
fonte

2 risposte

5

Tutto ciò che riguarda un messaggio e-mail può essere contraffatto o essere manomesso durante il trasporto. Le uniche intestazioni di cui ti puoi fidare sono quelle messe lì dal tuo server; l'unico contenuto di cui ti puoi fidare è quello protetto da una firma digitale verificata. Nel caso del tuo file pastebin, se sto capendo correttamente la tua descrizione della configurazione di rete, le righe dalla 1 alla 22 sono affidabili, le righe dalla 23 alla 25 sono probabilmente affidabili, e tutto dalla linea 26 in poi è forgiato.

I server di posta elettronica non tengono conto delle lacune nelle intestazioni perché non ne hanno bisogno. La maggior parte dei server di posta elettronica sono progettati sulla filosofia Unix: fare una cosa, farlo bene e fornire un modo standard per interfacciarsi con altri programmi. Il compito di un server di posta elettronica è spostare l'e-mail dal punto A al punto B; cose come la ricerca di spazi vuoti nelle intestazioni è il compito di un filtro antispam.

    
risposta data 22.01.2014 - 09:13
fonte
0

L'intestazione dell'ID del messaggio non può essere convalidata poiché non c'è nulla a cui deve conformarsi. L'ID messaggio viene utilizzato semplicemente come identificativo univoco per un messaggio. Se un messaggio viene inviato nuovamente senza alcuna modifica, l'ID messaggio dovrebbe rimanere lo stesso, in modo che i client sappiano che è lo stesso messaggio. Un tipico ID messaggio segue uno schema in cui saranno concatenati alcuni md5 (spesso del corpo del messaggio) seguiti dal nome host del server di posta - o qualcosa di simile. Ciò consente al messageID di comunicare brevemente da dove proviene il messaggio e cosa contiene il corpo del messaggio ... ma non è affatto necessario ed è solo una di quelle cose che la gente fa in questo modo. '1234567890abcdefghijklmnopqrstuvwxyz' è anche un ID messaggio valido. Quindi no, contrariamente alle altre risposte, ho intenzione di dire che l'ID del messaggio NON PUO 'essere falsificato, perché non c'è alcun beneficio nella modifica di qualsiasi cosa nell'ID del messaggio, al di là di confusione degli amministratori di sistema e dei poveri filtri anti-spam.

    
risposta data 02.01.2019 - 13:59
fonte

Leggi altre domande sui tag