Introducción
El 4 de mayo de 2022, F5 publicó un aviso de seguridad que hablaba de una vulnerabilidad en el sistema iControl REST de BIG-IP que podría permitir a un atacante saltarse la autenticación del software y ejecutar comandos arbitrarios. Esta vulnerabilidad ha sido asignada CVE-2022-1388 por el NIST.
Las versiones vulnerables de este dispositivo son las siguientes (y pueden encontrarse en el sistema de archivos de dispositivos en "/etc/f5-release")
- 16.1.0 - 16.1.2
- 15.1.0 - 15.1.5
- 14.1.0 - 14.1.4
- 13.1.0 - 13.1.4
- 12.1.0 - 12.1.6
- 11.6.1 - 11.6.5
These potentially vulnerable devices can be found using a simple Censys search query: (services.http.response.html_title: “BIG-IP®- Redirect”) or services.http.response.html_tags=`<meta name=”description” content=”F5 Networks Configuration Utility.”>`
En el momento de escribir estas líneas, había algo más de 3.000 servicios y algo más de 2.500 hosts/hosts virtuales que coincidían con esta huella digital en la base de datos Censys . La mayoría de estos hosts residen en Asia, con un 38,8% del total, mientras que Europa ocupa un cercano segundo lugar con más del 30% del total.
También se ha informado de que esta vulnerabilidad está siendo explotada activamente en la naturaleza, por lo que los administradores deben comprobar sus activos, y actualizar de inmediato.
Resumen técnico
El servidor BIG-IP tiene varios servidores HTTP en ejecución: Un servidor Apache para operaciones frontend (escuchando en una interfaz pública) y varios servidores web backend internos, incluyendo un servidor Jetty para la API REST de iControl. Y mientras que los servicios backend no son accesibles públicamente, varias rutas URI están expuestas en el servidor frontend, que son proxyadas internamente por el servidor Apache frontend con mod_proxy.
Cuando un usuario se autentica en el servidor Apache, se utiliza un módulo personalizado de Apache llamado mod_auth_pam para validar las credenciales entrantes. Pero si el cliente incluye una cabecera llamada "X-F5-Auth-Token", la validación de las credenciales se difiere al servicio que gestiona la solicitud y asume que el servicio posterior hará lo correcto (y rechazará los valores X-F5-Auth-Token no válidos).
Pero el servicio backend de iControl tiene un descuido lógico bastante interesante. Cuando se envía una petición directamente al servicio a través de localhost, y el "X-F5-Auth-Token" no está presente, la petición se permite sin validación siempre que se encuentre un nombre de usuario válido en la sección Authorization de la petición. La idea (suponemos) es que cualquier petición local debería ser inherentemente fiable, ya que no había forma de que un cliente externo excluyera la cabecera X-F5-Auth-Token (y no incluyera credenciales) sin ser descartado en el frontend a través de mod_auth_pam.
Pero, ¿y si hubiera una forma de engañar a mod_proxy para que elimine el "X-F5-Auth-Token" antes de enviar la petición al servicio backend local? Echemos un vistazo a la especificación HTTP/1.1, RFC7230, en la sección 6. 1 para obtener una pista:
Esta declaración significa que cualquier valor de token no estándar (close/keep-alive, etc.) que se encuentre en esta cabecera se tratará como cabecera a eliminar cuando actúe como proxy. Así, por ejemplo, si la cabecera "Connection" de un cliente contiene el valor "close,X-F5-Auth-Token", un servidor proxy conforme con la RFC (como Apache mod_proxy) eliminará la cabecera X-F5-Auth-Token de la petición antes de enviarla al backend. Y así es precisamente como un atacante puede eludir las suposiciones originales hechas por el servicio backend.
Se puede realizar una simple solicitud de prueba de vulnerabilidad a cualquier servicio BIG-IP utilizando el siguiente comando curl:
