Últimamente me ha dado por estudiar los ataques relacionados con el DoS y vengo a contar mi experiencia.
Tengo el permiso explícito para hacer estas pruebas con lo cual no estoy cometiendo ningún delito.
Muchas páginas web contratan servicios costosos de protección, como Cloudflare, que actúan como proxy, filtran solicitudes y protegen puertos, entre otras coas. Si un servidor está configurado correctamente con Cloudflare, resultara difícil agotar los recursos de la página, ya que este servicio distribuye la carga y elimina solicitudes maliciosas. Además, dado que Cloudflare puede asociar una única IP a varios dominios, se evita afectar a otros sitios alojados en la misma dirección.
En mi primer escáner de nmap pude identificar la ip , los puertos abiertos y los servicios en ejecución. Algunos puertos se encuentran filtrados.
Probé a acceder a la IP y las dos que me proporcionaba el escaneo eran ip's de proxy de cloudflare.
Existen varias herramientas en Linux para generar tráfico masivo, como hping3, locust o incluso repositorios públicos de Slowloris. Aunque algunos de estos ataques pueden ser medianamente efectivos en ciertos escenarios, con Cloudflare dichos métodos quedan descartados, ya que los paquetes maliciosos ni siquiera llegan al servidor real y el rendimiento de la página no se ve afectado.
Tras varios intentos fallidos de "tumbar" la página de diversas maneras, se me ocurrió una idea. El hosting – es decir, el servidor real y no el de Cloudflare – tiene un límite de ancho de banda, como todos. Al tratarse de una empresa pequeña, es probable que dicho límite no fuera muy alto. ¿Sería posible interactuar con el backend, pasando por Cloudflare, para agotar los recursos del servidor?
Observé que el sistema no validaba el correo electrónico y que cada solicitud de creación de cuenta se procesaba sin inconvenientes, la solicitud de registro contenía una cookie pero era aceptada sin ella, siempre que no se repitiera el email o el nombre de usuario. En teoría, esto permitiría crear cuentas de manera indefinida. Aunque el proceso de registro implica únicamente la escritura de unos 20 a 30 caracteres (correspondientes al email, el user y la contraseña).
Para probar mi "hipótesis", intenté registrar una cuenta utilizando una contraseña compuesta por 10,000 caracteres, se olvidaron de poner longitud máxima en los campos de entrada. La validación se realizó sin problemas, lo que confirmó la existencia de una vulnerabilidad.
Posteriormente, programé – utilizando la librería requests de Python – las solicitudes necesarias para registrar alrededor de 10,000 correos electrónicos aleatorios acabados en @gmail.com , cada uno con contraseñas enormes. Realicé las solicitudes en bloques de 500, lo que llegó a consumir aproximadamente 4 GB de RAM en mi PC y, potencialmente toda mi banda ancha. Cabe señalar que, desde una VPS, este proceso resultaría aún más sencillo, pero opté por no gastar para probar.
Inicialmente, la página comenzó a ralentizarse y ciertos elementos dejaron de cargarse. Sin embargo, al alcanzar alrededor de 4,000 cuentas, la base de datos no pudo soportar la carga. El servidor comenzó a colapsar, volviéndose completamente inaccesible, lo comprobé desde los datos del teléfono y tampoco, aparecia un banner de este estilo al intentar acceder.
Quiero aclarar que soy estudiante de un ciclo formativo en informática y no me considero ni hacker ni pentester. Mi intención al compartir este método es simplemente reflexionar lo importante de los pequeños detalles y como una simple configuración puede afectar a todo un sistema incluso protegido por grandes empresas como Cloudflare.
Tengo el permiso explícito para hacer estas pruebas con lo cual no estoy cometiendo ningún delito.
Muchas páginas web contratan servicios costosos de protección, como Cloudflare, que actúan como proxy, filtran solicitudes y protegen puertos, entre otras coas. Si un servidor está configurado correctamente con Cloudflare, resultara difícil agotar los recursos de la página, ya que este servicio distribuye la carga y elimina solicitudes maliciosas. Además, dado que Cloudflare puede asociar una única IP a varios dominios, se evita afectar a otros sitios alojados en la misma dirección.
En mi primer escáner de nmap pude identificar la ip , los puertos abiertos y los servicios en ejecución. Algunos puertos se encuentran filtrados.
Probé a acceder a la IP y las dos que me proporcionaba el escaneo eran ip's de proxy de cloudflare.
Existen varias herramientas en Linux para generar tráfico masivo, como hping3, locust o incluso repositorios públicos de Slowloris. Aunque algunos de estos ataques pueden ser medianamente efectivos en ciertos escenarios, con Cloudflare dichos métodos quedan descartados, ya que los paquetes maliciosos ni siquiera llegan al servidor real y el rendimiento de la página no se ve afectado.
Tras varios intentos fallidos de "tumbar" la página de diversas maneras, se me ocurrió una idea. El hosting – es decir, el servidor real y no el de Cloudflare – tiene un límite de ancho de banda, como todos. Al tratarse de una empresa pequeña, es probable que dicho límite no fuera muy alto. ¿Sería posible interactuar con el backend, pasando por Cloudflare, para agotar los recursos del servidor?
Observé que el sistema no validaba el correo electrónico y que cada solicitud de creación de cuenta se procesaba sin inconvenientes, la solicitud de registro contenía una cookie pero era aceptada sin ella, siempre que no se repitiera el email o el nombre de usuario. En teoría, esto permitiría crear cuentas de manera indefinida. Aunque el proceso de registro implica únicamente la escritura de unos 20 a 30 caracteres (correspondientes al email, el user y la contraseña).
Para probar mi "hipótesis", intenté registrar una cuenta utilizando una contraseña compuesta por 10,000 caracteres, se olvidaron de poner longitud máxima en los campos de entrada. La validación se realizó sin problemas, lo que confirmó la existencia de una vulnerabilidad.
Posteriormente, programé – utilizando la librería requests de Python – las solicitudes necesarias para registrar alrededor de 10,000 correos electrónicos aleatorios acabados en @gmail.com , cada uno con contraseñas enormes. Realicé las solicitudes en bloques de 500, lo que llegó a consumir aproximadamente 4 GB de RAM en mi PC y, potencialmente toda mi banda ancha. Cabe señalar que, desde una VPS, este proceso resultaría aún más sencillo, pero opté por no gastar para probar.
Inicialmente, la página comenzó a ralentizarse y ciertos elementos dejaron de cargarse. Sin embargo, al alcanzar alrededor de 4,000 cuentas, la base de datos no pudo soportar la carga. El servidor comenzó a colapsar, volviéndose completamente inaccesible, lo comprobé desde los datos del teléfono y tampoco, aparecia un banner de este estilo al intentar acceder.
Quiero aclarar que soy estudiante de un ciclo formativo en informática y no me considero ni hacker ni pentester. Mi intención al compartir este método es simplemente reflexionar lo importante de los pequeños detalles y como una simple configuración puede afectar a todo un sistema incluso protegido por grandes empresas como Cloudflare.
