Come hackerare un server Exchange senza patch con codice PowerShell canaglia

Poco meno di due mesi fa, sono arrivate alcune preoccupanti notizie sui bug: un paio di vulnerabilità zero-day sono state annunciate in Microsoft Exchange.

Come abbiamo consigliato a suo tempo, queste vulnerabilità, designate ufficialmente CVE-2022-41040 ed CVE-2022-41082:

[erano] due giorni zero che [potrebbero] essere concatenati insieme, 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.

La prima vulnerabilità ricordava il fastidioso e ampiamente abusato Buco di sicurezza di ProxyShell dall'agosto 2021, perché si basava su un comportamento pericoloso nella funzione di individuazione automatica di Exchange, descritto da Microsoft come un protocollo che è "utilizzato dai client Outlook ed EAS [Exchange ActiveSync] per trovare e connettersi alle caselle di posta in Exchange".

Fortunatamente, la funzionalità errata di individuazione automatica che poteva essere sfruttata nell'attacco ProxyShell da qualsiasi utente remoto, connesso o meno, era rattoppato più di un anno fa.

Sfortunatamente, le patch ProxyShell non hanno fatto abbastanza per chiudere l'exploit agli utenti autenticati, portando al nuovo zero-day CVE-2022-40140, che è stato presto laconicamente, anche se fuorviante, soprannominato ProxyNotShell.

Non così pericoloso, ma comunque pericoloso

Chiaramente, ProxyNotShell non era neanche lontanamente pericoloso come il ProxyShell originale, dato che richiedeva quello che è noto come accesso autenticato, quindi non era soggetto ad abusi da parte di chiunque da qualsiasi luogo.

Ma è rapidamente emerso che su molti server Exchange, conoscere il nome di accesso e la password di qualsiasi utente sarebbe stato sufficiente per passare come autenticato e lanciare questo attacco, anche se quell'utente stesso avrebbe dovuto utilizzare l'autenticazione a due fattori (2FA) per accedere correttamente per accedere la loro e-mail.

Come l'esperto di Sophos Chester Wisniewski metterlo al tempo:

È una "vulnerabilità di autenticazione intermedia", se così si vuole chiamare. Questa è una benedizione mista. Significa che uno script Python automatizzato non può semplicemente scansionare l'intera Internet e potenzialmente sfruttare ogni server Exchange nel mondo in pochi minuti o ore, come abbiamo visto accadere con ProxyLogon e ProxyShell nel 2021. […]

Hai bisogno di una password, ma trovare una combinazione di indirizzo e-mail e password valida su un dato server Exchange probabilmente non è troppo difficile, sfortunatamente. E potresti non essere stato sfruttato fino ad oggi, perché per accedere correttamente a Outlook Web Access [OWA] è necessario il loro token FIDO, o il loro autenticatore, o qualsiasi altro fattore che potresti utilizzare.

Ma questo attacco non richiede quel secondo fattore. […] La semplice acquisizione di una combinazione di nome utente e password è una barriera piuttosto bassa.

Come probabilmente ricorderete, molti di noi presumevano (o almeno speravano) che Microsoft si sarebbe affrettata a risolvere i buchi di ProxyNotShell, dato che mancavano ancora due settimane al Patch Tuesday di ottobre.

Ma siamo rimasti delusi nello scoprire che apparentemente c'era una soluzione affidabile più complesso del previsto, e ottobre andava e veniva con ProxyNotShell risolto solo da soluzioni alternative, non da patch appropriate.

Anche il Patch Tuesday di novembre non ha fornito direttamente le correzioni necessarie, nonostante le patch comunque è uscito lo stesso giorno come parte di un aggiornamento della sicurezza specifico di Exchange che può essere recuperato e installato separatamente:

Proof-of-concept rivelato

Ora che il polverone si è calmato e tutti hanno avuto il tempo di applicare patch ai propri server Exchange (quelli di cui non si sono dimenticati, almeno), i ricercatori della Zero Day Initiative (ZDI), a cui queste vulnerabilità sono state originariamente responsabilmente divulgate per essere sottoposte a Microsoft, ho spiegato come i bug possono essere sfruttati.

La cattiva notizia, a seconda della tua opinione sulle rivelazioni esplicite di exploit, è che il team ZDI ha ora effettivamente fornito una prova di concetto (PoC) che spiega come attaccare i server Exchange.

La buona notizia, ovviamente, è che:

