E-mail spoofing di Istituzioni e P.A.

INTRODUZIONE AL FENOMENO

Sono passati quasi 30 anni dall’origine del termine phishing e dai primi attacchi documentati, tuttavia, la stretta correlazione tra la buona riuscita degli stessi attacchi ed il fattore umano, sommata a campagne sempre più mirate e “autorevoli” e ad una – non proprio estesa – conoscenza e adozione globale dei meccanismi di prevenzione; fanno si che la prima posizione (per numero di vittime) dell’Internet Crime Report 2020 dell’FBI venga occupata da eventi criminosi di tipologia Phishing, al sesto posto quelli di tipo spoofing seguiti da misrepresentation, business e-mail compromise e, fuori dalla “top ten” di sole sei posizioni, la tipologia Government Impersonation.

Il fenomeno dell’e-mail spoofing e, più nello specifico, sender spoofing (impersonificazione di un indirizzo mittente di un dato nome di dominio) e domain spoofing (impersonificazione di un intero nome di dominio) sono spesso e da sempre, alla base delle campagne phishing e spear phishing in quanto consentono di condizionare negativamente il comportamento, le azioni e la scelte del destinatario, trasmettendo un falso senso di autorevolezza e attendibilità, sfruttando quindi proprio il “fattore umano” per la buona riuscita della campagna stessa.

Anche ENISA, sulla falsariga dell’FBI, già con le pubblicazioni Threat Landscape 2020 e 2021, pone l’accento verso gli “E-Mail Related Threats” dove le campagne BEC (Business e-mail compromise) e Phishing la fanno da padrona, tanto da arrivare a suggerire azioni tecniche volte all’implementazione di specifici standard / protocolli: DMARC, SPF e DKIM. Al centro di questa analisi e proposta di strategia sono proprio gli standard DMARC e, parzialmente, Sender Policy Framework e la loro comprovata utilità nel contrasto, se adottati in un più strutturato processo di intelligence, e nella prevenzione (intesa come blocco) di attacchi a tipologia Spoofing, Misrepresentation e Government Impersonation.

ANALISI DEL CONTESTO NAZIONALE: DAL 2009 AD OGGI

La Direttiva n.8/2009 a firma dell’allora Ministro per la Pubblica amministrazione Renato Brunetta delineava le disposizioni in materia di riconoscibilità, aggiornamento, usabilità, accessibilità e registrazione al dominio “.gov.it” dei siti web delle P.A. assegnando al nome di dominio “.gov.it” l’obiettivo di « aggregare i siti web delle pubbliche amministrazioni che già erogano servizi istituzionali con un adeguato ed omogeneo livello di qualità, sicurezza ed aggiornamento dei servizi » delegando all’ormai cessato CNIPA ora AgID, Agenzia per l’Italia digitale, la fornitura dell’assistenza tecnica necessaria per l’iscrizione al dominio .gov.it e la sua gestione operativa: AgID che risponde egregiamente al compito assegnatole implementando, ormai da anni, un portale per la registrazione e gestione dei nomi di dominio di terzo livello di .gov.it, portale che integra (già in fase di accreditamento della P.A. richiedente) la gestione dei record DNS – inclusi quelli di tipo TXT come DMARC e Sender Policy Framework oggetto della presente analisi – o la delega del dominio verso name server (e relativi pannelli di gestione DNS) terzi, esterni alla stessa AgID.

Nel panorama Istituzionale odierno, con il Piano Triennale per l’informatica nella Pubblica Amministrazione 2019-2021 e con la precedente determina AgID 36/2018 si è assistito al cosiddetto “riordino” del dominio di secondo livello gov.it, avviato, de facto, con lo scopo di aggiornare e riorganizzare i criteri di assegnazione e allocazione dei sottodomini secondo le politiche vigenti nell’Unione Europea; tale determina prevede nello specifico l’assegnazione del dominio di terzo livello di .gov.it « alle sole amministrazioni centrali dello Stato indicate all’elenco delle amministrazioni pubbliche individuate ai sensi dell’articolo 1, comma 3, della legge 31 dicembre 2009, n. 196 e successive modificazioni e pubblicate annualmente in G.U. » e prevede inoltre:

