Mi è venuto in mente solo pochi anni fa molte applicazioni iOS dove infetto da XcodeGhost (in particolare WeChat). Questo mi ha fatto pensare a pochi possibili scenari:

Codice dannoso iniettato nei file oggetto

I compilatori producono molti file temporanei e questi file, spesso, non vengono nemmeno scansionati dal software AV perché rallentano visibilmente la compilazione, anche se la minaccia viene rilevata in seguito, con un certo euristico, sull'eseguibile compilato spesso lo ignoriamo come falso positivo ( "hey, è MY code" ).

Un'applicazione dannosa (probabilmente un Trojan) è in esecuzione con privilegi bassi ma ha (ovviamente?) l'accesso ai dati dell'utente. Un'applicazione dannosa può FACILMENTE iniettare codice dannoso nei file di oggetti intermedi generati dal compilatore e il codice dannoso farà parte della nostra applicazione compilata. Inoltre, il compilatore può applicare ottimizzazioni intra-modulo, mescolando codice malevolo con il nostro rilevamento del codice nel file eseguibile prodotto più difficile.

Ovviamente l'hacker deve conoscere il formato esatto del file, l'architettura di destinazione e la versione del compilatore ma è fattibile per supportare poche architetture e compilatori popolari.

Nessuno, presumo, controllerà il codice generato ... nemmeno quando è facile decompilare come per .NET e Java.

Codice dannoso iniettato nei file temporanei

I file temporanei sono spesso (almeno nella mia esperienza) trattati come parte dell'applicazione e considerati sicuri . A meno che non utilizzi uno strumento come VERACODE in cui ogni input esterno viene considerato compromesso , un'applicazione malevole può leggerla e modificarla, modificando il comportamento di un'altra applicazione e, in alcune circostanze, persino iniettando codice o sfruttando un altro problema di sicurezza.

È vero che i dati sono considerati condivisi ma non è raro (non dirò in quali applicazioni ...) archiviare una cache di codice eseguibile come file temporaneo che può essere manomesso e forzare l'applicazione host per eseguire codice dannoso. Si apre a tre possibilità: l'applicazione host può eseguire azioni indesiderate , condividere dati che dovrebbero essere riservati o eseguire qualcosa con privilegi elevati.

Una combinazione di questo approccio e quella precedente: un utente malintenzionato può semplicemente modificare la makefile generata da un IDE come file temporaneo in includere la sua libreria (o il file obj).

Almeno su Windows, i file temporanei sono quindi aperti all'iniezione anche da un'applicazione non superiore (poiché la protezione è per utente).

L'applicazione dannosa può leggere i dati privati

È sorprendente la quantità di dati memorizzati nei nostri file temporanei, alcuni non dovrebbero essere visibili a un'applicazione con privilegi bassi ma, ancora una volta, la protezione è per utente. anche se non si inserisce alcun codice, un'applicazione dannosa può leggere dati che non ha le autorizzazioni per leggere (e ho fatto una scansione molto veloce negli avanzi della mia cartella temp di Windows ... tutti i file temporanei correttamente cancellato dopo alcune centinaia di millisecondi può contenere anche dati più sensibili).