Bypass a CloudFlare buscando datos en Internet

Cloudflare es un servicio que actúa como intermediario entre un sitio web y sus usuarios finales, protegiéndolo de varios ataques. Desafortunadamente, esos sitios web a menudo están mal configurados, lo que permite a un atacante eludir por completo Cloudflare y ejecutar ataques DDoS o explotar vulnerabilidades basadas en la web que de lo contrario se bloquearían. Esta publicación demuestra la debilidad e introduce CloudFlair, una herramienta de detección automatizada.

Cloudflare permite que los sitios web que se protejan contra todo tipo de ataques. También puede actuar como un cortafuegos de aplicación web (WAF) para bloquear la explotación de vulnerabilidades basadas en la web, como las inyecciones de XSS y SQL. Cloudflare ganó aún más atracción recientemente al anunciar la mitigación de los ataques DDoS: Cloudflare está básicamente estableciendo que protegerán a sus clientes contra ataques DDoS de cualquier escala sin cobrar ningún extra, sin importar en qué plan de precios se encuentren (incluido el gratuito).

En las últimas semanas, descubrí que varios sitios web que usaban Cloudflare estaban mal configurados y permitía que un atacante omitiera fácilmente cualquier protección Cloudflare. Varias de las empresas detrás de estos sitios web tenían más de 1 millón de usuarios y se encontraban entre las principales compañías de su segmento de mercado.

Importante: Este artículo no habla de una vulnerabilidad en el servicio Cloudflare en sí, sino de un error de configuración comúnmente hecho por los propietarios del sitio web que protegen su sitio web con Cloudflare.

Proteger un sitio web con Cloudflare

Este es el aspecto de un flujo de solicitud típico para un sitio web que no está protegido por Cloudflare.

1. El usuario se pone en contacto con el servidor DNS del proveedor de alojamiento del sitio web y solicita la IP de example.com
2. El servidor DNS responde con la IP del servidor web que aloja example.com (por ejemplo, 10.20.300.40)
3. El usuario hace una solicitud HTTP a ese servidor web
4. El servidor web responde con la página web

Flujo de solicitud típico para un sitio web no protegido por Cloudflare

Como cualquiera puede acceder directamente al servidor web que aloja example.com, un atacante puede dañar el sitio web al ejecutar un ataque DDoS. Si la infraestructura detrás de example.com no es lo suficientemente grande como para absorber o bloquear el tráfico, el sitio puede ser completamente noqueado.

Cuando una empresa (o persona) decide usar Cloudflare para proteger su sitio web,

1. Va a su registrador de dominio y establece los servidores DNS a Cloudflare (por ejemplo, empresa.ns.cloudflare.com);
2. Configura su cuenta Cloudflare para trabajar con el nombre de dominio (por ejemplo, empresa.com).

Ahora, cuando un usuario accede a empresa.com, sucede lo siguiente.

1. El usuario se pone en contacto con el servidor DNS kim.ns.cloudflare.com y solicita la dirección IP de micompañia.com
2. El servidor DNS responde con la IP de un servidor intermediario Cloudflare (por ejemplo, 103.10.119.248)
3. El usuario hace una solicitud HTTP a este servidor
4. Cloudflare verifica la legitimidad de la solicitud (presencia de contenido malicioso, dirección IP de origen, además de otros factores), y decide si permite que la solicitud pase o la bloquea.
5. Si Cloudflare decide permitir el paso de la solicitud, la reenvía al servidor web real responsable de mycompany.com (por ejemplo, 155.246.997.63). Este servidor se llama comúnmente el servidor de origen.

Flujo de solicitudes para un sitio web que usa Cloudflare

En teoría, un atacante no puede acceder directamente al servidor de origen y, en particular, no conoce su dirección IP. Sin embargo, esta protección se basa en que solo se puede acceder al servidor de origen a través de Cloudflare.

Para que esta protección funcione, un atacante no debe poder acceder directamente al servidor de origen. De lo contrario, puede ponerse en contacto con el servidor de origen sin pasar por Cloudflare, y pasar por alto cualquier protección.

Servidores de origen expuestos

La forma correcta en que debe comportarse un servidor de origen detrás de Cloudflare es solo para aceptar el tráfico procedente de los intervalos de IP de Cloudflare. Sin embargo, muchos servidores de origen aceptan con mucho gusto el tráfico entrante desde cualquier fuente. Creo que esto se debe en parte a la falta de énfasis en este tema en la documentación de Cloudflare. Lo más parecido que encontré en los documentos se encuentra en una página titulada "Primeros Pasos Recomendados para todos los usuarios de Cloudflare":

Paso 1: incluir en la lista blanca las direcciones IP de Cloudflare

Una vez que haya cambiado sus servidores de nombres a Cloudflare, el tráfico web se enrutará a través de la red de Cloudflare. Esto significa que su servidor web verá mucho tráfico con proxy a través de Cloudflare, y para permitir que todo este tráfico acceda a él, deberá asegurarse de que las IP de Cloudflare estén en la lista blanca y no de ninguna otra manera en su servidor. Tenemos a nuestra disposición una página con todas las IP Cloudflare (https://www.cloudflare.com/ips/).

Como puede leer, esto solo les dice a los administradores del sistema que incluyan en la lista blanca las direcciones IP de Cloudflare, sin dar instrucciones explícitas para bloquear el tráfico entrante proveniente de otras fuentes.

Importante:

Cloudflare no detiene los atacantes inteligentes que saben su dirección IP origin ya que el tráfico que mandan no pasa por Cloudflare, sino que lo mandan directamente a tus servidores.

En resumen: un servidor de origen de acceso público es seguro "siempre y cuando" nadie encuentre sus direcciones IP.