qual è la vostra configurazione di sicurezza ?

[gianpietro]

Ciao sampei.nihira

Per la seconda risposta non avevo attivato la funzione, ora è attiva.

Niente da fare Chrome rimane bloccato, se vado in Gestione attività Windows sono presenti due chrome.exe, se cerco di terminarli il comando
non viene eseguito.

Vorrei precisare che non succede sempre, suppongo che essendo Chrome un browser a 32bit, su un sistema a 64 bit possa a volte non funzionare correttamente.

[sampei.nihira]

Ciao Gianpietro.
Nel mio OS a 64 bit (ma non uso SBIE) non accade mai.

[[Claudio]]

E nonostante alcune volte non si evidenzia la protezione in Logs, tramite Process Explorer, è possibile notare che il sw è protetto ugualmente. Ti consiglierei di fare questa prova e poi nel caso magari segnalare.

Hola @sapei tramite PEx si evidenzia che è protetto; comunque ho segnalato ugualmente sul forum di Malwarebyes (tra l'altro ho notato che lo stesso accade con il flash player integrato in Chrome, ma forse qui potrebbe essere corretto, perché Chrome nel Tab Log è presente).
Per gli aggiornamenti è augurabile arrivino alla distribuzione automatica, altrimenti è necessario corrergli sempre dietro.

Off topic: per SBox ho deciso di aspettare un paio di settimane, in maniera che i problemi segnalati vengano risolti; per ora mantengo la versione 3.6; per EMET ci sto lavorando sopra: ci sono alcune cose che non mi sono chiare quindi preferisco appoggiarmi alla guida di @enne (che piano piano, sta crescendo in fatto di informazioni).

[The Walking Dead]

Dura presa di posizione contro ExploitShield, che condivido come credo si sia capito dai miei post.
http://www.insanitybit.com/

[sampei.nihira]

E nonostante alcune volte non si evidenzia la protezione in Logs, tramite Process Explorer, è possibile notare che il sw è protetto ugualmente. Ti consiglierei di fare questa prova e poi nel caso magari segnalare.

Hola @sapei tramite PEx si evidenzia che è protetto; comunque ho segnalato ugualmente sul forum di Malwarebyes (tra l'altro ho notato che lo stesso accade con il flash player integrato in Chrome, ma forse qui potrebbe essere corretto, perché Chrome nel Tab Log è presente).
Per gli aggiornamenti è augurabile arrivino alla distribuzione automatica, altrimenti è necessario corrergli sempre dietro.

Off topic: per SBox ho deciso di aspettare un paio di settimane, in maniera che i problemi segnalati vengano risolti; per ora mantengo la versione 3.6; per EMET ci sto lavorando sopra: ci sono alcune cose che non mi sono chiare quindi preferisco appoggiarmi alla guida di @enne (che piano piano, sta crescendo in fatto di informazioni).

Tieni presente che in assenza di problemi l'uso della ver 3.76 è certamente più insicuro anche se questo dipende molto dal OS usato.
A ciò si aggiungono problemi di compatibilità.
Per esempio con il nuovo EMET 4 mentre la protezione assicurata dallo stesso dovrebbe essere rispettata mancano senz'altro le notifiche di attacco che rimangono confinate nella SBIE.

[[Claudio]]

Dura presa di posizione contro ExploitShield, che condivido come credo si sia capito dai miei post.

Lo trovo ingiustamente tranchant: non si è mai parlato di ExploitShield come il "rimedio assoluto", ma sempre e solo come "strumento di rilevazione" (se già restasse tale, sarebbe comunque utile, dal mio punto di vista).
E' indiscutibile che EMET sia tutta altra pasta.
Direi di aspettare e vedere come di evolve Malwarebytes Anti-Exploit, prima di dare un giudizio definitivo (si può presumere che se dovesse diventare uno strumento a pagamento, il cambiamento potrebbe essere radicale; nessuno acquisterebbe una licenza per un software che non compie, in termini di sicurezza, un compito preciso).

[[Claudio]]

[The Walking Dead] .... interessante il workaround per PDF.js per Chrome

[The Walking Dead]

Dura presa di posizione contro ExploitShield, che condivido come credo si sia capito dai miei post.

Lo trovo ingiustamente tranchant: non si è mai parlato di ExploitShield come il "rimedio assoluto", ma sempre e solo come "strumento di rilevazione" (se già restasse tale, sarebbe comunque utile, dal mio punto di vista).
E' indiscutibile che EMET sia tutta altra pasta.
Direi di aspettare e vedere come di evolve Malwarebytes Anti-Exploit, prima di dare un giudizio definitivo (si può presumere che se dovesse diventare uno strumento a pagamento, il cambiamento potrebbe essere radicale; nessuno acquisterebbe una licenza per un software che non compie, in termini di sicurezza, un compito preciso).

Mi rendo conto che la mia posizione sia piuttosto radicale nei confronti di ES.
La verità è che di base io credo ES sia un falso anti exploit, è per questo che, pur amando questa tipologia di software, non apprezzo appieno ES come per esempio sampei.

Di base un software di questo tipo dovrebbe 1) rendere l'attacco più difficile, attenuarlo, 2) aumentarne i costi, riducendo il ROI .

ES manca in tutti gli aspetti fondamentali di quelli che sono i principi cardini di un software anti exploit.
Perché non è un vero anti exploit, non attenua i rischi, non riduce il ROI, non rende più difficile l'attacco, risulta facilmente bypassabile.

L'acquisizione da parte dei tecnici di MB mi lascia ben sperare, il punto però è sempre quello secondo me.
I tecnici di MB rivedranno il software nel suo approccio sostanziale? (prevenire, invece di rilevare?)

[sampei.nihira]

Ho sempre sostenuto,del resto come lo sviluppatore di MBAE stesso, che EMET e malwarebytes anti-exploit agiscono su 2 piani diversi e distinti.
E' un errore portare MBAE sullo stesso piano di EMET.
Io spero vivamente che ciò non avvenga.
Per la sovrapposizione di interventi,che risulta sempre deleteria.
Che allo stato attuale non c'è certamente.

perché è interessante MBAE ?
perché interverrebbe quando e se EMET fallisce nel suo aspetto preventivo.
Ed io personalmente in passato ho provato l'inefficacia di EMET con exploit a bersaglio JAVA.
Ovvio che la ver attuale di EMET quasi certamente ha efficacia superiore.

Ci sono molti test su Youtube di ES vs exploit (trà cui anche vulnerabilità JAVA) basta controllare.

Quindi in definitiva nei miei pc MBAE costituirebbe l'ultima linea di difesa.
EMET quella intermedia.
Il browser quella principale.

E l'aspetto preventivo del browser dev'essere ottimo visto che dalla ver iniziale di EMET non ho mai visto un suo intervento sia nel mio pc che nel pc con W.7.

[sampei.nihira]

Già che son quì vorrei ancora una volta sottolineare che quell'articolo contiene errori di valutazione che si riflettono presumibilmente anche nel giudizio:

We want to clarify some parts of your post which are technical incorrect with two examples. It is not our intention to get into any prolonged discussion but we do want to defend our work especially when it is being misinterpreted and misrepresented.

1) Are the page permissions of the address RX (read-execute)?

