Hoy comenzamos una serie de artículos para mostrar las distintas perspectivas que se pueden tomar a la hora de enfrentarse a un pentest.
Un pentest recrea las acciones ofensivas de un atacante para identificar posibles vulnerabilidades
Vamos a empezar por definirlo. Un pentest es un proceso de auditoría que intenta recrear las acciones ofensivas de un atacante, de la misma manera en que este las haría sobre un sistema para conseguir acceso a él, una denegación de servicio, una fuga de información o cualquier otro fallo de seguridad.
Consiste, como habíamos explicado anteriormente, en pruebas ofensivas contra los mecanismos de defensa del entorno que se está analizando, con el objetivo de identificar posibles vulnerabilidades en ellos.
Cuando alguien no relacionado con la informática me pregunta sobre esta labor, suelo poner el símil de la película "The Italian Job" ("La Estafa Maestra"), en la que la protagonista empieza “asaltando” una caja fuerte de manera legal para comprobar su seguridad.
Cuando realizamos una prueba de este tipo, debemos mezclar el uso de metodologías “convencionales” o formales con el “arte” del atacante, ponernos en su piel. Esto quiere decir que podemos apoyarnos en OSSTMM (Open Source Security Testing Methodology Manual) o en OWASP (The open web application Security Project) como base de nuestro trabajo.
El uso de metodologías formales nos permite reproducir los procesos y procedimientos en distintos clientes. Pero esto no es suficiente.
Cuando el profesional de la seguridad se enfrenta a sistemas defensivos complejos, o simplemente a las particularidades de cada empresa, debe hacer uso de su magia, el “hocus pocus” norteamericano o el “kung fu” asiático.
Vamos a dar algunos ejemplos para ilustrarte los casos.
Atacando todos los frentes
En un proceso de pentesting comenzamos por la definición del objetivo. Según las distintas metodologías podemos encontrar esta fase con distintos nombres, pero lo importante es el concepto: averiguar toda la información de la organización o sistema antes de atacarlo.
Esta es la parte más importante por varios motivos. Los tipos de auditorías o pentesting se pueden clasificar según la información previa que nos proporciona la organización:
- En el caso de contar con información previa detallada, se denomina White Box o caja blanca.
- En el caso de contar con información parcial de la organización se denomina Grey Box o caja gris.
- Aquellas auditorías que se realizan sin información previa por parte de la empresa se denominan Black Box o caja negra.
Imaginemos una empresa típica cuyo sitio web está alojado en un hosting externo. La empresa nos contrata para un pentesting del tipo Black Hat (sin información previa) y averiguamos la dirección IP del hosting. No tenemos permiso para realizar un ataque de red contra ese servidor, ya que la web está en un servidor compartido; por lo tanto, sería un error definir o preparar un ataque bajo esta perspectiva.
Comenzamos definiendo un objetivo para saber sobre la organización o sistema antes de atacarlo
Vamos a poner otro ejemplo. Tenemos una web de una empresa, que está alojada en un hosting, pero realizando un WHOIS descubrimos que el registro MX del servidor de correo reside en una IP de un ISP (proveedor de servicios de Internet) regional.
Otras veces el MX está en el mismo proveedor de hosting pero en el registro SPF (Sender Policy Framework) del correo aparece una dirección IP “externa” al hosting. Es esa la vía de ataque que debemos emplear, la dirección IP de la línea de la empresa y no la del servidor web externo.
Si realizas este parte sin obtener la dirección IP “real” del objetivo, puedes optar por enviar un correo a la empresa. Por ejemplo, solicitando información comercial. Muchas veces encontramos servidores de correo mal configurados a raíz de los cuales en la cabecera del e-mail podemos encontrar la dirección IP de la conexión saliente del correo.
Otras veces navegamos por la web de la empresa en busca de un enlace del tipo Intranet, Extranet, Acceso clientes, RRHH o similares, que apunten a recursos externos al hosting; la típica aplicación que corre en el servidor de la empresa y no el CMS frontal del webserver.
Para navegar por la web podemos usar un Spider como Burp Proxy o realizarlo manualmente. Por supuesto que debemos revisar el fichero robots.txt y probar una transferencia de zona con esta herramienta de HackerTarget, por ejemplo.
Una vez que encontramos la dirección IP de la “sede principal” o de la línea de datos principal podemos usar el servicio que mencionábamos antes de WHOIS para detectar rangos completos de direcciones contratadas por la empresa. Lo más habitual es que empresas de tamaño medio tengan muchas (repito, muchas) direcciones IP públicas, y suele ocurrir que “protegen” las principales, las que más exposición tienen y los servicios que corren sobre ellas.
Otro aspecto a valorar a la hora de dedicarle esfuerzo a la primera fase de reconocimiento es averiguar las capacidades defensivas de la empresa. No es lo mismo realizar pruebas en un entorno altamente asegurado, o a una empresa que sabemos de antemano que no posee mecanismos de seguridad.
¿Y qué tal si nos enfrentamos a un entorno medianamente seguro?
En un entorno medianamente seguro, con firewalls web y sistemas de detección/prevención de intrusos, debemos ser meticulosos a la hora realizar pruebas sobre aplicaciones web, escaneos de puertos, ataques de fuerza bruta y demás. Seguramente los sistemas detecten el “ruido” que hacemos y se pongan en modo defensivo, por lo que realizar una pequeña prospección nos puede servir a la hora de definir nuestros procesos de ataque.
Debemos intentar entrar por todas las vías posibles
Por ejemplo, podemos usar un navegador en la red Tor y realizar peticiones con un user-agent malicioso del tipo Nikto, Openvas o similar. Podemos realizar un ataque XSS/SQLi básico; podemos realizar un escaneo de puertos estándar, probar fuerza bruta contra servicios sin control, hacer 10 peticiones por segundo.
Según los resultados, podemos configurar las herramientas que usamos para proporcionar evasión más o menos profunda. Recuerda que las tareas de evasión suelen tener coste de tiempo y un escaneo lento desde la red Tor, que ya de por sí es lenta, puede consumir muchas horas del proyecto.
Nosotros los auditores queremos “entrar en el castillo” de la manera que sea. Generalmente el castillo suele tener una muralla, una buena puerta y una buena defensa frontal, por lo que si no es posible entrar por la puerta delantera, tendremos que probar cómo vulnerar esa defensa por todos los frentes. Debemos intentar todas las vías posibles, incluyendo rodear la puerta, hacer un túnel, entrar por una ventana...
Cuando una empresa pide asesoramiento sobre qué tipo de auditoría o pentesting realizar, siempre le aconsejo Black Hat, es decir, sin información previa. Me he encontrado con organizaciones que teniendo 10 direcciones IP públicas quieren auditar una de ellas por ser la “más expuesta” y, sin embargo, me encontré con graves fallos de seguridad en el resto de las direcciones.
Ese es un razonamiento erróneo, ya que un atacante en un país remoto, que no busca atacar concretamente a una organización sino encontrar alguna que sea atacable, no distingue entre una dirección IP acabada en 103, en 104 o en 105…
Mi recomendación es atacar o auditar todo el rango. El proceso de auditoría Black Hat requiere de una validación por parte del cliente, como decíamos antes; no sea que estemos atacando a un socio o proveedor sin permiso.
En el próximo artículo de la serie seguiremos hablando sobre estos “trucos” o visiones en cualquiera de las fases de un test de penetración o pentest.
