Come attenuiamo l'inattivazione del codice "AtomBombing" della vulnerabilità non sottoposta a patch in macchine Windows?

Per quanto posso indovinare (non completamente sicuro):

Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

Per prima cosa dobbiamo considerare come funziona Atom Bombing:

Funziona iniettando un codice dannoso nelle tabelle Atom di Windows. Le tabelle Atom sono un tipo di tabelle in cui qualsiasi programma può "salvare" alcune stringhe di dati da utilizzare successivamente o da condividere con qualsiasi altra applicazione.

Quindi dà a qualsiasi potenziale aggressore la possibilità di utilizzare questo metodo come un vettore di dirottamento o di escalation dei privilegi, ma non per un attacco o un'intrusione diretta.

Perché? Bene, a meno che non venga utilizzata un'altra vulnerabilità / bug, le tabelle Atom possono essere modificate solo localmente. Ciò significa: solo quando sei già in, puoi aggiungere qualcosa alle tabelle atom per inserire codice dannoso.

Quindi, ci sono molti modi per sfruttare questa vulnerabilità, MA, quando sei già IN (usando malicious.exe , sfruttando un'altra vulnerabilità per entrare nel sistema e poi usare l'Atomombing per l'escalation dei privilegi, ecc, ecc. ).

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

L'unico modo per il team Microsoft di applicare questa patch sarebbe la rimozione delle tabelle Atom o l'aggiunta di molte misure di sicurezza aggiuntive.

Il modo più semplice per difendersi da questo tipo di minaccia, è controllare tutti i dati dell'atomo salvati prima di usarlo (sui programmi) e / o qualsiasi sistema / programma / modulo di sicurezza dando un'occhiata costantemente a questi Atom Entries.

Il modo per risolvere questo problema è utilizzando un pòece di software che controlla periodicamente le voci della tabella Atom, alla ricerca di codice dannoso. Probabilmente verrà aggiunto da alcune aziende anti-malware (o antivirus).

Puoi controllare quegli articoli per maggiori informazioni:

• Per saperne di più sull'attacco: link
• Per saperne di più su "API" Atom Tables: link

Gli altri commenti dimenticano qualcosa. Un utente malintenzionato può elevare da un contesto non privilegiato (senza diritti di amministratore) in un contesto privilegiato (diritti di amministratore) se viene eseguito in un account che proviene effettivamente da un amministratore. Questo è chiamato UAC Bypass.

L'attacco

Come ci si può aspettare, questo attacco comporta tecniche di iniezione di codice, come AtomBombombing (ma in realtà qualsiasi altro metodo, anche il semplice CreateRemoteThread funzionerà).

Questo viene fatto in 2 passaggi. La prima cosa da fare è, in effetti, iniettare il codice in determinati processi che vengono eseguiti in modalità utente. Ci sono alcuni processi vulnerabili ma parlerò di explorer.exe che è anche il più stabile. Questo processo non è come gli altri, è speciale perché ha molti usi. Ecco perché ha alcuni privilegi speciali. Ad esempio, l'interfaccia COM IFileOperation può essere elevata; Ciò significa che verrà eseguito con una sorta di privilegi di tipo admin. Questo può sembrare inutile, dal momento che puoi solo scrivere file con diritti di amministratore. Ma non lo è! Dal momento che puoi usarlo per eseguire un altro attacco; Dirottamento DLL. Questo è il passo 2. Fondamentalmente si posizionerebbe il evil.dll , che può essere embebed in evil.exe , nello stesso posto in cui si trovano i processi autoelevati; Programmi o processi autoelevati sono programmi che una volta eseguiti otterranno automaticamente i diritti di amministratore. In breve, questo viene fatto da Microsoft poiché quei programmi devono avere quei privilegi per funzionare correttamente ed eseguire cose come attività automatizzate. Infine, eseguiremo quel programma, che caricherà evil.dll e quindi eleveremo automaticamente, quindi concedendo i privilegi di amministratore al codice dell'attaccante.

Mitigazione

Microsoft ha provato a correggere il secondo passaggio in passato, inserendo nella whitelist i file .dll e le tecniche simili, ma non è riuscito, poiché è possibile aggirarlo facilmente sostituendo i file .dll esistenti in alcuni casi.

Il primo passo non verrà affatto corretto. Microsoft non ha applicato patch ad altri metodi di iniezione come CreateRemoteThread, perché dovrebbero correggere Atombring? Ciò richiederebbe un enorme sforzo e pesanti modifiche del sistema operativo, che probabilmente non accadrà. L'unico modo per evitare che questo sarebbe eliminare quei diritti speciali da programmi come l'esploratore, ma sembra che non accadrà nessuno dei due. Quindi in sostanza dipende da AV per rilevare se i programmi dannosi tenteranno di iniettare il codice utilizzando qualsiasi metodo.

Puoi vedere un POC dell'exploit sopra qui

EDIT: ho dimenticato alcuni punti della domanda. Quindi, questi sono i modi tecnici per evitare che gli atroombranti abbiano successo: -Avviso API: una soluzione antivirus può intercettare e analizzare tutti i tentativi di modifica della tabella atom. Le funzioni GlobalAddAtom () e GlobalGetAtomName () sono quelle utilizzate per eseguire questo attacco. Potrebbero intercettare le chiamate e scansionare i dati che verranno aggiunti alla tabella Atom, cercando parole chiave o più probabilmente, cercando di analizzare i dati, se si tratta di uno shellcode.

Una rapida recensione di questo attacco ha fatto clic su questi punti nella mia testa:

Primo punto

La vittima ha per eseguire evil.exe per essere sfruttata. Anche se l'attaccante in qualche modo persuade la vittima a eseguire evil.exe , a causa della natura di questo attacco, evil.exe sarà in grado di iniettare codice solo nei processi in esecuzione nello stesso contesto di sicurezza di evil.exe in esecuzione. Quindi, nessuna escalation di privilegi solo usando questo attacco. (Forse persuadere la vittima ad eseguire evil.exe come amministratore? Non è troppo difficile se la vittima è già persuasa a eseguirla)

Secondo punto

L'iniezione di codice è necessaria perché evil.exe potrebbe essere bloccato da Antivirus a causa di attività sospette. Quindi, il codice viene iniettato in processi legittimi. Ma i browser e le altre applicazioni non sono inclusi nella whitelist degli antivirus. Perché AV dovrebbe avere fiducia in un browser quando la prima fonte di attività nocive è il Web? Solo i processi autorizzati che ho visto sono svchost.exe e altri processi di sistema. Ora, l'attacco richiede un thread alterabile in cui inserire il codice. Ma ottenere un thread modificabile nei processi di sistema (eseguito nel contesto di sicurezza dell'utente) è difficile. Ma di nuovo, non impossibile. Anche l'iniezione di shellcode nei normali processi avrebbe funzionato. Quindi questo attacco è ancora possibile.

Terzo punto

Il cuore di questo attacco è catena ROP . Non ho controllato i dettagli su come la catena ROP è implementata, ma ASLR è ora abilitato su gran parte dei processi.

Mitigazione

Possibile attenuazione che vedo sta installando EMET. EMET monitora anche le funzioni VirtualAlloc di basso livello per possibili ROP. Non ho controllato da solo, ma sono abbastanza sicuro che EMET fermerà la catena ROP di questo attacco.