Introducción a la seguridad ofensiva

Pon a dos profesionales frente al portal de una clínica. Los dos ven exactamente lo mismo: una casilla de usuario, un campo de contraseña y un botón de ingreso.

La primera persona se pregunta cómo entrar sin autorización. Prueba contraseñas predecibles, mira si el sistema suelta pistas cuando falla y cuenta cuántos intentos tolera antes de bloquear a alguien. Su trabajo es encontrar las grietas antes de que las encuentre otro.

La segunda se pregunta cómo impedirlo. Decide cuántos intentos se permiten, comprueba que cada fallo quede anotado en los registros y se asegura de que alguien reciba el aviso cuando el patrón se repita. Su trabajo es cerrar lo que la primera abre.

Al primer enfoque se le llama seguridad ofensiva (Red Team) y al segundo seguridad defensiva (Blue Team). No son bandos opuestos: son dos turnos del mismo trabajo, y quien defiende sin entender cómo se ataca, defiende solo contra lo que imagina.

Dos personas trabajan hoy en la seguridad de la clínica:

• Valeria usó una lista de contraseñas frecuentes contra el formulario de acceso, con autorización por escrito, para ver si alguna entraba.
• Mateo dejó configurado que, tras varios fallos seguidos desde la misma conexión, el sistema deje de aceptar intentos y avise al equipo.

Abre el laboratorio con el botón de abajo. Vas a ver un escritorio con dos cosas: un navegador, ya abierto, y un icono de terminal que usarás más adelante. No son dibujos: el navegador abre direcciones y la terminal ejecuta comandos.

El sitio de esta práctica es la Clínica Meridiano, una clínica que no existe, montada para que puedas trastear sin romperle nada a nadie. Su dirección es clinica-meridiano.local, y es lo que el navegador tiene cargado.

Antes de tocar nada, mira qué te está contando el sitio de sí mismo: un nombre, un número de historia, una cita. Reconocer qué datos maneja un sistema es el primer paso de cualquier revisión, porque es lo que dice qué se pierde si algo sale mal. Aquí no es dinero: es a quién atienden, de qué y cuándo.

Un sitio web casi nunca es solo lo que se ve desde su menú. Se construye por partes y a lo largo de años, y por el camino quedan direcciones que funcionan y no están enlazadas desde ningún sitio: la pantalla con la que una recepcionista organiza el día, el formulario de una campaña de vacunación que ya terminó, la copia de una página vieja que nadie borró.

No están escondidas en el sentido de protegidas. Están escondidas en el sentido de que no hay ningún enlace que te lleve a ellas. Si escribes la dirección exacta en la barra, el servidor responde igual que con cualquier otra página.

¿Y cómo se encuentran, si no están enlazadas? Probando nombres. Casi nadie inventa direcciones originales para una pantalla interna: se llaman /login, /admin, /panel, /agenda, /backup. Así que se toma una lista de miles de palabras así y se pide una por una al servidor, anotando cuáles contestan que existen. A mano son semanas; un programa lo hace en segundos, y a esa familia de herramientas se le llama escáner de directorios.

Para usarlo necesitas la terminal, y todavía no está abierta: en el escritorio, a la izquierda, hay un icono que dice Terminal. Pulsa ahí y escribe:

dirb http://clinica-meridiano.local

(También puedes utilizar gobuster dir -u http://clinica-meridiano.local -w /usr/share/wordlists/dirb/common.txt)

El escáner probará miles de palabras y te devolverá las que responden, marcadas como CODE:200 — el 200 es la forma en que un servidor dice «esto existe, aquí lo tienes». Una de ellas es el portal (/). Las otras no aparecen en el menú, y una de esas dos guarda información de pacientes.

Ahora escribe esa dirección en la barra del navegador y pulsa Ir.

Vas a encontrarte la pantalla con la que la clínica organiza su día. Sin que nadie te pidiera usuario ni contraseña. Fíjate en el código de turno que aparece arriba: es la prueba de que llegaste.

Y mira la tabla que hay debajo. Entraste al portal como Amparo, y ahora tienes delante la agenda completa: nombre y apellido de cada paciente, parte de su documento, y a qué viene cada uno. Hay alguien que va a salud mental a las 9:15. Tú no tenías que saber eso.

Eso es lo que se filtra de verdad cuando una página no comprueba quién llega. No es un número en una pantalla: es que en una clínica el simple hecho de que alguien tenga una cita ya es un dato que no debería salir de ahí — y aquí sale sin pedir nada.

Eso es un fallo real y tiene nombre. La página estaba sin enlazar, y quien la puso confió en que nadie la encontraría. Pero no enlazar algo no lo protege de nada: solo lo hace más difícil de encontrar navegando, que es exactamente el obstáculo que acabas de quitar en segundos con un comando.

La palabra para esto es control de acceso, y la pregunta que lo resuelve no es «¿puede alguien llegar a esta dirección?» sino «¿comprueba esta página quién es el que llega?». Son cosas distintas, y confundirlas es una de las causas más repetidas de incidentes reales.

En veinte minutos has mirado un sistema preguntándote qué hay fuera de lo que te ofrece, has usado una herramienta para responder eso a escala, has decidido cuál de los hallazgos importaba y has distinguido «lo escondí» de «lo protegí». Ese último paso es el que separa un hallazgo de un informe útil.