savsch/poc_cve-2019-0217Preuve de concept d'exploit pour CVE-2019-0217, une condition de concurrence dans mod_auth_digest d'Apache HTTP Server permettant un contournement d'authentification. Comprend un environnement vulnérable basé sur Docker et un script d'automatisation Burp Turbo Intruder.
Ce dépôt contient une preuve de concept d'exploit pour CVE-2019-0217, ainsi qu'un Dockerfile pour configurer un serveur web vulnérable à cette CVE.
Dans Apache HTTP Server 2.4 versions 2.4.38 et antérieures, une condition de concurrence dans mod_auth_digest lorsqu'il est exécuté sur un serveur multithreadé pourrait permettre à un utilisateur disposant d'informations d'identification valides de s'authentifier en utilisant un autre nom d'utilisateur, contournant ainsi les restrictions de contrôle d'accès configurées.
Lorsqu'un client tente d'accéder à une ressource protégée par l'authentification Digest HTTP, le serveur répond avec un code d'état 401, accompagné d'un en-tête WWW-Authenticate, dont le format est approximativement le suivant :
Digest realm="rlm", nonce="TToc8M0jBgA=7afa4f292c97632a6c17eec458d3db31021b111f", algorithm=MD5, qop="auth"
Le client calcule HA1, qui est le condensé md5 de A1 (c'est-à-dire nom_utilisateur:domaine:mot_de_passe), puis y ajoute le nonce et d'autres métadonnées comme cnonce pour obtenir A2, dont le condensé md5 donne HA2, que le client envoie comme réponse, avec le nom d'utilisateur, cnonce et autres métadonnées, dans l'en-tête Authentication :
'Digest username="attacker", realm="rlm", nonce="TToc8M0jBgA=7afa4f292c97632a6c17eec458d3db31021b111f", uri="/scripts/userprofile.cgi", response="bcb433e4071fa228fe0c9452a7495efd", algorithm="MD5", qop="auth", nc=00000001, cnonce="2309510923095109"
^^^^^^^^^^
Comme décrit ci-dessous, la partie surlignée de l'en-tête ci-dessus peut être manipulée pour créer la condition de concurrence nécessaire au fonctionnement de l'exploit.
La vulnérabilité a été corrigée par ce commit.
En regardant le code du module mod_auth_digest (plus précisément la fonction get_hash dans mod_auth_digest.c), il est évident que le serveur analyse d'abord d'abord l'en-tête Authentication pour déterminer ce qui se trouve entre les guillemets après username=, qu'il traite comme l'utilisateur associé à la requête (r->user). Il vérifie ensuite si cet « utilisateur » a accès à la ressource demandée ou non. Si c'est le cas, la fonction get_hash récupère le HA1 correspondant dans le fichier d'authentification.
Avant le commit de correction de la vulnérabilité, le HA1 ainsi récupéré était stocké dans la variable conf = (digest_config_rec *) ap_get_module_config(r->per_dir_config,&auth_digest_module) qui n'est apparemment pas thread-safe.
Ce qui nous donne l'exploit :
Sur la base de la section d'analyse de la vulnérabilité ci-dessus, il devrait être possible de créer une condition de concurrence en envoyant simultanément des requêtes avec un en-tête Authentication valide et des requêtes avec un en-tête Authentication forgé (qui est le même que l'en-tête valide mais avec la valeur username= définie sur l'utilisateur cible (celui sous lequel l'attaquant veut s'authentifier)).
Terminologie utilisée dans cet exploit : - Attaquant : l'utilisateur qui exécute cet exploit. Il dispose d'un nom d'utilisateur et d'un mot de passe valides pour son propre compte. - Victime : l'utilisateur sous lequel l'attaquant veut se faire passer. Le nom d'utilisateur de la victime est connu, mais le mot de passe ne l'est (évidemment) pas.
J'ai pu faire fonctionner cette méthode en lançant une multitude de threads Python, certains envoyant des requêtes du premier type et d'autres du deuxième type, mais cela n'était pas fiable et nécessitait un grand nombre de requêtes pour réussir. Cela m'a conduit à utiliser Turbo Intruder de Burp (gratuit), qui envoie les requêtes en parallèle de manière fiable. Malheureusement, le support CLI de Turbo Intruder est défaillant, certaines parties de l'exploit doivent donc être réalisées à l'aide de l'interface graphique.
Pour utiliser le serveur vulnérable exemple que j'ai inclus dans ce dépôt, exécutez :
$ cd sample_vulnerable_server
$ docker build -t poc_httpd .
$ docker run -p 8038:80 poc_httpd
Exécutez generate_turbo_intruder_script.py, après avoir configuré les variables en haut :
# Configuration
URL = 'http://localhost:8038/scripts/userprofile.cgi' # location to the resource protected by digest auth
ATTACKER_USERNAME = 'attacker'
ATTACKER_PASSWORD = 'known'
VICTIM_USERNAME = 'victim'
NUMBER_OF_REQUESTS = 2000 # number of concurrent requests sent to catch a glimpse of the race condition
Ce script génère ensuite deux fichiers, generated/turbo_intruder_script.py et generated/request.txt dans le répertoire courant.
Ouvrez maintenant BurpSuite Community Edition, et installez l'extension « Turbo Intruder » en vous rendant dans Extensions -> BApp Store, si ce n'est pas déjà fait.
Ouvrez le Burp Repeater. Définissez l'hôte et le port de la cible :
Collez le contenu de generated/request.txt dans la section Requête :
Faites un clic droit n'importe où dans la section Requête, et sélectionnez 'Extensions->Turbo Intruder->Send to Turbo Intruder'.
Collez le contenu de generated/turbo_intruder_script.py dans la section script :
Enfin, cliquez sur le bouton Attack en bas de la fenêtre Turbo Intruder. Il devrait afficher tout résultat réussi dans l'écran résultant :
