De la versión al camino conocido

Cuando la enumeración devolvió una versión concreta, media explotación está encaminada: con ese dato se busca si existe un aviso público conocido para esa versión. El criterio no es memorizar fallos, es saber pasar de «versión X» a «¿qué se sabe públicamente de la versión X?». En Salitre, el gestor de contenidos del servidor web mostró su versión exacta, y con ella se consulta qué caminos conocidos aplican antes de tocar nada más.

Con la versión en la mano, el trabajo deja de ser adivinar y pasa a ser consultar lo que ya se conoce. Esa es la base de una explotación guiada.

Aquí está la decisión fina: de los avisos que aparecen, solo sirve el que cubre tu versión exacta. Un aviso de otra rama —por llamativo que suene— no aplica, y perseguirlo es perder el tiempo o, peor, tumbar algo que no toca. Leer el rango de versiones afectadas y compararlo con la tuya es el paso que descarta el callejón. En Salitre, uno de los avisos cubre la versión del CMS y otro es de una rama distinta que no aplica.

El dato que decide no es el nombre del fallo: es si el rango de versiones afectadas incluye la tuya. Ahí se separa el camino del callejón.

Elegido el camino, todavía no se lanza a ciegas: un exploit es código que aprovecha un fallo concreto, y ejecutarlo sin saber qué toca puede tumbar el servicio. En una prueba autorizada, tumbar el objetivo es un hallazgo en tu contra, no a tu favor. El criterio es entender qué hace el camino conocido, qué acceso promete y qué riesgo tiene para el objetivo antes de usarlo. En Salitre, el aviso que aplica lleva a acceso, y conviene saberlo antes de darle.

Un pentest no es entrar como sea; es entrar demostrando control de lo que haces. El daño colateral cuenta en tu contra.

El camino que aplica no se adivina: sale de cruzar la versión con los avisos. Abre el laboratorio, revisa qué aviso conocido encaja con la versión del CMS de Salitre y baja hasta el código de sala al pie.