Le vulnerabilità di corruzione della memoria stanno vivendo i loro ultimi giorni? Il futuro delle strategie di sfruttamento

Di Chintan Shah · 24 gennaio 2022

Le moderne tecniche di sfruttamento hanno rivoluzionato il modus operandi dei criminali informatici e i metodi utilizzati dagli esperti di sicurezza per tracciare gli incidenti, dalla vulnerabilità al suo sfruttamento. Negli ultimi dieci anni la priorità è stata rafforzare la sicurezza, sia del sistema operativo che delle applicazioni. Questa strategia ha portato a notevoli progressi nella prevenzione dello sfruttamento. In alcuni casi, questi progressi hanno portato all'eliminazione graduale di intere classi di vulnerabilità del tipo di danneggiamento della memoria. Per esempio, UAF (Use-After-Free) è una classe di vulnerabilità molto comune in grandi basi di codice complesse come i browser Web. È facile da sfruttare. Microsoft ha quindi introdotto novità come l'heap di memoria isolato e il rilascio ritardato di oggetti nel motore del suo browser (mshtml.dll), che interrompe la catena di sfruttamento UAF e costringe i criminali informatici a riconsiderare i propri exploit. La figura 1 di seguito mostra la parte di codice in cui sono state apportate queste modifiche per prevenire le vulnerabilità UAF.

Notare la differenza tra codice protetto e codice non protetto. Sebbene questa sia solo la punta dell'iceberg, sfruttare le vulnerabilità UAF è diventato estremamente difficile, poiché i criminali informatici ora devono tenere conto di precisi limiti di tempo e soglie di memoria specifiche. La figura 2 di seguito è una rappresentazione sintetica delle funzionalità di prevenzione degli exploit della memoria nel sistema operativo Windows introdotte nell'ultimo decennio.

Tuttavia, in molte occasioni, abbiamo constatato che queste protezioni dagli exploit venivano eluse poco dopo la loro introduzione. Il motivo principale era che tutto il codice, incluso il codice dipendente e di terze parti, era incompatibile con queste contromisure o compilato senza che fossero abilitati nel compilatore. Pertanto, la prevenzione degli exploit non è stata applicata a tutte le porzioni di codice o la funzione di prevenzione stessa non è stata completamente implementata. Rimanevano poi vulnerabilità che a loro volta potevano essere sfruttate. Leggendo il diagramma sopra, possiamo notare che l’ASLR non è stato inizialmente implementato nella sua interezza ma gradualmente, lasciando così gran parte del codice esposto a soluzioni alternative.

Vulnerabilità di corruzione della memoria: la fine è vicina?

Sebbene le vulnerabilità di corruzione della memoria rimangano la classe di bug più segnalata, la loro conversione in exploit dannosi è stata complicata negli ultimi anni dall'introduzione di contromisure preventive sia a livello di sistema operativo che di applicazione lato client (per esempio i motori di script). Per trasformare le vulnerabilità di corruzione della memoria in exploit a tutti gli effetti che portano all'esecuzione arbitraria di codice, è necessario violare una moltitudine di protezioni e passare sotto il radar delle misure di protezione o rilevamento delle soluzioni di sicurezza degli endpoint. Al giorno d'oggi, i criminali informatici devono dedicare molto tempo, sforzi e denaro per sperare di aggirare queste contromisure. In molti casi, i criminali informatici sono costretti a sfruttare molteplici vulnerabilità per eseguire un exploit efficace sul sistema di destinazione, il che aumenta i costi di sviluppo e complica ulteriormente lo sfruttamento.

Riteniamo che questa evoluzione nella prevenzione degli exploit giocherà un ruolo cruciale nel determinare quali classi di vulnerabilità saranno favorite in futuro dai criminali informatici. Le vulnerabilità della corruzione della memoria stanno vivendo i loro ultimi giorni? Il dibattito è aperto ed è necessaria una riflessione.

Quale futuro per le strategie di sfruttamento?

Le vulnerabilità di danneggiamento della memoria non scompariranno dalle applicazioni fintanto che le applicazioni contengono codice che gestisce male la memoria. Tuttavia, l'intensità e la frequenza dello sfruttamento di questa classe di vulnerabilità finiranno per diminuire. In passato, abbiamo osservato un gran numero di tecniche di exploit in cui i criminali informatici riescono a eseguire operazioni di lettura/scrittura arbitrarie in memoria sfruttando una falla di corruzione della memoria e utilizzando quella primitiva per modificare determinati contrassegni o dati nella memoria dell'applicazione, provocando l'esecuzione del codice. Questi metodi, chiamati attacchi “data-only”, sono strategie relativamente semplici, comunemente viste in molti exploit. La randomizzazione di alcune posizioni di strutture di dati essenziali nella memoria alla fine ha soppresso questo tipo di attacco nel tempo.

