Moverse por la red

El encargo de hoy es la Bodega Viña Alta (la de Blue Team, la de las copias que se escapaban). Ya tienes un pie dentro: la bodega te ha dado una cuenta sin privilegios (deploy) en el servidor de la tienda (srv-tienda), el que da a internet. Pero lo que de verdad importa —los pedidos, los clientes— no está ahí: está en el servidor de datos (srv-datos), un equipo interno. La pregunta del tema: desde la tienda, ¿se puede llegar a él?

Eso es moverse por la red (o pivotar): usar el equipo en el que estás como trampolín para saltar a otro. La ventana va de las 20:00 a las 23:00, y la cláusula del encargo es clara: se demuestra el salto y se lee el marcador de B, pero el dato de negocio no se saca.

El movimiento lateral y el pivote

Entrar en una red casi nunca te deja directamente donde está lo valioso. Entras por donde se puede —la web, una cuenta de servicio— y desde ahí saltas: de un equipo al siguiente, usando lo que cada uno te da. Ese salto se llama pivote, y lo que lo hace posible suele ser un descuido que se encuentra mirando: una clave que abre otro servidor, una contraseña que se repite, una red donde todo se alcanza con todo.

El trabajo del auditor es encontrar ese camino, demostrarlo llegando al otro equipo, y documentarlo: «desde la tienda, con esta clave, se llega al servidor de datos». No hace falta robar nada para probar que se podría.

La red plana

Lo primero: ¿qué alcanza la tienda? Un nmap desde ella al servidor de datos lo dice.

deploy@srv-tienda:~$ nmap -Pn -p 22 192.168.88.11
Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for srv-datos (192.168.88.11)

PORT   STATE SERVICE
22/tcp open  ssh

El servidor de datos contesta en el 22 directamente desde la tienda: no hay nada que los separe. Eso es una red plana, y es justo lo contrario de lo que hacía Blue Team en esta misma bodega (BT.5: segmentar, cortar lo que un equipo puede hablar con otro). Una red plana convierte un fallo en la tienda —que da a internet— en un fallo en el servidor de datos. Es un hallazgo de baja gravedad por sí solo, pero es el terreno donde el salto es fácil. La recomendación es segmentar: que la tienda solo hable con el servidor de datos por lo justo (un puerto, una dirección) y nada más, con el cortafuegos del router. Cambiar el servidor de datos de IP o ponerle contraseña dejando la red plana no separa nada.

La clave SSH que viaja de más

Alcanzar B no basta: hace falta con qué entrar. Y la tienda lo regala: una clave SSH privada, en el sitio de siempre, pero legible de más.

deploy@srv-tienda:~$ ls -l ~/.ssh/id_rsa; cat ~/.ssh/id_rsa
-rw-r--r-- 1 deploy deploy 1876 oct 5 ~/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAAB...
-----END OPENSSH PRIVATE KEY-----

Dos cosas mal. Una, los permisos: -rw-r--r-- (0644) quiere decir que la lee cualquiera que entre en la tienda, no solo su dueño (una clave privada va a 0600). Dos, esa misma clave abre el servidor de datos con la cuenta deploy: la misma llave para dos puertas. Encontrarla en la tienda es, de hecho, tener ya la entrada al servidor de datos. Es el hallazgo alto del encargo.

Credenciales reutilizadas

Lo mismo pasa con las contraseñas. El fichero de despliegue de la tienda guarda la de la base de datos… que resulta ser la misma que abre el servidor de datos.

deploy@srv-tienda:~$ cat ~/deploy.env
# despliegue de la tienda
DB_HOST=srv-datos
DB_USER=deploy
DB_PASS=Bodega.2024
# nota: la misma contraseña vale para entrar en srv-datos

Reutilizar una contraseña es cómodo y es un regalo para quien audita: encontrarla en un sitio abre el otro. Es un hallazgo de gravedad media; la recomendación es una contraseña distinta por servicio, en un gestor de secretos y no escrita en un fichero de despliegue.

El salto y la flag de B

Con la clave (o la contraseña), se salta: ssh -i ~/.ssh/id_rsa deploy@srv-datos. Al otro lado, una sesión en el servidor de datos y su marcador, como el user.txt de los retos de Hack The Box:

deploy@srv-tienda:~$ # el botón del puesto: «saltar al servidor de datos con la clave»
sesión abierta en srv-datos como deploy
el marcador del encargo está en ~/user.txt de srv-datos:
SQ{salto-…}

Ese SQ{…} es la flag: prueba que llegaste al servidor interno. Y aquí está la cláusula del tema: se para ahí. Se demuestra el salto y se lee el marcador; el dato de negocio —los pedidos, los clientes— no se saca. Demostrar que se podría es el trabajo; lo demás sería el daño que un auditor no causa.

El salto es el hallazgo crítico del encargo: con lo que había en la tienda se llega al servidor interno sin nada en medio. Su recomendación junta las piezas de este tema: una clave distinta por servidor (y cuentas distintas), la privada protegida (0600 y, mejor, con frase) y segmentar para que la tienda no llegue al servidor de datos. Cambiar la clave de sitio o ponerle contraseña a la cuenta no corta el camino mientras la misma clave siga abriendo los dos servidores.

En la sala del tema

Estás en una sesión de deploy@srv-tienda, sin privilegios, de 20:00 a 23:00. El alcance es el servidor de datos (192.168.88.11), al que se llega desde la tienda; de la red interna (192.168.88.0/24) solo se puede barrer para ver qué hay. Excluido, el router de la bodega (192.168.88.1). En el puesto tienes la terminal (con nmap, cat…) y, en el cajón, el pivote para saltar a B con la clave que encuentres.

Cada hallazgo va al tablero con su evidencia —la salida de un comando o la flag de B—, su gravedad y su recomendación. Y la cláusula, siempre: se demuestra y se para; el dato no se saca. Al final entregas el informe y te llevas la nota en estrellas.