Prevenire è meglio che curare :) Software HIPS

[Roby_P]

A parte Comodo e la filosofia della sua nuova suite, che proprio non condivido , io non capisco che senso ha usare questi due tipi di software insieme

[nV 25]

Chi vuole provare in anteprima ExploitShield Browser Edition 0.9 mandi un privato all'autore del thread.

Io ho pronta la VM con 8 per qualche ora di test non appena mi fornirà le istruzioni.

Ciao

[nV 25]

Stavolta ES 0.9 va liscia come l'olio (mi sono concentrato infatti esclusivamente su un discorso di usabilità).

Le "innovazioni":
"Since version 0.8 we have been working really hard into expanding ExploitShield's detection and blocking capabilities of advanced vulnerability exploits.
We have integrated its hooking mechanism lower into the Operating System to prevent potential bypasses and have added quite a few new exploit detection techniques such as memory checks in order to detect and block exploits at an earlier stage."

Consiglio davvero a chi fosse interessato di contattarlo per farsi dare il link per una presa-visone specie se ha una VM sottomano.

[done75]

Originariamente inviato da Roby_P

A parte Comodo e la filosofia della sua nuova suite, che proprio non condivido , io non capisco che senso ha usare questi due tipi di software insieme

Non condividi la nuova filosofia perchè non sei niubba.
CIS 6 per i niubbi è molto più semplice.
Per noi invece c'è da smanettare 10 minuti per riportare tutto come nelle precedenti versioni.

[nV 25]

trovo quest'esperienza molto interessante:
TDL4 Rootkit and Imaging Apps

In poche parole, Aigle ha infettato di proposito il proprio sistema (VM o reale non è importante) con 2 virus della famiglia TDL 4, uno che infetta semplicemente il MBR, l'altro il VBR.

Entrambi creano un File System (FS) apposito come "luogo" nel quale "stoccare" parte dei componenti che gli sono necessari per permettergli di caricarsi ad ogni reboot.

Ebbene, neppure la formattazione ha la capacità di eliminare il FS infetto.
Idem per i tool di immagine utilizzati (macrium reflect free/paragon free).

E' ovvio che in entrambi i casi (ricorrere ad un'immagine/formattare) restano solo residui del Bootkit dunque nessun pericolo.

Quello su cui lui focalizza l'attenzione, cmq, è il fatto che restino "tracce" dell'infezione se pur disattivata.


Messaggio:
occhi agli HD che comprate sui mercatini

[nV 25]

Originariamente inviato da nV 25

lettura davvero interessante (quantomeno la parte discorsiva) sul tema "Sandbox":
The Sandbox Roulette, Blackhat 2013 (pdf).

Notizia:
cliccami, fonte: solito Wilderssecurity...

Originariamente inviato da nV 25

ok, ho tentato di leggere con attenzione il materiale e un'idea me la sono fatta.

Guardo di tirare giù una sintesi comprensibile.