Di fronte ad applicazioni ricche di funzionalità, i criminali informatici preferiranno sempre le strategie più semplici per eseguire del codice sul sistema di destinazione. Esistono ancora sistemi di vecchia generazione esposti a Internet che, non avendo implementato funzioni di prevenzione, sono prede più facili. Devono solo sfruttare funzionalità difettose o difetti di progettazione nell'applicazione o nel protocollo di rete. Immaginiamo che i criminali informatici riescano a trovare la falla nell'applicazione di destinazione e forzino questa o un servizio a connettersi al dispositivo di cui hanno preso il controllo senza sfruttare esplicitamente la memoria: è quindi relativamente più facile eseguire codice da remoto e compromettere il dispositivo di destinazione, poiché la funzionalità del codice arbitrario eseguito dal processo sfruttato è lasciata alla discrezione del criminale informatico. La figura 3 di seguito rappresenta in modo semplificato l'evoluzione delle strategie di sfruttamento negli ultimi anni.

Negli ultimi anni, abbiamo ripetutamente osservato attacchi data-only ed exploit dannosi di funzionalità difettose o falle di progettazione nelle applicazioni. Questi attacchi presentano numerosi vantaggi rispetto ai tradizionali exploit di corruzione della memoria. Siamo convinti che questa debba essere vista come la strategia di sfruttamento di domani, per diversi motivi.

• In primo luogo, questi attacchi sono in grado di aggirare le funzioni di prevenzione poste in essere. I criminali informatici quindi non hanno bisogno di progettare l'exploit specificamente allo scopo di aggirare queste contromisure.
• Poiché il codice arbitrario viene eseguito con i privilegi del processo sfruttato e quindi favorisce l'escalation dei privilegi.
• Gli exploit che sfruttano difetti di progettazione o funzionalità interrotte nell'applicazione non devono manipolare esplicitamente la memoria e considerare i vincoli di spazio prima di sfruttare la vulnerabilità. Non sarà più necessario iniettare shellcode in memoria ed eseguire lo stack pivoting come prima.
• Il funzionamento è molto più semplice, con costi di sviluppo e manutenzione inferiori e in tempi ridotti.

L'analisi retrospettiva delle vulnerabilità critiche degli ultimi due trimestri ci fornisce un indizio accurato di quale forma assumeranno gli attacchi futuri. Nei paragrafi seguenti esamineremo alcune vulnerabilità pericolose e recenti. Analizziamo come funzionalità difettose o falle di progettazione a livello di servizio o applicazione sono stati sfruttati per eseguire codice o sottrarre informazioni sensibili con una resistenza minima.

CVE-2021-44228 – Vulnerabilità nella libreria di registrazione Apache Log4j2 che consente l'esecuzione di codice remoto.

Questa vulnerabilità legata all'esecuzione di codice in modalità remota nella libreria di registrazione Apache Log4j è uno dei difetti più critici segnalati negli ultimi anni. I criminali informatici possono eseguire codice arbitrario sul server vulnerabile che utilizza la libreria di registrazione Log4j per registrare le voci di registro. In un articolo precedente, abbiamo richiamato l'attenzione sul fatto che il software open source è attualmente utilizzato per lo sviluppo del programma e l'importanza di verificarlo. In effetti, la minima vulnerabilità ha conseguenze potenzialmente gravi per il prodotto che la utilizza.

La vulnerabilità in questione risiede nel metodo “Lookup” della classe “jndimanager”. When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. Quest'ultimo può quindi inviare il riferimento JNDI dannoso nella risposta e quindi eseguire il codice arbitrario sul server vulnerabile.

L'esecuzione di codice da remoto è possibile perché Java implementa diversi fornitori di servizi JNDI (Java Naming e Directory Interface) come LDAP, DNS, RMI e CORBA. Era anche possibile caricare classi remote, in base alle proprietà di sistema predefinite.

