Proprio quando speravi che la settimana si calmasse e ti portasse un po' di tempo di inattività SecOps durante il fine settimana...
…e arriva un nuovissimo buco zero-day in Microsoft Exchange!
Più precisamente, due giorni zero che apparentemente possono essere concatenati, con il primo bug utilizzato in remoto per aprire un buco sufficiente per attivare il secondo bug, che potenzialmente consente l'esecuzione di codice remoto (RCE) sul server Exchange stesso.
Microsoft ha pubblicato rapidamente guida ufficiale su queste vulnerabilità, riassumendo la situazione come segue:
Microsoft sta esaminando due vulnerabilità zero-day segnalate che interessano Microsoft Exchange Server 2013, 2016 e 2019. La prima vulnerabilità, identificata come CVE-2022-41040, è una vulnerabilità Server-Side Request Forgery (SSRF), mentre la seconda, identificata come CVE-2022-41082, consente l'esecuzione di codice in modalità remota (RCE) quando PowerShell è accessibile all'attaccante.
Al momento, Microsoft è a conoscenza di attacchi mirati limitati che utilizzano le due vulnerabilità per entrare nei sistemi degli utenti. In questi attacchi, CVE-2022-41040 può consentire a un utente malintenzionato autenticato di attivare in remoto CVE-2022-41082. Va notato che l'accesso autenticato all'Exchange Server vulnerabile è necessario per sfruttare con successo una delle due vulnerabilità.
Per quanto possiamo vedere, ci sono due lati positivi qui:
- I bug non possono essere attivati da chiunque. Certo, qualsiasi utente remoto che ha già effettuato l'accesso al proprio account di posta elettronica su Internet e il cui computer è stato infettato da malware, in teoria potrebbe sovvertire il proprio account per lanciare un attacco che sfrutti questi bug. Ma avere solo il tuo server Exchange accessibile su Internet non è abbastanza da solo per esporti ad attacchi, perché i cosiddetti invocazione non autenticata di questi bug non è possibile.
- Blocco Comunicazione remota PowerShell può limitare gli attacchi. Secondo Microsoft, il blocco delle porte TCP 5985 e 5986 sul server Exchange limiterà (se non effettivamente impedirà) agli aggressori di concatenarsi dalla prima vulnerabilità alla seconda. Sebbene gli attacchi possano essere possibili senza fare affidamento sull'attivazione dei comandi di PowerShell, i rapporti di intrusione finora sembrano suggerire che l'esecuzione di PowerShell fosse una parte necessaria dell'attacco.
Memorie di ProxyShell
Se questo attacco ti ricorda il Vulnerabilità ProxyShell di circa un anno fa, non sei il solo a pensarlo.
Secondo GTSC, la società di sicurezza informatica vietnamita che per prima indagato e denunciato questi nuovi buchi, ricercatori "richieste di exploit rilevate nei registri IIS con lo stesso formato della vulnerabilità di ProxyShell".
In particolare, il tipo di query di ricerca delle minacce che abbiamo consigliato per l'exploit di ProxyShell, la speleologia nel 2021 sembra funzionare anche per rilevare l'abuso di questi nuovi zero-day:
SELECT grep.* FROM file CROSS JOIN grep ON (grep.path = file.path) WHERE file.path LIKE 'C:inetpublogsLogFilesW3SVC%u_ex210[89]%' AND grep.pattern = 'autodiscover.json'
Anche Microsoft note che "[il rilevamento che abbiamo] creato in risposta a ProxyShell può essere utilizzato per le query poiché esistono somiglianze in funzione con questa minaccia".
Naturalmente, non sappiamo ancora se il nuovo attacco possa essere portato a termine senza lasciare questo specifico segno rivelatore nei tuoi registri.
In altre parole, se trovi segnali di attivazione simili a quelli lasciati dagli exploit di PowerShell, probabilmente hai prove di un attacco, ma l'assenza di questi segni non è una prova di assenza.
Secondo GTSC, negli attacchi su cui hanno indagato finora, i criminali informatici hanno utilizzato i loro poteri RCE non autorizzati per impiantare ed eseguire una serie di malware successivi, tra cui:
- Webshell impiantate per aprire una backdoor basata sul Web per dopo. Le Webshell in genere consentono agli attacchi successivi di incorporare comandi di sistema arbitrari, con argomenti di comando arbitrari, in richieste HTTP dall'aspetto regolare. Il webshell quindi esegue direttamente il comando desiderato con i privilegi del server web stesso.
- Malware di dumping delle credenziali. I ladri di credenziali in genere curiosano nel disco e nella memoria (se hanno privilegi sufficienti) alla ricerca di password in chiaro, cookies di sessione e token di autenticazione che potrebbero consentire ciò che è noto come movimento laterale ad altri computer della rete.
- Malware zombie sotto forma di DLL caricate in processi dall'aspetto legittimo. Un campione di DLL analizzato dai ricercatori GTSC potrebbe essere alimentato in remoto con istruzioni crittografate per eseguire il dump delle informazioni di sistema, eseguire comandi arbitrari, avviare moduli C# e modificare file e cartelle sul sistema infetto.
Aggiorneremo questo articolo man mano che impariamo di più, inclusa la segnalazione quando Microsoft ottiene patch per chiudere questi buchi.
Consigli per la caccia alle minacce
Per i consigli sulla caccia alle minacce di GTSC, che ha scoperto e segnalato i bug, di Microsoft e di Sophos, vedere:
Cosa fare?
Le mitigazioni includono:
- Bloccare Comunicazione remota PowerShell per ridurre il rischio di RCE. Come accennato in precedenza, il blocco delle porte TCP 5985 e 5986 limiterà gli attacchi al server Exchange, secondo Microsoft.
- Utilizzare Regola di riscrittura dell'URL per bloccare i trigger di attacco noti. GTSC e Microsoft forniscono spiegazioni su come utilizzare le regole di riscrittura degli URL del server IIS per rilevare e neutralizzare le forme comuni di questo attacco.
- Assicurati che il rilevamento comportamentale delle minacce agli endpoint sia abilitato, anche sui server. Come accennato in precedenza, GTSC riferisce che gli attacchi visti finora includono l'impianto di webshell e DLL malware per eseguire comandi arbitrari, manipolare file ed estrarre informazioni di sistema. Questo ti offre numerosi potenziali indicatori di rilevamento e risposta per superare un attacco riuscito.
- Prendi in considerazione la rimozione dell'autenticazione degli utenti di posta elettronica che hanno effettuato l'accesso. Se puoi eseguire una sorta di valutazione della sicurezza degli endpoint sul dispositivo di ciascun utente prima di consentire loro di riautenticarsi, ridurrai (sebbene non eliminerai) il rischio che i dispositivi già compromessi vengano cooptati nel lancio di attacchi. Ridurrai anche ciò che è noto come il tuo totale superficie di attacco non avendo utenti autenticati in giro che non hanno bisogno di essere registrati o che non si ricordano nemmeno di aver mai effettuato l'accesso in primo luogo.
- Applicare eventuali patch non appena sono disponibili. Finora sono stati segnalati solo attacchi limitati, per lo più nel sud-est asiatico, e GTSC sta deliberatamente nascondendo i dettagli delle vulnerabilità fino all'eliminazione delle patch. Ma ricorda che una volta pubblicate le patch, i criminali informatici inizieranno immediatamente a lavorare a ritroso verso exploit funzionanti nella speranza di catturare coloro che sono in ritardo nell'applicazione degli aggiornamenti.
Finora [2022-09-30T13:30Z], sembra che le cose più importanti da tenere a mente siano: [a] i suggerimenti e le tecniche che hai imparato per dare la caccia agli attacchi ProxyShell saranno quasi sicuramente utili qui, se non gli unici strumenti di cui potresti aver bisogno; [b] nonostante le somiglianze (e nonostante tutto ciò che potresti aver visto online), questo non stiano ProxyShell, quindi le tue patch ProxyShell non ti proteggeranno da esso; e [c] quando arrivano le patch, presupponiamo che saranno reingegnerizzato in modo inverso per far funzionare gli exploit molto rapidamente, quindi non tardare ad applicarle.
SCOPRI DI PIÙ SULLE WEBSHELL E COME PREVENIRLE
