Trojan

Per capire come funziona questo trojan è necessario ripercorrere alcuni aspetti funzionali e storici del sistema operativo Linux. In particolare questo attacco non sfrutta una vera e propria vulnerabilità, ma fa leva su una funzione standard per la gestione dei permessi chiamata bit SUID e sulla componente socio-tecnologia relegata maggiormente agli anni ‘90 per quanto riguarda la variabile PATH.
Aspetto funzionale: Se il bit SUID è settato allora chiunque, potrà eseguire filename con i permessi di chi ha eseguito il file. E’ chiaro che se filename è stato creato da un amministratore, un utente che eseguirà filename assumerà per quello specifico file i permessi di root.
Aspetto socio-tecnologico: quando si lancia un comando l’eseguibile associato a questo viene ricercato nelle directory che sono scritte nella variabile d’ambiente $PATH. $PATH è organizzata in modo da andare a cercare l’eseguibile nel percorso che si trova scritto più in alto; se non viene trovato allora la ricerca viene fatta nella directory scritta successivamente e così via finché l’eseguibile non viene lanciato oppure non viene trovato niente. In passato nel PATH come prima entry c’era la directory corrente ovvero “.” perchè file ed eseguibili spesso si trovavano nella stessa directory. Quindi era comodo usare come prima directory di ricerca quella corrente.
Avendo fatto queste premesse ecco come funziona LS-TROJAN:
La vittima riceve un shell script mascherato dall’eseguibile ls, quando lo eseguirà effettuerà le seguenti operazioni:
-Copiare la shell (interprete dei comandi) su /tmp/.xxsh (quindi nascosto, occultato nella directory)(carico del malware)
-Viene dato all'user il permesso s(bit suid) e agli altri soltanto la possibilità di eseguire.(carico del malware)
-Eliminazione del file ls (quindi autodistruzione del trojan)
-Lancio di ls di sistema Lo script ls trojan è molto semplice, viene eseguito dalla vittima in quanto si assume che quest'ultima non sia competente abbastanza da eseguire un file in modo sicuro o meno. Pertanto c'è sempre una compartecipazione da parte della vittima.
Seconda variante:
ls-trojan V2 invece, al posto di creare il file direttamente in /tmp, prima lo crea nella cartella corrente e quindi fa chmod all’eseguibile appena copiato. Solo successivamente chmod verrà spostato con “mv” nella cartella /tmp.

Soluzione SElinux:
1) Non consentire ad utente_u di eseguire il chmod il file creati in /tmp
2) Non consentire ad utente_u di eseguire file creato nella cartella /tmp
In realtà solo uno dei due accorgimenti sarebbe sufficiente a confinare l’attacco, ma c’è una leggera differenza: (1) protegge la vittima mentre (2) confina l’attaccante. La soluzione data per la prima versione nella seconda variante non sarà quindi più valida dal momento che il comando mv, che sposta il file “chmoddato” in /tmp, preserverà il security context di esso.
Soluzione variante: Non consentire ad utente_u di eseguire un qualsivoglia file creato da esso nella propria user home, a meno che non gli assegni il SELinux type “bin_t”
In realtà questa seconda soluzione può essere valida soltanto se si va a considerare il comportamento di default di Linux che non consente di modificare gli attributi di un file che non è di proprietà. Incorporando nella policy le due soluzioni confiniamo ogni variante di questo trojan.

Soluzione AppArmor:
Il modo che ha AppArmor per hardenizzare il sistema, consiste nel limitare ogni applicativo con un profilo personalizzato. Data questa premessa, creare un profilo per il trojan non è una scelta sensata in quanto se l’utente individua il trojan, non va a creare l’apposito profilo, piuttosto lo elimina! Dunque l’unico modo che ha AppArmor per confinare l’attacco del trojan è agire sulle funzioni utilizzate da quest’ultimo (cp / chmod). Limitare cp, impedendogli di scrivere su /tmp/ è troppo limitativo per l’intero sistema, in quanto tale directory è usata proprio per copiare file temporanei al suo interno. La soluzione adottata consiste nell’hardenizzare la funzione chmod, creando un profilo specifico in cui inseriamo la regola “deny /tmp/** w” così che, quando chmod prova a cambiare i permessi della shell copiata su /tmp/, l’operazione viene negata.
In merito alla seconda versione del trojan, la limitazione su chmod appena discussa non ha alcun effetto in quanto, quest’ultima operazione, viene effettuata in una directory diversa da /tmp/. L’unico approccio possibile, sarebbe impedire al comando “mv” di scrivere in /tmp/, tuttavia questa soluzione sarebbe estremamente limitativa per l’intero sistema, risultando una strada non percorribile.

Soluzione Tomoyo:
Per risolvere l’attacco bisogna effettuare alcune limitazioni al pathname dell’eseguibile /bin/chmod. Innanzitutto bisogna aggiungere una eccezione che reinizializzi il pathname per poterlo identificare univocamente (indipendentemente dalla sua storia di esecuzione). Quindi bisogna imporre a chmod di non poter aggiungere i permessi di esecuzione a file presenti su /tmp.
Soluzione variante:
Tomoyo non permette di bloccare questo Trojan in quanto non può controllare con quali permessi viene fatto il mv del file. L’unico approccio possibile potrebbe essere limitare l’utilizzo del bit SUID ovunque, oppure di impedire al comando mv di scrivere in /tmp, tuttavia questa soluzione sarebbe limitativa per l’intero sistema.

Soluzione GrSecurity:
Il lavoro fatto con GrSec è stato all'opposto rispetto ai miei colleghi, capire perchè l'attacco non funzionava.
Con le impostazioni di default l’attacco non funzionerebbe, per due motivi:
1) Per via del TPE (Trust Path Execution), dove ogni utente deve esser aggiunto ad un gruppo (grsec-tpe) per poter eseguire binari.
2) L’altro per via della policy di default che non permette di eseguire su /tmp e non permette di copiare il bit suid, a meno che non sia specificato con il parametro m, sulla singola cartella dove si vuole concedere la possibilità di copiare il bit-suid.
Nel ls-trojan V2, sempre supponendo di cambiare i permessi di /tmp rendendolo eseguibile, l’attacco potrebbe funzionare solo se concedo la possibilità di copiare il bit suid nella home, ma è altamente improbabile che per un utente generico, l’amministratore conceda di copiare il bit-suid nella propria home.