Indagare il file .eml di un'e-mail è sufficiente per ritenerlo dannoso?

No. ci sono alcuni campi SMTP come

MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.

anche

From: Joe Q Doe - the address visible to the recipient; but again, by default no checks are done that the sending system is authorized to send on behalf of that address.

Chiunque può spoofare qualsiasi indirizzo di posta esistente. Potrei persino inviarti una mail dal tuo indirizzo email .

Concentrandosi sul client di posta elettronica e le sue vulnerabilità, per la maggior parte le prove sarebbero effettivamente nel file eml inviato. Posso immaginare qualcosa come, ad esempio, un buffer overflow nel renderizzatore di immagini o il danneggiamento della memoria nel parser html per le email html - la prova per queste sarebbe presente nel file .eml. Se è ovvio, questa è un'altra domanda, in alcuni casi speciali può essere sottile e se la domanda è se è possibile trovare automaticamente questi con qualche tipo di strumento - probabilmente no in caso di difetti zero-day. Ma l'analisi manuale (analisi forense) può identificare questi tipi di attacchi dai file .eml.

Posso pensare a un'altra cosa che potrebbe interessarti o meno. Un utente malintenzionato potrebbe essere in grado di creare in qualche modo un messaggio di posta elettronica ricevuto dal server smtp e compromettere tale smtp attraverso i propri difetti in un modo che successivamente, presumibilmente, lo stesso server lo invia ai client tramite imap o pop3, l'attacco viene inoltrato a i client all'interno di imap o pop3 stesso. In questo caso non ci sarebbero prove nei file .eml, la vulnerabilità era nell'implementazione del protocollo nel client di posta elettronica. Tuttavia, un tale attacco sarebbe molto improbabile, ma ritengo che non sia necessariamente impossibile.

Quindi riassumendo, penso che il client possa essere compromesso attraverso due canali, o i contenuti della stessa email, che è molto più probabile, e la prova sarebbe quindi nei file .eml non elaborati, o tramite il protocollo che utilizza per scaricare e-mail dal server, ma tale server è controllato da te, quindi rappresenta un rischio molto minore.

Un'altra cosa che viene in mente è se nel client di posta elettronica viene sfruttata l'esecuzione del codice, è possibile che il codice dell'attaccante venga effettivamente modificato per nascondere le prove. Ancora una volta penso che sarebbe molto difficile farlo in modo affidabile nel caso generale, ma teoricamente non impossibile. Avresti comunque i file e-mail invariati sul server, a meno che anche questo non sia compromesso in un attacco separato.

Non puoi mai classificare nulla come sicuro al 100%.

Per rispondere correttamente alla tua domanda, non puoi dire se qualcosa è al sicuro solo con la fonte di posta elettronica (o l'intestazione), ma puoi dire se è molto probabilmente non sicuro. Ricorda che non sapere se qualcosa è sicuro non significa che non sia sicuro.

La risposta è NO . L'unico modo per credere che una particolare e-mail proviene da una fonte autentica e il mittente non è stato falsificato né il messaggio alterato maliziosamente è attraverso un certificato digitale emesso da un'autorità di certificazione attendibile .

Un tipico e ampiamente usato algoritmo usato per firmare e crittografare digitalmente la posta elettronica è RSA. Il digest del messaggio viene crittografato utilizzando la chiave privata nota solo al mittente del messaggio. Una volta che il destinatario dell'e-mail riceve il messaggio, lui o lei utilizza la chiave pubblica del mittente per decodificare il messaggio. Se il mittente è stato falsificato, la chiave pubblica non funzionerebbe poiché è associata a una particolare chiave privata univoca. Se il messaggio è stato alterato durante la trasmissione in qualsiasi modo, il messaggio decrittografato risultante sarebbe considerato danneggiato. Le firme digitali sono affidabili solo se il certificato utilizzato per generarle è affidabile, il che significa che è necessaria una CA per garantire l'identità di mittente e destinatario.

Sicurezza email, dal mittente alla tua casella postale

L'SMTP è di progettazione non sicura perché non autentica il mittente. Quindi un aggressore abbastanza intelligente può creare un messaggio di posta elettronica "sicuro" usando solo telnet.

Esistono alcune iniziative per rendere SMTP più sicuro: SPF e altri, server SMTP autenticati, PGP, ecc ... ma poiché nessuno di essi è ampiamente diffuso, smtp rimane non regolato.

Inoltre, tieni presente che anche se è la fonte di email che mostra lo stesso paio di relay, lo stesso mailer, ecc., questo non renderà l'email sicura perché l'attacker potrebbe controllare la tua casella postale corrispondente a causa di:

• una perdita su un sito pubblico in cui il tuo corrispondente ha utilizzato la stessa email indirizzo e stessa password dell'account e-mail per registrarsi.

• Un attacco bruteforce, una vulnerabilità nel software webmail FAI, un malware sul suo computer.

• qualcuno che dirotta la sua sessione (blocca sempre il computer se vai al piano di sotto a fumare una sigaretta).

• Un uomo che punta una pistola di fronte a lui e gli dice di scrivere quell'email.

La risposta è chiaramente NO :) (e sì, in realtà, ogni tipo di comunicazione non è sicuro)

Sicurezza email, nella tua casella di posta (aggiunta a causa della modifica di una domanda)

Poiché la domanda originale si è evoluta, continuiamo a rispondere; -)

Come dici tu, un'e-mail può incorporare un codice dannoso per sfruttare una vulnerabilità nel tuo MUA. Possiamo classificare le vulnerabilità in due categorie:

• Vulnerabilità nel renderer HTML
• Vulnerabilità nella busta della posta elettronica (fondamentalmente, le intestazioni che analizzano ecc.).

Desidero che oggi la maggior parte di MUA incorpori codice migliorato e robusto per l'analisi delle buste della posta elettronica. Poiché la busta non cambia da decenni ed è piuttosto basica (< nome intestazione & gt ;: < valore intestazione >) possiamo sperare che questa parte sia sicura. Ma solo "speranza" ... tenete presente che ogni giorno vengono introdotte regressioni su ogni tipo di software (date un'occhiata a CVE-2007-6165 e CVE-2006-0395 per esempio).

E ricorda anche che tutte le vulnerabilità non sono pubblicate, quindi un exploit sconosciuto può essere usato per abusare del tuo client di posta.

Per finire, la parte peggiore e più pericolosa è il motore di rendering HTML: poiché è in costante evoluzione, anche il codice si evolve e un utente malintenzionato potrebbe tentare di sfruttare alcune vulnerabilità in questo specifico software. L'email HTML è, IMHO, la parte più pericolosa della posta elettronica.

Ispezionare .eml ti aiuterà a scoprire i più ovvi tentativi di sfruttare qualsiasi vulnerabilità: intestazioni malformate, allegati con nomi strani (big_b00bs.jpg.exe)

Ma dal momento che il vettore di attacco può essere molte altre cose, penso che questo ancora non sia sufficiente per considerare un'e-mail sicura .

Ma se:

• disabiliti il rendering HTML.
• disabiliti la visualizzazione delle immagini.
• sei cauto con l'allegato.
• usi un antivirus (lato server è preferibile) nella tua catena di posta elettronica.
• si utilizza un client di posta elettronica in modalità sandbox.

Sei al sicuro al 90%:)