This is not true. The following is the actual ExploitShield code where the comparison takes place:

VirtualQuery ((LPVOID)dwMemory, &mbi, sizeof(MEMORY_BASIC_INFORMATION));
if(mbi.AllocationProtect == PAGE_READWRITE)

In your case while reversing the ExploitShield.dll library you probably found this:
http://www.zerovulnerabilitylabs.com/do ... shield.png

The comparison is done against the value 0×4 (CMP DWORD PTR SS:[EBP-18], 4) and that’s why your conclusion is totally incorrect because this value belongs to PAGE_READWRITE (http://msdn.microsoft.com/en-us/library ... 86(v=vs.85).aspx).

It is possible that you have mistaken it with 0×40 which does equal to the PAGE_EXECUTE_READWRITE value mentioned in your article, but that has nothing to with our analysis and even less to do with our detection logic.

As you well know there are exploits that do not use ROP and which affect mainly XP machines where unfortunately the attacked program does not have DEP activated. Under these circumstances for the programs we protect, evaluating if the page which has called certain function comes from a PAGE_READWRITE memory area is a completely valid behavioral detection.

2) Is the address located within the bounds of a loaded module?

This logic as explained in your post is also incorrect since that is not the objective of ExploitShield. Rather we look for which loaded module the call comes from. With this explanation you can now probably get a good idea of the logic used in the ExploitShield analysis and the behavior of certain payloads.

