Enumeration di porte e servizi su TCP e UDP

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

Leave a Reply

Your email address will not be published. Required fields are marked *