From version to exploit

El escaneo de versiones devuelve cosas como Apache httpd 2.4.49, vsftpd 2.3.4 o ProFTPD 1.3.5, y whatweb o el propio panel añaden las de la capa de aplicación (Pluck 4.7.18, WP Advanced Search 3.3.9). Ese dato no es un adorno del informe: es el que decide el siguiente paso. El salto de "hay un servicio X versión N" a "existe un exploit para esto" es una búsqueda, no una intuición, y conviene hacerla siempre igual.

Por qué la versión exacta es lo que importa. Una vulnerabilidad no afecta a un producto, afecta a un rango de versiones: cuando un aviso dice <= 3.3.9, significa que el fallo se corrigió en la siguiente. Por eso 3.3.9 es explotable y 3.3.9.2 no, aunque el producto sea el mismo. Un número de versión sin el tercer dígito, o un "más o menos esta rama", no sirve para decidir.

Dónde se busca. El primer sitio es el espejo local de Exploit-DB, porque es instantáneo y funciona sin internet:

searchsploit vsftpd 2.3.4          # busca por producto y version
searchsploit -x unix/remote/17491.rb   # LEER el exploit antes de ejecutarlo
searchsploit -m unix/remote/17491.rb   # copiarlo al directorio de trabajo
searchsploit -w vsftpd             # devuelve la URL de exploit-db en vez del path

Si ahí no hay nada, se amplía: el CVE en NVD (para leer la descripción y el rango afectado), una búsqueda en GitHub por el identificador (CVE-2021-43857), el changelog o el aviso de seguridad del fabricante (a veces la corrección se documenta antes de que exista PoC público), y para WordPress un wpscan que ya cruza plugins y temas contra su propia base.

Buscar por componente, no solo por servidor. El fallo casi nunca está en el nginx de delante, sino en la aplicación o en uno de sus plugins. Una web con un nginx 1.18.0 perfectamente parcheado puede estar corriendo un plugin de WordPress con una SQLi sin autenticar. La versión que hay que enumerar es la de cada pieza, no la del contenedor.

Leer el exploit antes de lanzarlo. Es código de terceros que se ejecuta con nuestro usuario y contra un sistema del que respondemos. Abrirlo (searchsploit -x, o simplemente el editor) sirve para tres cosas a la vez: comprobar que hace lo que dice, entender el mecanismo del fallo (que es lo que queda después, cuando el exploit ya no sirva) y detectar lo que hay que adaptar. Lo habitual es que haya algo: una IP o un puerto fijados en el código, un python2 que ya no está instalado, un offset calculado para otra compilación, una URL con la ruta del laboratorio original.

Que la versión sea vulnerable no garantiza que el exploit funcione. Son dos afirmaciones distintas, y confundirlas hace perder horas:

• La distribución puede haber aplicado un backport: Debian, Ubuntu y RHEL corrigen el fallo sin cambiar el número de versión, así que el banner sigue anunciando la versión vulnerable mientras el código ya está parcheado.
• El banner puede estar falseado a propósito, o ser el de un componente distinto del que responde.
• La configuración concreta puede no cumplir los requisitos del exploit: un módulo desactivado, una ruta que no existe, un recurso al que el exploit necesita llegar y que aquí está cerrado.

Por eso un escáner que dice VULNERABLE es un indicio; la prueba es el exploit ejecutado con resultado. Cuando falla, lo correcto no es insistir sino leer por qué falló (el mensaje suele decirlo) y volver a la enumeración con esa información.

Por qué importa. Es el punto donde el reconocimiento se convierte en acceso, y también donde más se improvisa. Hacerlo con método (versión exacta → rango afectado → exploit leído → adaptado → ejecutado) evita las dos formas típicas de atascarse: dar por explotable algo que no lo es, y descartar un servicio porque un exploit copiado a ciegas no funcionó a la primera.

Defensa. Mantener un inventario de software con versiones y parchear por rango, no por corazonada. Minimizar los banners ralentiza esta búsqueda pero no la impide (la huella de la aplicación delata la versión igual), así que no sustituye al parcheo. Y dado que la ventana entre el aviso público y el PoC suele ser de días, lo que de verdad reduce el riesgo es acortar el tiempo de actualización de los componentes expuestos, incluidos los plugins de terceros que nadie recuerda que están instalados.