• che le amministrazioni territoriali e scolastiche che attualmente lo utilizzano debbano abbandonarlo nei termini stabiliti dalla determina;
• che tutte le infrastrutture ICT utilizzate per l’implementazione di tali siti siano conformi alle Misure minime di sicurezza ICT emanate da AgID e le applicazioni siano immuni almeno per i Top 10 Risk di OWASP correnti (allora OWASP Top 10 : 2017).

In estrema sintesi è stata disposta, in tutta fretta, la sola migrazione dei domini di terzo livello appartenenti a istituzioni scolastiche dal dominio “.gov.it” verso il nuovo “.edu.it” (quest’ultimo assegnato al MIUR) mentre per gli enti territoriali interessati dalla determina AgID è stata disposta la migrazione verso il dominio “.it” indicante, dal 1987, l’estensione geografica ufficiale dell’Italia.

A fronte di una tale migrazione su larga scala, si è sprecata la possibilità di adottare una politica di conformità per adeguare le “identità web” delle P.A. rendendole conformi a standard antiphishing e antispoofing globalmente riconosciuti e adottati già prima del Dicembre 2019, meccanismi dei quali la stessa ENISA raccomanda l’implementazione nella sua pubblicazione Threat Landscape 2021.

Ciò che sembrerebbe infatti non essere stato preso in considerazione e tantomeno valutato da AgID nella sua determina del 2018 e nel successivo Piano triennale ICT 2019-2021 è, relativamente alle “misure minime di sicurezza ICT” (e per causa dell’obsolescenza delle stesse basate su profili di conformità del 2015), l’implementazione, per i sottodomini di “.gov.it” assegnati alle Amministrazioni centrali dello Stato (così come per tutti i domini di terzo livello “.edu.it” in uso alle Istituzioni scolastiche ed i “.it” in uso alle Istituzioni territoriali), di una strategia ed una rispettiva implementazione tecnica atta a prevenire, bloccando sul nascere e segnalando in autonomia, i tentativi di domain spoofing e sender spoofing volti alla diffusione di campagne di phishing per conto di identità (intese come nomi di dominio) appartenenti alle stesse Pubbliche Amministrazioni.

Tale strategia verterebbe, per larga parte, intorno all’abilitazione di due tanto elementari quanto funzionali protocolli:

• DMARC, Domain-based Message Authentication, Reporting & Conformance (rfc7489)
• SPF, Sender Policy Framework (rfc7208)

I due “protocolli”, entrambi applicati a livello del nome di dominio interessato sottoforma di record TXT, collaborano per le finalità di autenticazione e validazione dell’indirizzo mittente (e del relativo nome di dominio in uso a quest’ultimo) delle email nel momento in cui queste raggiungono il mail exchanger del destinatario; in sintesi, il record SPF ha lo scopo di contenere una lista di indirizzi IP e FQDN di SMTP server autorizzati a spedire email per conto del nome di dominio dove esso è applicato, il record DMARC si occupa invece di imporre ai mail exchanger riceventi (dove sono definite le mailbox dei destinatari) l’azione da intraprendere qualora una o più mail da essi ricevute violassero le condizioni definite nel record SPF e provenissero quindi da un SMTP server il quale IP non risultasse autorizzato a spedire per conto del nome di dominio in uso al mittente, inoltre, DMARC include una funzionalità nativa di reporting che consente al dominio implementante di ricevere quotidianamente report dettagliati sulle violazioni (o tentativi) avvenute, quest’ultime spesso riconducibili a tentativi di domain spoofing e sender spoofing.

Il protocollo DMARC, pensato e progettato per un’adozione graduale al fine di consentire ai domini e sottodomini implementanti una transizione priva di disservizi e interruzioni, permette di specificare tre tipologie di policy da adottare in caso di violazione rilevata:

• none: non viene chiesta al mail exchanger ricevente alcuna azione sulla mail in ingresso che ha fallito il controllo DMARC, consente però (se associato alla funzionalità di reporting) di ricevere feedback dettagliati sulle violazioni avvenute (controlli DMARC con esito negativo);
• quarantine: viene chiesto al mail exchanger ricevente di trattare con diffidenza la mail in ingresso che ha fallito il controllo DMARC (classificazione come Spam / Spoofing);
• reject: viene chiesto al mail exchanger ricevente di rifiutare la mail in ingresso che ha fallito il controllo DMARC.
  Ne consegue che, la sola implementazione di DMARC in assenza di SPF o, nel caso opposto, lo specificare una lista di server autorizzati (SPF) in assenza di DMARC, rende nulli i benefici provenienti da entrambi in termini di prevenzione dello spoofing e reporting centralizzato delle violazioni.

