Come posso ottenere un virus semplicemente visitando un sito Web? [duplicare]


47

Possibile duplicato:
un computer può essere infettato da malware tramite browser Web?

È risaputo che è possibile ottenere un virus semplicemente visitando un sito Web. Ma come è possibile?

Questi virus attaccano gli utenti Windows, Mac e Linux o gli utenti Mac / Linux sono immuni?

Capisco che ovviamente posso ottenere un virus scaricando ed eseguendo un file .exe in Windows, ma come posso ottenere un virus accedendo a un sito Web?

I virus sono programmati in JavaScript? (Avrebbe senso poiché si tratta di un linguaggio di programmazione che viene eseguito localmente.) In tal caso, quali funzioni JavaScript sono quelle comunemente utilizzate?


2
Molto spesso è una combinazione di varie tecniche e falle di sicurezza dei browser.
Paŭlo Ebermann,

Buona domanda, e IMHO, dal momento che è web, dipende da HTTP e non è più influenzato dal sistema operativo, il browser invece conta più del sistema operativo.
Kenan D,

Argomento molto ampio, le vulnerabilità del browser possono cambiare man mano che vengono scoperte e variano da browser a browser.
Moab,


@LordCover: mentre le tattiche di spavento iniziale possono essere http, il payload deve essere un eseguibile mirato a sistemi specifici per superare un semplice fastidio e diventare un vero virus. Poiché Linux e Mac non possono eseguire exe (senza aiuto, comunque) e Win non può eseguire eseguibili scritti per gli altri sistemi operativi, è ancora un sistema dipendente dal sistema operativo. Recenti hack-festival hanno dimostrato che Win7 è paragonabile a (e per certi versi, migliore di) Mac e Linux in termini di sicurezza. Attualmente è ancora il fatto che molte persone eseguono Windows che lo rende un obiettivo popolare.
music2myear,

Risposte:


24

È risaputo che è possibile ottenere un virus semplicemente visitando un sito Web. Qualcuno può spiegare come questo è possibile?

Esempi in parentesi. C'è un bug nel browser (IE), nell'interprete javascript o in un plugin (come flash o java). Questo bug porta all'esecuzione del codice - quella parte può essere davvero complicata ma spesso comporta una manipolazione dell'heap e del bug use-after-free .

Poi ho un po 'di shellcode in esecuzione. Il codice shell deve sfuggire a qualsiasi protezione del browser - per un bug V8 / Chrome dovresti sfuggire alla sandbox di Chrome e sconfiggere DEP e ASLR. Per IE, dovresti battere DEP e ASLR e poi uscire dalla modalità a bassa integrità. Per Java non dovresti ... non fare nulla: sei tutto d'oro. (Ecco perché c'è stata un'ondata di bug java.)

Quindi ora che ho un codice arbitrario in esecuzione sul tuo computer, poiché tu (non sei in esecuzione come amministratore, giusto?), Posso andare a scaricare un file da Internet ed eseguirlo, facendo cadere del malware sul tuo computer.

I virus sono programmati in JavaScript? (Avrebbe senso poiché si tratta di un linguaggio di programmazione che viene eseguito localmente.) In tal caso, quali funzioni JavaScript sono quelle comunemente utilizzate?

In particolare - no. Javascript è un vettore di attacco che le persone useranno per trovare un bug in un browser. Potrebbero anche usare Flash, Java o Silverlight come vettore di attacco. Nel caso di javascript, scrivono javascript per attivare il bug del browser, quindi il virus viene infine rimosso da Internet.


4
Questo è inaccurato. I virus spesso lo fanno, ma non sono tenuti a (scaricare codice aggiuntivo). Possono avere un payload incorporato nell'exploit basato su JavaScript. Quel payload sarebbe un codice assembly, ma sarebbe presentato come javascript. Tutto dipende dal bug e dalla specifica implementazione dell'exploit.
Merlyn Morgan-Graham,

2
Hai appena scritto che Java non ha sandbox? Perché lo fa davvero in tutti i browser di cui sono a conoscenza.
CarlF,

4
@CarlF: No, non si tratta del sandbox Java (che esiste ancora). Si tratta di bug in Java - se questi ti consentono di uscire dalla sandbox, c'è poca sicurezza aggiuntiva (come DEP) per fermare un attaccante.
sleske,

3
Java è una grande falla, mi ha morso due volte. Ora lo disabilito religiosamente: superuser.com/questions/201613/…
Jeff Atwood,

2
@Merlyn Sì, è possibile inserire l'intero payload in javascript e non scaricare codice aggiuntivo (ad esempio tutti i moduli metasploit come 'Aggiungi un ulteriore utente al sistema' o reverse_tcp). Ma i malware sofisticati di solito usano il codice shell in javascript come uno stager per abbattere il codice più complicato e più sofisticato. Tutto dipende dal bug e dall'exploit - tutta la logica e lo shellcode potrebbero trovarsi in un'immagine che busta un parser di immagini - Sto solo dicendo il percorso più comune.
Tom Ritter,

14

Sfortunatamente e perversamente, ci sono molti modi in cui ciò può accadere.

Hai assolutamente ragione di stupirti che un "dispositivo di lettura" come un browser possa manipolare attivamente il tuo sistema (e fare del male). Leggere un libro non esaurisce il tuo conto in banca e aprire un giornale non fa male ai tuoi figli, quindi perché aprire un sito web può fare tutto questo e altro?

Il problema si verifica ogni volta che esiste la possibilità che i dati esterni da Internet, che dobbiamo sempre presumere siano realizzati con il massimo intento maligno, riescano in qualche modo a essere eseguiti dal tuo sistema.

Se ti siedi semplicemente alla riga di comando e digiti wget http://evil.com/hitme.php, il client HTTP wget scriverà semplicemente un dump binario della richiesta sul tuo disco e non è successo nulla di male (tranne forse il tuo riempimento del disco). Ma se inserisci l'indirizzo nel tuo browser, il tuo browser è libero di fare tutto ciò che vuole - formatta il tuo disco rigido, invia i dettagli della tua carta di credito, ecc. Sta a te affidarti al tuo browser per non farlo. La maggior parte dei browser tenta davvero di non fare quelle cose cattive, ma noi, gli utenti ovini , abbiamo chiesto ai browser di essere in grado di fare sempre più "trucchi intelligenti" e di mostrare un comportamento automatico basato sulle istruzioni di Internet. Le nostre richieste hanno portato alla creazione di tecnologie di esecuzione del codice lato client come JavaScript e Flash, che scaricano ed eseguono codice arbitrario, estraneo, non attendibile e dannoso , il tutto per nostro piacere.

Il motivo per cui le persone che hanno inventato queste tecnologie non sono state immediatamente linciate è perché a) ha fatto ballare i coniglietti sui nostri schermi e b) hanno affermato di aver messo a punto controlli di sicurezza sufficienti per impedire che il codice dannoso arbitrario potesse manipolare il sistema locale (ad es. non consentire la lettura / scrittura dei dischi locali, la lettura / scrittura degli appunti, la lettura / scrittura dei campi modulo in altre schede).

Sfortunatamente, l'approccio progettuale per "consentire prima tutto e poi coprire in modo irregolare alcuni punti negativi a cui possiamo pensare" è fondamentalmente imperfetto, e ora stiamo affrontando un flusso infinito di nuovi modi in cui le nostre funzionalità di convenienza sul lato client possono essere utilizzato per compromettere i nostri sistemi.

L'unica via di uscita moderatamente sicura è disabilitare JavaScript e plugin nel tuo browser. Sicuro come eravamo nel 1995.


6
Wget non è "sicuro", né i driver che eseguono il tuo computer, né i sistemi a livello di kernel. Ci sono mitigazioni, ma alla fine ogni parte di codice è potenzialmente soggetta ad attacchi.
Merlyn Morgan-Graham,

