Apocalipsis cibernético 2025: ataque cibernético
Table of Contents
Ciberataque (web)
Para este desafío, se nos proporciona una IP y presumiblemente el código fuente del sitio web en esa IP.
Al observar el código, vemos varias ubicaciones de posible inyección. El sitio utiliza scripts cgi python para manejar solicitudes y un index.php básico sin vulnerabilidades del lado del servidor. Lo primero que nos viene a la mente es la inyección CRLF, ya que no vemos ninguna validación o desinfección de expresiones regulares en el parámetro de nombre, además de que se imprime detalladamente como encabezado.
que podemos verificar así:
Esto funciona porque mientras imprime el encabezado, inyectamos \r\n, en el que luego podemos inyectar encabezados arbitrarios.
Además, vemos otro script aparentemente protegido en cgi-bin, lo que implica que primero debemos explotar attack-domain antes de atacar a attack-ip.
Este es el código para attack-ip:
Aquí vemos la misma inyección de comando con os.popen, pero esta vez no está protegido por una expresión regular, lo que significa que este debería ser nuestro objetivo final.
Entonces necesitamos:
- Explotar una SSRF en
attack-domain - Haga que el servidor llame a
127.0.0.1/cgi-bin/attack-ippara omitir la configuración de Apache. - Inyecte una carga útil en el
os.popen
Al mirar el archivo docker que viene con el desafío, vemos varios complementos de Apache habilitados deliberadamente, lo que me da curiosidad:
Pasé un tiempo largo probando rutas de explotación alternativas y profundizando en madrigueras de conejos, pero finalmente me topé con esto en documentation para mod_proxy_fcgi. Notarás que tiene una notación peculiar proxy:.
Antes de realizar la prueba, configuré un túnel de acceso público para no tener que depender de ngrok o del colaborador burp. Alojaré aquí un servidor web Python simple para recibir respuestas.
Así que ahora enviamos una carga útil ciega para hacer ping a nuestro túnel. Tenga en cuenta que necesitamos codificar dos veces la solicitud de proxy, ya que es una segunda solicitud anidada dentro de la primera.
El envío de la carga útil valida nuestras sospechas sobre la SSRF
La SSRF lo logró. Ahora pasamos a explotar. Recuerde, ya vimos el código de attack-ip, por lo que sabemos que es fácilmente vulnerable a la inyección de comandos ya que no hay ninguna expresión regular que lo proteja. Crearé index.html en mi túnel que contiene un script para filtrar la bandera.
Y cambie la carga útil para canalizarla a bash para que realmente se ejecute:
¡Luego recibimos una devolución de llamada con la bandera codificada en base64!
