Gli zero-day sono vulnerabilità di sicurezza non note agli sviluppatori che vengono già sfruttate da parte dei criminali informatici 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. Come spiegano i ricercatori in quest’analisi, gli aggressori stanno già usando due exploit fino ad oggi 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. 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.
Nel campo Pattern si deve quindi inserire .*autodiscover\.json.*\@.*Powershell.*, scegliere Regular expression e in Condition input (finestra Edition condition) impostare {REQUEST_URI}.
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’