Posta aziendale: la superficie di attacco che nessuno verifica

Il cluster di contenuti sulla posta elettronica che trovate su questo blog affronta il problema da un lato preciso: come riconoscere un messaggio costruito per ingannarvi, cosa succede se si è già aperto un allegato sospetto, come funzionano le campagne di malspam e con quali tecniche si rilevano, cosa significa il banner sospetto spam che compare in cima ai messaggi. È il lato del comportamento e del rilevamento, e resta il più raccontato perché è quello che le persone vivono ogni giorno.

Manca l’altro lato, e nelle valutazioni di sicurezza è quello che viene esaminato per primo: la posta aziendale è anche un’infrastruttura esposta su internet, con una superficie di attacco che si misura da fuori. Nessun messaggio da recapitare, nessun allegato da aprire, nessun dipendente da convincere: è la stessa logica con cui si valutano le vulnerabilità di qualunque altro sistema esposto.

Questo articolo tratta esclusivamente quel lato. Cosa è raggiungibile dall’esterno, perché la webmail va trattata come un’applicazione web, quali percorsi di accesso aggirano il secondo fattore, chi ha permessi permanenti sulle vostre caselle, e quali verifiche producono un esito documentabile — il tipo di riscontro che serve quando lo chiede un cliente, un auditor o un audit di sicurezza interno.

1. Da canale a infrastruttura: cosa cambia
2. Cosa è raggiungibile dall’esterno
3. La webmail è un’applicazione web
4. I percorsi che aggirano il secondo fattore
5. Chi ha permessi permanenti sulle vostre caselle
6. Configurato non significa verificato
7. Quali verifiche producono evidenza

Da canale a infrastruttura: cosa cambia

Nella maggior parte delle aziende la posta viene pensata come un canale: trasporta messaggi, e si protegge filtrando quello che arriva. Su quella descrizione poggiano il filtro antispam, l’antivirus e la formazione del personale, tutti presidi legittimi di cui il blog si occupa altrove.

Quella descrizione però ne omette una parte, e l’omissione ha conseguenze concrete. Perché la posta funzioni servono servizi accessibili da internet: un’interfaccia web da cui il personale legge i messaggi fuori ufficio, endpoint che accettano tentativi di autenticazione, protocolli che permettono ai client di scaricare le caselle, pannelli di amministrazione, connettori che consentono ad applicativi esterni di inviare notifiche a vostro nome.

Ognuno di questi è interrogabile da chiunque, in qualsiasi momento, senza inganni e senza allegati. È un piano di attacco parallelo, e chi valuta la vostra sicurezza dall’esterno parte da lì perché è la parte che si misura senza chiedere permesso.

Cambia anche cosa perdete in caso di compromissione. Una casella aziendale non è un contenitore di messaggi: è l’identità con cui quella casella comunica, l’archivio delle conversazioni passate, e nella maggior parte delle configurazioni il canale con cui si reimpostano le credenziali di ogni altro servizio. È la ragione per cui una credenziale di posta compromessa ha un valore sproporzionato rispetto alla stessa credenziale su un applicativo qualsiasi.

Cosa è raggiungibile dall’esterno

Il punto di partenza di qualunque verifica è l’inventario di ciò che è esposto, e coincide con la prima fase di una scansione delle vulnerabilità fatta con criterio. Nelle aziende strutturate quell’inventario è quasi sempre più ampio di quanto l’IT si aspetti, e la ragione è banale: si accumula per stratificazione, un servizio alla volta, e nessuno lo rilegge a distanza di anni.

La riga sugli endpoint di autenticazione merita una precisazione. Accettare tentativi di accesso da qualunque origine significa che chiunque disponga di un elenco di indirizzi aziendali può provare credenziali a ripetizione, e quegli elenchi circolano: le raccolte di credenziali esposte in violazioni passate, verificabili con strumenti come Have I Been Pwned, sono il materiale di partenza più economico che esista per un attaccante.

L’ultima riga della tabella è invece la più trascurata. Gestionali, CRM, piattaforme di fatturazione e sistemi di notifica hanno spesso credenziali o autorizzazioni per inviare posta usando il vostro dominio. Quelle credenziali vivono dentro sistemi che non controllate direttamente, e continuano a funzionare anche dopo la fine del contratto se nessuno le revoca — ragione per cui vale la pena inserirle fra le voci da chiarire quando si valuta la sicurezza di un fornitore.

La webmail è un’applicazione web

Vale la pena isolare questo punto, perché è quello che nelle valutazioni viene classificato più spesso in modo errato.

Un’interfaccia webmail esposta su internet è, sotto ogni aspetto tecnico, un’applicazione web: ha una pagina di autenticazione, gestisce sessioni, elabora input dell’utente, restituisce contenuto dinamico, spesso carica allegati e li rende visualizzabili nel browser. Le classi di vulnerabilità che la riguardano sono quelle delle applicazioni web, non quelle della posta.

Ne segue che la verifica appropriata non è una scansione dell’host che la ospita, ma un test sull’applicazione — quello che rientra nel perimetro del web application penetration testing. Un controllo infrastrutturale vi dice che quel servizio è raggiungibile e con quali versioni; non vi dice se la sua pagina di login o la sua gestione delle sessioni presentano difetti sfruttabili.

