Ciao a tutti!
Eccomi tornato con un altro writeup di una macchina di HTB, questa volta Postman.
Senza perdere altro tempo, cominciamo subito!
HTB Writeups 0x02 - Redis (4.3/10)
La macchina è piuttosto semplice, ma per completarla è necessario conoscere il funzionamento di Redis, utilizzato appunto in questa box. L'IP del nostro target è 10.10.10.160 e il percorso boot2root è piuttosto lineare.
Per iniziare, eseguiamo una scansione completa della macchina con Nmap, cercando di estrapolare i banner e le versioni dei demoni in ascolto sulle porte aperte:
La nostra scansione ci rivela che sono in ascolto 4 porte: SSH, per collegarci successivamente alla macchina, due web server sulle porte 80 e 10000 e redis sulla porta 6379.
Diamo un occhiata ai due web server e facciamo un po' di enumerazione. Una rapida ricerca ci rivela che per MiniServ esistono exploit per questa versione, che necessitano però di autenticazione... Potrebbero tornarci utili dopo!
Siccome non abbiamo trovato nulla di utile, passiamo all'enumerazione di Redis: utilizzarò lo script di nmap redis-info per cercare di ottenere qualche informazione utile.
Nulla di troppo utile...
Redis è un database che lavora in memoria sulla macchina, perciò può interagire direttamente con essa. Per funzionare ha bisogno della creazione di un utente apposito, che avrà permessi di scrittura e quant'altro sulla propria home.
Siccome questo è un utente a tutti gli effetti, gli è concesso avere delle chiavi SSH con cui loggarsi da remoto, e poichè abbiamo i permessi di scrittura sulla nostra directory e la possibilità di loggarci in SSH... Abbiamo la possibilità di loggarci sulla macchina come user redis impostando delle chiavi SSH a nosta scelta!
Per loggarci come utente Redis, per prima cosa, ho generato un paio di chiavi SSH (terminale di destra).
Fatto ciò, all'interno della macchina Postman ho creato la cartella .ssh, e al suo interno ho inserito nel file authorized_keys la nostra chiave pubblica, in modo da essere autorizzati a loggarci senza disporre di credenziali.
Fatto questo, colleghiamoci in SSH con utente redis per loggarci all'interno di Postman.
Carichiamo sulla nostra macchina LinEnum.sh, un tool per l'enumerazione automatica, e lanciamolo.
Tra le migliaia di righe di info restituite, notiamo come sia presente un file di backup di una chiave rsa per il login in SSH appartenente a Matt, l'utente della macchina, ma leggibile da tutti.
Estrapoliamo e portiamolo sulla nostra macchina locale in modo da provare a craccarlo.
Per craccare una chiave ssh useremo ssh2john, un tool della suite di john-the-ripper, con cui andremo a creare un hash da craccare proprio utilizzando lo stesso john.
Ottenuta la password, proviamo a loggarci in SSH con utente Matt... ma non funziona.
Proviamo allora a cambiare semplicemente utente tramite il comando su Matt
Bingo! Siamo l'utente Matt!
Come possiamo ora diventare root?
Enumerando la macchina non ho trovato nulla di interessante, ma mi sono ricordato di quell'exploit di WebMin sulla porta 10000 che permetteva di eseguire una RCE con permessi di root.
github.com
Siamo root, abbiamo ownato la macchina e possiamo fare quello che vogliamo!
Ottimo lavoro!
Spero che il writeup sia stato chiaro, per qualsiasi domanda o dubbio non esitate a contattarmi o ancora meglio a postarlo nella discussione in modo da discuterne tutti assieme.
Buono studio e buon divertimento!
Autore: 0xbro
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Eccomi tornato con un altro writeup di una macchina di HTB, questa volta Postman.
Senza perdere altro tempo, cominciamo subito!
HTB Writeups 0x02 - Redis (4.3/10)
La macchina è piuttosto semplice, ma per completarla è necessario conoscere il funzionamento di Redis, utilizzato appunto in questa box. L'IP del nostro target è 10.10.10.160 e il percorso boot2root è piuttosto lineare.
Per iniziare, eseguiamo una scansione completa della macchina con Nmap, cercando di estrapolare i banner e le versioni dei demoni in ascolto sulle porte aperte:
Bash:
# Nmap 7.80 scan initiated Wed Feb 26 21:38:20 2020 as: nmap -sV -O -A -p 1-10000 --script=banner -o nmap.txt 10.10.10.160
Nmap scan report for 10.10.10.160
Host is up (0.047s latency).
Not shown: 9996 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
|_banner: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
6379/tcp open redis Redis key-value store 4.0.9
10000/tcp open http MiniServ 1.910 (Webmin httpd)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=2/26%OT=22%CT=1%CU=38345%PV=Y%DS=2%DC=T%G=Y%TM=5E56D77
OS:5%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=106%TI=Z%CI=Z%II=I%TS=A)OPS
OS:(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST1
OS:1NW7%O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN
OS:(R=Y%DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=A
OS:S%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R
OS:=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F
OS:=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%
OS:T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD
OS:=S)
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 110/tcp)
HOP RTT ADDRESS
1 46.46 ms 10.10.14.1
2 46.53 ms 10.10.10.160
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Feb 26 21:39:17 2020 -- 1 IP address (1 host up) scanned in 57.09 secondsLa nostra scansione ci rivela che sono in ascolto 4 porte: SSH, per collegarci successivamente alla macchina, due web server sulle porte 80 e 10000 e redis sulla porta 6379.
Diamo un occhiata ai due web server e facciamo un po' di enumerazione. Una rapida ricerca ci rivela che per MiniServ esistono exploit per questa versione, che necessitano però di autenticazione... Potrebbero tornarci utili dopo!
Siccome non abbiamo trovato nulla di utile, passiamo all'enumerazione di Redis: utilizzarò lo script di nmap redis-info per cercare di ottenere qualche informazione utile.
Bash:
nmap --script redis-info -sV -p 6379 10.10.10.160
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-26 22:20 CET
Nmap scan report for 10.10.10.160
Host is up (0.047s latency).
PORT STATE SERVICE VERSION
6379/tcp open redis Redis key-value store 4.0.9 (64 bits)
| redis-info:
| Version: 4.0.9
| Operating System: Linux 4.15.0-58-generic x86_64
| Architecture: 64 bits
| Process ID: 608
| Used CPU (sys): 81.29
| Used CPU (user): 27.25
| Connected clients: 2
| Connected slaves: 0
| Used memory: 840.94K
| Role: master
| Bind addresses:
| 0.0.0.0
| ::1
| Client connections:
| 10.10.14.12
|_ 10.10.14.27
Found redis with INFO command: $2743\x0d\x0a# Server\x0d\x0aredis_version:4.0.9\x0d\x0aredis_git_sha1:00000000\x0d\x0aredis_git_dirty:0\x0d\x0aredis_build_id:9435c3c2879311f3\x0d\x0aredis_mode:standalone\x0d\x0aos:Linux 4.15.0-58-generic x86_64\x0d\x0aarch_bits:64\x0d\x0amultiplexing_api:epoll\x0d\x0aatomicvar_api:atomic-builtin\x0d\x0agcc_version:7.4.0\x0d\x0aprocess_id:608\x0d\x0arun_id:7bf00bc00a12920ef47d175e86b40501042ee107\x0d\x0atcp_port:6379\x0d\x0auptime_in_seconds:87075\x0d\x0auptime_in_days:1\x0d\x0ahz:10\x0d\x0alru_clock:5693983\x0d\x0aexecutable:/usr/bin/redis-server\x0d\x0aconfig_file:/etc/redis/redis.conf\x0d\x0a\x0d\x0a# Clients\x0d\x0aconnected_clients:2\x0d\x0aclient_longest_output_list:0\x0d\x0aclient_biggest_input_buf:0\x0d\x0ablocked_clients:0\x0d\x0a\x0d\x0a# Memory\x0d\x0aused_memory:861120\x0d\x0aused_memory_human:840.94K\x0d\x0aused_memory_rss:4415488\x0d\x0aused_memory_rss_human:4.21M\x0d\x0aused_memory_peak:880976\x0d\x0aused_memory_peak_human:860.33K\x0d\x0aused_memory_peak_perc:97.75%\x0d\x0aused_memory_overhead:848944\x0d\x0aused_memory_startup:782456\x0d\x0aused_memory_dataset:12176\x0d\x0aused_memory_dataset_perc:15.48%\x0d\x0atotal_system_memory:941203456\x0d\x0atotal_system_memory_human:897.60M\x0d\x0aused_memory_lua:37888\x0d\x0aused_memory_lua_human:37.00K\x0d\x0amaxmemory:0\x0d\x0amaxmemory_human:0B\x0d\x0amaxmemory_policy:noeviction\x0d\x0amem_fragmentation_ratio:5.13\x0d\x0amem_allocator:jemalloc-3.6.0\x0d\x0aactive_defrag_running:0\x0d\x0alazyfree_pending_objects:0\x0d\x0a\x0d\x0a# Persistence\x0d\x0aloading:0\x0d\x0ardb_changes_since_last_save:0\x0d\x0ardb_bgsave_in_progress:0\x0d\x0ardb_last_save_time:1582749536\x0d\x0ardb_last_bgsave_status:ok\x0d\x0ardRedis è un database che lavora in memoria sulla macchina, perciò può interagire direttamente con essa. Per funzionare ha bisogno della creazione di un utente apposito, che avrà permessi di scrittura e quant'altro sulla propria home.
Siccome questo è un utente a tutti gli effetti, gli è concesso avere delle chiavi SSH con cui loggarsi da remoto, e poichè abbiamo i permessi di scrittura sulla nostra directory e la possibilità di loggarci in SSH... Abbiamo la possibilità di loggarci sulla macchina come user redis impostando delle chiavi SSH a nosta scelta!
Per loggarci come utente Redis, per prima cosa, ho generato un paio di chiavi SSH (terminale di destra).
Fatto ciò, all'interno della macchina Postman ho creato la cartella .ssh, e al suo interno ho inserito nel file authorized_keys la nostra chiave pubblica, in modo da essere autorizzati a loggarci senza disporre di credenziali.
Fatto questo, colleghiamoci in SSH con utente redis per loggarci all'interno di Postman.
Carichiamo sulla nostra macchina LinEnum.sh, un tool per l'enumerazione automatica, e lanciamolo.
Bash:
redis@Postman:/tmp$ ./LinEnum.sh
#########################################################
# Local Linux Enumeration & Privilege Escalation Script #
#########################################################
# www.rebootuser.com
# version 0.982
[-] Debug Info
[+] Thorough tests = Disabled
Scan started at:
Thu Feb 27 09:44:23 GMT 2020
### SYSTEM ##############################################
[-] Kernel information:
Linux Postman 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[-] Kernel information (continued):
Linux version 4.15.0-58-generic (buildd@lcy01-amd64-013) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019
[-] Specific release information:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
[-] Hostname:
Postman
...
[-] Location and Permissions (if accessible) of .bak file(s):
-rwxr-xr-x 1 Matt Matt 1743 Aug 26 2019 /opt/id_rsa.bak
-rw------- 1 root root 695 Aug 25 2019 /var/backups/group.bak
-rw------- 1 root shadow 577 Aug 25 2019 /var/backups/gshadow.bak
-rw------- 1 root shadow 935 Aug 26 2019 /var/backups/shadow.bak
-rw------- 1 root root 1382 Aug 25 2019 /var/backups/passwd.bak
[-] Any interesting mail in /var/mail:
total 8
drwxrwsr-x 2 root mail 4096 Aug 24 2019 .
drwxr-xr-x 13 root root 4096 Aug 25 2019 ..
### SCAN COMPLETE ####################################Tra le migliaia di righe di info restituite, notiamo come sia presente un file di backup di una chiave rsa per il login in SSH appartenente a Matt, l'utente della macchina, ma leggibile da tutti.
Estrapoliamo e portiamolo sulla nostra macchina locale in modo da provare a craccarlo.
Per craccare una chiave ssh useremo ssh2john, un tool della suite di john-the-ripper, con cui andremo a creare un hash da craccare proprio utilizzando lo stesso john.
Ottenuta la password, proviamo a loggarci in SSH con utente Matt... ma non funziona.
Proviamo allora a cambiare semplicemente utente tramite il comando su Matt
Bingo! Siamo l'utente Matt!
Come possiamo ora diventare root?
Enumerando la macchina non ho trovato nulla di interessante, ma mi sono ricordato di quell'exploit di WebMin sulla porta 10000 che permetteva di eseguire una RCE con permessi di root.
metasploit-framework/documentation/modules/exploit/linux/http/webmin_packageup_rce.md at master · rapid7/metasploit-framework
Metasploit Framework. Contribute to rapid7/metasploit-framework development by creating an account on GitHub.
github.com
Compiliamo i campi necessari, utilizziamo l'utenza di Matt con la password appena scoperta e lanciamo l'exploit
Siamo root, abbiamo ownato la macchina e possiamo fare quello che vogliamo!
Ottimo lavoro!
Spero che il writeup sia stato chiaro, per qualsiasi domanda o dubbio non esitate a contattarmi o ancora meglio a postarlo nella discussione in modo da discuterne tutti assieme.
Buono studio e buon divertimento!
Autore: 0xbro
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