“If either of these two tests fail, ExploitShield reports that it has discovered an exploit!”

Now I understand this comment. Initially we didn’t understand it because in addition to the checks mentioned above there are more things being considered in the equation. But I understand how based on a misunderstanding of how ExploitShield really works you arrived at this wrong conclusion.

– David Sanchez Lavado

e di tali errori ne ha preso atto anche l'autore:

Neat! Thanks for that clarification. Those were foolish mistakes on my part.

They are subtle differences that I don’t think change the results of my analysis too much. The facts are: It checks page permissions and also the calling module (or lack thereof), and bases a policy decision off of those facts. These checks are still based on detecting executing shellcode, no? So I stand by my conclusion.

nel frattempo MBAM ne ha fatta di strada ed è certamente migliorato.

[[Claudio]]

@The Walking, non era una critica alla tua posizione (ci mancherebbe altro), ho solo trovato piuttosto "prevenuto" l'articolo su Insanity.
D'altronde siamo tutti sulla stessa barca, ma non significa che tutti si rem nella stessa direzione (per dire che, ognuno imposta la propria "linea di prevenzione, protezione e sicurezza" sulla base delle proprie esigenze).
Non posso non concordare con @sampei quando dice (riassumo, credo, il pensiero) che stante la non infallibilità dei diversi software di protezione, sia più utile una "stratificazione" dei livelli di sicurezza.
In definitiva, ES non era la panacea di tutti i mali prima, probabilmente non lo sarà MAE, ma resta uno strumento utile.

