Per prima cosa, bella domanda. Ho controllato come si comporta Thunderbird modificando una mail esistente e in realtà vengono prese le prime intestazioni per la visualizzazione di From, To e Subject mentre il meccanismo di firma DKIM parte dalla fine :(. Pertanto la firma DKIM è considerata valida anche se From, A e Oggetto sono falsificati. È interessante notare che la prima riga Da viene utilizzata solo nella vista della posta mentre nella vista elenco di tutte le mail mostra l'ultima riga Da.
Per quanto riguarda altri attacchi o come gli attacchi che hai descritto possono essere utilizzati in un modo che potresti non aver realizzato:
Ci sono alcune intestazioni di posta che hanno effetti collaterali interessanti e spesso queste intestazioni non sono completamente protette (cioè protette contro il cambiamento o contro l'aggiunta di una nuova intestazione). In particolare Content-Type e Content-Transfer-Encoding hanno un significato speciale su come il contenuto viene interpretato. La manipolazione di queste intestazioni può avere effetti interessanti. Ad esempio avere un multipart Content-Type con un confine non esistente fa sì che Thunderbird non mostri più il testo originale della mail, ma piuttosto un contenuto vuoto. Se combinato con lo spoofing dell'oggetto ("scarica l'aggiornamento da hxxp: // ...") e / o la risposta-a questo contenuto vuoto inatteso può essere utilizzato per un attacco social. Esempio:
Subject: Blank mail? Download hotfix for your mail client at http://....
Content-type: multipart/mixed; boundary=boundary_does_not_exist
Subject: original subject
Content-type: original/type
La modifica di Content-Transfer-Encoding simile a base64 per contenuti non multiparte può causare la visualizzazione di termini privi di significato che possono essere utilizzati in un attacco social. Esempio:
Subject: Mail corrupt? Download hotfix for your mail client at http://....
Content-Transfer-Encoding: base64
Subject: original subject
Content-type: text/plain
Se la firma DKIM utilizza l= per limitare il numero di linee utilizzate nell'hash del corpo, si può anche "sostituire" il contenuto della posta cambiando (o aggiungendo) il tipo di contenuto in un tipo multipart con un contorno speciale . Il confine è quindi progettato per saltare il contenuto esistente incluso nell'hash che sarà trattato come preambolo per le nuove parti MIME (e quindi non verrà mostrato). Esempio:
Content-type: multipart/mixed; boundary=my_own_boundary
DKIM-Signature: ... bh=...; l=...
Content-type: original/type
here is the original content, no matter if single part or multipart
this is the last line included in the body hash
--my_own_boundary
Content-type: text/plain
Only this text is shown at the recipient
--my_own_boundary--
... uses a l= tag (most ordinary emails usually don't)
In realtà sono rimasto sorpreso di quante firme DKIM con l= ho trovato nella mia casella di posta. In particolare le e-mail di cisco.com utilizzano (d?) Questa funzione e ne ho usata una per sostituire con successo il contenuto nel modo in cui ho descritto mantenendo valida la firma.
Oltre a modificare una posta esistente da Sammy, l'aggressore potrebbe anche essere in grado di creare una nuova posta per Rita che sembra provenire da Sammy. Questo può essere fatto creando una mail con una firma DKIM valida e quindi aggiungendo un'intestazione From simulata in cima. Se Rita controlla solo se la firma DKIM è valida, non vedrà alcun problema. Se controlla inoltre se il dominio della firma corrisponde al dominio dei mittenti, il risultato dipende da quale intestazione From viene utilizzata per questa convalida. Ma se Sammy utilizza uno dei provider di posta pubblica, l'utente malintenzionato potrebbe semplicemente ottenere anche un account di posta lì e quindi non importa quale da è considerato quando si controlla il dominio perché entrambi provengono dallo stesso dominio.