ivant7d3/cve-2025-44203Exploit pour CVE-2025-44203 ciblant une condition de concurrence dans HotelDruid 3.0.0/3.0.7 qui divulgue les identifiants admin et provoque un déni de service. Inclut un script de brute-force pour la récupération hors ligne des mots de passe.
HotelDruid 3.0.0 et 3.0.7 contiennent une condition de course sur le point de terminaison de configuration creadb.php, accessible avant la fin de l'installation. Cela a deux impacts, provenant tous deux de la même course perdue : une divulgation d'informations sensibles (via des messages d'erreur SQL verbeux) et un déni de service.
En envoyant de nombreuses requêtes POST à la fois, un attaquant peut déclencher une condition de course et lire des données sensibles dans la réponse, notamment le nom d'utilisateur de l'administrateur, le hachage du mot de passe et le sel. Si le mot de passe choisi lors de la configuration du paquet Debian est faible, il peut ensuite être récupéré hors ligne avec une liste de mots.
Lorsque l'attaque réussit, l'administrateur ne peut plus se connecter avec les identifiants définis lors de l'installation (déni de service).
Le paquet Debian laisse creadb.php accessible sans connexion jusqu'à la fin de l'installation, et avec la valeur par défaut du paquet C_UTILIZZA_SEMPRE_DEFAULTS="AUTO", il réexécute toute la création de la base de données à chaque requête. Cette routine émet plus de 100 instructions SQL (création et remplissage des tables) sans verrou autour d'elle, de sorte que plusieurs requêtes arrivant ensemble l'exécutent en même temps. C'est la course.
Sur une machine lente ou occupée, les exécutions parallèles se chevauchent et entrent en collision sur la base de données SQLite. Une fois qu'une requête a commencé à créer les tables et les lignes, les instructions d'une requête ultérieure échouent en masse pour diverses raisons, comme des lignes déjà existantes ou la base de données verrouillée par une autre écriture. À chaque échec, le wrapper de requête d'HotelDruid esegui_query() imprime l'instruction en échec complète dans la réponse HTTP. Cela signifie qu'une seule réponse revient avec des dizaines de ces erreurs SQL, et l'une d'elles contient les informations sensibles du compte administrateur.
update ...utenti set password = '<hash>', salt = '<salt>', tipo_pass = '5' where idutenti = '1'
C'est à peu près ainsi que l'exploit détecte le succès. Il recherche dans la réponse set password, qui n'apparaît que lorsque cette instruction précise est affichée, ce qui ne se produit jamais dans la sortie normale de creadb.php.
Le verrouillage provient du même échec. La ligne admin est d'abord insérée avec tipo_pass='n', et seul le UPDATE ci-dessus la transforme en un compte fonctionnel (tipo_pass='5' avec un mot de passe défini). Le code qui s'exécute juste après le UPDATE ne vérifie jamais s'il a fonctionné. Il crée le fichier abilita_login, qui active la connexion, supprime ini.php, qui contenait les identifiants administrateur, et écrit ensuite ultimo_accesso, qui ferme définitivement l'installation. Ainsi, lorsque le UPDATE perd la course, le compte reste à tipo_pass='n', ce que la page de connexion rejette toujours même avec le bon mot de passe, alors que la connexion est activée et que le fichier d'identifiants a disparu. À ce stade, il n'y a aucun moyen de revenir en arrière sans réinstaller.
C'est pourquoi une fuite réussie et le verrouillage sont en réalité le même événement. Les deux se produisent lorsque ce seul UPDATE perd la course. Lorsque vous obtenez uniquement le nom d'utilisateur, cela signifie qu'une instruction antérieure est entrée en collision tandis que le UPDATE du mot de passe a réussi, donc rien n'a été verrouillé.
Exécutez l'exploit contre la cible depuis la machine de l'attaquant :
python3 exploit.py 192.168.1.1
où 192.168.1.1 est l'adresse IP de la machine exécutant HotelDruid.
Si cela fonctionne, utilisez brute.py avec une liste de mots pour tenter de récupérer le mot de passe en clair. Ouvrez brute.py, définissez salt sur le sel que vous avez obtenu et final_hash sur le hachage que vous avez obtenu, puis exécutez :
python3 brute.py rockyou.txt
où rockyou.txt est votre liste de mots.
Notez que même avec le nom d'utilisateur et le mot de passe corrects, vous ne pourrez toujours pas vous connecter, et l'administrateur non plus. Le mot de passe que vous récupérez est correct, mais la course réussie a laissé le compte bloqué à tipo_pass='n', donc la page de connexion le rejette. Voir la section « Cause racine ».
La vulnérabilité a été corrigée dans HotelDruid 3.0.8. Voici le journal des modifications, il suffit de rechercher « CVE-2025-44203 ».
L'assistant de verrouillage qu'il utilise (crea_lock_file(), un flock(LOCK_EX) bloquant) était déjà présent dans la version 3.0.7 et était utilisé dans d'autres parties du code. Cependant, creadb.php ne l'a jamais appelé. Le correctif fait deux choses :
Il prend un verrou exclusif autour de la routine d'installation, de sorte que les requêtes arrivant ensemble attendent leur tour au lieu de faire la course. Le correctif implémente cela en appelant enfin cet assistant dans creadb.php : il acquiert le verrou juste avant le provisionnement de l'admin et le libère avec distruggi_lock_file() ensuite. Ce qui le rend efficace, c'est la vérification juste après la prise du verrou. La requête qui entre en premier supprime ini.php alors qu'elle détient toujours le verrou, et chaque requête relit si ini.php existe avant le provisionnement, donc celles qui suivent prennent le verrou, trouvent le fichier déjà disparu, et sautent tout le bloc. Au moment où la seconde s'exécute, l'installation est déjà terminée et elle ne fait rien.
Il passe le drapeau de silence aux deux requêtes UPDATE admin, de sorte que même si l'une d'elles échoue, elle n'imprime plus les identifiants dans la réponse. Le correctif implémente cela en ajoutant un second argument, 1, à ces deux appels esegui_query(), celui qui définit le nom d'utilisateur et celui qui définit le mot de passe et le sel. Ce drapeau indique au wrapper de requête de rester silencieux lorsqu'une requête échoue. Il enregistre toujours l'erreur dans le journal du serveur, mais il saute le echo qui aurait autrement placé l'instruction en échec, y compris le hachage et le sel, dans la page.
creadb.php:
879: esegui_query("update $tableutenti set nome_utente = '".aggslashdb($admin)."' where idutenti = '1'",1);
897: esegui_query("update $tableutenti set password = '$passw', salt = '$salt', tipo_pass = '5' where idutenti = '1'",1);