in poche parole (ma davvero in poche parole), il concetto è semplice:
uno strumento di prevenzione proattiva (in questo caso un Sandbox anche se il concetto non cambierebbe nell'ipotesi in cui si considerasse un HIPS tradizionale) è robusto...cosi' quanto è robusto il Kernel del sistema su cui è installato.

Anche ipotizzando infatti che lo strumento di prevenzione considerato sia ben programmato, di fronte ad una vulnerabilità del kernel (in particolare i bug che consentono di acquisire maggiori privilegi rispetto a quelli che gli sarebbero altrimenti riconosciuti) il Sandbox può fare ben poco per contenere ciò che ha programmato chi lancia l'attacco.


Più che il Sandbox, pertanto, conta quanto è robusto il Kernel di un OS.

[nV 25]

per riallacciarmi al concetto sopra (un Sandbox è robusto...a patto che sia robusto il kernel del sistema operativo su cui è installato), voglio provare (fondamentalmente) a tradurre quello che è scritto nell'articolo cosi' da tentare di offrire una visione il più aderente possibile a quello che è scritto nel pezzo.

Anzitutto una premessa:
uno dei 2 tizi che ha firmato l'articolo è considerato semplicemente "avanti", rafal wojtczuk

Dopo averci dunque descritto in 2 battute cosa è un Sandbox (un ambiente pensato per far girare codice insicuro in un modo tale che il codice incapsulato non danneggi il resto del sistema), analizza quella che è la debolezza di fondo di uno strumento di questo tipo.

Il kernel di Windows - dice il nostro amico - presenta un ampia superficie di attacco per figure di altissimo profilo, e un exploit mirato sul kernel può bypassare tranquillamente le restrizioni poste dal Sandbox.
Questo tipo di attacco è da considerare a tutti gli effetti un rischio concreto o, quantomeno, al pari degli altri rischi.

E rafforza il concetto del rischio reale proveniente da questo vettore di attacco:
se da un lato queste soluzioni di difesa sono oggettivamente ben costruite (= non soffrono di clamorosi bug), gli attacchi al kernel sono molto frequenti sebbene richiedano menti altamente qualificate per essere sviluppati.

Di fronte a queste minacce, dunque, coloro che si avvalgono di un Sandbox sono sempre di fronte ad una sorta di Roulette (in poche parole: andrà a finire bene??)..

E il problema qual'è, allora, visto che si parla di Sandbox?

Fondamentalmente queste soluzioni vivono attorno ad un driver che ha il compito di alterare il comportamento che sarebbe altrimenti riconosciuto dal sistema a quell'applicazione.
Il problema, dunque, risiede nel fatto che, a meno di non chiudere l'accesso a qualsiasi risorsa rendendo dunque impossibile l'esecuzione del codice incapsulato nel Sandbox, resteranno sempre canali (kernel interface) accessibili per l'esecuzione remota (= indotta) di codice che gira in modalità kernel.

Di fatto, quindi, il PC è a pecorina. perchè a questo punto, tanto il Sandbox che il codice nocivo lavorano al solito livello e lo strumento di difesa non può più contare su alcuno strumento teso a proteggerlo.

Fine.


Resta l'esempio che a breve integro.

[nV 25]

Ok, l'esempio che porta:

ms12-042 (CVE-2012-0217)
che poi ha scoperto lui (per dire, io posso scoprire giusto l'acqua calda )...

HIPS testato:
Sandboxie su Windows 7 SP1 x64

Ci dice quindi che l'exploit "viaggia che è una bellezza" ("The exploit worked flawlessly, providing the ability to run arbitrary code in kernel mode") ma al contempo ci consola facendoci presente che l'exploit ha bisogno di un "surplus" per essere realmente utile su un sistema protetto da Sandboxie ("A slight twist is that the usual kernel shellcode that just steals the SYSTEM access token is not particularly useful to the attacker. Although the attacker gains SYSTEM rights in his user mode process, the process is still confined by Sandboxie (and an attempt to kill a nonsandboxed process from this SYSTEM shell fails). The attacker needs to perform some extra work while in kernel mode").

E fa vedere quindi cosa poter fare...


Insomma, credo tutto parli da solo anche se il vostro amato nV confessa che confiderà sempre su soluzioni di questo tipo per proteggere meglio la propria postazione.

Semplicemente, lo farà sapendo che in circostanze (rare) gioca un pò alla Roulette.


Di nuovo

[nV 25]

dimenticavo giusto per dovere di cronaca:

l'altrettanto "amato" EP_X0FF su kernelmode.info fa presente senza tanti giri di parole quanto ama queste soluzioni e i loro sviluppatori.

In pratica, fosse per lui tutti a lavorare..


Ma vabbè, si sa che il tipo è estremo, altro che nV

[nV 25]

dimenticavo:

è logico che oggi non è più possibile sfruttare quel canale (CVE-2012-0217) per acquisire maggiori privilegi dato che è stata rilasciata a suo tempo la patch (ms12-042, appunto).

E' il concetto cmq che resta valido...


Di nuovo,
l' "amato" nV da Lucca

[nV 25]

ah, dimenticavo 3:
sarebbe gradito un qualsiasi commento in proposito (anche se non avete capito nulla):
al più, si prova a ripetere con altre parole.


'namo, che i monologhi non li amo...


Aspetto paziente,

il vs amato nv

[pcpassion]

Sei stato chiaro.
In sostanza sandboxie sui 64 bit non è infallibile, ma le probabilità di infettarsi sono comunque le stesse che si hanno di fare 6 al superenalotto?
Ma secondo te se a sandboxie abbino un buon HIPS ( intendo quello di comodo) l'exploit ha + o - probabilità di sferrare il suo attacco?

[nV 25]

come la vedo io?

Il fatto che attaccato sia Sandboxie & i suoi fratelli non c'entra nulla perchè:
- vale per qualsiasi strumento di prevenzione sia esso Sandbox o HIPS
- non c'entra nulla nè l'essere @ 64bit o a 32.

Quello che vuol dire è che di fronte a gente con gli stra-°° che tirano giù un exploit di quella natura, la vera difesa non è ciò che uno utilizza per proteggere il sistema ma l'architettura del sistema stesso (kernel).

Più questo è robusto (e 8 ad es è mooolto migliore di 7 e dei suoi fratelli), più è robusto (effettivo) lo strumento di prevenzione.

In altre parole, se l'exploit è del tipo visto sopra (non rivolto cioè ad una specifica applicazione o user-mode exploit..), non esistono difese se non il kernel stesso (che però come abbiamo visto è bucabile)...

[pcpassion]

Originariamente inviato da nV 25

come la vedo io?

Il fatto che attaccato sia Sandboxie & i suoi fratelli non c'entra nulla perchè:
- vale per qualsiasi strumento di prevenzione sia esso Sandbox o HIPS
- non c'entra nulla nè l'essere @ 64bit o a 32.

Quello che vuol dire è che di fronte a gente con gli stra-°° che tirano giù un exploit di quella natura, la vera difesa non è ciò che uno utilizza per proteggere il sistema ma l'architettura del sistema stesso (kernel).

Più questo è robusto (e 8 ad es è mooolto migliore di 7 e dei suoi fratelli), più è robusto (effettivo) lo strumento di prevenzione.

In altre parole, se l'exploit è del tipo visto sopra (non rivolto cioè ad una specifica applicazione o user-mode exploit..), non esistono difese se non il kernel stesso (che però come abbiamo visto è bucabile)...

Ok grazie, chiarissimo.

[done75]

Originariamente inviato da nV 25

come la vedo io?

Il fatto che attaccato sia Sandboxie & i suoi fratelli non c'entra nulla perchè:
- vale per qualsiasi strumento di prevenzione sia esso Sandbox o HIPS
- non c'entra nulla nè l'essere @ 64bit o a 32.

Quello che vuol dire è che di fronte a gente con gli stra-°° che tirano giù un exploit di quella natura, la vera difesa non è ciò che uno utilizza per proteggere il sistema ma l'architettura del sistema stesso (kernel).

Più questo è robusto (e 8 ad es è mooolto migliore di 7 e dei suoi fratelli), più è robusto (effettivo) lo strumento di prevenzione.

In altre parole, se l'exploit è del tipo visto sopra (non rivolto cioè ad una specifica applicazione o user-mode exploit..), non esistono difese se non il kernel stesso (che però come abbiamo visto è bucabile)...

In altre parole ancora, il 100% di protezione NON ESISTE.

[nV 25]

esatto.

Il tizio, peraltro, trova vulnerabilità in qualsiasi Kernel (Linux, MS,..) dunque contro una reale volontà di attacco che viene da queste menti c'è veramente poco da fare.


La realtà, però, dice che statisticamente è improbabile imbattersi in queste MACRO-vulnerabilità, ergo secondo me un'utenza domestica ha di che beneficiare (ma alla grande, anche) dall'uso di questi strumenti (quantomeno quelli rispondenti ai nomi più volte trattati da me nel corso del thread) per combattere i rischi "più probabili".


Il resto è "dottrina" fino ad un certo punto...

[Roby_P]

Ho capito pure io

PS: Comodo mi sta andando sulle °° con questa storia dell'user-friendly ... DefenseWall non è freeware, vero?

[arnyreny]

Originariamente inviato da Roby_P

Ho capito pure io

PS: Comodo mi sta andando sulle °° con questa storia dell'user-friendly ... DefenseWall non è freeware, vero?

mi dispiace deluderti ma sui 64 bit comodo settato bene rimane ancora la soluzione migliore

ps defence wall non è free e non è per i 64 bit

[Roby_P]

C'è troppa roba in quella suite per i miei gusti

Spero sarà possibile installare solo Firewall e HIPS, altrimenti dovrò spostarmi su un HIPS puro e la cosa mi spaventa un po'

[done75]

Originariamente inviato da Roby_P

Spero sarà possibile installare solo Firewall e HIPS, altrimenti dovrò spostarmi su un HIPS puro e la cosa mi spaventa un po'

Ovviamente si, quando mai non si è potuto?