A margine, il "workaround" di PDF-Js per Chrome, proposto su Insanity Blog, funziona (resta da verificare se l'estensione si aggiorna):



e considerato che il lettore PDF integrato in Chrome non è esattamente il massimo in termini di sicurezza .....

Per chi ne vuole sapere di più (fonte InsanityBit): qui e qui.

[sampei.nihira]

Buon giorno Claudio.
Oggi purtroppo non avrò mai accesso al pc con W.7.
Mia figlia è nel suo studio e si prepara all'esame di maturità,domani terza prova scritta !!

Quindi ti chiederei di fornirmi in questo 3D qualche immagine (la pagina delle estensioni).

perché il lettore predefinito in Chrome gira non solo in PPAPI ma anche ad IL non attendibile.
Mentre questo js ha la stessa vulnerabilità di ogni altro js.
Tant'è che per impostazione predefinita sarebbe consigliabile disabilitare i js.

Non sono per nulla convinto delle affermazioni di HM nei commenti in merito alla superficie di attacco.

[The Walking Dead]

Ho sempre sostenuto,del resto come lo sviluppatore di MBAE stesso, che EMET e malwarebytes anti-exploit agiscono su 2 piani diversi e distinti.
E' un errore portare MBAE sullo stesso piano di EMET.
Io spero vivamente che ciò non avvenga.
Per la sovrapposizione di interventi,che risulta sempre deleteria.
Che allo stato attuale non c'è certamente.

perché è interessante MBAE ?
perché interverrebbe quando e se EMET fallisce nel suo aspetto preventivo.
Ed io personalmente in passato ho provato l'inefficacia di EMET con exploit a bersaglio JAVA.
Ovvio che la ver attuale di EMET quasi certamente ha efficacia superiore.

Ci sono molti test su Youtube di ES vs exploit (trà cui anche vulnerabilità JAVA) basta controllare.

Quindi in definitiva nei miei pc MBAE costituirebbe l'ultima linea di difesa.
EMET quella intermedia.
Il browser quella principale.

E l'aspetto preventivo del browser dev'essere ottimo visto che dalla ver iniziale di EMET non ho mai visto un suo intervento sia nel mio pc che nel pc con W.7.

Ciao sampei.
Io non riesco ad essere in disaccordo con quello che scrivi.
Perché tu fai un ragionamento utilitaristico che è senz'altro condivisibile.
Tu in sostanza dici "se EMET ed ES lavorassero sullo stesso piano, uno escluderebbe l'altro, come conseguenza di ciò le nostre configurazioni di sicurezza risulterebbero meno complete".

Mentre io faccio un ragionamento sui principi di quello che è o dovrebbe essere un software di questo genere.
La mia è in un certo senso una visione da purista.
E la mia visione un po' intransigente in questo campo è appagata esclusivamente dall'approccio MS al problema.

Sui principi cardini di un software antiexploit ho già scritto.
Ed EMET ne è il massimo interprete secondo me.

Però anche quello è insufficiente.
A monte c'è la scrittura di codice sicuro, processi qualitativi elevati durante la fase di creazione del software, fase di update che usi standard elevati (che in MS possono richiedere fino a 4 settimane).
Quello che noi chiamiamo codice sicuro.

Spesso noi discutiamo di EMET, ExploitShield, Comodo Antiexploit (altra robaccia) però il processo parte da prima.
Dalla scrittura del codice, dalla fase di test del prodotto, dalla fase di update, e solo in un secondo momento subentrano i software che si occupano di attenuare i rischi.
Si scrivono software sicuri, poi ci si occupa di indurirli.
A che servirebbe attenuare i rischi con EMET se alla base il codice è buggato?

L'approccio MS al problema è esattamente questo, è un approccio a 360°.
La risposta di MS al problema exploit non è "utilizza EMET", ma invece è "scrivendo codice sicuro, diminuiamo gli errori in esso contenuti, diminuendo gli errori in esso contenuti diminuiscono i bug di sicurezza. In seguito ci occupiamo di far si che questi risultino difficilmente sfruttabili, attenuando i rischi e rendendo più difficile sfruttare quei pochi bug che inevitabilmente saranno emersi".

Però questa è solo la mia visione, un po' da purista del genere e mi rendo conto si possa preferire un discorso invece più utilitaristico al problema exploit.

[The Walking Dead]

@The Walking, non era una critica alla tua posizione (ci mancherebbe altro), ho solo trovato piuttosto "prevenuto" l'articolo su Insanity.
D'altronde siamo tutti sulla stessa barca, ma non significa che tutti si rem nella stessa direzione (per dire che, ognuno imposta la propria "linea di prevenzione, protezione e sicurezza" sulla base delle proprie esigenze).
Non posso non concordare con @sampei quando dice (riassumo, credo, il pensiero) che stante la non infallibilità dei diversi software di protezione, sia più utile una "stratificazione" dei livelli di sicurezza.
In definitiva, ES non era la panacea di tutti i mali prima, probabilmente non lo sarà MAE, ma resta uno strumento utile.

A margine, il "workaround" di PDF-Js per Chrome, proposto su Insanity Blog, funziona (resta da verificare se l'estensione si aggiorna):



e considerato che il lettore PDF integrato in Chrome non è esattamente il massimo in termini di sicurezza .....

Per chi ne vuole sapere di più (fonte InsanityBit): qui e qui.

Ciao Claudio.
Si non preoccuparti, avevo capito che non si trattasse di una critica alla mia posizione, ma che facevi un discorso relativo all'articolo.
Ho cercato di dettagliare meglio la mia posizione nella risposta di poco sopra a sampei.

[[Claudio]]

Buon giorno Claudio.
Oggi purtroppo non avrò mai accesso al pc con W.7.
Mia figlia è nel suo studio e si prepara all'esame di maturità,domani terza prova scritta !!
Quindi ti chiederei di fornirmi in questo 3D qualche immagine (la pagina delle estensioni).

Un in "bocca al lupo" a tua figlia, intanto (la mia, con le superiori è appena all'inizio).

Qui lo screen (fammi sapere):

L'approccio MS al problema è esattamente questo, è un approccio a 360°.
La risposta di MS al problema exploit non è "utilizza EMET", ma invece è "scrivendo codice sicuro, diminuiamo gli errori in esso contenuti, diminuendo gli errori in esso contenuti diminuiscono i bug di sicurezza. In seguito ci occupiamo di far si che questi risultino difficilmente sfruttabili, attenuando i rischi e rendendo più difficile sfruttare quei pochi bug che inevitabilmente saranno emersi".

Qui devo darti ragione: EMET, visto che si tratta di un prodotto $MS, dovrebbe essere integrato di default nel sistema.
Però, a fronte delle vulnerabilità proprie del sistema e software correlati $MS, si deve anche fare i conti con quelle di software di terze parti (e qui non si può addebitare la responsabilità a $MS, anche se, in talune occasioni, incidono non poco i suoi accordi commerciali con altre software house).
Forse aveva ragione Jobs a volere un "sistema chiuso" in tutto e per tutto

[sampei.nihira]

Come prima impressione io punterei al plugin interno PPAPI.
Occorrerebbe fare qualche test con PE.
Ma queste 2 settimane sono piuttosto "intasato".

[The Walking Dead]

Buon giorno Claudio.
Oggi purtroppo non avrò mai accesso al pc con W.7.
Mia figlia è nel suo studio e si prepara all'esame di maturità,domani terza prova scritta !!
Quindi ti chiederei di fornirmi in questo 3D qualche immagine (la pagina delle estensioni).

Un in "bocca al lupo" a tua figlia, intanto (la mia, con le superiori è appena all'inizio).

Qui lo screen (fammi sapere):

L'approccio MS al problema è esattamente questo, è un approccio a 360°.
La risposta di MS al problema exploit non è "utilizza EMET", ma invece è "scrivendo codice sicuro, diminuiamo gli errori in esso contenuti, diminuendo gli errori in esso contenuti diminuiscono i bug di sicurezza. In seguito ci occupiamo di far si che questi risultino difficilmente sfruttabili, attenuando i rischi e rendendo più difficile sfruttare quei pochi bug che inevitabilmente saranno emersi".

Qui devo darti ragione: EMET, visto che si tratta di un prodotto $MS, dovrebbe essere integrato di default nel sistema.
Però, a fronte delle vulnerabilità proprie del sistema e software correlati $MS, si deve anche fare i conti con quelle di software di terze parti (e qui non si può addebitare la responsabilità a $MS, anche se, in talune occasioni, incidono non poco i suoi accordi commerciali con altre software house).
Forse aveva ragione Jobs a volere un "sistema chiuso" in tutto e per tutto

Ciao Claudio.
Sull'integrazione di EMET in Windows...
Come certamente saprai, di default, in particolar modo da Windows Vista in avanti (XP è un po' diverso) il sistema operativo già utilizza tecniche parti integranti di EMET quali DEP ,ASRL, SEHOP.
Quindi da questo punto di vista già beneficiamo dei vantaggi di queste tecnologie, ciò non è cosa da poco se si pensa che Apple (considerato un OS estraneo al problema virus) fino a qualche anno fa non includeva in modo soddisfacente attenuazioni di questo tipo.
EMET permette una personalizzazione maggiore (oltre ad aggiungerne altre) ma sostanzialmente richiede una competenza di base superiore a quella dell'utente medio.

Sugli accordi commerciali MS non ho ben capito a cosa ti riferisci.
Io non vedo negli accordi commerciali MS un problema che possa aver comportato una riduzione della qualità negli standard di sicurezza del codice.
MS è un multinazionale con oltre 100.000 dipendenti, con sedi sparse in tutto il mondo, più di 50 miliardi di dollari di fatturato.
Un azienda di queste proporzioni può non avere un attenzione fatta anche di accordi commerciali nel settore che rappresenta il suo core business?
Apple fa accordi commerciali, Google fa accordi commerciali.
È impensabile guidare un azienda di questo proporzioni senza fare accordi commerciali.
Perché poi noi diciamo sempre che MS fa accordi commerciali , però non è che è l'unica azienda che cura i suoi interessi in questo modo.

Un esempio.
PC preinstallati con software dei produttori terzi.
1) I pc marchiati MS, prodotti da MS non includono software di terze parti.
2) Guardiamo anche i vantaggi, il preinstallato riduce il costo complessivo dei pc che paghiamo meno nei negozi.
3) L'ecosistema dei software prodotti per Windows ne beneficiano, (esempio l'utente si compra Norton perché è preinstallato).

[[Claudio]]

Sull'integrazione di EMET in Windows...
Come certamente saprai, di default, in particolar modo da Windows Vista in avanti (XP è un po' diverso) il sistema operativo già utilizza tecniche parti integranti di EMET quali DEP ,ASRL, SEHOP .......

Dal mio punto di vista, è una questione di lana caprina = utente poco attento, utente poco preparato, utente che non sa che pesci pigliare.
Poi succede questo:

2) Guardiamo anche i vantaggi, il preinstallato riduce il costo complessivo dei pc che paghiamo meno nei negozi.
3) L'ecosistema dei software prodotti per Windows ne beneficiano, (esempio l'utente si compra Norton perché è preinstallato).