SCENARIO DI RISCHIO

La mancata conformità agli standard DMARC e Sender Policy Framework, ossia l’assenza dei relativi record DNS di tipo TXT a livello dei nomi di dominio in uso a Pubbliche Amministrazioni, Enti Territoriali e Istituzioni Scolastiche, espone le stesse a scenari di rischio ulteriori che vertono su attacchi di tipo domain spoofing e sender spoofing volti all’impersonificazione di una o più identità (non per forza reali) appartenenti ad un dato nome di dominio quindi “brand”, o per meglio dire, associabili all’identità della Pubblica Amministrazione vittima di questa tipologia di attacco.

Entrando nel dettaglio, poichè la pratica dell’impersonificazione e, più generalmente, gli attacchi spoofing hanno come fine “ultimo” (o come obiettivo iniziale) l’avvio e la diffusione di campagne phishing e spear phishing sfruttando per l’appunto la notorietà e l’autorevolezza di un determinato dominio (domain spoofing) o mittente (sender spoofing) è altamente probabile che bad actor, approfittando della ridotta – quasi nulla – complessità di attacco, possano sfruttare identità appartenenti a nomi di dominio non conformi a DMARC e Sender Policy Framework per la diffusione, incontrollata per via dell’assenza delle funzionalità di reporting proprie dello standard DMARC, di dette campagne.

Nel peggior caso ipotizzabile bad actor o organizzazioni criminali potrebbero “istituire” una rete di server SMTP o sfruttare le migliaia di relay SMTP aperti o compromessi e pertanto accessibili a chiunque per l’invio, massivo o mirato, di e-mail di phishing per conto di indirizzi mittente Istituzionali, in uso a Pubbliche Amministrazioni o ai Dipendenti di quest’ultime.

Al verificarsi di un simile scenario, ai provider riceventi ossia ai mail exchanger dei destinatari della campagna malevola, siano essi basati su soluzioni enterprise-grade o “community”, non riscontrando la presenza – verificata mediante query DNS verso il nome di dominio mittente – di record DMARC e/o SPF validi, non resterebbe altro che trattare la mail di phishing come lecita in una sorta di “modo di agire” estremamente garantista, fatto salvo il caso di ulteriori controlli operati dal mail exchanger ricevente che riescano a contrassegnare la mail come malevola basandosi, ad esempio, sulla reputazione dell’indirizzo IP del server mittente.

Un esempio lampante è dato dal comportamento di Google Mail, che alla ricezione di una mail con mittente (e dominio) spoofed da un nome di dominio per il quale non risultano “dichiarati” e validi i record SPF e/o DMARC delegherà la “decisione finale” (ovvero la classificazione come Posta in arrivo, Importante o Spam) all’algoritmo proprietario “Google Magic” (citato espressamente nella sola versione US / UK di GMail) il quale si limita ad effettuare controlli per certi versi banali e non sempre funzionali a rilevare una campagna phishing, come:

• Numero di destinatari
• Presenza del destinatario in To o Cc
• Presenza tra i contatti / contatti frequenti del mittente e del dominio mittente
• Presenza di parole chiave “importanti”
• URL contenuti nella mail
• etc.

È quindi evidente come i mail exchanger riceventi e gli stessi provider siano “in difficoltà” nello stabilire l’autorevolezza e la provenienza lecita delle mail con indirizzo mittente appartenente ad un dato dominio per il quale non risultino dichiarati DMARC e/o Sender Policy Framework (questa analisi, finalizzata ad evidenziarne il solo rischio alla sicurezza non tiene conto degli ulteriori impatti alla mail deliverability di un dominio in assenza di detti record che potrebbero tradursi in mancate ricezioni, bassa reputazione delle mail lecite, blacklisting e impatti al business nel caso di domini in uso ad aziende), ma sono ancora più evidenti i rischi ai quali le Pubbliche Amministrazioni sono attualmente esposte, specie quelle ad alto tasso di rapporti / comunicazioni da e verso il cittadino (basti pensare a comuni, enti locali, scuole, etc.) a causa dell’assenza di una “strategia antispoofing” delle identità istituzionali – intese come nomi di dominio – che preveda, tra i suoi punti cardine, l’adozione e l’implementazione di misure efficaci come DMARC e Sender Policy Framework per i nomi di dominio Istituzionali (gov.it, edu.it, etc.) ed i relativi third-level domain appartenenti.