@Meryll: omettevo un'intera classe di problemi, vale a dire quelli provenienti da codice difettoso. Sì, c'è sicuramente una minaccia da librerie di immagini rotte e parser di intestazione MP3 e cose del genere. Non volevo andare troppo lontano. Ho riscontrato che i problemi derivanti dalla progettazione delle moderne tecnologie Internet sono molto più pertinenti alla domanda del PO.
Kerrek SB,

1
@Kerrek: La loro domanda era "posso ottenere un virus dalla visita di una pagina Web" e hai continuato dicendo che non potevano ottenere un virus da wget. Parli anche di fiducia. Ma la domanda non riguarda "come posso proteggermi", ma piuttosto su "come funzionerebbe un exploit". La superficie di attacco sembra essere il tuo punto principale, il che è grandioso, ma offuscato da queste inesattezze e tangenti.
Merlyn Morgan-Graham,

3
Sì, stavo semplificando un po '... Non volevo ingombrare l'argomento con un dettagliato "in linea di principio potrebbe esserci un errore in wget che lo fa comportare inaspettatamente" a parte. Hai ragione ovviamente. Ho pensato che l'OP sembrasse nuovo sul campo e volevo concentrarmi sui problemi più fondamentali e concettuali della nostra società IT piuttosto che su problemi dovuti a guasti tecnici.
Kerrek SB,

-1 questa risposta non comprende il problema: "Le nostre richieste hanno portato alla creazione di tecnologie di esecuzione del codice lato client come JavaScript e Flash, che scaricano codice arbitrario, estraneo, non attendibile e dannoso e lo eseguono, tutto per nostro piacere". - l'intenzione non è scaricare codice arbitrario; e anche senza questi, otterremmo comunque virus da Internet. Puoi ottenere un virus aprendo un file .jpg in paint o guardando un film in VLC. Non è comune, ma è già successo prima.
BlueRaja - Danny Pflughoeft il

11

Il punto che è stato davvero eluso in queste risposte, che voglio davvero battere a casa, è questo: il motivo per cui è possibile ottenere un virus da una pagina Web è che alcuni software in esecuzione hanno un bug: una vulnerabilità della sicurezza .

In ogni fase del processo di creazione del software, i creatori di Flash; del tuo browser; del sistema operativo in uso ha cercato di accertarsi che un codice malevolo casuale proveniente da Internet non riesca a trovare un modo per eseguire se stesso. Sfortunatamente, farlo è difficile . Davvero difficile .

Quindi, come tutti gli umani, gli sviluppatori di questo software sono tenuti a fare errori: il parser HTML sovrascrive accidentalmente un byte nello stack quando si termina l'html con </p. Hanno accidentalmente usato un signed intinvece di ununsigned int . Il compilatore JIT JavaScript JIT tenta di dereferenziare accidentalmente un indice di array in un puntatore null. Tutte queste vulnerabilità e altre milioni si verificano continuamente nel software, a causa della mancanza di conoscenza della sicurezza, o di una svista, o anche solo di un semplice errore. Il software è semplicemente modo troppo complesso per catturarli tutti.

Per questo motivo, i sistemi operativi dispongono di meccanismi integrati per prevenire danni al sistema, anche quando viene rilevata una vulnerabilità. Il tuo sistema operativo probabilmente ha DEP e ASLR . I programmi possono avere varie protezioni aggiunte dal compilatore. I browser funzionano con privilegi inferiori. I programmi vengono eseguiti mediante analisi e test automatici che possono rilevare molte di queste vulnerabilità.

Il mio punto è che nessuno lascia che ciò accada, ma è impossibile progettare un software completamente sicuro, proprio come è impossibile progettare una cassaforte completamente sicura. Qualcuno con abbastanza tempo, conoscenza, denaro e incentivi troverà sempre un modo per aprirlo. E il problema con questa cassaforte è che, una volta che alcuni hacker hanno aperto la loro copia, possono facilmente aprire altre copie in tutto il mondo senza lasciare la loro stanza.


