inj3ct0rss - Medium
Este documento narra la metodología y los pasos seguidos para comprometer este ctf llamado inj3ct0rss
Reconocimiento y Enumeración
Arrancamos realizando un reconocimiento inicial sobre el host objetivo para identificar qué servicios se encuentran expuestos.
Para ello ejecutamos un escaneo completo de puertos con Nmap, ignorando comprobaciones de ICMP (-Pn) y habilitando salida detallada (-vv):
El resultado nos revela que los puertos 22/tcp (SSH) y 80/tcp (HTTP) están abiertos, lo cual establece los primeros vectores de ataque disponibles.
A partir de esta información, procedemos a un escaneo de detección de versiones y scripts comunes de enumeración (-sCV) con el fin de obtener detalles sobre los servicios en ejecución:
Esta fase nos permite identificar tecnologías, versiones específicas y posibles puntos débiles que podremos explotar más adelante, tanto en el servicio web como en el acceso SSH.
En el mismo hay un mensaje donde se nos da la bienvenida a un portal que nos explicara las caracteristicas del CTF que pondra a prueba nuestras habilidades
Realizamos deteccion de las tecnologias empleadas por la web
Para descubrir archivos olvidados, backups, endpoints no listados
ACCESO INICIAL (Explotación Web / SQLi)
De forma manual pruebo algunas SQLQueryes para intentar bypassear el panel de login
Despues de probar algunos payloads logro tener exito con
Al tener exito nos redirige a: http://172.17.0.2/content_pages_hidden/welcome.php
Sabiendo que el login es vulnerable a inyeccion SQL usaremos la herramienta SQLMap para automatizar la inyeccion.
Primero interceptamos la solicitud para luego realizar un descrubrimiento sobre las bases de datos:
Tablas de: injectors_db
Columns
Dump:
MOVIMIENTO LATERAL
Probamos las credenciales con ssh que se aloja en el puerto 22:
Ahora miraremos en este directorio no_mirar_en_este_directorio:
Lo descargamos y al intentar descomprimir el archivo nos pide una contrasena que no tenemos
Asi que realizaremos un ataque de fuerza bruta para descubrir la clave que nos permita descomprimir el archivo:
Ahora si logramos que se descomprima y leer el contenido obteniendo credenciales de ralf
Ya contando con otras credenciales para el usuario ralf, probamos nuevamente la conexion via ssh
Después de obtener acceso inicial al sistema como un usuario de bajo privilegio, el siguiente paso lógico es identificar qué capacidades adicionales posee este usuario dentro del sistema. Una de las formas más directas de detectar rutas potenciales de escalada es revisar los comandos permitidos por la política de sudoers.
Este análisis permite determinar:
si el usuario puede ejecutar ciertos comandos con
sudo,si esos comandos requieren o no contraseña,
a qué usuario puede impersonar (incluido root),
y si existen restricciones aplicadas, como rutas limitadas, binarios específicos o uso de comodines.
Con esta información es posible identificar configuraciones débiles que permitan ejecutar binarios privilegiados, escapar entornos restringidos o incluso obtener acceso total como root.
Hasta ahí, parece un permiso limitado. Pero BusyBox es un arma multiuso.
BusyBoxs
BusyBox es un binario monolítico que contiene decenas de utilidades Unix, incluyendo sh.
Cuando lo ejecutás de forma privilegiada, podés invocar cualquiera de sus “applets”.
El administrador intentó restringir el binario usando un wildcard:
El sudoers solo controla el prefijo, no el contenido expandido del wildcard.
Por lo tanto, se puede escapar del directorio /nothing/ usando:
Cuando sudo expande el comodín *, no valida que la ruta final siga dentro de /nothing/.
Esto permite ejecutar un sh real (no restringido) como el usuario “capa”:
Una vez dentro del sistema con una shell real como el usuario capa, el control del entorno ya no está restringido por el wildcard /nothing/*
A este nivel, podemos ejecutar cualquier comando permitido para este usuario dentro de la política sudoers.
Al revisar nuevamente las capacidades de sudo para capa
Encontramos que este usuario tiene permisos excesivos que le permiten ejecutar el binario /bin/cat como root, sin necesidad de contraseña. Esto convierte la shell de capa en un punto de pivot ideal para acceder a información sensible
Primero leemos el archivo encontrado en el directorio /home de capa obteniendo su contraseña
Entre los archivos accesibles como root se encuentra:
/root/.ssh/id_rsa
sudo -u root /bin/cat /root/.ssh/id_rsa
Asi obtenemos la clave rsa del usuario root con el cual podremos logrearnos en el protocolo ssh con privilegios
COMPROMISO TOTAL
Le damos los permisos necesarios
chmod 600 id_rsa
Asi obtenemos la clave rsa del usuario root con el cual podremos logrearnos en el protocolo ssh con privilegios
ssh -i id_rsa root@localhost o ssh -i id_rsa root@172.17.0.2
pwned!!!
Regresamossss
Última actualización