ovvero, si risparmia da una parte e dall'altra ci si ritrova con software trial da acquistare successivamente ..... e Norton come antivirus ....
Il tuo ragionamento non fa una grinza quando si parla di "accordi commerciali" in funzione di una azienda di dimensioni mostruose .... ma dico .... un minimo di attenzione in più rispetto alla "semplificazione della sicurezza", uno se lo aspetta.
Invece, è sempre un "rincorrere" (ovviamente, se ci si tiene e se si ha voglia di imparare); altrimenti si torna alla casella iniziale: questione di lana caprina .... è questo che assolve aziende come $MS.

[gianpietro]

Nightly a 64bit

Ragazzi mi serve un vostro aiuto.

In cerca di un browser alternativo, ho trovato Nightly a 64bit una versione di Firefox ottimizzata per il 64bit, l'ho provato sotto sandboxie,
non installato sul sistema, e non mi a dato nessun problema, con le estensioni AdBlock / Ghostery / HTTPS Everywhere / Wot.

Molto veloce, mi permette di accedere anche alla mia piattaforma di sicurezza esterna, l'unico problema è in Inglese, nel menù delle lingue è
presente anche l'italiano, ma rimane in inglese.

È possibile che usandolo sotto Sanboxie non abbia preso il comando?

http://nightly.mozilla.org/

