Cómo hackeé el servidor de un desconocido

Share
Cómo hackeé el servidor de un desconocido
audio-thumbnail
Smoke and Steel
0:00
/142.254145

Antes de continuar

Acceder sin autorización y de manera ilegítima a infraestructura virtual supone graves delitos dependiendo de la actividad que se haya realizado con dicha intrusión. Siempre que se vaya a realizar alguna práctica como la demostrada a continuación, se debe preocurar obrar desde la ética y de buena manera. No permitas hacer un mal uso del buen conocimiento que has obtenido.

  • Sistema operativo: Debian 13

Nota: Todo esto se hizo con la autorización del objetivo. Mientras realicé el pentest, siempre me estuve encargando de mantener intacta la seguridad del objetivo y de su información, como deberías hacer tú también.


¡Bienvenidos, mis queridos hackers! Hace poco encontré una página de un usuario en Discord, moderador de un servidor, que me llamó la atención. Como aquí somos curiosos, empecé a indagar y encontré cosas bastante interesantes. En este post, explico los pasos que seguí, las herramientas que usé y cómo exploté la vulnerabilidad hasta conseguir el objetivo deseado. Pero antes de eso, comencemos hablando de qué es Cloudflare.

Cloudflare, la medida de seguridad "definitiva"

Cloudflare es un WAF (Web Application Firewall), que es una medida de seguridad que se implementa en páginas webs para poder proteger de ataques web como "XSS", "SQLi" o "IDORs". Cloudflare cambia la dirección IP de la web (hacia la cual se envían las peticiones) por una IP de alguno de los servidores de Cloudflare, Cloudflare analiza la petición web que se envía al servidor antes de llegar a él, y si detecta alguna anomalía o petición maliciosa, evita el acceso al servidor con Cloudflare instalado, y prohibe acceder a la web debido a actividad maliciosa. Por otro lado, si detecta que la petición web es normal y no contiene información que suela ser relativa a ciberataques, permite su paso hasta llegar al servidor web.

Cloudflare protege contra todo ataque web que esté relacionado con peticiones web, o incluso contra ataques DDOS. Es por ello que muchos lo consideran una parte fundamental de la ciberseguridad y al ser una medida tan eficaz, la instalan para proteger su sistema. El problema es, que Cloudflare sólo protege de ataques web cuando se encuentra de intermediario entre la comunicación del cliente al servidor. Por eso mismo, si el atacante decide no hacer una petición a Cloudflare para que sea redirigida al servidor, sino que le hace esa misma petición directamente al servidor, no pasa el análisis de Cloudflare y la petición maliciosa llega al servidor. La cosa no queda ahí aun así. al existir servidores de Cloudflare que actúan como intermediarios, el atacante nunca sabrá a qué servidor corresponde la web, o al menos, no debería ser así.

Revisando la web

El objetivo principal era la página web principal de una persona llamada "Davito". Se trataba de una especie de portfolio, que usa para darse a conocer. La web del portfolio la analicé al completo y no encontré nada interesante (al menos, a cuanto a vulnerabilidades se refiere).

Sin embargo, al revisar las tecnologías que usaba la web, encontré dos cosas. La primera, fue que, al revisar los archivos de javascript en siu web, hallé una clave API perteneciente a su cuenta de Spotify, con la que podrían tomar posesión de la misma (es por eso que no debería estar visible de forma pública).

Además, usando "Wappalizer", también descubrí que su web estaba tras un túnel de "Cloudflare".

Lo cual me llevó a pensar que quizá podría sacar la dirección IP del servidor real si comprobaba por brechas de datos en motores de búsqueda como "Shodan" o "Censys", así que eso mismo hice. Una búsqueda rápida en Censys desveló que ese nombre de dominio estaba asociado a una IP que no pertenecía a los túneles de Cloudflare.

Una dirección IP de un túnel de Cloudflare se ve así:

Ambas direcciones sirven para llegar al servidor final. Sin embargo, esas IPs no son las IP reales del servidor web "davito.es". Es por ello que con Censys averigué que existía una IP asociada a la web "davito.es" que no estaba dentro del rango de IPs de Cloudflare:

Observando mejor esta IP podemos ver distintos puertos que tiene abiertos. Esto es debido a que los hostings normalmente no suelen abrir mñas puertos de los necesarios. Sin embargo, que la página sea española, pero que el servidor esté ubicado en Francia, y tengo puertos abiertos que pertenecen a otro tipo de aplicaciones web como paneles de monitorización, me hizo pensar que se trataba de un VPS (servidor virtual privado), y efectivamente, estaba en lo cierto.

Un VPS es un servidor que cualquiera puede comprar para poder alojar tus propias webs o aplicaciones en él. ¿Quieres un servidor de Minecraft pero los servidores son demasiado caros? Compras un VPS por 3 euros al mes y haces el apaño. Sin embargo, Davito tiene su VPS para otros fines que no eran necesariamente el gaming. En el puerto 80 (HTTP) y 443 (HTTPS) tenía alojada su página web, pero como se puede ver a continuación, existen muchos más puertos abiertos.