La vulnerabilità CVE-2021-44228 è un classico esempio di sfruttamento di funzionalità. In questo caso, la funzionalità dirottata era la sostituzione delle ricerche (lookups) che supporta la funzionalità Lookups. Le ricerche o lookups consentono di aggiungere valori alle voci di registro, solitamente nomi di variabili risolti utilizzando una mappa definita o in fase di esecuzione tramite interfacce implementate come le classi StrSubstitutor e StrLookup.

Log4j supporta la sintassi della proprietà "${prefix:name}" in cui il prefisso indica a Log4j di valutare la variabile in un contesto specifico. Il contesto JNDI è integrato in Log4j come mostrato di seguito.

Poiché le ricerche (lookups) JNDI erano abilitate per impostazione predefinita in Log4j versione 2.14.1 e precedenti (vedere la figura 6 sopra), la libreria potrebbe identificare i riferimenti JNDI passati come valore di parametro nelle intestazioni delle richieste HTTP salvate sul server. I criminali informatici potrebbero perciò iniettare riferimenti JNDI dannosi nei parametri della richiesta HTTP e quindi eseguire codice Java in remoto.

CVE-2021-34527 – Vulnerabilità nel servizio Spooler di stampa di Windows che consente l'esecuzione di codice in modalità remota.

Soprannominata PrintNightmare, la vulnerabilità del tipo esecuzione di codice con elevazione dei privilegi in spoolsv.exe è un'altra vulnerabilità critica segnalata lo scorso anno. Illustra perfettamente lo sfruttamento di un difetto di progettazione a livello di protocollo per eseguire un codice arbitrario sul dispositivo preso di mira, senza dover intervenire sulla memoria.

La vulnerabilità è stata sfruttata sui protocolli MS-RPRN (Print System Remote Protocol) e MS-PAR (Print System Asynchronous Remote), effettuando chiamate RPC su SMB. L'exploit sfrutta un classico difetto di progettazione nell'implementazione del componente del server di stampa nel servizio Spooler, quando RPC richiede alle interfacce MS-RPRN e MS-PAR di aggiungere il driver di stampa al sistema di destinazione. La chiamata RPC a RpcAddPrinterDriverEx (MS-RPRN Opnum 89) o RpcAsyncAddPrinterDriver (MS-PAR Opnum 39) richiede il passaggio di una struttura DRIVER_CONTAINER come argomento.

Come si può vedere nei dettagli della struttura sopra, DRIVER_CONTAINER contiene pDriverPath e pConfigFile, che sono il percorso completo del nome del file contenente rispettivamente il driver di stampa e il modulo di configurazione. Il server verifica che i percorsi specificati nelle variabili pDriverPath e pConfigFile non siano in formato UNC per impedire il caricamento di codice arbitrario.

Tuttavia, a causa di un difetto di progettazione o logico del codice, questo controllo del percorso UNC non viene eseguito sulla variabile pDataFile, ovvero il percorso completo del file contenente i dati della stampante. Un criminale informatico può quindi effettuare più chiamate a RpcAddPrinterDriverEx:

1. fornendo al dispositivo di destinazione il percorso UNC della DLL dannosa nella variabile pDataFile. Questa DLL dannosa viene quindi copiata localmente sul dispositivo di destinazione;
2. con la stessa API che integra il nome del file copiato assegnato a pConfigFile (questa volta la DLL dannosa diventa il percorso locale), il che fa sì che il servizio Spooler di stampa carichi il codice dannoso.

CVE-2021-36942 – Vulnerabilità di tipo spoofing dell’identità in Windows LSA che porta alla perdita di credenziali.

La chiamata RPC su SMB è sempre stata il vettore preferito per molti metodi di sfruttamento. Questa vulnerabilità può essere sfruttata dirottando ancora una volta il protocollo MS-EFSRPC utilizzato in Windows per gestire i file su un sistema remoto e crittografato utilizzando l’EFS (Encrypting File System).

Effettuando chiamate RPC specifiche come EfsRpcOpenFileRaw tramite l'interfaccia LSARPC, il criminale informatico può forzare un host Windows ad autenticarsi su un altro server. Il server di destinazione si autenticherà quindi con NTLM su un server controllato da un criminale informatico. Inoltre, è possibile inviare LSARPC utilizzando chiamate RPC senza alcuna autenticazione preventiva. Se questo server di destinazione è Active Directory (AD), l'autore dell'attacco può forzare la connessione di AD al server arbitrario utilizzando l'account macchina per l'autenticazione NTLM. Questo protocollo EFSRPC può essere dirottato per sfruttare in sequenza più vulnerabilità all'interno di una rete aziendale per trasmettere le credenziali NTLM a un server controllato dai criminali informatici, che possono essere utilizzati per eseguire uno spostamento laterale, con una compromissione completa del dominio.

