[Ufficiale] 2a Revisione: Behavior Blocker

Moderators: forart, Davy Bartoloni, gabrielilardi

Post Reply
PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

[Ufficiale] 2a Revisione: Behavior Blocker

Post by PUOjACKz »

Qui di seguito, ora come ora, provvedo nell'inserire il 2° listato ufficiale del Behavior Blocker, in modo da facilitarne la discussione. Dall'idea precedente, son state inserite delle novità. Prima della 3a revisione, verrà inserità anche una feature riguardo il controllo di autenticazione delle DLL.

Il Behavior Blocker deve:

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo
* poter essere attivato o disattivato, in un sistema, anche limitando il suo funzionamento ad alcuni utenti
* identificare quando i programmi tentano di agire nell'utilità di pianificazione
* identificare quando i programmi aggiungono dei files nelle cartelle di auto-esecuzione all'avvio (es Esecuzione Automatica)
* HIPS (Host Intrusion Prevention System), contro Code Injection, DLL Injection, Traffico UPnP Sospetto e Buffer Overflow

Opzioni Specifiche

Per lo switch, legato all'autoaccensione del behavior blocker (il quale, presumo, sarà un servizio di sistema), è buona cosa far interagire le opzioni dell'area del pannello, con l'ipotetica area Servizi del Management Console di ReactOS (come Windows). In particolare, è bene porre degli elementi per l'accensione manuale, lo spegnimento manuale e la disposizione se avviare tale servizio, durante il LogOn.
Ah, è bene tener in considerazione una cosa: Tale funzione NON deve poter essere killata, nè, in caso di crash, rimanere spenta, se nel pannello, sia manualmente, che automaticamente, risulta avviata.
Tale fattore, in quanto, se il processo và a farsi benedire, dopo un crash, un qualsiasi malware può generare un attacco DoS apposito, al fine di spegnere il Behavior Blocker.

Es.

1) Il programma maligno, viene avviato dall'utente
2) Il programma maligno causa un iniezione di codice anomalo, che conduce, il sistema, nel crashare alcuni moduli
3) Il Behavior Blocker rimane spento (mentre il malware è acceso)
4) Il Malware fà bisboccia nel sistema e la sicurezza è andata a quel paese (senza affrancatura, nè biglietto di viaggio)

Opzioni

Personalmente, ha poco senso slegare queste 3 opzioni:

Code: Select all

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
Sono la base del Behavior Blocker. Se si disattiva anche una sola di queste 3, è abbastanza inutile tener acceso il resto.

Code: Select all

* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
Questo, in riferimento ad un discorso futuro, può essere disattivato, come opzione dell'utility, in quanto, sarebbe, alla fin fine, una semplice segnalazione, all'utente, per scopo informativo. Certo ha la sua gravità, ma questa è circoscritta solo in particolari ambiti.

Code: Select all

* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo
Questa parte, non dev'essere collegata ad alcun switch. E' bene che l'utente si legga, OGNI VOLTA, cosa significhi attivare un programma, in modo che, magari, gli entri in testa di non fare sciocchezze. Come si diceva una volta? Repetita Juvant?

Frasi, ipotetiche, che possono essere inserite, come descrizione, in caso di Popup possono essere:

Per l'avvio di un programma:

Code: Select all

Avvio di un File Eseguibile

E' stato avviato il programma: $NomeProgrammaDaEseguire

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi).
Per la sostituzione di un applicazione:

Code: Select all

Sostituzione di un File Eseguibile

E' stato identificato un tentativo di sostituzione del programma: $NomeProgrammaSostituito

E' consigliato permette la sostituzione, solo se l'operazione è stata compiuta volontariamente e consapevolmente. In caso contrario, si consiglia di vietare tale attività, onde evitare la possibile sostituzione del file, con una versione contenente codice malfunzionante o pericoloso.
Per l'avvio di un applicazione, richiamata da un'altra applicazione:

Code: Select all

Esecuzione Nidificata

Il programma: $NomeProgrammaRichiamante
Ha tentato di eseguire il programma: $NomeProgrammaRichiamato

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi). 
Per la ricezione di un tentativo di autoaccensione, tramite la configurazione dell'utilità di pianificazione di sistema:

Code: Select all

Tentativo d'Interazione con l'Utilità di Pianificazione

Il File Eseguibile: $NomeFile
Ha tentato di apportare delle modifiche all'utilità di pianificazione di sistema: $Aggiunta/$Modifica/$Cancellazione $InformazioneCoinvolta