Ma in molti casi il bug è presente perché gli utenti lo hanno "richiesto". Vale a dire, le specifiche per HTML3.14159 sono difettose in quanto consentono alcuni comportamenti intrinsecamente rischiosi. E i progettisti di siti utilizzano le caratteristiche specifiche che provocano questi comportamenti, richiedendo che i progettisti di browser implementino i "feechurs" (o rischino di rimanere indietro nella "guerra dei browser"). Il progettista del browser probabilmente tenta di mitigare il comportamento rischioso in qualche modo e gli implementatori di antivirus accumulano controlli aggiuntivi, ma qualcosa riesce sempre a superare.
Daniel R Hicks,

@DanH: hai qualche esempio specifico di falle nella sicurezza che sono lasciate intenzionalmente in tutti i browser, perché gli utenti lo hanno richiesto?
BlueRaja - Danny Pflughoeft,

Non sto dicendo che i buchi siano lasciati lì intenzionalmente. Piuttosto, specifiche scadenti portano a implementazioni "rischiose" e in troppi casi l'implementazione non è (ovviamente) dimostrabilmente corretta dal punto di vista della sicurezza. (E non è dimostrabilmente corretto perché le specifiche non lo consentono.)
Daniel R Hicks,

Ah sì, l'informatica ... La scienza nel mondo in cui ci sono macchine che guidano nel modo sbagliato in una strada a senso unico per la metà del tempo, e si teletrasporta dall'altra parte.
Breakthrough

8

Le tue domande specifiche

Capisco che ovviamente posso ottenere un virus scaricando ed eseguendo un file .exe in Windows, ma come posso ottenere un virus accedendo a un sito Web?

Il tuo browser esegue codice continuamente (è fatto di codice). Quando scarica pagine Web, quel codice scarica e visualizza dati arbitrari (pixel, caratteri, ecc.).

Il codice è anche dati (a livello di processore).