[The Walking Dead]

Però è una scelta opzionale quella di acquistare Norton, puoi benissimo non farlo e risparmiare comunque sul costo del pc grazie a quella trial di Norton (e altre duecento trial inutili ).
Puoi acquistare un pc MS (per esempio di quelli ottimizzati) o di quei produttori che hanno una politica sui preinstallati che ritieni corretta.
Insomma alla fine l'importante è che il consumatore possa scegliere.

Uno dei compiti di chi scrive un OS è anche quello di mettere gli sviluppatori terzi nella condizione di trarre profitti da quello che fa.
Attraverso strumenti che permettano di scrivere facilmente il proprio software, o anche attraverso politiche che permettano di beneficiare dei profitti del proprio lavoro.
Questo non è necessariamente negativo.
Più il mercato è ricco, stimolante, maggiori saranno i software prodotti per quel dispositvo, OS che sia.
Questo produrrà una maggiore scelta per l'utente, ed un ecosistema più ricco.

Guardiamo LInux, quanti sono i software per esso disponibili?
400.000?
Su Windows sono oltre 10 milioni (se non ricordo male).
Guardiamo Windows Phone, settore dove MS non predomina.
Mancano applicazioni basiche (persino quelle di Google) perché non ha appeal.
Non basta scrivere un buon OS, bisogna mettere nella condizione chi sviluppa software per quel dato OS di trarre un vantaggio dallo sviluppo di una propria personale applicazione.
Non è una questione di favorire quella determinata azienda rispetto all'utente, è una questione di favorire la crescita del mercato per ogni parte in causa (utenti, sviluppatori, creatore dell'OS).

Sulla questione semplificazione della sicurezza, questa è una strada seguita da tutte le più grandi aziende informatiche.
Google pubblicizza il proprio browser come veloce, sicuro e semplice.
Apple è da anni la regina incontrastata del minimalismo, della semplificazione di ogni operazione.
Non possiamo chiedere secondo me che un utente qualunque, sotto Windows, debba conoscere l'indirizzo degli spazi di memoria.