Explorando el servidor

El puerto 22 se refiere a ssh, un servicio que te permite conectarte de forma remota a tu servidor para poder gestionarlo. En el puerto 3000 se encuentra un panel de instalación del software "AdGuard Home". Aparentemente la versión del software que se puede instalar (v0.107.78) tiene está asociado vulnerabilidad llamada CVE-2022-32175, pero por el contexto del ataque, no podemos aprovechar esta vulnerabilidad.

En el puerto 3001 tiene un panel de monitorización del VPS, para ver los recursos que consume, aunque por desgracia requiere de un inicio de sesión de unusario y contraseña, por lo que no me molesté mucho en esta parte.

En el puerto 8085 aparentemente no hay nada. Y de haberlo, no responde por muchos paquetes que envíe. En el puerto 8090 aparentemente tiene un portfolio de un bot de discord que o bien está desarrollando, o ha desarrollado, y aunque tiene buena pinta, en ese puerto no he encontrado nada que pueda indicar que haya alguna vulnerabilidad.

En el puerto 8096 tiene Jellyfin, que se trata de una aplicación que te permite ver tus propias series y películas, similar a Netflix, pero son películas que puedes descargar. De nuevo, aquí no encontré ninguna vulnerabilidad.

Vulnerabilidades interesantes

Sin embargo, en el siguiente puerto, el 8191, encontré algo más que interesante. Aparentemente se trataba de una API de un software llamado "FlareSolverr", que es un proxy para redirigir peticiones y resolver desafíos anti-bot como los de Cloudflare, es decir, para permitir el paso a páginas web protegidas a bots. Casualmente, al acceder al puerto nos encontramos con esto:

Aparentemente, buscando en Google podemos ver que existe una vulnerabilidad que afecta a esta versión de FlareSolverr, que permite la lectura arbitraria de archivos en el sistema afectado. Esto significa que es posible leer archivos del servidor, ya sean archivos de configuración, páginas web ocultas, o archivos esenciales del sistema como el /etc/passwd (archivo que registra los usuarios del sistema). Esta vulnerabilidad es conocida como "CVE-2026-51031".

Para explotar esta vulnerabilidad, me he documentando usando la web de "xinyi" (quien creo que fue quien descubrió por primera vez esta vulnerabilidad) y he desarrollado un exploit para la misma (que se puede encontrar en mi Github).

GitHub - daemoncibsec/flar3ad: POC of CVE-2026-51031 for arbitrary local file read
POC of CVE-2026-51031 for arbitrary local file read - daemoncibsec/flar3ad

Explotando esta vulnerabilidad usando el exploit que creé (aunque también es posible realizar el ataque usando el POC de la página de "xinyi"), conseguí acceder al sistema, y de haber querido, probablemente podría haber leído archivos de configuración, que podrían contener credenciales, archivos tales como ".htaccess" o similares.

Sin embargo, paré de indagar una vez descubrí la vulnerabilidad debido a que no quiero entrar el problemas. Seguí investigando y encontré en el puerto 8444 un navegador llamado "SearXNG". Es un metanavegador de búsqueda que recibe tu consulta y recoge fuentes de distintos indexadores (es decir, combina los resultados que encontrarías en Google, Bing, Brave...) para luego mostrarte por pantalla los resultados más óptimos. Revisé la configuración de su navegador, pero no encontré nada más que 2 cookies que no me eran realmente útiles.

Finalmente, el puerto 8501 me permitía acceder a una página que, según su contexto, debería ser privada. Se trata de un "Centro de mando personal" para su VPS, donde tiene alguna que otra estadística sobre su VPS.

Lo curioso es que, las funcionalidades que tratan información crítica, como bien podría ser la "base de datos de Dabot" (que ya vimos anteriormente que era un servidor de Discord y aparentemente se puede acceder a la BD desde esta web), "Estado de los servicios" o el apartado de "Seguridad y analíticas", no poseen datos, no por que no indiquen que estén activas, sino por errores en el código del backend de la web (es decir, el código que hay detrás de la web).

Gracias a que existen errores en el código de la web y estos datos no se pueden obtener, la información del VPS está aún a salvo, pero en cuanto se actualice la página con nuevas funcionalidades y soluciones a los bugs existentes, se expondrá de forma pública información que no debería. Es por ello que se debería limitar el acceso a esta web solo a nivel local. Y fiinalmente, el puerto 9696 no permitía conexiones, por lo que no he podido acceder y ver qué potenciales vulnerabilidades podrían existir en el mismo.

Conclusión

De vez en cuando podemos dejar puestos expuestos a internet que podrían permitir que algunos atacantes con intenciones maliciosas puedan dañar nuestro trabajo y esfuerzo. Es por ello que existen herramientas como las anteriormente vistas (Censys o Shodan) que pueden ayudarnos a identificar filtraciones de información, y bases de datos de vulnerabilidades en internet que nos permiten detectar fallas de seguridad. Espero que este post haya ayudado a alguien a entender mejor cómo identificar puntos débiles en servidores y llegar a explotarlos. Como siempre, feliz hacking. ¡Nos vemos!

Read more