• Ora possiamo studiare e comprendere noi stessi i bug. Questo non solo aiuta tutti noi a garantire che le precauzioni generali che abbiamo preso (non solo limitate all'applicazione di patch) possano fornire la protezione che ci aspettiamo, ma ci informa anche sulle pratiche di programmazione che vorremmo evitare in futuro, quindi non non rimanere intrappolati nell'aprire bug di questo tipo nel nostro codice lato server.
• Ora non abbiamo più scuse per non applicare le patch. Se abbiamo trascinato i piedi sull'aggiornamento, la spiegazione di ZDI sul motivo per cui l'attacco funziona chiarisce che la cura è decisamente preferibile alla malattia.

Come funziona

ZDI spiegazione di questa vulnerabilità crea un racconto affascinante di quanto possa essere complesso concatenare tutte le parti necessarie per trasformare una vulnerabilità in un exploit praticabile.

Vale anche la pena leggere per aiutarti a capire perché scavare in un exploit esistente può aiutare a rivelare altri modi in cui una vulnerabilità potrebbe essere utilizzata in modo improprio, richiedendo potenzialmente patch aggiuntive, sollecitando modifiche alla configurazione e promuovendo nuove pratiche di programmazione che potrebbero non essere state ovvie solo risolvendo il foro originario.

La spiegazione è, per necessità, complicata e abbastanza tecnica, e ti guida attraverso una lunga serie di passaggi per raggiungere l'esecuzione di codice remoto (RCE) alla fine.

Nella speranza di aiutarti a seguire più facilmente i dettagli di alto livello se decidi di leggere il rapporto ZDI, ecco un riepilogo, si spera, non troppo semplificato con i passaggi elencati al contrario...

…quindi saprai in anticipo perché la storia prende le direzioni che prende:

• PASSAGGIO 4. Indurre Exchange in remoto a istanziare un oggetto .NET di tua scelta, con un parametro di inizializzazione a tua scelta.

Nella codifica moderna, an oggetto istanziato è la parola in gergo per un pezzo di memoria allocato, inizializzato automaticamente con i dati e le risorse di cui avrà bisogno mentre è in uso e legato a un insieme specifico di funzioni che possono operare su di esso. (Istanziare è solo una parola di fantasia per creare.)

Gli oggetti possono essere gestiti e controllati dal sistema operativo stesso, per aiutare a evitare il tipo di errori di cattiva gestione della memoria comuni in un linguaggio come C, dove in genere è necessario allocare la memoria da soli, riempire manualmente i campi dati pertinenti e ricordarsi di rilascia la memoria e le risorse che stai utilizzando, come socket di rete o file su disco, quando hai finito.

Gli oggetti generalmente hanno una funzione programmatica ad essi associata chiamata a costruttore, che viene eseguito automaticamente quando viene creato un nuovo oggetto per allocare la giusta quantità di memoria e il corretto set di risorse di sistema.

Di solito, è necessario passare uno o più parametri come argomenti al costruttore, per indicare come si desidera configurare l'oggetto all'avvio.

In poche parole, se si istanzia, ad esempio, a TextString oggetto (stiamo inventando questi nomi, ma hai capito) usando un parametro che è esso stesso una stringa di testo come example.com:8888...

... probabilmente ti ritroverai con un buffer di memoria allocato per contenere il tuo testo, inizializzato in modo che contenga lo stesso valore che hai passato, vale a dire il testo non elaborato example.com:8888.

In tale contesto, la stringa di testo passata come dati al costruttore di oggetti non pone immediatamente alcuna evidente minaccia alla sicurezza informatica quando si attiva il costruttore da remoto, a parte un possibile Denial of Service (DoS) chiedendo ripetutamente stringhe sempre più grandi a cercare di esaurire la memoria.

Ma se dovessi istanziare, diciamo, a ConnectedTCPClient oggetto utilizzando lo stesso parametro di stringa di testo di example.com:8888, potresti ritrovarti con un buffer di memoria pronto a contenere dati temporanei, insieme a un socket di rete allocato dal sistema operativo pronto a scambiare dati con il server example.com su porta TCP 8888.

Puoi vedere il rischio di esecuzione di codice remoto lì, anche se non riesci mai a inviare dati al socket aperto, dato che hai indotto il server a chiamare casa in una posizione che controlli.

Potresti persino trovare un oggetto chiamato, ad esempio, RunCmdAndReadOutput, dove la stringa di testo che invii come parametro è, letteralmente, un comando che desideri eseguire automaticamente non appena l'oggetto viene creato, in modo da poterne raccogliere l'output in un secondo momento.

Anche se non riuscissi mai a recuperare l'output del comando, la semplice istanziazione di un oggetto di questo tipo ti consentirebbe comunque di scegliere un comando da eseguire, offrendoti così l'esecuzione di codice remoto generico e presentando un rischio limitato solo dai diritti di accesso del processo del server stesso .

Ovviamente, l'attacco è così facile solo una volta che si arriva all'ultima fase, cosa che non si dovrebbe essere in grado di fare, perché Exchange ha una rigorosa lista consentita che impedisce di scegliere qualsiasi vecchio oggetto da istanziare.

In teoria, solo gli oggetti sicuri o a basso rischio possono essere creati in remoto tramite PowerShell, in modo che istanziando il nostro immaginario TextString sopra, o a SimpleIntegerValue, potrebbe essere considerato accettabile, mentre a ConnectedTCPClient o RunCmdAndReadOutput sicuramente non lo sarebbe.

Ma i ricercatori ZDI notano che prima di attivare l'ultimo passaggio, potevano fare questo:

• PASSAGGIO 3. Indurre Exchange in remoto a pensare che un oggetto a basso rischio che ha superato il test di sicurezza sia, in realtà, un altro oggetto di tua scelta.

Ciononostante, ci si potrebbe aspettare che Exchange impedisca la creazione remota anche di oggetti a basso rischio, per ridurre ulteriormente la minaccia.

Ma i ricercatori hanno scoperto che potevano:

• PASSAGGIO 2. Indurre Exchange da remoto a utilizzare il suo Comunicazione remota PowerShell funzionalità per creare un oggetto basato su parametri di inizializzazione controllati esternamente.

E questo è stato possibile grazie al buco simile a ProxyShell che era solo parzialmente rattoppato:

• PASSAGGIO 1. Indurre Exchange in remoto ad accettare ed elaborare una richiesta Web con codice inserendo un codice valido username:password anche il campo nella richiesta.

Anche se l'utente indicato nella richiesta non era effettivamente connesso e avrebbe dovuto eseguire una sorta di processo 2FA per accedere alla propria casella di posta, un utente malintenzionato che conosceva il proprio username:password combinazione avrebbe informazioni di autenticazione sufficienti per indurre Exchange ad accettare una connessione Web che potrebbe essere utilizzata per avviare la catena di attacco descritta nei passaggi da 2 a 4 sopra.

In parole povere, qualsiasi valido username:password la combinazione andrebbe bene, dato che l'"autenticazione" era necessaria semplicemente per impedire a Exchange di rifiutare la richiesta HTTP in anticipo.

Cosa fare?

Nota che questo attacco funziona solo:

• Se disponi di server Exchange locali. Microsoft afferma di aver bloccato rapidamente i propri servizi cloud, quindi Exchange Online non è interessato. Accertati di sapere dove si trovano i tuoi server Exchange. Anche se ora utilizzi Exchange Online, potresti avere ancora server locali in esecuzione, forse lasciati per errore dal processo di migrazione.
• Se i tuoi server non hanno patch. Assicurarsi di avere applicato l'aggiornamento del software Exchange del 2022-11-08 a chiudere le vulnerabilità che l'exploit richiede.
• Se i tuoi server accettano ancora l'autenticazione di base, nota anche come autenticazione legacy. Assicurarsi di avere bloccato tutti gli aspetti dell'autenticazione legacy quindi i tuoi server non accetteranno il file username:password intestazioni sopra menzionate e non accetterà richieste rischiose del protocollo di individuazione automatica in primo luogo. Questo ferma gli aggressori indurre un server ad accettare i loro trucchi di istanziazione di oggetti con trappola esplosiva, anche se quel server non è patchato.

Puoi tenere traccia dei nostri consigli ufficiali di prevenzione, correzione e risposta, e i clienti Sophos possono tenere traccia dei nomi di rilevamento delle minacce utilizzati dai nostri prodotti, tramite il feed Twitter di Sophos X-Ops (@SophosXOps).

Sono state pubblicate nuove informazioni relative a CVE-2022-41040 e CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 Novembre 2022

---

ULTERIORI INFORMAZIONI SU EXCHANGE AUTHENTICATION E OAUTH2

Con Paul Ducklin e Chester Wisniewski
Musica introduttiva e finale di Edith Mudge.

---