La distinzione non è formale. Una webmail vulnerabile è una via di accesso alle caselle che non passa da nessun messaggio, nessun allegato e nessun dipendente: non c’è comportamento umano da migliorare, perché nessun essere umano è coinvolto.

I percorsi che aggirano il secondo fattore

Molte aziende hanno attivato l’autenticazione a più fattori sulla posta e considerano il problema chiuso. In un numero significativo di casi non lo è, e la ragione è di configurazione, non di prodotto.

I sistemi di posta moderni mantengono attivi, per compatibilità con client e dispositivi meno recenti, metodi di accesso nati prima che il secondo fattore esistesse. Quei metodi non sono in grado di presentare una richiesta di verifica aggiuntiva, perché il protocollo non lo prevede: accettano una credenziale e concedono l’accesso. Finché restano abilitati, l’autenticazione a più fattori configurata sull’interfaccia principale può essere bypassata scegliendo semplicemente una via diversa.

Vale lo stesso ragionamento per le utenze escluse dall’obbligo. Caselle di servizio, account condivisi, utenze usate da applicativi automatici, amministratori che hanno chiesto un’esenzione temporanea mai revocata: sono le utenze che valgono più delle altre, e statisticamente sono quelle su cui il secondo fattore manca. È il motivo per cui il principio del privilegio minimo va applicato con più severità proprio dove sembra scomodo.

Anche dove è attivo e ben configurato, conviene sapere che non è invulnerabile: tecniche come l’MFA fatigue lo aggirano lavorando sulla persona. Resta comunque un presidio che alza molto il costo dell’accesso, purché non esistano scorciatoie a fianco.

Chi ha permessi permanenti sulle vostre caselle

C’è una categoria di accesso che non compare in nessun elenco di utenti e che nella pratica ha spesso più poteri di un dipendente.

Le piattaforme di posta aziendali permettono ad applicazioni terze di richiedere autorizzazioni sulle caselle: leggere i messaggi, inviare a nome dell’utente, accedere ai contatti, in alcuni casi operare senza che nessuno sia collegato. Estensioni per il browser, strumenti di produttività, plugin per la firma, integrazioni con il CRM, applicativi di analisi. Un utente concede il consenso una volta, e da quel momento l’autorizzazione continua a valere indipendentemente dalla password e dal secondo fattore, perché non è una credenziale: è una delega.

Le conseguenze operative sono tre e vale la pena esplicitarle. Un cambio di password non revoca queste deleghe. Un dipendente che lascia l’azienda non porta con sé le autorizzazioni che ha concesso. E se l’applicazione terza viene compromessa, l’attaccante eredita l’accesso che quell’applicazione aveva sulle vostre caselle, senza aver mai interagito con la vostra infrastruttura.

È lo stesso meccanismo di fiducia trasferita che rende efficace l’island hopping, applicato al livello applicativo anziché a quello di rete. La verifica utile è periodica e consiste in una sola domanda: quali applicazioni hanno autorizzazioni attive sulle caselle, chi le ha concesse e quando.

Configurato non significa verificato

I meccanismi di autenticazione del dominio — quelli che dichiarano quali server sono autorizzati a inviare per conto vostro e come trattare i messaggi che non superano i controlli — sono spiegati nel dettaglio nell’articolo sul malspam, e qui non li ripercorriamo.

Quello che riguarda invece questo perimetro è il divario fra averli configurati e averli verificati. Sono situazioni frequenti e tutte invisibili dall’interno: record che superano i limiti tecnici del protocollo e diventano inefficaci senza dare alcun segnale, chiavi di firma ruotate presso il fornitore e mai aggiornate nella zona DNS, politiche lasciate in modalità di sola osservazione per anni nell’attesa di un’analisi che nessuno ha completato, sottodomini dismessi rimasti privi di configurazione e utilizzabili da terzi.

Nessuna di queste condizioni produce un errore visibile nell’uso quotidiano. La posta continua ad arrivare, il pannello mostra i record come presenti, e la protezione che credete attiva è dichiarata ma non funzionante. Si rileva soltanto interrogando la configurazione dall’esterno, che è esattamente ciò che fa chi vi vuole impersonare. È anche il tipo di scostamento che un report di valutazione mette per iscritto, trasformando un sospetto in un rilievo tracciabile.

Quali verifiche producono evidenza

Il criterio che rende utile tutto quanto precede è la documentabilità. Sapere di essere protetti serve a voi; poterlo dimostrare serve quando un cliente enterprise vi manda un questionario, quando un auditor chiede riscontri, o quando gli obblighi introdotti dalla direttiva NIS2 richiedono valutazioni tracciabili e aggiornate.

Le prime quattro righe rispondono alla domanda su cosa è esposto e mal configurato. La quinta risponde a una domanda diversa, ed è la distinzione che separa vulnerability assessment e penetration test: la prima misura la superficie, il secondo stabilisce se quella superficie cede davvero. Su un’interfaccia di posta esposta pubblicamente la seconda domanda è quella che conta, perché è l’unica il cui esito non dipende da come si comporta il personale.