Poiché il codice è un dato, se il tuo browser tenta di eseguire i dati (indipendentemente dall'estensione o dal formato del file), potrebbe effettivamente essere eseguito (se realizzato correttamente).

Normalmente il tuo browser non sarà così sciocco da provare a eseguire dati casuali scaricati. Tuttavia, questo può succedere.

Un modo per farlo è quello di formare i dati in modo tale che, quando letti, "filtrino" e sovrascrivano i dati che compongono il programma eseguibile del browser. Ciò richiede che il browser abbia un bug (più comunemente in questo caso, consentendo un sovraccarico del buffer ).

Il browser esegue anche programmi nella parte superiore delle pagine Web. Javascript, come hai detto, è uno di questi tipi di codice. Ma ce ne sono dozzine. ActiveX, Flash, componenti aggiuntivi, script Grease Monkey, ecc. Sono tutti codici che stai eseguendo mentre visiti le pagine web. Questo codice può contenere bug che causano problemi di sicurezza.

Questi virus attaccano sia gli utenti Windows, Mac e Linux o gli utenti Mac / Linux sono immuni?

Nessuna piattaforma che utilizziamo è completamente immune ai bug, poiché utilizzano tutti processori che trattano i dati come codice. Questo è semplicemente il modo in cui funziona la nostra architettura informatica esistente.

La ragione di questo mito è che Mac e Linux hanno tassi di adozione molto più bassi rispetto ai computer Windows (a livello desktop). Quindi il software desktop su queste macchine non è un obiettivo così comune per i produttori di virus.

I virus non si verificano per magia o per evoluzione dell'occorrenza (come fanno i virus biologici). È un software scritto da singoli o team di sviluppatori. E vogliono raggiungere la più grande quota di mercato, allo stesso modo dei normali venditori di software.

Per quanto riguarda se un virus può colpire più piattaforme; Tutti i browser eseguono codice diverso, quindi avranno bug diversi (anche lo stesso browser su piattaforme diverse). Ma ci sono alcune librerie di codice condivise tra piattaforme. Se tale libreria contiene il bug, è possibile che l'exploit possa esistere su più piattaforme.

Ma, a seconda del tipo di attacco effettuato, un virus scritto per un Mac non Intel potrebbe non funzionare su un Mac Intel e viceversa, poiché hanno processori diversi. Per processori diversi, i dati che rappresentano il codice hanno un formato diverso.

Quando si parla di una macchina virtuale o di un linguaggio di scripting, tuttavia, gli attacchi potrebbero essere indipendenti dalla piattaforma. Questo ci porta alla prossima domanda ...

I virus sono programmati in JavaScript?

Alcuni virus lo sono. Le informazioni che ho dichiarato sopra (sugli exploit di sovraccarico del buffer) verrebbero normalmente utilizzate come attacco al di fuori di Javascript, ma potrebbero ugualmente applicarsi a un virus creato per attaccare un exploit in un interprete Javascript.

Javascript avrà anche una propria serie di exploit, a un livello operativo superiore ai sovraccarichi del buffer. Esistono molti modi per attaccare qualsiasi software. Più è grande il software (righe di codice), più varietà di input dell'utente (in questo caso, tipi di codice) è probabile che riceva e più bug può contenere.

Inoltre, più esposto è un software in esecuzione (ad esempio software che esegue un server), più è vulnerabile agli attacchi.

In generale, questo si chiama Attack Surface

Sfrutta in generale

Microsoft ha un mnemonico per i tipi di exploit comuni e tutti hanno le loro proprietà interessanti e diversi livelli di software che possono attaccare: STRIDE , che significa:

Spoofing (of user identity)
Tampering
Repudiation
Information disclosure (privacy breach or Data leak)
Denial of Service (D.o.S.)
Elevation of privilege

Alcuni di questi hanno maggiori probabilità di essere utilizzati in un attacco basato su Javascript rispetto ad altri, alcuni sui server, altri sui file di dati (come le immagini).

Ma la sicurezza è un campo grande ed in evoluzione. Ci sono davvero troppe informazioni per rispondere completamente a tutte le tue domande.


Quando hai a che fare con linguaggi interpretati (contro compilati), gli exploit sono di solito indipendenti dall'architettura. Un'applicazione (o virus) compilata per una diversa architettura di processore semplicemente non verrà eseguita (a meno che il processore non contenga un livello di compatibilità).
Breakthrough

@Breakthrough: chiedono "sono programmati in javascript?" non rende meno vero ciò che ho detto, soprattutto se applicato a "come posso ottenere un virus accedendo a un sito Web". Hanno posto più domande e ciò che ho descritto si è applicato a una parte della domanda, se non a tutto.
Merlyn Morgan-Graham,

@Breakthrough: ho aggiunto ulteriori informazioni su Javascript in particolare e le minacce in generale.
Merlyn Morgan-Graham,

@Merlyn Morgan-Graham, mi riferivo in particolare quando hai detto "... un virus scritto per un Mac non Intel potrebbe non funzionare su un Mac Intel e viceversa, perché hanno processori diversi". e non la tua intera risposta.
Breakthrough

1
@Merlyn Morgan-Graham "La ragione di questo mito è che Mac e Linux hanno tassi di adozione molto più bassi rispetto alla macchina Windows"
Lincity

7

Il termine si chiama "Drive By Download"

Ecco un bell'esempio di come succede senza che tu faccia altro che visitare un sito web.

Schneider ha affermato che il team di ricercatori dell'azienda ha scoperto un pezzo di JavaScript sulla pagina che stava iniettando un iframe che indicava un sito dannoso. Un'ispezione più approfondita ha rivelato che stava utilizzando un exploit di IE precedentemente sconosciuto (0 giorni) in grado di arrestare in modo anomalo una versione completamente corretta di quel browser ed eseguire codice dannoso. La durata di 0 giorni è stata di breve durata, poiché Microsoft ha presto rilasciato dettagli sulla vulnerabilità.

Un'ulteriore analisi del codice shell ha rivelato un URL in chiaro che punta a un server dannoso noto, che è stato archiviato nel repository M86 come sfruttando la nota vulnerabilità iepeers.dll, MS10-018.


+1 per essere l'unica risposta finora ad usare il termine corretto.
Breakthrough

3

Il trucco è che i produttori di virus / esperti di sicurezza trovano buchi nei browser. In parole semplici, trovano un buco nella sicurezza del browser e sono in grado di utilizzare questo buco per fare qualcosa al tuo sistema. Ci sono casi in cui Adobe Flash ha avuto buchi e con un codice specifico potrebbe essere sfruttato. Esistono anche stringhe javascript che possono attivare queste falle di sicurezza.

Tuttavia, se mantieni aggiornato il tuo browser, è molto improbabile che ti venga infettato semplicemente visitando un sito Web (scaricare file ed eseguirli è un'altra storia!)


Esistono bug di sicurezza in ogni software esistente. Non tutti vengono trovati. Microsoft Paint ha avuto a lungo un brutto bug, ad esempio, che è stato facilmente riproducibile (in pochi minuti) semplicemente lanciando i dati generati casualmente come "immagini" nella finestra di dialogo "file-> apri".
Merlyn Morgan-Graham,

Bene, sono sicuro che ci sia stato un po 'di software scritto da qualche parte senza bug di sicurezza. (Penso di averne forse scritto uno o due da solo.) Ma hai ragione. Circa 35 anni fa qualcuno ha dimostrato dozzine di bug in Unix semplicemente inserendo caratteri casuali nel parser dei comandi della shell. Si è schiantato la macchina in pochi minuti.
Daniel R Hicks

2

I virus come quelli che ti infettano visitando un sito web sfruttano un difetto nel sistema di visita. Ad esempio, un browser o un plug-in potrebbe avere un difetto nella sua programmazione in modo che a un'immagine possa essere consentito (accidentalmente, dal punto di vista dello sviluppatore del browser) di eseguire un comando arbitrario sul computer in visita.

In quanto tale, presumibilmente ogni sistema operativo è una potenziale vittima, ma gli autori di virus in genere incorniciano i loro attacchi in base alle economie di scala: più utenti, meglio è. Ecco perché Windows e Internet Explorer sono più spesso presi di mira.

Qualsiasi parte di un browser o plug-in potrebbe essere bersaglio di un virus. L'immagine sopra citata che ha causato un virus è stata un vero esempio. Flash è un obiettivo comune. Lo è anche il motore JavaScript nei browser. Ci sono molte cose diverse che possono andare storte.

La soluzione migliore è eseguire uno scanner antivirus di qualità. Ho usato NOD32 di Eset . Inoltre, non fare clic su qualcosa se è troppo bello per essere vero. Usa NoScript in Firefox e AdBlock .


1

Questi virus attaccano gli utenti Windows, Mac e Linux o gli utenti Mac / Linux sono immuni?

Se un sito web riesce a violare la sicurezza del browser, potrebbe muck con tutto ciò che appartiene a voi sul computer. Tuttavia, se può intensificare i suoi privilegi e ottenere l'accesso amministrativo, allora potrebbe confondere con qualsiasi cosa sul sistema.

Da tempo si ritiene che sia più difficile ottenere i privilegi di amministratore su una macchina Unix (es. Linux, Mac o BSD) che su Windows. Tuttavia, il recente rinnovamento (a partire da Windows Vista) delle funzionalità di sicurezza di Microsoft potrebbe aver reso Windows molto più sicuro di prima - o almeno, è quello che vorrebbero farti credere.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.