Se il criminale informatico controlla un server Web IIS su cui sono installate le funzionalità AD CS (Active Directory Certificate Services) ed è configurato per utilizzare l'autenticazione NTLM su HTTP, l'autenticazione di Active Directory in IIS comporterà il trasferimento delle credenziali NTLM al criminale informatico, rischiando di compromettere l'intero dominio. Gli attacchi di inoltro NTML non sono una novità. Tuttavia, è consigliabile applicare meccanismi di autenticazione più sicuri, come Kerberos, per evitare il dirottamento di protocolli di questo tipo.

In sintesi, la possibilità di dirottare un protocollo o una funzionalità per forzare una risorsa critica a connettersi al server esterno di un criminale informatico ha gravi conseguenze, come dimostrato dalla vulnerabilità CVE-2021-44228 in Log4j.

CVE-2021-40444 – Vulnerabilità in Windows MSHTML che consente l'esecuzione di codice in modalità remota.

Quest'altra vulnerabilità critica sfruttata l'anno scorso mostra che il semplice sfruttamento dannoso di una funzionalità può essere associato a un difetto logico per generare l'esecuzione di codice arbitrario. Innanzitutto, il sistema OLE (Object Linking and Embedding) è stato utilizzato per collegare il documento all'oggetto OLE esterno. OLE è stato spesso un vettore importante per sfruttare Office per scopi dannosi. Questo sfruttamento ha ancora un brillante futuro davanti a sé, sapendo che è una delle caratteristiche principali del formato di file di Microsoft Office, appositamente progettato per garantire l'interoperabilità.

Grazie ai formati XML aperti di Microsoft Office è possibile incorporare o collegare un documento in oggetti interni o esterni, in particolare l'oggetto OLE esterno specificato tramite relazioni. Nell'exploit presentato di seguito, possiamo vedere il file document.xml.rels con l'attributo Type “oleObject”, l’attributo Target impostato sul link dell'oggetto OLE e TargetMode impostato sull’esterno. Il documento può quindi collegarsi all'oggetto dannoso ospitato esternamente e chiamare i rispettivi gestori di protocollo/risorse per ottenere il suo rendering al fine di sfruttare un potenziale difetto logico o di progettazione nel gestore. Queste sono tipiche tecniche di iniezione di modelli OOXML implementate in molti precedenti exploit OOXML. Abbiamo discusso degli exploit OLE in un articolo precedente.

L'elaborazione del codice HTML avviene in mshtml.dll mentre il controllo di sicurezza del protocollo HTTP e dei download MSHTML avviene in urlmon.dll. La falla di progettazione nel codice urlmon.dll riguardava l'estrazione e la verifica di sicurezza del file CAB scaricato. Questo file CAB è stato scaricato tramite codice JavaScript (JS) integrato nella pagina side.html (vedi figura 11 sopra). In assenza di controlli sull'evasione del percorso di accesso durante l'estrazione del file CAB, l'exploit ha consentito di estrarre il file contenuto nel CAB con il percorso interessato (vedi figura 12 sotto). Ciò causerebbe l'eliminazione del carico utile dannoso all'esterno della directory TEMP creata e ne consentirebbe l'esecuzione.

Conclusioni

Negli ultimi anni abbiamo assistito all'emergere di vulnerabilità come CVE-2021-44228, CVE-2021-34527, CVE-2021-36942 e CVE-2021-40444 sopra descritte, che sfruttano i difetti di elaborazione per dirottare le funzionalità. I difetti di corruzione della memoria hanno ancora un futuro luminoso fintanto che il codice non sicuro rimane in linguaggi di memoria non sicuri diversi da Rust. Possiamo certamente aspettarci in futuro lo sfruttamento di difetti di progettazione o logica e il dirottamento dei protocolli. I clienti e gli sviluppatori di software libero devono essere estremamente vigili. Infatti, sempre alla ricerca di queste vulnerabilità, i criminali informatici possono raggiungere il loro obiettivo, ovvero spostarsi lateralmente nella rete, senza preoccuparsi della difesa in profondità fornita dalle funzioni di prevenzione degli exploit della memoria recentemente sviluppate.