Nell’aggiornamento cumulativo (CU, Cumulative Update) di settembre 2021, Microsoft ha aggiunto una nuova funzionalità denominata Servizio di mitigazione delle emergenze di Microsoft Exchange (Microsoft Exchange Emergency Mitigation Service, EM). Questo nuovo servizio non sostituisce l’installazione degli aggiornamenti di sicurezza (SU, Security Update) di Exchange Server, ma rappresenta il modo più veloce per ridurre i rischi più elevati per i server Exchange on-premises, prima di installare tutte le SU applicabili.
Indice degli argomenti
Microsoft Exchange Emergency Mitigation Service: cos’è
Come altri componenti di Exchange Server, l’Emergency Mitigation viene eseguito come servizio Windows su Exchange Server.
È una versione integrata dell’Exchange On-premises Mitigation Tool (EOMT) che funziona con l’Office Config Service (OCS) basato sul cloud, per fornire protezione contro le minacce cyber che hanno mitigazioni note. L’OCS è lo stesso servizio di configurazione online utilizzato dai client di Microsoft Office.
L’uso di Microsoft Exchange Emergency Mitigation service è facoltativo per i clienti che desiderano che Microsoft crei e applichi automaticamente le mitigazioni della vulnerabilità ai propri server Exchange. Di conseguenza, se la nostra organizzazione o quella per cui prestiamo consulenza non desidera utilizzare EM, un sysadmin può disabilitarlo e continuare ad utilizzare EOMT per mitigare manualmente le minacce.
Come funziona il Microsoft Exchange Emergency Mitigation
Il servizio EM controlla l’OCS contattando l’URL https://officeclient.microsoft.com/getexchangemitigations: poiché in futuro le mitigazioni saranno rilasciate in qualsiasi momento, Microsoft ha impostato il servizio EM in modo tale che controlli le mitigazioni periodicamente, ogni ora.
Una mitigazione, lo ricordiamo, è sostanzialmente un’azione o un insieme di azioni utilizzate per proteggere un server Exchange da una minaccia nota. Se Microsoft viene a conoscenza di una minaccia cyber e viene creata una corrispondente mitigazione, tale mitigazione può essere inviata direttamente al server Exchange, che implementerà automaticamente le impostazioni preconfigurate.
Il pacchetto di mitigazione è un file XML firmato (come è possibile verificare contattando l’URL sopra indicata) che contiene le impostazioni di configurazione.
Una volta ricevuto dal server Exchange, il servizio EM convalida la firma per verificare che l’XML non sia stato manomesso e che abbia l’emittente e l’oggetto corretti e, dopo la convalida, applica le attenuazioni.
Analogamente all’EOMT, il lavoro svolto dal servizio EM rappresenta una mitigazione temporanea e provvisoria per i clienti fino a quando non verrà applicata una SU che risolva la vulnerabilità.
Come già accennato, il servizio Emergency Mitigation non sostituisce gli aggiornamenti di sicurezza di Microsoft Exchange, ma è un modo veloce per ridurre i rischi più elevati per i server on-premises prima dell’aggiornamento.
L’installazione di Microsoft Exchange Emergency Mitigation
Il servizio EM verrà installato automaticamente sui server Mailbox quando si installa il CU di settembre 2021 (o successivi). Non verrà installato sui Transport Edge server.
Una volta installato, EM offre un servizio opzionale che può essere disabilitato dal sysadmin. In effetti, sui server Exchange senza connettività Internet, Microsoft consiglia di disabilitare EM perché, per ovvi motivi, non può appunto funzionare.
In questi casi, o quando non si desidera la mitigazione automatica, si consiglia di utilizzare l’EOMT per applicare manualmente le mitigazioni disponibili. Se si dispone di connettività Internet in uscita ma si utilizzano restrizioni, sarà necessario abilitare la connettività in uscita all’OCS, che è https://officeclient.microsoft.com.
I requisiti di sistema richiesti
L’aggiunta del servizio EM implica ulteriori requisiti per l’installazione di Exchange.
È richiesta, infatti, l’installazione del modulo IIS URL Rewrite v2 sul server Exchange. Se questo modulo non è installato sul server quando si installa la CU, si riceverà un messaggio di errore durante la fase di analisi dei prerequisiti dell’installazione.
Indipendentemente dal fatto che si preveda di utilizzare EM, il modulo IIS URL Rewrite è un prerequisito per l’installazione di Exchange, a partire dalla CU di settembre 2021.
Quando si applica una mitigazione tramite il modulo IIS URL Rewrite, EM può apportare modifiche al file web.config sul server Exchange. Queste modifiche o vengono eseguite automaticamente e tutte correttamente oppure verrà eseguito il rollback di web.config allo stato originale del cliente.
Se si sta gestendo o facendo manutenzione di un Exchange Server 2016 su Windows Server 2012 R2, occorre prima installare anche l’aggiornamento KB2999226. Se questo aggiornamento non è installato, l’installazione di Exchange non sarà in grado di procedere.
Infine, lo ricordiamo, il server Exchange avrà necessità della connettività verso l’OCS, in particolare verso https://officeclient.microsoft.com.
Comprendere le mitigazioni
Una mitigazione è un’azione o un insieme di azioni che vengono intraprese automaticamente per proteggere un server Exchange da una minaccia nota che viene sfruttata attivamente. Il servizio EM (come l’EOMT) è in grado di applicare più mitigazioni, tra cui:
- implementazione di una regola di riscrittura IIS per filtrare le richieste HTTPS dannose;
- disabilitazione di un servizio di Exchange;
- disabilitazione di una directory virtuale o di un pool di app.
Le azioni eseguite tramite una mitigazione includono la riscrittura delle URL, l’arresto/avvio di pool di app e servizi, la modifica delle impostazioni di autenticazione e di configurazione.
Ciò significa che per proteggere l’organizzazione/azienda e mitigare i rischi, il servizio EM può disabilitare automaticamente funzionalità di un server Exchange (proprio come ha fatto l’EOMT a marzo 2021).
Se la nostra organizzazione dispone di un mezzo alternativo per mitigare una minaccia conosciuta, possiamo scegliere di bloccare l’applicazione automatica di qualsiasi mitigazione del servizio EM per quella minaccia. I dettagli su come farlo possono essere consultati leggendo la documentazione ufficiale Microsoft.
Gestire e configurare le mitigazioni
Tramite PowerShell, i sysadmin hanno visibilità e controllo sul comportamento delle mitigazioni.
Ad esempio, è possibile trovare dettagli sulle mitigazioni applicate e il loro stato usando gli script inclusi in EM, così come trovare dettagli sulle mitigazioni bloccate da un sysadmin sia usando PowerShell che consultando l’Event Viewer di Windows.
Con lo script Get-Mitigations.ps1 è possibile, ad esempio, mitigare i seguenti quattro CVE:
- CVE-2021-26855
- CVE-2021-26857
- CVE-2021-27065
- CVE-2021-26858
Tutte le mitigazioni applicabili sono abilitate di default. Un sysadmin può abilitare e disabilitare le mitigazioni a livello organizzativo o a livello di server Exchange. Ad esempio:
- Set-OrganizationConfig -MitigationsEnabled $false è utilizzato per disabilitare la mitigazione automatica a livello di organizzazione. Di default è impostato su True. Se impostato su False, il servizio EM verificherà la presenza di mitigazioni ogni ora ma non applicherà automaticamente le mitigazioni a nessun server Exchange nell’organizzazione, indipendentemente dal valore di MitigationsEnabled a livello di server.
- Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false viene utilizzato per disabilitare la mitigazione automatica su di uno specifico server. Di default è impostato su True. Quando viene impostato a False, il servizio EM verifica le mitigazioni ogni ora ma non le applica automaticamente al server specificato.
La combinazione di queste due impostazioni determina il comportamento del servizio EM su ciascun server Exchange nell’organizzazione, come elencato nella tabella seguente.
Impostazioni organizzazione | true | Quando entrambe sono true, EM applicherà automaticamente le mitigazioni al server Exchange |
Impostazioni server | true |
Impostazioni organizzazione | true | EM non applicherà automaticamente le mitigazioni a un server Exchange specifico |
Impostazioni server | false |
Impostazioni organizzazione | false | EM non applicherà automaticamente le mitigazioni a nessun server Exchange quando l’impostazione dell’organizzazione è False. |
Impostazioni server | True o false |
Se si disabilitano le mitigazioni su un server o per l’intera organizzazione, è possibile comunque utilizzare l’EOMT per applicare manualmente tutte le mitigazioni disponibili per le nuove vulnerabilità di sicurezza, fino a quando l’SU applicabile non verrà installata sul server.
Un sysadmin può bloccare la riapplicazione delle mitigazioni utilizzando il parametro MitigationsBlocked.
Ad esempio, per bloccare una singola mitigazione denominata K1, può utilizzare:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @(“K1”)
Per bloccare più mitigazioni denominate K1 e K2, può utilizzare:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @(“K1”, “K2”)
Per rimuovere tutte le mitigazioni dall’elenco dei blocchi, può utilizzare:
Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @()
Dopo che una mitigazione è stata rimossa dall’elenco dei blocchi, verrà riapplicata dal servizio EM. Riavviando il servizio EM sarà possibile riapplicare manualmente un’attenuazione senza attendere la successiva esecuzione del servizio EM. Dopo il riavvio del servizio EM, la prima esecuzione per verificare e applicare le mitigazioni avviene a distanza di 10 minuti.
Quando una mitigazione è bloccata da un sysadmin, o quando non è più necessaria (come nel caso di un aggiornamento CU o SU), occorre rimuovere manualmente le azioni di mitigazione applicate per annullarne gli effetti.
Ad esempio, se la mitigazione K1 non è più rilevante dopo l’installazione dell’ultima SU, il servizio EM smetterà di applicare K1 su base oraria, e questa mitigazione scomparirà dall’elenco delle mitigazioni applicate, ma la mitigazione rimarrebbe comunque configurata.
I passaggi per rimuovere una mitigazione che non è più necessaria dipendono dalla mitigazione stessa.
Ad esempio, se nell’ambito di un’attenuazione un servizio di Exchange viene arrestato e impostato su disabilitato, la rimozione dell’attenuazione comporta l’avvio del servizio e l’impostazione dell’avvio automatico.
Per rimuovere un’attenuazione della regola di riscrittura di IIS, un sysadmin può eliminare la regola dal sito Web appropriato utilizzando il pannello Gestione IIS.
Come illustrato nella figura seguente, il servizio EM crea regole di riscrittura IIS con un prefisso “EEMS <ID mitigazione> <Descrizione>” che le rende facili da identificare.
Se un sysadmin rimuove una mitigazione ma non la blocca, EM riapplicherà la mitigazione quando eseguirà il controllo orario per nuove mitigazioni.
È possibile riapplicare manualmente una mitigazione senza attendere che il servizio EM controlli le mitigazioni arrestando e riavviando il servizio EM.
Dopo il riavvio del servizio EM, la prima esecuzione per controllare e applicare la mitigazione avviene dopo 10 minuti.
Se una mitigazione viene applicata correttamente, verrà tracciata tramite Applied Mitigations e Blocked Mitigations. Il monitoraggio di queste informazioni fa parte della gestione della mitigazione.
Ad esempio, dopo che una mitigazione è stata applicata con successo, il sysadmin dovrà installare la SU appropriata per la vulnerabilità sottostante. Dopo l’installazione della SU, le mitigazioni non sono più necessarie e il sysadmin dovrà rimuoverle (e il servizio EM non le riapplicherà).
Una volta che le mitigazioni vengono applicate ad un server, un sysadmin può visualizzare le mitigazioni applicate nel seguente modo:
Get-ExchangeServer -Identity <ServerName> | fl name, MitigationsApplied
Name: Server1
MitigationsApplied: {K1, K2, K3}
Possiamo listare l’elenco delle mitigazioni applicate e bloccate nel nostro ambiente nel seguente modo:
Get-ExchangeServer -Identity <ServerName> | fl name, MitigationsApplied, MitigationsBlocked
Name : Server1
MitigationsApplied : {K1, K3}
MitigationsBlocked : {K2}
Name : Server2
MitigationsApplied : {K1, K2}
Come già accennato, l’attività di mitigazione viene registrata nel registro eventi di Windows. Ad esempio, gli eventi 1005 e 1006 aventi origine MSExchange Mitigation Service verranno loggati per le azioni riuscite (ad esempio quando viene applicata una mitigazione) mentre l’evento 1008 con la stessa origine verrà tracciato per qualsiasi errore riscontrato (ad esempio quando il servizio EM non raggiunge l’OCS).
Oltre all’attività di logging delle mitigazioni, il servizio EM traccia anche i dettagli sull’avvio, l’arresto e la chiusura del servizio stesso (come tutti i servizi in esecuzione su Windows), nonché i dettagli delle sue azioni e gli eventuali errori riscontrati dal servizio stessp.
Mediante Search-AdminAuditLog è possibile esaminare le azioni intraprese da un sysadmin, inclusa l’abilitazione e la disabilitazione di mitigazioni automatiche e i dati di diagnostica.
Conclusione
Rinviando il lettore alla documentazione ufficiale Microsoft per ulteriori approfondimenti, tengo a precisare che il servizio ME non è la panacea per tutte le possibili vulnerabilità di Exchange (ipotetici 0day ancora sconosciuti, ad esempio), ma uno strumento integrativo a WAF, IPS e SIEM che il sysadmin (coadiuvato magari da un esperto di cybersecurity) può (e sostanzialmente, a mio avviso, dovrebbe) mettere in pista per contrastare pericolose minacce software (ransomware compresi) che le cyber gang sanno sfruttare molto bene per i loro lucrosi piani di malaffare, a danno di aziende, enti pubblici, utenti e consumatori.
A danno di tutti noi.
