¿Qué pensamos los pentesters durante una auditoría?

El trabajo de un pentester suele estar rodeado de cierta opacidad. Y no siempre porque queramos hacerlo parecer misterioso, sino porque, sencillamente, no es habitual conocer cómo trabajamos quienes nos dedicamos a este ámbito.

Si esto ya ocurre cuando hablo con otros profesionales tecnológicos, imaginaos en una cena de Navidad cuando alguien me pregunta a qué me dedico.

Por eso me gustaría arrojar un poco de luz sobre este tema y explicar, de una forma sencilla, qué pasa por la cabeza de un pentester durante los primeros compases de una auditoría de seguridad. Sin tecnicismos innecesarios y sin que parezca una explicación salida de una serie de televisión.

Lo primero que hacemos es analizar el entorno. Suena a película de espías, pero en realidad es algo mucho más terrenal. Utilizamos herramientas para identificar máquinas en la red, observar cómo se comunican entre ellas y, a partir de ahí, deducir para qué pueden estar siendo utilizadas.

En cierto modo, es un trabajo de observación y contexto. Como si siguieras a una persona y vieras que pasa gran parte del día llamando a clientes, presentándose y hablando de las ventajas de las sillas que vende su empresa. Sin que nadie te lo diga, puedes deducir que trabaja en el área comercial. En una auditoría ocurre algo parecido: observamos patrones y extraemos conclusiones iniciales.

Una vez tenemos una imagen general del entorno, el siguiente paso es buscar posibles puntos vulnerables. Para ello intentamos interactuar con los sistemas y comprobamos cómo responden ante comportamientos no habituales: peticiones inesperadas, entradas anómalas o situaciones que pueden revelar fallos de diseño, errores de configuración o versiones obsoletas.

Siguiendo con el ejemplo anterior, sería como acercarte a ese comercial de sillas, preguntarle por sus productos y, de repente, pedirle un presupuesto de cafeteras para ver cómo reacciona. Esa reacción puede decir mucho: quizá dude, quizá improvise, quizá revele información que no debería o quizá se limite a responder de forma controlada.

A partir de aquí llega una de las partes más importantes del trabajo: Formular hipótesis.

Cuando un sistema se comporta de una determinada manera, debemos preguntarnos por qué. ¿Responde así porque existe una vulnerabilidad real? ¿O porque está diseñado precisamente para reaccionar de ese modo ante entradas no previstas? La diferencia es clave.

Traducido al ejemplo: ¿el comercial ha reaccionado de forma extraña porque lo hemos sacado de su guion, o porque realmente su empresa también vende cafeteras y está intentando consultar con otro compañero?

En este punto empezamos a pensar como lo haría un atacante: no para causar daño, sino para anticipar qué caminos podría intentar explotar alguien con malas intenciones. Tal vez podamos construir una interacción que haga que una máquina revele más información de la debida. Tal vez no tengamos acceso directo a un determinado sistema, pero sí a otro que ya confía en él y puede servir como puente.

Cuando hemos definido un conjunto razonable de hipótesis, llega el momento de ponerlas a prueba. Modificamos peticiones, alteramos parámetros, repetimos pruebas y tratamos de confirmar o descartar nuestras sospechas.

Muchas hipótesis se descartan rápido. Algunas, incluso, casi de un vistazo; la experiencia ayuda. Otras, en cambio, acaban revelando un hallazgo real. Cuando esto ocurre, lo documentamos con detalle y seguimos avanzando hasta agotar las vías de análisis.

El resultado final de todo ese trabajo es un informe que traduce los hallazgos en información útil para distintos perfiles: detalles técnicos para quien tiene que corregir los problemas y una visión ejecutiva para quien necesita entender el nivel de exposición y tomar decisiones.

La conclusión, en el fondo, es sencilla: si ese comercial de sillas termina contándonos el plan de expansión del negocio de cafeteras de su empresa, no se trata de culpabilizarle, sino de entender que existe una debilidad que debe corregirse.

Porque al final, de eso trata una auditoría de seguridad: de encontrar vulnerabilidades antes de que lo haga quien no debe.