Microsoft Exchange sotto attacco: per due nuovi zero-day ancora non c'è la patch

• Business
• Patch management

Gli zero-day sono vulnerabilità di sicurezza non note agli sviluppatori che vengono già sfruttate da parte dei “cybercriminali” per sferrare attacchi informatici particolarmente efficaci. Dal momento che gli zero-day vengono utilizzati senza che sia disponibile qualunque aggiornamento correttivo questi attacchi si rivelano particolarmente efficaci.

Ecco perché gli zero-day non vanno mai presi sottogamba, soprattutto se si riferiscono a software utilizzati in ambito aziendale o comunque in qualche modo esposti sulla rete Internet.

Gli esperti della società vietnamita GTSC hanno scoperto e segnalato una nuova ondata di attacchi rivolti ai server Microsoft Exchange: ne avevamo parlato nei giorni scorsi. Come spiegano i ricercatori in quest’analisi, gli aggressori stanno già usando due exploit fino a qualche giorno fa completamente sconosciuti per eseguire codice dannoso a distanza sulle installazioni di Microsoft Exchange. Le vulnerabilità zero-day sulle quali viene fatto leva permettono infatti di porre in essere un vero e proprio attacco RCE (Remote Code Execution).

Le due nuove falle di sicurezza sono state individuate da GTSC e tempestivamente segnalate a Zero Day Initiative (ZDI) che a sua volta le ha condivise con Microsoft. I tecnici dell’azienda di Redmond sono al lavoro per risolvere il problema ma, allo stato attuale, non esistono ancora patch ufficiali.

Come proteggersi dagli zero-day che affliggono Microsoft Exchange

In termini di gravità, una delle due lacune di sicurezza è stata valutata con 8,8 punti su un massimo di 10 dal team di ZDI (Microsoft l’ha giudicata allo stesso modo). Questo perché, similmente a quanto avvenuto in passato con le vulnerabilità ProxyShell di Exchange (alle quali i nuovi attacchi sembrano peraltro ispirarsi…), un aggressore deve solo utilizzare un URL malevolo per indurre il server a eseguire codice arbitrario.

Per proteggere Microsoft Exchange, i dati da esso gestiti, i client collegati e l’intera rete aziendale in attesa dell’arrivo di una patch ufficiale (o di un aggiornamento in-memory di 0patch), il consiglio è quello di implementare una regola in IIS (Internet Information Services) in grado di bloccare le richieste di connessione al componente vulnerabile.

L’intervento consiste nel cercare il sito Autodiscover tra quelli creati in IIS, selezionare URL rewrite, aggiungere una nuova regola e impostare il blocco delle richieste.
Sia GTSC che Microsoft hanno suggerito di inserire nel campo Pattern la stringa .*autodiscover\.json.*\@.*Powershell.* selezionando quindi Regular expression. In Condition input (finestra Edition condition) bisogna impostare {REQUEST_URI}.

La modifica suggerita da Microsoft non è sufficiente per proteggere Exchange

Un ricercatore autonomo osserva però che questo intervento può essere agevolmente scavalcato dagli aggressori remoti.
Anziché utilizzare la stringa suggerita da Microsoft, quindi, l’esperto consiglia di utilizzare la soluzione più generica .*autodiscover\.json.*Powershell.* in grado di bloccare un più ampio ventaglio di potenziali attacchi.

Una conferma arriva anche da Will Dormann, analista di CERT/CC, e dai tecnici di GTSC. In entrambi i casi si fa presente che il simbolo “@” presente nel bollettino Microsoft introduce una protezione che vale per un caso particolare e per questo motivo è da ritenersi insufficiente.

Gli amministratori che desiderano verificare se i loro server Exchange fossero già stati compromessi utilizzando gli exploit individuati da GTSC possono eseguire il seguente comando PowerShell per scansionare i file di registro IIS alla ricerca di eventuali indicatori:

Get-ChildItem -Recurse -Path <Percorso_Log_IIS> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

Per individuare il percorso contenente i log di IIS si può digitare quanto segue in una finestra PowerShell:

Import-Module -Name WebAdministration (Get-ItemProperty -Path 'IIS:\Sites\Default Web Site' -Name logfile).directory

Microsoft ha pubblicato un bollettino in cui confermano l’esistenza del problema e le informazioni per tutelare i propri sistemi. Ad oggi, però, l’azienda di Redmond non ha ancora rilasciato una patch correttiva.