PROPOSTA DI SOLUZIONE

Le procedure di accreditamento e gestione DNS dei domini di terzo livello .gov.it, centralizzate in AgID, rappresentano ad oggi un terreno fertile ed un test case ideale per le azioni di enforcing e propagazione massiva dei record DMARC e Sender Policy Framework verso i nomi di dominio delle Pubbliche Amministrazioni aderenti al dominio gov.it, anche nell’ottica di una prima implementazione meno impattante che sfrutti la gradualità delle policy DMARC (ossia priva di policy DMARC decisionali, potenzialmente causa di disagi o interruzioni in assenza di un preliminare censimento dei mail server impiegati dalle singole P.A.) che abiliti la sola generazione e ricezione centralizzata dei report delle violazioni rilevate dai provider.

L’implementazione del solo “stack” DMARC – SPF, coordinata e condotta quindi da un organismo centrale o delegata ai responsabili tecnici delle rispettive Pubbliche Amministrazioni assegnatarie dei nomi di dominio .gov.it, .edu.it e ulteriori SLD, second level domain Istituzionali come sanita.it, apporterebbe certamente benefici tangibili – in termini di sicurezza percepita ed effettiva – estesi sia verso i Soggetti implementanti che verso i Dipendenti e Utenti a vario titolo (nel caso di pubbliche amministrazioni) di quest’ultime, comportando la riduzione, virtualmente prossima all’azzeramento (nel caso di policy DMARC decisionali non limitate al solo reporting) dei tentativi di domain spoofing e sender spoofing e, più nel concreto, delle conseguenti campagne di phishing e spear phishing avviate da bad actor sfruttando la mancanza di conformità (appurabile da fonti pubbliche come i name server autoritativi) dei domini “istituzionali” gov.it, edu.it et similia a meccanismi di “autenticazione” e “validazione” come DMARC e Sender Policy Framework.

In un’ottica di prevenzione del cyber crime l’implementazione di una “strategia Nazionale anti-spoofing” per i nomi di dominio .gov.it e Istituzionali consentirebbe di beneficiare delle capacità di reporting native dello standard DMARC agli scopi di poter ricevere, indicizzare, analizzare e, preferibilmente, centralizzare verso un unico organo di controllo e “monitoraggio” della Cyber Security Nazionale come il CSIRT Italia, gli alert e le segnalazioni generate dai provider di Posta (presenti nello scenario globale) relative ad eventi di violazione del Sender Policy Framework e pertanto riconducibili a tentativi di domain spoofing e sender spoofing e delle conseguenti campagne phishing avviate per conto (inteso come “ai danni di” trattandosi di veri e propri tentativi di impersonificazione) dei domini appartenenti o assegnati a Istituzioni e Pubbliche Amministrazioni nazionali: ciò comporterebbe, per i soggetti adottanti ed i sopracitati organi centrali di controllo, l’apertura e la pronta disponibilità di un “nuovo” flusso informativo di threat intelligence per l’acquisizione di informazioni, autorevoli e dettagliate, inerenti i tentativi di campagne phishing avviati ai danni delle Pubbliche Amministrazioni e Istituzioni, dei loro Dipendenti o Utenti a vario titolo; informazioni fondamentali per le successive fasi di un potenziale processo di intelligence volto all’analisi, classificazione, disseminazione / divulgazione (tramite processi di early warning) e “risposta” – quest’ultima integrata nelle policy “decisionali” quarantine e reject dello standard DMARC.

Continua a leggere o scarica il white paper gratuito “Quaderni di Cyber Intelligence #1“

Articolo a cura di Mirko Caruso, Esperto in sicurezza delle informazioni e conformità delle infrastrutture critiche