Introduction
Le 4 mai 2022, F5 a publié un avis de sécurité concernant une vulnérabilité dans le système iControl REST de BIG-IP qui pourrait permettre à un attaquant de contourner l'authentification du logiciel et d'exécuter des commandes arbitraires. Cette vulnérabilité a été classée CVE-2022-1388 par le NIST.
Les versions vulnérables de ce dispositif sont les suivantes (et peuvent être trouvées sur le système de fichiers du dispositif dans "/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.”>`
À l'heure où nous écrivons ces lignes, la base de données Censys compte un peu plus de 3 000 services et un peu plus de 2 500 hôtes ou hôtes virtuels correspondant à cette empreinte. La majorité de ces hôtes résident en Asie, avec 38,8 % du total, tandis que l'Europe suit de près avec plus de 30 % du total.
Il a également été signalé que cette vulnérabilité est activement exploitée dans la nature, de sorte que les administrateurs doivent vérifier leurs actifs et les mettre à jour immédiatement.
Résumé technique
Plusieurs serveurs HTTP sont en cours d'exécution sur le serveur BIG-IP : Un serveur Apache pour les opérations frontales (écoutant sur une interface publique) et plusieurs serveurs web backend internes, y compris un serveur Jetty pour l'API REST iControl. Bien que les services backend ne soient pas accessibles au public, plusieurs chemins URI sont exposés sur le serveur frontend, qui sont mandatés en interne par le serveur Apache frontend avec mod_proxy.
Lorsqu'un utilisateur s'authentifie auprès du serveur Apache frontal, un module Apache personnalisé appelé mod_auth_pam est utilisé pour valider les informations d'identification entrantes. Mais si le client inclut un en-tête nommé "X-F5-Auth-Token", la validation des informations d'identification est reportée au service qui traite la requête et suppose que le service en aval fera ce qu'il faut (et rejettera les valeurs X-F5-Auth-Token invalides).
Mais le service de backend iControl présente un oubli logique assez intéressant. Lorsqu'une requête est envoyée directement au service via localhost, et que le "X-F5-Auth-Token" n' est pas présent, la requête est autorisée sans validation tant qu'un nom d'utilisateur valide est trouvé dans la section Authorization de la requête. L'idée (nous le supposons) est que toute requête locale devrait être intrinsèquement fiable, car il n'y avait aucun moyen pour un client externe d'exclure l'en-tête X-F5-Auth-Token (et de ne pas inclure les informations d'identification) sans être rejeté au niveau du frontend via mod_auth_pam.
Mais s'il existait un moyen de tromper mod_proxy pour qu'il supprime le "X-F5-Auth-Token" avant d'envoyer la requête au service local de backend ? Regardons la spécification HTTP/1.1, RFC7230, à la section 6.1 pour un indice :
Cette déclaration signifie que toute valeur de jeton non standard (close/keep-alive, etc.) trouvée dans cet en-tête est traitée comme un en-tête à supprimer lorsqu'on agit en tant que proxy. Ainsi, par exemple, si l'en-tête "Connection" d'un client contient la valeur "close,X-F5-Auth-Token", un serveur mandataire conforme à la RFC (comme Apache mod_proxy) supprimera l'en-tête X-F5-Auth-Token de la demande avant de l'envoyer au backend. C'est précisément de cette manière qu'un attaquant peut contourner les hypothèses initiales formulées par le service dorsal.
Une simple demande de test de vulnérabilité peut être faite à n'importe quel service BIG-IP en utilisant la commande curl suivante :