E' consigliato permettere tale operazione, solo se il file è sicuro. In caso contrario, si consiglia di vietare la configurazione di tale impostazione, onde evitare l'esecuzione di programmi che potrebbero ridurre la sicurezza o la stabilità di sistema, ed, in certi casi, anche comportando una perdita di dati. Inoltre, altri applicativi leciti, potrebbero non funzionare più in modo corretto.
Per la ricezione di un tentativo di autoaccensione, tramite l'inserimento di collegamenti nelle cartelle di auto-esecuzione di sistema:

Code: Select all

Tentativo d'Interazione con l'Utilità di Esecuzione Automatica

Il programma: $NomeProgrammaRichiamante
Ha tentato di apportare delle modifiche all'utilità di esecuzione automatica: $Aggiunta/$Modifica/$Cancellazione $InformazioneCoinvolta

E' consigliato permetterne l'esecuzione, solo se tale sollecitazione è volontaria e consapevole. In caso contrario, si consiglia di vietare tale comportamento, onde evitare l'avvio di operazioni che potrebbero causare effetti indesiderati (a volte anche gravi).  Inoltre, altri applicativi leciti, potrebbero non funzionare più in modo corretto. 
Per la ricezione di un tentativo di Code Injection (identificato dall'HIPS):

Code: Select all

Tentativo di Code Injection

Il programma: $PathENomeProgrammaRichiamante
Ha effettuato un tentativo d'intrusione, via Code Injection.
Injection avvenuta presso: $AreadellInjection
Applicazione colpita: $PathENomeProgrammaColpito ($Descrizione [$Versione])

Il Behavior Blocker ha identificato e bloccato un operazione considerata sospetta, in quanto non utilizzata, come prassi, dai programmi legittimi, bensì dai malware, al fine di permettere l'esecuzione, nel sistema, di codice maligno e pericoloso. Solitamente, gli applicativi sicuri non impiegano questo genere di attività, durante il loro funzionamento. 
Bloccare questo genere di operazioni aumenta la protezione globale dell'ambiente operativo, in quanto, un attaccante non può sfruttare la tecnica di Code Injection per compiere danni (sia per metodi conosciuti che sconosciuti).
Per la ricezione di un tentativo di Application Hijacking (identificato dall'HIPS):

Code: Select all

Tentativo di Program HiJacking

Il programma: $PathENomeProgrammaRichiamante
Ha effettuato un tentativo d'Application Hijacking.
Applicazione colpita: $PathENomeProgrammaColpito ($Descrizione [$Versione])

Il Behavior Blocker ha identificato e bloccato un operazione considerata sospetta, in quanto non utilizzata, come prassi, dai programmi legittimi, bensì dai malware, al fine di permettere l'esecuzione, nel sistema, di codice maligno e pericoloso. Solitamente, gli applicativi sicuri non impiegano questo genere di attività, durante il loro funzionamento. 
Bloccare questo genere di operazioni aumenta la protezione globale dell'ambiente operativo, in quanto, un attaccante non può sfruttare la tecnica d'Application Hijacking per compiere danni (sia per metodi conosciuti che sconosciuti).
/* L'Application HiJacking avviene quando un programma maligno tenta di intercettare e manipolare i dati e i comandi in comunicazione tra DLL e Windows Hooks, nelle applicazione avviate in Windows */

Per la ricezione di Traffico UPnP Sospetto (identificato dall'HIPS):

Code: Select all

Traffico UPnP Sospetto Identificato

Il Dispositivo/Applicativo: $PathENomeProgrammaRichiamante
Ha effettuato del Traffico UPnP Sospetto.

Il Behavior Blocker ha identificato e bloccato un operazione considerata sospetta, in quanto può essere la causa di 3 pericolose vulnerabilità di sicurezza, nel sistema: Priviledge Escalation, DoS contro il sistema locale e DDoS contro un sistema esterno. Bloccare questo genere di traffico, se non sollecitato volontariamente, aumenta la protezione globale dell'ambiente operativo, in quanto, un attaccante non può sfruttare il protocollo UPnP per compiere danni.
Qualora il dispositivo, o il programma, sia lecito, si utilizzi la funzione di assegnazione del permesso di comunicazione.
/* Il controllo del traffico UPnP Sospetto tende ad arginare 3 vulnerabilità pericolose, presenti nel protocollo UPnP: 1) L'attaccante può ottenere il completo controllo nel sistema; 2) L'attaccante può causare un attacco DoS, contro il sistema, bloccando la fornitura dei servizi attivi, agli utenti legittimi; 3) L'attaccante può sfruttare i box di più utenti per causare un attacco DDoS. Con tale blocco di sicurezza, i dispositivi o i programmi che necessitano dell'impiego del protocollo UPnP, devono essere specificati */

Per la ricezione di un tentativo di Buffer Overflow (identificato dall'HIPS):

Code: Select all

Tentativo di Buffer Overflow

Il programma: $PathENomeProgrammaRichiamante
Ha effettuato un tentativo d'intrusione, via Buffer Overflow.
Overflow avvenuto presso: $AreadellInjection
Applicazione colpita: $PathENomeProgrammaColpito ($Descrizione [$Versione])

Il Behavior Blocker ha identificato e bloccato un operazione considerata sospetta, in quanto non utilizzata, come prassi, dai programmi legittimi, bensì dai malware, al fine di permettere l'esecuzione, nel sistema, di codice maligno e pericoloso. Solitamente, gli applicativi sicuri non impiegano questo genere di attività, durante il loro funzionamento. 
Bloccare questo genere di operazioni rafforza la protezione globale dell'ambiente operativo, in quanto, un attaccante non può sfruttare la tecnica di Buffer Overflow per compiere danni (sia per metodi conosciuti che sconosciuti).
Ovviamente, eventuali informazioni sui possibili rischi, è bene fornirli, premendo un pulsante di Help (diversificando di caso in caso), magari, cercando di non spaventare l'utente, in quanto, se effettivamente, il programma è maligno, è bene, in quei casi, mantenere la calma (fattore impossibile, se si viene bombardati da messaggi intimidatori e pieni di paroloni catastrofici e apocalitici, come su Windows).

Nel corpo del popup, bene in vista, inserire un pulsante decisionale per permettere tale esecuzione, un altro per vietarla, un checkbox per rendere permanente tale decisione, un altro se si vuole loggare tale attività in un file, ed un altro ancora se si vuole essere avvisati di tale esecuzione.

Inoltre, un buon consiglio è quello d'introdurre un eventuale switch per visualizzare eventuali informazioni aggiuntive specifiche ed esaustive (da includere in caso di logging), tra cui (alla rinfusa):

Code: Select all

Path Eseguibile Avviato: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Sostituito: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Richiamante: $Drive\$Path\$EseguibileConNomeEdEstensione
Path Eseguibile Richiamato: $Drive\$Path\$EseguibileConNomeEdEstensione
Path File Sospettato: $Drive\$Path\$FileConNomeEdEstensione (usato per le attività d'interazione sospetta)
Descrizione: $DescrizioneDell'Eseguibile
Versione Del File: $Versione ($BuildEdAltreInfo)
Esecuzione Nidificata Richiesta: $DataEOraDelRichiamo
File Richiamante Creato: $DataEOraDiCreazione
File Richiamante Modificato: $DataEOraDiModifica
Ultimo Accesso al File Richiamante: $DataEOraUltimoAccesso 
File Richiamato Creato: $DataEOraDiCreazione
File Richiamato Modificato: $DataEOraDiModifica
Ultimo Accesso al File Richiamato: $DataEOraUltimoAccesso 
File Controllato Dall'AntiVirus/Engine Euristico di Sistema: $Sì/$No ($SoloDall'EngineEuristico/$SoloDall'AntiVirus/$DaEntrambi)
Ultimo Controllo del File: $DataEOraUltimoControllo
File Considerato Sicuro: $Sì/$No ($SoloDall'EngineEuristico/$SoloDall'AntiVirus/$DaEntrambi)
N.B: I valori $Valore, li ho messi, all'incirca, per spiegare cosa c'andrebbe messo.

Nel pannello di gestione delle opzioni del Behavior Blocker, direi, inoltre, di aggiungere delle voci per diversificare il comportamento automatico dell'utilità, al manifestarsi di certe operazioni.

Per l'Accensione dei programmi:

- Avviare l'applicazione, senza richiedere l'intervento dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se questa è negata, non avviare nulla, altrimenti, eseguire l'applicazione senza richiedere l'interazione dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se questa è permessa, avviare il programma, altrimenti, bloccare l'applicazione senza richiedere l'interazione dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se non è presente, richiedere l'intervento decisionale dell'utente
- Bloccare l'applicazione, senza richiedere l'intervento dell'utente

Come Switch specifici:

- Avviare l'applicazione solo se è stata controllata da almeno uno dei due dispositivi di sicurezza (o Engine Euristico o Antivirus) ed è considerata sicura
- Avviare l'applicazione solo se è stata controllata da tutti e due i dispositivi di sicurezza (Engine Euristico e Antivirus) ed è considerata sicura
- Avviare l'applicazione anche se non è stata sottoposta al controllo di almeno uno dei due dispositivi di sicurezza
- Avviare l'applicazione anche se non è considerata sicura

E' bene, inserire una breve descrizione ed un pulsante di Help, per l'utente, in modo da poter conoscere, con esattezza cosa comportano le seguenti funzioni, i pro e i contro.

Per il Buffer Overflow, Application HiJacking, Suspicious UPnP Traffic & Code Injection

- Protezione contro il Buffer Overflow (con Lista Eccezioni)
- Protezione contro il Code Injection (con Lista Eccezioni)
- Protezione contro il Traffico UPnP Sospetto (con Lista Eccezioni)
- Protezione contro l'Application HiJacking (con Lista Eccezioni)
- Registrazione dell'Evento Buffer Overflow
- Registrazione dell'Evento Code Injection
- Registrazione dell'Evento Traffico UPnP Sospetto
- Registrazione dell'Evento Application HiJacking
- Bloccare il Buffer Overflow tacitamente
- Bloccare il Code Injection tacitamente
- Bloccare il Traffico UPnP Sospetto tacitamente
- Bloccare l'Application HiJacking tacitamente

Per il Monitoraggio & L'avviso

- Aggiornare il file log, con l'esecuzione del programma (da consigliare solo per certi programmi sospetti)
- Avvertire, l'utente, dell'avvenuta esecuzione del programma (da consigliare solo per certi programmi sospetti)

Allo stesso modo, deve funzionare l'opzione di gestione della Sostituzione delle applicazioni, così come quella dell'Esecuzione Nidificata.

Per i programmi che tentano di interagire con le utilità di pianificazione e auto-esecuzione, occorre aggiungere, inoltre, altre opzioni (oltre alle precedenti), da qualche parte, nella configurazione dei programmi, oppure, in quella generica:

- Permettere la modifica arbitraria delle entry presenti
- Permettere solo l'aggiunta (per quei programmi che necessitano di essere eseguiti periodicamente, ma che non devono combinare casino nella lista, mettendo le mani dove non devono)
- Permettere solo la modifica delle proprie entry (per quei programmi che permettono, all'utente, l'impostazione di eventuali attività pianificate o auto-esecuzioni, dalla loro interfaccia GUI, configurando, per loro, i parametri appropriati nell'utilità)
- Permettere la modifica di tutte le entry presenti (per quei programmi di gestione dell'utilità di pianificazione, con, ad esempio, un interfaccia più semplice)
- Permettere solo la cancellazione della propria entry (per quei programmi che rimuovono le loro entry, durante la disinstallazione)
- Permettere la cancellazione di tutte le entry (per quei programmi, di sicurezza, che monitorano l'eventuale presenza di entry legate a malware conosciuti)

Ovviamente, per la questione relativa all'ipotetico SandBox, che avrà anche funzioni di salvaguardia del sistema, per l'esecuzione di programmi poco sicuri, occorrerà sostenere un discorso apparte, più specifico.
Inoltre, è buona cosa includere la presenza attiva del Behavior Blocker, come configurazione di sicurezza nei profili degli utenti, in modo che, ad esempio, un utente possa decidere se accenderlo, oppure no. Altrimenti, l'admin può decidere se forzare l'attivazione, al LogOn, di tale tool, impedendo, all'utente, di spegnerlo ecc.
Last edited by PUOjACKz on Thu Feb 09, 2006 2:20 am, edited 2 times in total.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Personalmente, sono leggermente indeciso per via della funzione contro i Buffer Overflow, nel Behavior Blocker, a causa della presenza, nel sistema, del DEP (sebbene, in versione molto scarna e circoscritta). Occorrerebbe permettere, all'admin, di configurare quali programmi proteggere via DEP. Ahimè, tale funzione, oltre a non essere presente in molti computer (solo negli ultimi), tende ad occupare risorse di sistema. E' vero che il Behavior Blocker agirebbe utilizzando una logica "Just In Time", ma, combinando le due funzionalità, probabilmente, la sicurezza ne gioverebbe. Basterebbe impostare il DEP in tutti quei programmi considerati "a rischio" (perchè in comunicazione con l'esterno o che sò io). Per i rimanenti, basta, semplicemente, un controllo, via Behavior Blocker, legato al Buffer Overflow/Code Injection, per evitare che qualche attaccante tenti di danneggiare il sistema, dall'interno.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Scusa..ma hai una vaga idea di come scoprire un buffer overflow in modo generico? :shock:

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Di per sè, i metodi esistono (o il Behavior Blocker della Kerio, da cui ho preso spunto, sarebbe una bufala). Il programma dovrebbe effettuare certi controlli, legati allo spazio alloccato e all'input inviato. Il problema, però, è insito in quanto questa funzione possa costare, in termini di memoria. Io ho il Behavior Blocker nel Kerio Firewall e di per sè, con 3 processi attivi, son 26 Mega di memoria alloccata. Di per sè è tantino, ma è per questo che, IMHO, è bene, prima, premere riguardo gli aspetti inerenti alla sicurezza, che non alla grafica.
Da alcuni discorsi fatti da uno dei coders di ROS, emerge una mentalità uguale a quella di Windows: "Facciamo un OS uguale a WinXP, con estensioni server come 2k3 (e già questo aumenta esponenzialmente i rischi). Poi, mettiamo, come utente di default, un non Admin e tutto il problema è risolto". Come puoi ben comprendere, una simile affermazione è una cazzata, sotto molti punti di vista.
Ahimè, occorrerà sacrificare parte della memoria RAM disponibile, per implementare tutta la sicurezza trascurata finora. C'è poco da fare. Ereditando dai sistemi Win, questo passo è inevitabile, per un sistema sicuro e all'avanguardia e non l'ennesimo bloatware.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Ho riflettuto a lungo, prima di sottoporre alla vostra attenzione questo mio pensiero.
Riflettendo riguardo la funzione legata al controllo, da parte del Behavior Blocker, dei Buffer Overflow, non si può non tener in considerazione della presenza del DEP, ereditata dall'architettura di XP/2K3. Come tutti ben sanno, il DEP può essere implementato sia hardware, che software (sebbene, nel secondo caso, sia poco efficiente). Con la nuova componentistica hardware che uscirà nei prossimi anni, le funzionalità legate a questa feature, via Hardware, saranno disponibili completamente, pertanto, sarebbe bene nel procedere ad un uso intensivo del DEP, rispetto ad un engine "Just In Time" (in quanto, IMHO oneroso a livello di risorse impiegate e memoria RAM alloccata). Inoltre, il continuo incremento della velocità di elaborazione, da parte delle CPU, garantirà, in futuro, la possibilità di una copertura GLOBALE, di tutti gli applicativi presenti nell'ambiente operativo, senza rallentamenti. Alla fin fine, IMHO, fino a quando si parla di Code Injection, è un conto, ma riguardo il Buffer Overflow, è bene iniziare seriamente a considerare il DEP come soluzione, tralasciando le funzioni inizialmente presenti nei Behavior Blocker più comuni.
Secondo il mio parere, la funzione di Buffer Overflow, nel Behavior Blocker, andrebbe rimossa, preservando le altre.
Diversamente, sarebbe cosa buona e giusta inserire una funzione di controllo delle DLL e di tutte le librerie dinamiche più comuni, usate dai programmi. In certi casi, un attaccante, per ottenere un particolar tipo di effetto nel sistema compromesso, inietta, nell'ambiente operativo, un piccolo Malware dropper, che, all'avvio successivo del sistema, va a sostituire delle librerie, usate da un programma, con delle versioni trojanizzate. Se ad esempio, un utente, durante l'esecuzione di un programma, viene avvertito di una modifica di DLL, può, in modo più chiaro, comprendere se tale modifica è dovuta ad un'aggiornamento desiderato e volontario, oppure, causata da una compromissione o da un'attività pericolosa in atto nel sistema, permettendo, quindi, di permettere o sbarrare (a seconda della propria preferenza) le modifiche avvenute.

PS: ReactOS sarà un OS "Untrusted", pertanto, le funzionalità di Fritz Chip saranno completamente disabilitare. Ciò significa che è come se il Chip Crucco non ci fosse.
Anzi, esorto nel prendere in considerazione, a tutti gli utilizzatori di software e hardware Palladium-Compliant, nel evitare, assolutamente, di utilizzare materiale e dati "Trusted", proprio, in quanto, è bene che questa tecnologia venga completamente soppiantata, al fine di costringere il TCG nell'implementare la funzione di "Owner Override".

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest