[Ufficiale] 3a Revisione: Behavior Blocker

Moderators: forart, Davy Bartoloni, gabrielilardi

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

[Ufficiale] 3a Revisione: Behavior Blocker

Post by PUOjACKz »

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
* HIPS (Host Intrusion Prevention System), contro Code Injection, l'User Imitation e l'Application HiJacking

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.
;
; - (Obsoleto) - E' stata inoltrata, nel forum, una proposta nel poter
;collegare, degli script batch o simili, nel funzionamento delle cartelle.
;Tale feature, seppur utile, potrebbe fungere da WorkAround maligno, nei
;confronti del Behavior Blocker, per azioni maligne. Per evitare problemi
;al Behavior Blocker, diminuendo il carico di lavoro di quest'ultimo, è
;bene gestire le cartelle di esecuzione automatica via OS.
;
;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).
/* La seguente protezione blocca, inoltre, l'utilizzo delle API di sistema, da parte dei Process-Injecting Trojans ed in tutti quei tentativi ove un eseguibile generico, effettua iniezioni presso altri processi o librerie. Simili attività non dovrebbero essere compiute da un software, pertanto, vanno tutte bloccate. Il code injection, inoltre, può essere sfruttato al fine di provocare il funzionamento anomalo di un programma (es. costringendo il firewall ad ignorare le regole di traffico presenti o rimuovendo, in un antivirus, le funzioni di segnalazione dell'avvenuta identfiicazione di un malware ecc.). */

Per la ricezione di un tentativo di Application Hijacking (identificato dall'HIPS):

Code: Select all

Tentativo d'Application 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, oppure per ottenere dati privati. 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. Tramite questa protezione, i software Password-Stealer o i Keylogger non possono funzionare. */

Per la ricezione di un tentativo di User Imitation (identificato dall'HIPS):

Code: Select all

Tentativo di Imitazione d'input dell'Utente

Il programma: $PathENomeProgrammaRichiamante
Ha effettuato un tentativo d'User Imitation, inviando degli input, al programma colpito, non generati realmente dall'utente.
Applicazione colpita: $PathENomeProgrammaColpito ($Descrizione [$Versione])

Il Behavior Blocker ha identificato e bloccato un operazione considerata sospetta, in quanto utilizzata dagli attaccanti, per eseguire comandi, nel sistema, all'insaputa dell'utente. Solitamente, gli applicativi sicuri non effettuano tali 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'User Imitation per compiere danni.
/* L'User Imitating Attack, o SendKey Attack, avviene quando un programma maligno tenta di simulare delle attività, possibili solo all'utente (es. pressione dei tasti della tastiera), al fine di compromettere il funzionamento di un applicativo, anche causandone lo spegnimento. Questo può causare un rischio per la sicurezza di sistema, qualora vengano terminati eventuali software legati alla protezione e monitoraggio. */

;
; - (Obsoleto) - E' bene gestire il traffico Universal Plug And Play, via
; gestione delle periferiche, bloccando ogni interazione predefinita con il
; sistema, qualora l'utente non permetta un certo traffico, a priori, via
; configurazione
;
;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 */

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)
Linea di Comando Inoltrata: $LineaComandoPassataAlProgrammaEvocato
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 (ma la versione del programma non è cambiata), avviare il programma, altrimenti, bloccare l'applicazione senza richiedere l'interazione dell'utente
- Controllare la presenza dell'applicazione, nelle regole. Se è avvenuto un cambiamento nella versione del programma, avviare quest'ultimo lo stesso, 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

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 l'Application HiJacking & Code Injection

- Protezione contro il Code Injection (con Lista Eccezioni)
- Protezione contro l'Application HiJacking (con Lista Eccezioni)
- Registrazione dell'Evento Code Injection
- Registrazione dell'Evento Application HiJacking
- Bloccare il Code Injection 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)

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.
Il Database dei software principali dell'OS deve sopraggiungere già, in base, compilato. Inoltre, dev'essere possibile esportare quest'ultimo, al fine d'installarlo in più computer, via file d'acquisizione.

Modalità Intelligence-Learning

Quando questa modalità è attiva, il Behavior Blocker considererà, tutti i programmi avviati, come sicuri, senza richiedere l'intervento dell'utente. Questa opzione è utile al fine di completare il Database di software affidabili, in modo veloce.
Tale modalità può essere configurata, con una durata variabile, a seconda del numero di reboot avvenuti, dalla sua impostazione (es. per permettere, ad un utente, di avviare i programmi di base, appena installato il sistema, ma dopo qualche reboot, attivare le funzionalità del Behavior Blocker).
Tale feature, però, può rappresentare un problema di sicurezza, qualora, nel sistema, si autoeseguano dei programmi maligni, all'insaputa dell'utente. Infatti, quest'ultimi verrebbero inclusi nella lista di software sicuri, sebbene non lo siano.

Questo genere di modalità và utilizzato solo in ambienti sicuri e per un periodo limitato. Qualora si debba eseguire un programma, è bene, comunque, sfruttare sempre la presenza del Behavior Blocker, il quale, fornisce, nel popup, anche degli avvisi all'utente. Inoltre, nel software son presenti delle opzioni per l'inserimento e la rimozione, manuale, degli
eseguibili.

Note Aggiuntive:

1) Per i programmi avviati utilizzando RunAs, occorre inserire, a livello kernel, una protezione, aggiuntiva, per l'accesso alla memoria fisica, effettuato dal software, onde evitare Code Injection e simili.
2) Per bloccare la possibilità, ad un eseguibile, di terminare altri processi, è bene impiegare le capabilities. Questo evita il sovraccarico, di lavoro, al Behavior Blocker, agendo in modo più sicuro e preciso.
3) I RootKit Kernel-Mode, vengono installati solo se l'utente è Amministratore. Per bloccare tale prassi, l'utente non deve utilizzare, tale account, durante il normale utilizzo del sistema. E' inutile aggiungere una funzionalità, di blocco, nel Behavior Blocker, inerente a questo genere di problema.
4) I problemi riguardanti i LeakTest, devono essere trattati dal Firewall, non dal Behavior Blocker. E' il firewall che deve sbarrare ogni attività maligna che dall'esterno, tenta di iniettarsi all'interno.
5) I problemi legati alle funzioni sconosciute del Windows File Protection (protezione dei files di sistema di Windows), devono essere gestiti con hardening delle librerie utilizzate (sfc.dll) e altri controlli, non dal Behavior Blocker. Inoltre, è bene che questo genere di coding in "Security By Obscurity" non sia prassi di ROS.
6) C'è un problema irrisolto: il Registry DLL Injection. Solitamente, i programmi aggiungono, automaticamente, le DLL a loro collegate, ad una lista di librerie condivise di sistema (presenti in più chiavi di registro). Successivamente, tali software possono usare le DLL. Certi malware, però, possono manipolare le informazioni contenute nel registro di sistema, comportando il puntamento di una libreria, non più alla sua versione sicura e originale, ma ad un doppione contenente funzioni maligne, le quali sembrano figurare far parte dell'applicativo, quando, in realtà, quest'ultimo è innocuo. Vari spyware (es. il CoolWebSearch (CWS)) sfruttano tale tecnica per rendere la loro rimozione, più complessa.
7) Il Message Handling, dev'essere gestito via Capabilities, in modo da evitare, anche in questo caso, la terminazione di certi applicativi sensibili, via Windows Message.
8) Altro problema: la sospensione dei processi. In tal caso, si tenta, solitamente, di sospendere tutti i threads di un processo, permettendone, comunque la residenza, ma inattiva (cioè, in stato congelato). In questo modo, il software sembra funzionare (es. icone nella system tray), ma in realtà, le sue routine non vengono eseguite.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest