Come abbiamo già detto, un Penetration Test è un susseguirsi di ricerche e di attacchi. L’enumeration è fondamentale. non possiamo attaccare un servizio se non sappiamo che è in ascolto. Se Steve Ballmer dovesse fare un discorso a dei Penetration Tester, probabilmente batterebbe la mani su “Enumeration, Enumeration, Enumeration, Enumeration” allo stesso ritmo del suo famoso “Developers, Developers, Developers, Developers” [1] (ok, fa ridere solo a me 🙂 ). Presupponendo di aver già identificato i sistemi su cui eseguire la nostra attività, è importante avere una strategia efficace delle porte aperte e come capire quali siano i servizi esposti. Come fare – velocemente – a capire quali sono le porte aperte e i servizi in ascolto? Questo approccio è particolarmente utile – per esempio – per l’OSCP.
Metodologie, scansioni ed enumeration
Una volta che sappiamo quali sono i sistemi su cui andiamo a fare il Penetration Test e focalizzandoci su quanto disponibile sui protocolli TCP e UDP, il NIST SP-800-115 [2] e per la fase di ricerca consiglia quanto segue:
“L’enumeration si comincia utilizzando tecniche di network discovery e scanning per determinare i sistemi e i servizi in ascolto”
L’OSSTMM v3 [3] – nel capitolo 11 (che appunto riguarda i test della parte Data Network) è più specifica e ha una lunga lista di controlli, ma focalizziamoci sui seguenti:
- Verificare le risposte che si hanno inviando pacchetti UDP sulle porte 0-65535
- Verificare le risposte che si hanno inviando pacchetti TCP SYN sulle porte 0-65535.
- Verificare i service banner che si hanno in risposta alle porte TCP in ascolto.
- Verificare i service banner che si hanno dalle interazione coi servizi [TCP e UDP NdR] inviando richieste valide e non valide.
- Far corrispondere ad ogni porta aperta per protocollo un servizio e/o un applicazione con la relativa versione.
Il PTES [4] considera di eseguire invece delle prime attività di scanning durante la fase attiva dell’Intelligence Gathering e quindi andare più in profondità nella fase di Vulnerability Analysis ovviamente attiva (facendo le scansioni interagiamo coi bersagli) enumerando le porte aperte, i servizi in ascolto e facendo banner grabbing per capire – per esempio – la versione.
Se utilizzassimo invece una logica più vicina alle Minacce Avanzate e Persistenti (Advanced Persistent Threat – APT) saremo in fase di Recon utilizzando la tattica “Network Service Scanning” particolarmente difficile da identificare se fatta dall’esterno dove spesso è presente un gran rumore di fondo.
Enumerazione delle porte TCP e UDP
I protocolli TCP e UDP in breve
Per capire come eseguire dell’enumerazione sono necessarie delle conoscenze teoriche di base sul TCP e sull’UDP.
Transmission Control Protocol (TCP) [5]
Una delle caratteristiche del protocollo TCP è la gestione della sessione. Quindi prima di arrivare al Layer 7 – il livello applicativo del servizio che vogliamo enumerare – dobbiamo stabilire una sessione TCP al Layer 4. Durante l’enumerazione delle porte aperte questo facilita notevolmente il lavoro di scansione. Per stabilire una sessione TCP, è descritta nell’RFC una procedura chiamata “three-way handshake”:
- Nel primo passo: Il sistema A invia un pacchetto con il flag SYN attivo verso il sistema B, per una porta specifica.
- Nel secondo passo (se il sistema B ha la porta richiesta in ascolto): Il sistema B invia un pacchetto con i flag SYN e ACK attivati verso il sistema A.
- Nel terzo passo: Il sistema A invia un pacchetto con il flag ACK attivo verso il sistema
Come da RFC, quindi:
- Se la porta è aperta riceviamo un SYN-ACK
- Se la porta è chiusa:
- da RFC possiamo ricevere un RST.
- Oppure si potrebbe NON ricevere una risposta. Infatti anche se la porta è chiusa, potrebbe essere presente un firewall che si occupa semplicemente di scartare la richiesta senza rispondere.
Quindi diamo per assunto che la porta TCP è aperta se riceviamo il SYN-ACK, altrimenti la consideriamo chiusa. E’ inoltre possibile che il three-way handshake venga completato e poi non sia possibile interagire al Layer 7, qui si aprono diversi scenari, come ad esempio un filtro a livello applicativo (Layer 7). In generale possiamo considerare il noto TCP joke per ricordare come funziona il protocollo:
User Datagram Protocol (UDP) [6]
Diversa è l’enumerazione sul protocollo UDP. Questo protocollo infatti non prevede la sessione o la gestione degli errori al Layer 4. In UDP, che è stato progettato pensando ad una maggiore velocità, queste funzionalità sono demandate direttamente al Layer 7. Pertanto scansionando UDP possono succedere diverse cose:
- Se la porta è in ascolto:
- e la richiesta è corretta (richiesta applicativa) possiamo ricevere una riposta.
- e la richiesta è sbagliata (per esempio facciamo una richiesta DNS ad un servizio diverso) è possibile sia
- ricevere una riposta
- sia NON riceverla (dipende secondo il protocollo specifico e la sua implementazione si potrebbe ricevere anche non ricevere una risposta di errore.
- Se la porta NON è in ascolto è possibile:
- ricevere un pacchetto ICMP Type 3 Code 3 “Port Unreachable” (ma molto dipende dagli apparati che sono tra noi e i bersagli e dalla frequenza delle nostre richieste)
- oppure più semplicemente NON ricevere una risposta. 🙂
Quindi enumerare servizi UDP è tendenzialmente può complesso, come possiamo leggere dal TCP joke:
Per enumerare le porte ha senso quindi inviare dei pacchetti – normalmente dei pacchetti SYN (lato TCP) e UDP (possibilmente con richieste applicative) e osservare come reagisce il bersaglio.
Considerando che un sistema può avere 65536 porte (da 0 a 65535) per protocollo, per ogni sistema abbiamo almeno 131072 pacchetti. I pacchetti non sono pochi anche se escludiamo la ritrasmissione e il timeout. Quindi l’operazione non è necessariamente veloce. E’ importante scansionare tutte le porte in quanto diamo per scontato che è possibile che i servizi ascoltino su porte non standard 🙂 . In generale, al netto dei casi citati per pacchetti UDP e TCP è possibile ricevere anche ulteriori risposte che vanno interpretate a parte.
Come per tutte le fasi di un Penetration Test anche in questo caso la strategia è quella di procedere in maniera iterativa e incrementale per avere man mano la copertura completa delle porte TCP e UDP. Il primo passo sarà quello di capire quali sono le porte aperte (eventualmente concentrandoci su quelle dove più probabilmente è presente il servizio) e poi capire i servizi in ascolto.
Gli strumenti per l’enumeration
Sono diversi gli strumenti che possiamo utilizzare per fare la scansione di porte TCP e UDP.
Anzitutto il pluricitato netcat, che può essere usato come segue dove possiamo osservare una porta aperta:
# nc -vvnzw 1 192.168.1.103 21 (UNKNOWN) [192.168.1.103] 21 (ftp) open sent 0, rcvd 0
Oppure Nmap [7], Unicornscan [8] e Sparta [9], che rendono il lavoro normalmente più veloce ed efficace, se usati con criterio.
Nmap uno tra i più, se non il più usato network scanner – che consta delle apparizioni nella trilogia di Matrix [10] – e ha numerose funzionalità oltre un gran numero di plugin/script che lo rendono molto versatile.
Unicornscan è sempre un port scanner, nasce con lo scopo della velocità e il suo funzionamento è sostanzialmente diverso da nmap, che utilizza i socket in maniera sincrona. Si struttura con tre processi: uno per l’invio dei probe, uno per la ricezione delle risposte e uno per la gestione dello scanner. Questo approccio lo rende uno dei port-scanner più veloci. Per esempio – anche dietro una VPN – permette di scansionare tutte le porte TCP in circa 5 minuti. Questa operazione – con uno scanner sincrono – richiede comunque un tempo maggiore.
Sparta invece è una GUI scritta in Python che richiama diversi strumenti (tra cui nmap e unicornscan).Personalmente ne utilizziamo una versione modificata secondo le nostre preferenze e più che altro per organizzare i vari risultati delle scansioni fatte a parte.
Esempio di enumeration
Facciamo un esempio scansionando una delle più note macchine linux vulnerabili: Metasploitable2 [11] che nel laboratorio ha l’indirizzo IP: 192.168.1.103.
A livello operativo, ha quindi senso utilizzare Unicornscan per scansionare tutte le porte TCP e UDP, specificando in delle variabili un bash (usando una Kali), l’interfaccia di rete e l’indirizzo IP, questo permette di poter utilizzare i comandi al meglio e di evitare eventuali errori di digitazione.
# nic=eth0 # ip=192.168.1.103 # unicornscan -v -i $nic -mT $ip:a -l $ip-tcp_unicorn.txt # unicornscan -v -i $nic -mU $ip:a -l $ip-udp_unicorn.txt
Una volta eseguiti i comandi è possibile leggere l’output TCP, notando le porte trovate aperte:
# cat $ip-tcp_unicorn.txt adding 192.168.1.103/32 mode `TCPscan' ports `a' pps 300 using interface(s) eth0 scaning 1.00e+00 total hosts with 6.55e+04 total packets, should take a little longer than 3 Minutes, 45 Seconds sender statistics 297.0 pps with 65536 packets sent total listener statistics 131094 packets recieved 0 packets droped and 0 interface drops TCP open ftp[ 21] from 192.168.1.103 ttl 64 TCP open ssh[ 22] from 192.168.1.103 ttl 64 TCP open telnet[ 23] from 192.168.1.103 ttl 64 TCP open smtp[ 25] from 192.168.1.103 ttl 64 TCP open domain[ 53] from 192.168.1.103 ttl 64 TCP open http[ 80] from 192.168.1.103 ttl 64 TCP open sunrpc[ 111] from 192.168.1.103 ttl 64 TCP open netbios-ssn[ 139] from 192.168.1.103 ttl 64 TCP open microsoft-ds[ 445] from 192.168.1.103 ttl 64 TCP open exec[ 512] from 192.168.1.103 ttl 64 TCP open login[ 513] from 192.168.1.103 ttl 64 TCP open shell[ 514] from 192.168.1.103 ttl 64 TCP open rmiregistry[ 1099] from 192.168.1.103 ttl 64 TCP open ingreslock[ 1524] from 192.168.1.103 ttl 64 TCP open shilp[ 2049] from 192.168.1.103 ttl 64 TCP open scientia-ssdb[ 2121] from 192.168.1.103 ttl 64 TCP open mysql[ 3306] from 192.168.1.103 ttl 64 TCP open distcc[ 3632] from 192.168.1.103 ttl 64 TCP open postgresql[ 5432] from 192.168.1.103 ttl 64 TCP open winvnc[ 5900] from 192.168.1.103 ttl 64 TCP open x11[ 6000] from 192.168.1.103 ttl 64 TCP open irc[ 6667] from 192.168.1.103 ttl 64 TCP open unknown[ 6697] from 192.168.1.103 ttl 64 TCP open unknown[ 8009] from 192.168.1.103 ttl 64 TCP open unknown[ 8180] from 192.168.1.103 ttl 64 TCP open msgsrvr[ 8787] from 192.168.1.103 ttl 64 TCP open unknown[37080] from 192.168.1.103 ttl 64 TCP open unknown[44885] from 192.168.1.103 ttl 64 TCP open unknown[55259] from 192.168.1.103 ttl 64 TCP open unknown[58521] from 192.168.1.103 ttl 64
E’ l’output UDP:
# cat $ip-udp_unicorn.txt adding 192.168.1.103/32 mode `UDPscan' ports `a' pps 300 using interface(s) eth0 scaning 1.00e+00 total hosts with 6.55e+04 total packets, should take a little longer than 3 Minutes, 45 Seconds sender statistics 297.1 pps with 65545 packets sent total listener statistics 14 packets recieved 0 packets droped and 0 interface drops UDP open domain[ 53] from 192.168.1.103 ttl 64 UDP open sunrpc[ 111] from 192.168.1.103 ttl 64 UDP open netbios-ns[ 137] from 192.168.1.103 ttl 64 UDP open shilp[ 2049] from 192.168.1.103 ttl 64 UDP open unknown[40440] from 192.168.1.103 ttl 64
Unicornscan può fare molto di più e non è scopo di questo articolo andare in profondità sul tuning e sulle varie opzioni, anche se un man può togliere molti dubbi 🙂 come ben spiegato dal concetto RTFM. E’ importante notare che Unicorn non ha fatto l’identificazione dei servizi e il servizio associato alla porta è quanto definito nel Service Name and Transport Protocol Port Number Registry [12]. L’eventuale corrispondenza deve essere verificata.
Enumeration dei servizi su porte TCP e UDP
Tornando alla nostra scansione con Unicorn, abbiamo ottenuto in breve tempo la lista delle porte TCP e UDP aperte. Il primo passo è procedere quindi all’enumeration dei servizi in ascolto su quelle porte e poi ottenere maggiori informazioni (per esempio la versione). Utilizzando un approccio incrementale e iterativo quindi utilizziamo Nmap coi suoi numerosi plugin, per poi andare nel dettaglio – sia a mano sia con diversi strumenti – sui singoli servizi (saranno dedicati dei post ai vari servizi).
Anzitutto è pratico processare i file ottenuti da Unicorn e generare una lista in un formato facilmente utilizzabile da nmap – oltre che per la reportistica:
# tcp=$(cat $ip-tcp_unicorn.txt | grep "\[" | cut -d "[" -f2 | cut -d "]" -f1 | tr "\n" "," | sed -e "s/ //g" | sed -e "s/,$//"); echo $tcp 21,22,23,25,53,80,111,139,445,512,513,514,1099,1524,2049,2121,3306,3632,5432,5900,6000,6667,6697,8009,8180,8787,37080,44885,55259,58521 # udp=$(cat $ip-udp_unicorn.txt | grep "\[" | cut -d "[" -f2 | cut -d "]" -f1 | tr "\n" "," | sed -e "s/ //g" | sed -e "s/,$//"); echo $udp 53,111,137,2049,40440
Quindi procedere con l’enumeration di base tramite Nmap, passandogli solamente le porte che già sappiamo aperte. La scansione utilizza la Service Version ed è comunque Aggressiva (-A). Fornendo ad Nmap solo le porte aperte, non è detto che sia sempre possibile eseguire correttamente l’OS identification che spesso richiede almeno una porta chiusa.
Passiamo quindi ad Nmap il nostro IP bersaglio e le porte TCP aperte. Questa scansione ha richiesto circa 4 minuti per ottenere comunque numerose informazioni come servizi, banner, versioni ecc…
# nmap -sTV $ip -oA $ip-nmap_sTV -p$tcp -A -PN -n --reason Nmap scan report for 192.168.1.103 Host is up, received arp-response (0.00051s latency). PORT STATE SERVICE REASON VERSION 21/tcp open ftp syn-ack vsftpd 2.3.4 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) 22/tcp open ssh syn-ack OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) | ssh-hostkey: | 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA) |_ 2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA) 23/tcp open telnet syn-ack Linux telnetd 25/tcp open smtp syn-ack Postfix smtpd |_smtp-commands: metasploitable.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, 53/tcp open domain syn-ack ISC BIND 9.4.2 | dns-nsid: |_ bind.version: 9.4.2 80/tcp open http syn-ack Apache httpd 2.2.8 ((Ubuntu) DAV/2) |_http-server-header: Apache/2.2.8 (Ubuntu) DAV/2 |_http-title: Metasploitable2 - Linux 111/tcp open rpcbind syn-ack 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 37080/tcp mountd | 100005 1,2,3 49293/udp mountd | 100021 1,3,4 44885/tcp nlockmgr | 100021 1,3,4 48887/udp nlockmgr | 100024 1 52048/udp status |_ 100024 1 55259/tcp status 139/tcp open netbios-ssn syn-ack Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn syn-ack Samba smbd 3.0.20-Debian (workgroup: WORKGROUP) 512/tcp open exec? syn-ack 513/tcp open login? syn-ack 514/tcp open shell? syn-ack 1099/tcp open java-rmi syn-ack Java RMI Registry 1524/tcp open shell syn-ack Metasploitable root shell 2049/tcp open nfs syn-ack 2-4 (RPC #100003) 2121/tcp open ftp syn-ack ProFTPD 1.3.1 |_ftp-bounce: no banner 3306/tcp open mysql syn-ack MySQL 5.0.51a-3ubuntu5 |_mysql-info: ERROR: Script execution failed (use -d to debug) 3632/tcp open distccd syn-ack distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) 5432/tcp open postgresql syn-ack PostgreSQL DB 8.3.0 - 8.3.7 | ssl-cert: Subject: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX | Not valid before: 2010-03-17T14:07:45 |_Not valid after: 2010-04-16T14:07:45 |_ssl-date: 2017-06-09T19:52:08+00:00; -5m57s from scanner time. 5900/tcp open vnc syn-ack VNC (protocol 3.3) | vnc-info: | Protocol version: 3.3 | Security types: |_ VNC Authentication (2) 6000/tcp open X11 syn-ack (access denied) 6667/tcp open irc syn-ack UnrealIRCd | irc-info: | users: 1.0 | servers: 1 | lusers: 1 | lservers: 0 | server: irc.Metasploitable.LAN | version: Unreal3.2.8.1. irc.Metasploitable.LAN | uptime: 0 days, 10:34:46 | source ident: nmap | source host: DE3541CF.78DED367.FFFA6D49.IP |_ error: Closing Link: uitefwbvw[192.168.1.104] (Quit: uitefwbvw) 6697/tcp open irc syn-ack UnrealIRCd 8009/tcp open ajp13 syn-ack Apache Jserv (Protocol v1.3) |_ajp-methods: Failed to get a valid response for the OPTION request 8180/tcp open http syn-ack Apache Tomcat/Coyote JSP engine 1.1 |_http-favicon: Apache Tomcat |_http-title: Apache Tomcat/5.5 8787/tcp open drb syn-ack Ruby DRb RMI (Ruby 1.8; path /usr/lib/ruby/1.8/drb) 37080/tcp open mountd syn-ack 1-3 (RPC #100005) 44885/tcp open nlockmgr syn-ack 1-4 (RPC #100021) 55259/tcp open status syn-ack 1 (RPC #100024) 58521/tcp open unknown syn-ack Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.9 - 2.6.33 Network Distance: 1 hop Service Info: Hosts: metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: -5m57s, deviation: 0s, median: -5m57s |_nbstat: NetBIOS name: METASPLOITABLE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-os-discovery: | OS: Unix (Samba 3.0.20-Debian) | NetBIOS computer name: | Workgroup: WORKGROUP |_ System time: 2017-06-09T15:52:09-04:00 TRACEROUTE HOP RTT ADDRESS 1 0.51 ms 192.168.1.103
Stesso discorso per UDP, cambiando appunto il tipo di scansione (-sU) e la variabile che contiene le porte:
# nmap -sUV $ip -oA $ip-nmap_sUV -p$udp -A -PN -n --reason Nmap scan report for 192.168.1.103 Host is up, received arp-response (0.00028s latency). PORT STATE SERVICE REASON VERSION 53/udp open domain udp-response ttl 64 ISC BIND 9.4.2 | dns-nsid: |_ bind.version: 9.4.2 |_dns-recursion: Recursion appears to be enabled 111/udp open rpcbind udp-response ttl 64 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 37080/tcp mountd | 100005 1,2,3 49293/udp mountd | 100021 1,3,4 44885/tcp nlockmgr | 100021 1,3,4 48887/udp nlockmgr | 100024 1 52048/udp status |_ 100024 1 55259/tcp status 137/udp open netbios-ns udp-response ttl 64 Samba nmbd netbios-ns (workgroup: WORKGROUP) 2049/udp open nfs udp-response ttl 64 2-4 (RPC #100003) 40440/udp closed unknown port-unreach ttl 64 Too many fingerprints match this host to give specific OS details Network Distance: 1 hop Service Info: Host: METASPLOITABLE Host script results: |_nbstat: NetBIOS name: METASPLOITABLE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) TRACEROUTE HOP RTT ADDRESS 1 0.28 ms 192.168.1.103
Una volta ottenuta una mappatura base dei servizi e le relative versioni (che non sempre abbiamo), è utile approfondire sempre con nmap utilizzando gli script relativi al servizio specifico. Questi script sono presenti nell’installazione di Nmap sulla Kali in /usr/share/nmap/scripts/. Segue un esempio di utilizzo degli script di Nmap specifici per il servizio FTP identificato sulla porta 21 (cominciando la quello in quanto è il primo nella lista). Andremo a cercare anzitutto il tipo di servizio, il software utilizzato, la versione ed eventuali configurazioni.
Questa oneliner si occupa di selezionare tutti i plugin di Nmap relativi ad un determinato servizio e li fa girare per un determinato IP su porte specifiche (configurabili nella prima parte). Ovviamente è necessario evitare – a meno che non sia voluto – i vari script che possono creare problemi (e.g. i flood, dos, brute).
# service=ftp; ip=$ip; ports=21; script=$(ls /usr/share/nmap/scripts/ | grep $service | grep -v "flood\|brute\|slowloris\|psexec\|dos" | tr '\n' ',' | sed -e "s/,$//"); echo -e "\n============\nTarget\t $ip\nPorts\t$ports\nScripts\t $script\nOutput\t$ip-$service\n==================\n"; nmap -d --script=$script $ip -oA $ip-$service -v -n -p$ports -PN –sV ============ Target 192.168.1.103 Ports 21 Scripts ftp-anon.nse,ftp-bounce.nse,ftp-libopie.nse,ftp-proftpd-backdoor.nse,ftp-vsftpd-backdoor.nse,ftp-vuln-cve2010-4221.nse,tftp-enum.nse Output 192.168.1.103-ftp ================== PORT STATE SERVICE REASON 21/tcp open ftp syn-ack ttl 64 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) | ftp-vsftpd-backdoor: | VULNERABLE: | vsFTPd version 2.3.4 backdoor | State: VULNERABLE (Exploitable) | IDs: CVE:CVE-2011-2523 OSVDB:73573 | vsFTPd version 2.3.4 backdoor, this was reported on 2011-07-04. | Disclosure date: 2011-07-03 | Exploit results: | Shell command: id | Results: uid=0(root) gid=0(root) | References: | http://osvdb.org/73573 | https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/unix/ftp/vsftpd_234_backdoor.rb | http://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html |_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2523
In questo caso una vulnerabilità già piuttosto interessante è stata identificata dal plugin di vsftpd, è presente infatti una backdoor ed – inoltre – siamo con l’utente root. Questo fa notare l’importanza dell’enumeration. E’ quindi utile proseguire con l’enumeration come dalla oneliner per i vari servizi identificati. Senza questo plugin sarebbe comunque stato possibile trovare la vulnerabilità cercando su exploit-db.com “vsftpd 2.3.4”.
Nell’esempio specifico Metasploitable è pensata per essere vulnerabile e semplice da sfruttare (e questa da questa backdoor si possono eseguire comandi come root, come si può vedere dalla parte evidenziata). In un contesto reale – anche se può capitare di trovare backdoor che girano come root 🙂 – può essere comunque richiesto di fornire la lista il più possibile completa delle vulnerabilità presenti o in un ottica più di “diventare root ” è utile avere la lista per capire la via “più breve/facile/veloce” per poter ottenere il controllo della macchina.
Come continuare l’enumeration
Il prossimo passo è quindi procedere con l’enumerazione dei servizi specifici e – in particolare in attività dove sono presenti molte macchine o anche poche macchine ma con molti servizi, come dicono i vecchi saggi:
“Ordine e disordine dipendono dall’organizzazione”
In questo caso Sparta torna particolarmente utile. Gli output di Nmap nel formato XML possono essere importati dentro Sparta (e li abbiamo salvati prima con -oA), con il quale possiamo avere un idea della situazione a livello grafico anche sullo stato dei servizi, l’output degli script di Nmap, altre informazioni e un comodo campo note.
Al netto di quanto caricato su Sparta è sempre utile leggere – e saper leggere – l’output “raw” degli strumenti per eseguire il debug o per osservare degli elementi particolari che possono sfuggire al parsing automatico. Inoltre non è detto che il test si svolga in una situazione di rete ottimale ed è pertanto sempre necessario calibrare correttamente tempi e timeout degli strumenti, oltre a porre attenzione ad eventuali sistemi (come firewall o IDS) che possono influenzare i nostri test.
In questo caso abbiamo usato Sparta principalmente per tenere in ordine i risultati. Volendo può essere utilizzato direttamente per il port scanning. In tal caso Sparta utilizza diverse sessioni di Nmap ogni volta con diverse porte in approccio a 5 fasi, come dal file sparta.conf:
[StagedNmapSettings] stage1-ports="T:80,443" stage2-ports="T:25,135,137,139,445,1433,3306,5432,U:137,161,162,1434" stage3-ports="T:23,21,22,110,111,2049,3389,8080,U:500,5060,U:161" stage4-ports="T:0-20,24,26-79,81-109,112-134,136,138,140-442,444,446-1432,1434-2048,2050-3305,3307-3388,3390-5431,5433-8079,8081-29999" stage5-ports="T:30000-65535"
Deve essere comunque usato con attenzione in quanto di default utilizza il T4, quindi delle tempistiche abbastanza veloci e potrebbe perdersi qualche porta. Facendo alcuni test abbiamo notato che utilizzando per esempio il T2 la scansione è particolarmente lenta quindi da usare solamente se si ha molto tempo a disposizione. Con l’approccio “Fire and Forget”, per citare un noto gioco.
La scansione è incrementale perché Sparta una volta conclusa la singola fase (stage), processa i risultati ed enumera i servizi lanciando una serie di strumenti. Per esempio alla fine della prima fase – dove cerca le porte aperte tipicamente web – lancia poi strumenti come Nikto. E’ un procedimento piuttosto sensato – tanto che è quello che facciamo anche noi a mano e per questo è nata una versione “personalizzata” di Sparta. Il fatto che questo avvenga in automatico ha dei pro e dei contro, come tutto. Se da un lato è particolarmente comodo lanciare, attendere e poi vedere i risultati, dall’altro può essere lento, può creare problemi al server e il Tester, se non lancia spesso i comandi può facilmente dimenticarli. Altro aspetto importante rispetto al già citato “lancia e dimentica” è che diversi servizi – per esempio quelli web – necessitano comunque di lavorare a “cervello acceso” e quindi lanciare si in una prima fase degli strumenti ma con criterio, evitando il “lame mode”.
[1] https://www.youtube.com/watch?v=Vhh_GeBPOhs
[2] http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
[3] http://www.isecom.org/research/
[4] http://www.pentest-standard.org/index.php/Main_Page
[5] https://tools.ietf.org/html/rfc793
[6] https://tools.ietf.org/html/rfc768
[7] https://nmap.org/
[8] https://www.defcon.org/images/defcon-13/dc13-presentations/DC_13-Lee.pdf
[9] http://sparta.secforce.com/
[10] https://nmap.org/movies/
[11] https://sourceforge.net/projects/metasploitable/files/Metasploitable2/
[12] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml