Domanda:
È possibile allegare malware a un'immagine?
user2143356
2014-04-08 02:39:15 UTC
view on stackexchange narkive permalink

Ho un numero limitato di dipendenti che utilizzano un computer aziendale, ma queste persone non sono molto esperte di tecnologia. Usano un client di posta elettronica e un client di messaggistica.

Sono abbastanza sicuro che non farebbero clic sul file .exe o .zip in un'e-mail senza pensarci, e so che è un'area di preoccupazione.

Tuttavia, sto pensando alle immagini. In effetti, indipendentemente dalle capacità di una persona con la tecnologia, credo che allegare cose (codice o altro) a un'immagine possa essere un rischio per la sicurezza.

Cosa si può allegare alle immagini per danneggiare un altro?

Credo che le immagini possano rappresentare un rischio per la sicurezza in quanto "vengono eseguite automaticamente" o qualcosa del genere.

Ci sono tanti modi in cui le immagini possono essere ricevute da un computer (inclusi telefoni o tablet corso):

  - email- iMessage (o qualsiasi altra app di messaggistica) - qualcuno che fa clic con il pulsante destro del mouse e salva un'immagine da una pagina web - semplicemente visualizzando una pagina web ovviamente scarica l'immagine nella cache 

Quali precauzioni devo prendere riguardo alle quattro cose precedenti? Qualcuno può semplicemente allegare del codice a un'immagine ed eseguirla?

Cosa devo fare per evitare che le immagini vengano utilizzate sui miei computer?

Immagino che non potresti basta allegare il codice a un'immagine e iMessage l'iPhone di qualcuno. E Android?

Questa domanda sembra rivolgersi principalmente agli utenti finali.Tuttavia può valere la pena notare che i server sono in realtà ancora più presi di mira da questo tipo di attacco, di solito attraverso un qualche tipo di meccanismo di caricamento dei file di immagine, poiché a differenza degli utenti finali con server, l'aggressore che ha caricato il file dannoso è anche libero di attivarloesecuzione nel modo desiderato (non c'è bisogno di aspettare e sperare che un utente esegua una determinata azione).Puoi vedere alcuni esempi [qui] (https://security.stackexchange.com/q/32580/32746) e [lì] (https://security.stackexchange.com/q/90968/32746) oltre che sualtri post correlati.
Nove risposte:
#1
+75
jamesdlin
2014-04-08 06:58:35 UTC
view on stackexchange narkive permalink

Le altre risposte parlano principalmente di allegare codice arbitrario alle immagini tramite tecniche steganografiche, ma questo non è molto interessante poiché richiede che l'utente sia complice nell'estrarlo e nell'eseguirlo. L'utente potrebbe semplicemente eseguire codice dannoso direttamente se questo è il suo obiettivo.

Sei davvero interessato a sapere se c'è la possibilità di esecuzione di codice arbitrario e inaspettato durante la visualizzazione di un'immagine. E sì, esiste una tale possibilità che un utente malintenzionato crei un'immagine dannosa (o qualcosa che afferma di essere un'immagine) che prende di mira implementazioni di visualizzazione di immagini specifiche con difetti noti. Ad esempio, se un visualizzatore di immagini alloca un buffer e calcola la dimensione del buffer necessaria da un ingenuo calcolo di width * height * bytes_per_pixel , un'immagine dannosa potrebbe riportare dimensioni sufficientemente grandi da causare l'overflow del calcolo precedente, facendo sì che il visualizzatore allochi un buffer più piccolo del previsto, consentendo quindi un attacco di overflow del buffer quando i dati vengono letti al suo interno.

Esempi specifici:

In generale, questo genere di cose è difficile da proteggere. Alcune cose che puoi fare:

  • Mantieni aggiornati i tuoi sistemi e le tue applicazioni.
  • Abilita DEP.
  • Abilita ASLR se possibile.
  • Evita di eseguire programmi con privilegi di amministratore.
  • Su Windows, anche Microsoft EMET potrebbe fornire una certa protezione.
Questa, per me, è l'unica risposta corretta. Tutte le altre risposte coinvolgono l'utente deliberatamente, in modo dannoso, che estrae malware nascosto in un file immagine e l'OP ha affermato che gli utenti non erano esperti di tecnologia, quindi è molto improbabile.
L'OP ha chiesto informazioni sulla prevenzione, quindi probabilmente vale anche la pena ricordare che il problema può essere ampiamente prevenuto assicurando che gli aggiornamenti di sicurezza vengano applicati tempestivamente ai sistemi e installando software antivirus su qualsiasi sistema basato su Windows.
Non c'è nulla di "steganografico" nello sfruttamento delle vulnerabilità elencate.È piuttosto una tecnica RARJPEG.
@FreeConsulting Hm?La mia risposta non ha nulla a che fare con la steganografia, né ho affermato di sì.
"... alle immagini tramite tecniche steganografiche ..."
@FreeConsulting Quella citazione si riferiva ad [alcuni] (https://security.stackexchange.com/a/55062/43625) degli [altri] (https://security.stackexchange.com/a/55064/43625) pubblicati [risposte] (https://security.stackexchange.com/a/55125/43625).* La mia * risposta non ha nulla a che fare con la steganografia.
Si, lo so.Tuttavia non ha senso discutere con una risposta sbagliata (nello scenario del PO non c'è nessuna parte che riceva un messaggio stenografico).
#2
+11
bob
2014-04-08 05:43:36 UTC
view on stackexchange narkive permalink

Yes, there are ways to 'exploit' buffer overflows.

Sometimes the code may need to be executed via a separate script, and in theory you could assemble a virus from multiple images that contained code hidden within the picture using stenography but there are easier ways.

Basically many computer systems expected images to comply with the exact specification for the type and the failed to correctly range check the formats/parameters being passed.

By 'engineering' an image so that externally it looks like it complies but internally it does not, it was to be possible to trigger stack corruption/buffer overflows that would allow code hidden in an image to be executed under the authority of the user.

But note that this does not ONLY apply to images, it can apply to ANY file, take a look at the recent RTF exploit in MS word.

#3
+7
Matthew Peters
2014-04-08 02:48:38 UTC
view on stackexchange narkive permalink

You can always hide files/programs/anything in the 'slack space' of any file. Then you could run a script later to extract and/or compile what you have hidden... For instance, you could embed a malicious executable (or smaller script) within multiple images on a website. When a user goes to the website, they download the images.

Learn more about Slack Space here: http://www.computerhope.com/jargon/s/slack-space.htm and then play around with it yourself by grabbing a hex editor (http://mh-nexus.de/en/hxd/) and messing around.

Grazie, alcune buone informazioni. Che ne dici di eseguire il codice dannoso? La tua risposta spiega come qualcuno potrebbe nascondere il codice. Sicuramente non possono semplicemente incorporare un .exe in un'immagine e ogni visitatore web ha quel file eseguito. Vedo che è molto facile per qualcuno incorporare il codice, ma non riesco a credere che qualcosa funzionerà volenti o nolenti. L'hacker deve fare qualcosa di specifico per attivare l'esecuzione del codice?
Ci sono due modi fondamentali in cui può verificarsi un attacco dallo spazio lento. Il più semplice è memorizzare semplicemente il codice veramente cattivo (quello che è più probabile che venga rilevato da uno scanner antivirus) nello spazio libero e quindi "attivare" il codice con un metodo più tradizionale. Ad esempio, potresti andare su un sito torrent e non direttamente dl un virus stesso ma solo il file torrent apparentemente innocuo (per il tuo Scanner Virus) tutto il tempo mentre il tuo browser è dl il vero virus in tutti quei banner pubblicitari ' . L'altro modo è incorporare il metodo di chiamata all'interno della parte dell'immagine "reale".
Ecco un bell'articolo su tutti i diversi tipi di virus dello spazio lento e tale http://computervirus.uw.hu/ch04lev1sec2.html sezione 4.2.13.6 è probabilmente più utile per descrivere il mio secondo metodo.
L'incorporamento della chiamata nella parte dell'immagine non funzionerà. l'unico modo per eseguire un virus come questo sarebbe richiamare direttamente il codice nell'immagine dannosa da un altro eseguibile o script.
Quindi posso essere sicuro che anche se le immagini possono contenere tutti i tipi di malware incorporati (spazio inutilizzato, EXIF, ecc.) Il solo visualizzare e scaricare immagini non infetterà il mio computer e che il codice in queste immagini deve farlo essere eseguito da uno script separato?
@Kotzu, ha ragione nel dire che il codice dannoso non può essere eseguito solo perché l'immagine viene caricata (per quanto ne so). Tuttavia, il codice è ancora lì e può essere chiamato da qualsiasi numero di altri vettori. C'è stato un tempo in cui i browser consentivano persino collegamenti diretti a file locali direttamente da una pagina web ... Ad esempio, 'codice errato' nello spazio non Slack poteva ancora essere pericoloso se sfrutta un problema del programma legittimo che caricava l'immagine (simile a un'iniezione SQL, potresti lanciare alcuni metadati errati e farlo interpretare da Firefox). Per rispondere alla tua domanda, direi che l'utente medio è al sicuro per il 90% del tempo.
@MatthewPeters La possibilità di eseguire codice dannoso quando viene caricata l'immagine è un problema di qualità dell'implementazione. I decoder di immagini possono avere bug che portano a overflow del buffer (che quindi potrebbero portare all'esecuzione di codice).
Windows ha i loro video eseguibili (WMA) resistenti ai virus, hanno anche l'equivalente dell'immagine?
Ma i dati trasmessi dalla rete non hanno rallentamenti fino a quando non vengono scritti nella memoria ...
#4
+3
Peteris
2014-04-08 13:55:58 UTC
view on stackexchange narkive permalink

Per quasi tutti i formati di file, i programmi che lo leggono potrebbero avere alcuni bug sfruttabili da un file pericoloso.

Può succedere (ed è successo) anche per le immagini; ma generalmente sarebbe limitato a un singolo programma particolare (o libreria) che lo legge, non a una "immagine con malware" generale che attacca tutti questi programmi.

Anche i file di testo non sono teoricamente sicuri se il i programmi cercano di fare qualcosa di interessante con loro. Un'iniezione sql in un post di commento sul blog è essenzialmente "malware allegato al testo"; c'era una vulnerabilità in Python che permetteva l'arresto anomalo (= denial of service) inviando dati di testo dannosi e sostenendo che era nella codifica UTF-7, sfruttando un bug in quel decoder; e esistono attacchi basati sulla violazione di analizzatori XML da parte, ancora una volta, di dati quasi testuali dannosi.

#5
+1
Ubaidah
2014-04-08 03:01:06 UTC
view on stackexchange narkive permalink

Sì, è possibile nascondere il malware in un'immagine. Non è affatto un attacco molto comune, ma recentemente sembra che gli autori di malware inizino a nascondere malware all'interno delle immagini.

L'analisi del malware non fa per me. se desideri maggiori informazioni, cerca " Steganography Malware" .

Un consiglio è di non aprire email da fonti non attendibili / sconosciute.

#6
+1
user3437670
2014-04-08 09:53:30 UTC
view on stackexchange narkive permalink

Gli exploit sono proprio questo, gli exploit. Qualcuno trova una vulnerabilità in un codice ampiamente utilizzato e quindi si propone di preparare il terreno affinché quella vulnerabilità faccia la sua cosa. Facciamo finta, ad esempio, che qualcuno là fuori abbia capito che un client di posta elettronica ampiamente utilizzato ha un bug che porta a un overflow del buffer in alcune circostanze specifiche. Se un numero sufficiente di dati non validi viene inserito nel buffer, viene sovraccaricato nello stack. Ora puoi acquisire un'immagine, malformata esattamente come deve essere per causare il sovraccarico del buffer, incorporarvi del malware e riempire la fine dei dati con un mucchio di NOP e poi una routine di assemblaggio intelligente che viene scaricata sul stack, che quando viene eseguito punta direttamente al malware già caricato in memoria nel buffer dell'immagine. Tutto ciò che un utente deve fare per essere infettato è visualizzare l'immagine non corretta nell'applicazione vulnerabile. Questo è un canale di attacco più comune negli exploit zero-day altamente specifici.

I rimedi a questi problemi sono fortunatamente facili da applicare. Configurare le macchine per consentire solo i messaggi di testo normale. Assicurati di utilizzare solo software ben mantenuto e di applicare automaticamente tutti gli aggiornamenti.

"Configura le macchine per consentire solo messaggi di testo normale" Ma puoi facilmente incorporare malware in testo normale. Diciamo, script di shell o VBScript.
#7
+1
Man Person
2014-04-08 20:03:59 UTC
view on stackexchange narkive permalink

Esistono programmi chiamati raccoglitori che normalmente allegheranno un eseguibile a un'immagine. I malware trovati nelle immagini tendono ad essere RAT (Remote Administration Tools) che sono alcune cose skid che alcuni skid useranno per accedere al tuo computer. Normalmente questo viene usato solo sui siti web in cui gli idioti arrapati parlano con questi pattini, e questi fingono di essere una ragazza e dicono loro di scaricare un'immagine. Personalmente penso che ci siano modi molto migliori per diffondere le cose, inoltre la maggior parte degli antivirus dovrebbe rilevare questi "legami" anche se il virus è FUD (completamente inosservato).

#8
+1
Drunken Code Monkey
2014-04-12 11:17:25 UTC
view on stackexchange narkive permalink

The of plain text messages is that when the mail client is only reading plain text, none of the potentially dangerous or hidden scripts will be interpreted or run at all. It will just be a string to the mail client.

#9
  0
user2497
2017-06-08 00:50:49 UTC
view on stackexchange narkive permalink

Esiste un esempio di una vulnerabilità descritta qui: esecuzione completa del codice su sistemi Windows, se javascript era abilitato => SVG SNAFU.

Info:

Joshua Yabut, un altro ricercatore che ha anche analizzato il codice, ha detto ad Ars che sfrutta un cosiddetto bug use-after-free che richiede l'abilitazione di JavaScript sul computer vulnerabile. Yabut ha continuato dicendo che il codice è "efficace al 100% per l'esecuzione di codice in modalità remota su sistemi Windows". Il codice di exploit, ha aggiunto il ricercatore, regola la posizione di memoria del payload in base alla versione di Firefox sfruttata. Le versioni vanno da 41 a 50, con la versione 45 ESR che è la versione utilizzata dall'ultima versione del browser Tor. Le modifiche indicano che le persone che hanno sviluppato l'attacco lo hanno testato ampiamente per assicurarsi che funzionasse su più versioni di Firefox. L'exploit effettua chiamate dirette a kernel32.dll, una parte fondamentale del sistema operativo Windows. Fonte



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...