Il tag DKIM l= (minuscolo "L") in DKIM è un tag opzionale che specifica la lunghezza del corpo del messaggio che deve essere firmato. Questa può essere considerata una vulnerabilità DKIM poiché il tag l= consente di firmare parzialmente il corpo del messaggio. Ciò può rendere più facile per gli attori delle minacce sfruttare i messaggi firmati DKIM.
Esploriamo come DKIM e perché non si consiglia di utilizzare il tag DKIM l= nella firma DKIM.
Scopo delle limitazioni della lunghezza del corpo DKIM (tag l=)
DKIM (DomainKeys Identified Mail) è un protocollo di autenticazione delle e-mail che garantisce che il contenuto delle e-mail non sia stato alterato durante il transito. Consente al destinatario di verificare che un'e-mail sia stata effettivamente inviata e autorizzata dal proprietario del dominio.
Quando i server intermediari inoltrano i messaggi, possono modificare il corpo del messaggio. Possono aggiungere informazioni supplementari nel piè di pagina o nel contenuto del messaggio. Il tag DKIM l è stato introdotto per evitare che i messaggi legittimi non superino il DKIM, nel caso in cui il contenuto sia stato modificato durante l'inoltro o dalle mailing list.
Come funziona il tag DKIM l=
- Specificare la lunghezza: Il parametro l= è seguito da un numero intero che indica il numero di byte nel corpo del messaggio che sono coperti dalla firma DKIM.
- Firma parziale del corpo: Specificando una lunghezza, solo i primi 'n' byte del corpo sono inclusi nell'hash utilizzato per generare la firma DKIM. Qualsiasi modifica al corpo oltre questa lunghezza non influirà sulla verifica della firma DKIM.
Esempio: Firma DKIM con la vulnerabilità l-Tag DKIM
Si consideri un'e-mail in cui il corpo è lungo 1000 byte, ma solo i primi 500 byte sono firmati:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notify.domain.com; s=selector1; t=1718098168; i=@notify.domain.com; l=500; bh=SF9K/AZh8dO2XDYZlOtjrmHj5txv4H4qjhFr+q3ASuM=; h=Subject:Message-ID:To:Date:Content-Type:From:To:Cc:Subject; b=h0Jp5xjZSjUo06er2Gm5k0Fvt0cuC0xOnfobu1oYAFT2ugVxY0h/xly6x/E/pPT2S
In questo esempio, il valore l=500 indica che solo i primi 500 byte del corpo dell'email sono inclusi nella firma DKIM.
Tuttavia, il principale registrar di domini con sede in Europa, Il team di analisti di Zone.eu ha scoperto una grave vulnerabilità legata al tag l della firma DKIM. Al di là dei suoi vantaggi negli scenari di inoltro della posta, il tag l può essere facilmente sfruttato dai criminali informatici per inviare e-mail di phishing che superano comunque i controlli DKIM.
Vulnerabilità DKIM l= Tag
Si sconsiglia l'uso del tag DKIM l= in quanto può indebolire la vostra posizione di sicurezza, lasciando il vostro dominio vulnerabile agli attacchi anche con l'autenticazione delle e-mail configurata.
Un utente malintenzionato può modificare il contenuto del corpo del messaggio e allegare file o link dannosi nella sezione non firmata dell'e-mail, al di là dell'ambito dei byte definito nel tag "l". Quando l'e-mail raggiunge il destinatario, supera la verifica DKIM. Successivamente, se avete abilitato il DMARC per il vostro dominio, passerà anche questa.
Il destinatario potrebbe aprire questa e-mail, fidandosi del vostro nome di dominio, e cadere vittima dell'ennesimo attacco di phishing! Ciò può causare una grave violazione della privacy, il furto di credenziali e la perdita di fiducia nella vostra credibilità. Se il vostro cliente perde denaro in questo processo, potreste addirittura essere tenuti a fornire un risarcimento finanziario.
Il ruolo di BIMI nel peggioramento della vulnerabilità DKIM
BIMI è un protocollo emergente che sta guadagnando popolarità sia nel settore della sicurezza che in quello del marketing, grazie alla sua capacità di aggiungere loghi di marca alle e-mail. Non molto tempo fa, i principali provider di posta elettronica come Gmail e Apple Mail hanno esteso il supporto a BIMI, per dare alle e-mail un aspetto professionale e migliorare la sicurezza attraverso verifiche visive.
Poiché i messaggi contraffatti inviati da domini che utilizzano il tag DKIM l nella loro firma superano i controlli DKIM e DMARC, anche il logo BIMI del marchio viene allegato a queste e-mail dannose! Ora non solo questo falso messaggio inviato dal vostro nome di dominio supera tutti i filtri di autenticazione, ma ha anche il logo del vostro marchio attaccato ad esso! Ciò amplifica ulteriormente le possibilità che i destinatari si fidino della sua credibilità.
A causa della natura potenzialmente sfruttatrice del tag DKIM l=, Gmail, nel Centro assistenza dell'area di lavoro di Google Admin, ne sconsiglia fortemente l'uso. Ecco cosa dice Google a questo proposito:
"Se state impostando il DKIM con un sistema di posta elettronica diverso da Google Workspace, non utilizzate il tag di lunghezza DKIM (l=) nei messaggi in uscita. I messaggi che utilizzano questo tag sono vulnerabili agli abusi".
I rischi associati al tag DKIM l sono ulteriormente evidenziati in RFC 6376 sezione 8.2 intitolata "Uso improprio dei limiti di lunghezza del corpo (tag "l=")". La RFC avverte gli utenti che specificare il tag l nella firma DKIM può portare gli utenti ad accedere a contenuti e-mail dannosi senza alcun preavviso. La RFC esorta i firmatari DKIM a prestare la massima attenzione in presenza di questo tag e raccomanda ai server di valutazione di ignorare completamente le firme DKIM con un tag l= specificato.
Controllate la vostra firma DKIM per verificare la presenza di vulnerabilità l-Tag DKIM
È essenziale determinare innanzitutto se il vostro dominio è vulnerabile. Per farlo, abbiamo elencato di seguito alcuni metodi che potete utilizzare:
Metodo manuale: Verifica delle intestazioni originali della firma DKIM
1. Inviate un'e-mail vuota a voi stessi (in questo caso prendiamo l'esempio di un utente Gmail).
2. Aprite questa e-mail.
3. Andate su "altre opzioni", indicato da tre puntini in alto a destra.
4. Cliccare su "Mostra originale".
5. Nella pagina del messaggio originale, scorrere verso il basso per vedere le intestazioni grezze.
6. Passare alla sezione "DKIM-Signature:" e analizzare la sintassi. Se si nota che il tag DKIM l= è presente nell'intestazione della firma DKIM, il dominio è vulnerabile. Se è assente, è tutto a posto e non è necessario intervenire.
Metodo automatico: Utilizzare uno strumento di analisi delle intestazioni delle e-mail
1. Registratevi su PowerDMARC per usufruire di una prova gratuita. Andate su Strumenti di analisi > MailAuth Analyzer.
2. Copiate l'indirizzo e-mail generato automaticamente e incollatelo come destinatario di una nuova e-mail di prova in Gmail. Inviare il messaggio di prova.
3. Tornare al portale e aggiornare la pagina. Fare clic sull'icona "visualizza" nella sezione Azioni per esaminare i risultati.
4. Produciamo immediatamente un rapporto aggregato con informazioni sulle vostre configurazioni DKIM, SPF e DMARC e molto altro ancora!
5. È possibile scorrere verso il basso per visualizzare l'intestazione della firma DKIM in formato grezzo e analizzato. Qui sarà possibile determinare se la firma ha il tag l= presente. Se è presente, occorre intervenire per eliminare questa vulnerabilità.
Esempio: Una firma DKIM senza la vulnerabilità l-Tag DKIM
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notify.domain.com; s=selector1; t=1718098168; i=@notify.domain.com; bh=SF9K/AZh8dO2XDYZlOtjrmHj5txv4H4qjhFr+q3ASuM=; h=Subject:Message-ID:To:Date:Content-Type:From:To:Cc:Subject; b=h0Jp5xjZSjUo06er2Gm5k0Fvt0cuC0xOnfobu1oYAFT2ugVxY0h/xly6x/E/pPT2S
Prevenire le vulnerabilità DKIM: Quali sono le migliori pratiche DKIM?
Se volete sfruttare al meglio il vostro protocollo DKIM, ecco alcuni suggerimenti che i nostri esperti vi consigliano:
- Evitare di utilizzare il tag DKIM l= nell'intestazione della firma DKIM.
- Contattate il vostro provider di servizi e-mail per ottenere nuove chiavi pubbliche DKIM (senza il tag l=) da aggiungere al vostro DNS.
- Ruotare periodicamente le chiavi DKIM per garantire che le vecchie chiavi con la vulnerabilità dell'l-tag possano essere sostituite da nuove chiavi prive di questa vulnerabilità.
- È possibile utilizzare chiavi DKIM forti, come quelle a 2048 bit, anziché a 1024 bit, per migliorare la sicurezza delle e-mail DKIM.
- Utilizzare un DKIM in hosting per gestire i selettori e le chiavi DKIM e monitorare i risultati dell'autenticazione DKIM da un'unica dashboard centralizzata.
- Creare le chiavi DKIM utilizzando un generatore automatico generatore DKIM automatico. Questo vi aiuterà a evitare errori di sintassi che è facile trascurare.
Protocolli complementari da utilizzare con DKIM
Per aumentare l'efficacia del DKIM, è possibile implementare i seguenti protocolli (insieme a un consiglio bonus alla fine!):
- Utilizzo ARC (Authenticated Received Chain) per garantire che le e-mail legittime superino i controlli di autenticazione anche quando vengono inoltrate o utilizzate nelle mailing list. Questo annulla automaticamente la necessità del tag DKIM l=. ARC conserva automaticamente le intestazioni originali del messaggio per evitare falsi negativi.
- Configurare meccanismi di fallback come SPF e DMARC per aumentare l'accuratezza dell'autenticazione e la sicurezza complessiva.
- Abilitazione Rapporti DMARC per tenere traccia dei canali di posta elettronica e delle fonti di invio. I rapporti DMARC possono aiutarvi a individuare indirizzi IP e mittenti dannosi, in modo da poter agire rapidamente contro di loro.
Aderendo a queste best practice, le organizzazioni possono migliorare significativamente la loro posizione di sicurezza delle e-mail e proteggere la reputazione del loro dominio. Sebbene il tag l= possa fornire flessibilità nella gestione delle e-mail che potrebbero essere alterate durante il transito, può indebolire la sicurezza del dominio. Per questo motivo, insieme a vari provider di posta elettronica, esperti del settore e organizzazioni, non lo raccomandiamo. Per saperne di più sulla sicurezza del dominio e sui servizi di autenticazione delle e-mail, contattateci oggi stesso!
- Come aggiungere il proprio logo alle e-mail di Gmail: Gmail e le e-mail brandizzate - 2 luglio 2024
- Quali sono le minacce alla sicurezza informatica quando si consente l'uso di cookie di terze parti su Mac? - 29 giugno 2024
- DMARC: l'anello mancante nella strategia di difesa dell'MSP - 27 giugno 2024