Vulnerabilità in SMBv3.1.1: dimostrata la possibilità di eseguire codice dannoso

• Windows 10

Vi ricordate la falla di sicurezza scoperta all’inizio di marzo in Windows 10 versioni 1903 e 1909 e in Windows Server versioni 1903 e 1909 (CVE-2020-0796)?
Ne avevamo parlato nel nostro articolo Falla wormable in SMBv3: Microsoft rilascia l’aggiornamento correttivo spiegando che si tratta di un problema legato all’implementazione della più recente versione del protocollo SMB (SMBv3.1.1) che però, in attesa della patch ufficiale distribuita attraverso Windows Update o di un workaround applicabile a livello di registro di sistema, può facilitare l’esecuzione di codice arbitrario in modalità remota.

Il problema di sicurezza, battezzato SMBGhost, è doppiamente pericoloso perché può essere sfruttato per eseguire codice dannoso su un sistema che condivide risorse via SMBv3.1.1 ma anche per provocare il caricamento di codice nocivo lato client persuadendo l’utente a collegarsi con un server SMB malevolo.

Nessuno dei codici proof-of-concept (PoC) presentati fino ad oggi, tuttavia, hanno messo in evidenza una procedura pratica per provocare l’esecuzione di codice in modalità remota.
Ci sono invece appena riusciti i ricercatori di Ricerca Security che hanno pubblicato un video dimostrativo in cui si vede come un aggressore riesca a prendere pieno possesso di una macchina con i servizi SMBv3.1.1 abilitati senza disporre di alcuna credenziale.

A questo indirizzo gli esperti di Ricerca Security hanno illustrato tutti i dettagli tecnici per aggredire una macchina Windows vulnerabile preferendo però non condividere ancora il codice exploit vero e proprio così da non semplificare la vita ai criminali informatici.

Fortunatamente, almeno lato server, è possibile proteggere la macchina non solo applicando la patch ufficiale Microsoft (vedere Falla wormable in SMBv3: Microsoft rilascia l’aggiornamento correttivo) ma anche impedendo via firewall le connessioni sulla porta TCP 445.
Per chi non potesse ancora installare l’aggiornamento correttivo distribuito da Microsoft, resta valido il workaround che consiste nell’aprire una finestra di Windows PowerShell con i diritti amministrativi quindi digitare quanto segue:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

Lo stesso intervento è applicabile da prompt dei comandi (aperto sempre i con i diritti di amministratore):

reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v DisableCompression /t REG_DWORD /d 1 /f