Huntarr - Vos mots de passe et toutes les clés API de votre pile arr sont exposés à quiconque sur votre réseau, ou pire, sur Internet

[Raccoon]

Aujourd’hui, après avoir soulevé des préoccupations de sécurité dans un post sur r/huntarr concernant le manque de normes de développement dans ce qui ressemble à un projet 100% vibe-coded, j’ai été banni. Ça m’a mis la puce à l’oreille, donc j’ai décidé de faire un audit de sécurité du code. Ce que j’ai trouvé n’était pas bon. TLDR : Si vous avez Huntarr exposé sur votre stack, n’importe qui peut récupérer vos clés API pour Sonarr, Radarr, Prowlarr, et toutes les autres applications connectées sans se connecter, obtenant un contrôle total sur votre stack de médias.

Le processus

J’ai fait un audit de sécurité de Huntarr.io (v9.4.2) et trouvé des vulnérabilités critiques de contournement d’authentification. Je poste ça ici parce que Huntarr se situe au-dessus de (et essaie maintenant de les remplacer aussi !) Sonarr, Radarr, Prowlarr, et d’autres applications *arr qui ont des années de renforcement de sécurité derrière elles. Si vous installez Huntarr, vous ajoutez une application sans aucune authentification sur ses points d’accès les plus sensibles, et ça perfore la sécurité réseau que vous avez mise en place pour le reste de votre stack.

La pire : POST /api/settings/general ne nécessite aucune connexion, aucune session, aucune clé API. Rien. Quiconque peut accéder à votre instance Huntarr peut réécrire toute votre configuration, et la réponse revient avec tous les paramètres pour chaque application intégrée en texte clair. Pas seulement les identifiants proxy de Huntarr - la réponse inclut les clés API et les URLs d’instance pour Sonarr, Radarr, Prowlarr, Lidarr, Readarr, Whisparr, et toutes les autres applications connectées. Une commande curl et un attaquant a un accès API direct à l’ensemble de votre stack de médias :

curl -X POST http://your-huntarr:9705/api/settings/general \
  -H "Content-Type: application/json" \
  -d '{"proxy_enabled": true}'

Dump complet de la config avec mots de passe et clés API pour chaque application connectée. Si votre instance est accessible depuis Internet - ce qui est souvent le cas, Huntarr incorpore des fonctionnalités comme Requestarr conçues pour l’accès externe - quiconque sur Internet peut récupérer vos identifiants sans se connecter.

Autres découvertes (21 au total à travers critiques/hautes/moyennes) :

• Inscription 2FA non authentifiée sur le compte propriétaire (Critique, prouvé en CI) : POST /api/user/2fa/setup sans session a retourné le véritable secret TOTP et le code QR pour le compte propriétaire. Un attaquant génère un code, appelle /api/user/2fa/verify, s’inscrit avec son propre authentificateur. Prise de contrôle complète du compte, aucun mot de passe nécessaire.

• La configuration claire non authentifiée permet la prise de contrôle complète du compte (Critique, prouvé en CI) : POST /api/setup/clear ne nécessite pas d’authentification. Retourne 200 “Configuration réinitialisée.” Un attaquant réactive le flux de configuration, crée un nouveau compte propriétaire, remplace complètement le propriétaire légitime.

• Génération de clé de récupération non authentifiée (Critique, prouvé en CI) : POST /auth/recovery-key/generate avec {"setup_mode": true} atteint la logique métier sans contrôle d’authentification (retourne 400, pas 401/403). Le point de terminaison n’est pas authentifié.

• Exposition complète des identifiants entre applications (Critique, prouvé en CI) : Écrire un seul paramètre renvoie la configuration pour 10+ applications intégrées. Un seul appel, toutes les clés API de votre stack.

• Dissociation de compte Plex non authentifiée - quiconque peut déconnecter votre Plex de Huntarr

• Contournement d’authentification sur la liaison de compte Plex via un drapeau contrôlé par le client setup_mode - le serveur passe les vérifications de session si vous envoyez {"setup_mode": true}

• Écriture de fichier arbitraire Zip Slip (Haute) : zipfile.extractall() sur des ZIPs téléchargés par l’utilisateur sans nettoyage de nom de fichier. Le conteneur s’exécute en tant que root.

• Parcours de chemin dans la restauration/suppression de sauvegarde (Haute) : backup_id provenant de l’entrée utilisateur va directement dans les chemins du système de fichiers. shutil.rmtree() en fait une primitive de suppression de répertoire.

• local_access_bypass fait confiance aux en-têtes X-Forwarded-For , qui sont triviellement falsifiables - combinez avec l’écriture de paramètres non authentifiés et vous obtenez un accès complet aux points de terminaison protégés.

Comment j’ai trouvé ça : Revue de code basique et outils automatisés standards (bandit, pip-audit). Des choses que tout mainteneur devrait exécuter. Le contournement d’authentification n’est pas un bug subtil - auth.py a une liste blanche explicite qui ignore l’authentification pour /api/settings/general. Ce n’est tout simplement pas là.

À propos du mainteneur et du code :

Le mainteneur dit qu’ils ont “une série de documents de gouvernance que j’ai générés qui effectuent des vérifications de cybersécurité et fournissent un renforcement supplémentaire” et “Notez que je travaille aussi dans la cybersécurité.” Ils disent qu’ils ont passé “120+ heures au cours des 4 dernières semaines” à utiliser “des documents de gouvernance pour conseiller tout au long du processus de cybersécurité, de renforcement et de normes”. Si c’est vrai, ça ne se voit pas dans le code.

Si vous travaillez dans la cybersécurité, vous devriez savoir qu’il ne faut pas mettre sur liste blanche votre point d’accès le plus sensible en tant qu’inauthentifié. Vous devriez savoir que retourner des secrets TOTP à des appelants non authentifiés est une prise de contrôle de compte. Vous devriez savoir que zipfile.extractall() sur une entrée non fiable est un Zip Slip classique. C’est des choses d’introduction. Les “documents de gouvernance en cybersécurité” ne prennent pas en compte ce qu’un scan de sécurité basique signale en quelques secondes.

Regardez l’historique des commits : des dizaines de commits avec des messages comme “Mise à jour”, “update”, “Patch”, “changement”, “Correction de bug” - des centaines de fichiers changés dans des commits séparés par quelques minutes. Pas de processus PR, pas de revue de code, pas de deuxième paire d’yeux - juste un développement brut basé sur le tronc où 50 fonctionnalités sont poussées en un jour sans aucune revue. Les projets OSS normaux sont plus lents pour une raison : plusieurs personnes examinent les changements avant qu’ils ne soient intégrés. Huntarr n’a rien de tout ça.

Quand a été appelé là-dessus, le mainteneur a parlé de contraintes budgétaires : “Avec un budget limité, vous ne pouvez aller que jusqu’à un certain point à moins de vouloir dépenser plus de 1000 $. J’alloue 40 $ par mois pour les tâches les plus lourdes.” Ce n’est tout simplement pas vrai - vous pouvez utiliser le développement assisté par IA 8 heures par jour pour 20 $/mois. Le vrai problème n’est pas le budget. C’est que le mainteneur ne comprend pas l’architecture de sécurité qu’il construit et ne comprend pas les outils qu’il utilise pour la construire. Vous ne pouvez pas guider une IA pour mettre en œuvre l’authentification si vous ne reconnaissez pas ce qui ne va pas quand ça ne marche pas.

Ils censurent également les rapports de sécurité et banni ceux qui soulèvent des préoccupations. Un utilisateur a posté des préoccupations de sécurité sur r/huntarr et cela a été supprimé par le modérateur - le mainteneur contrôle le subreddit. J’ai été banni de r/huntarr après avoir souligné ces problèmes dans ce fil où le mainteneur prétendait travailler dans la cybersécurité (qu’ils ont maintenant supprimé).

Une chose de plus - le README du projet a une section “Support - Construire l’Avenir de ma Fille” sollicitant des dons. C’est un signal d’alarme pour moi. Vous demandez aux gens de financer votre développement tout en livrant du code avec 21 vulnérabilités de sécurité non corrigées, pas de processus de revue de code, et en banni ceux qui soulèvent des problèmes, tout en faisant appel à l’émotion pour votre fille. Si vous avez besoin d’argent, c’est bien - mais vous devriez être transparent sur ce que vous en faites et vous devriez livrer un code qui ne met pas vos utilisateurs en danger.

Dépôt de preuves avec CI automatisé : https://github.com/rfsbraz/huntarr-security-review

Configuration Docker Compose qui tire l’image Huntarr publiée et exécute un script Python prouvant chaque vulnérabilité. GitHub Actions l’exécute à chaque push - vérifiez vous-même les résultats du workflow ou exécutez-le localement avec docker compose up -d && python3 scripts/prove_vulns.py.

Pour ce que ça vaut, et pour prouver que je ne suis pas un haineux de l’IA, le script prove_vulns lui-même a été codé avec une vibe - j’ai identifié les vulnérabilités par une revue de code, écrit les étapes de reproduction, et fait générer le script de preuve par IA.

Revue complète de sécurité (21 découvertes) : https://github.com/rfsbraz/huntarr-security-review/blob/main/Huntarr.io_SECURITY_REVIEW.md

Ce qui se passera ensuite : Le mainteneur va probablement ignorer ces problèmes - alimenter les découvertes à une IA et livrer un patch. Mais corriger 21 découvertes spécifiques ne corrige pas le processus qui les a créées. Pas de revue de code, pas de processus PR, pas de tests automatisés, personne qui comprend la sécurité pour examiner ce qui est livré. Le prochain lot de fonctionnalités aura le prochain lot de vulnérabilités. Ce n’est que le début. Si la communauté ne pousse pas pour de meilleures normes de codage, un développement contrôlé, et une feuille de route sensée, les gens continueront à exécuter du code que personne n’a examiné.

Si vous exécutez Huntarr, gardez-le hors de tout réseau que vous ne faites pas entièrement confiance jusqu’à ce que cela soit réglé. Les applications *arr qu’il englobe ont leur propre authentification par clé API - Huntarr contourne cela complètement.

Veuillez informer les autres à ce sujet. Si vous avez une instance de Huntarr, partagez cela avec votre communauté. Si vous connaissez quelqu’un qui en exécute un, partagez-le avec lui. Plus les gens sont au courant des risques, plus il y aura de pression sur le mainteneur pour les corriger et améliorer son processus de développement.

Édition : On dirait que r/huntarr est passé en privé et le dépôt a été supprimé ou mis en privé https://github.com/plexguide/Huntarr.io . Je suis désolé pour tous ceux qui ont donné à “la caisse de soutien universitaire de la fille de ce gars”.

Source : reddit.com

[BahBwah]

Rien compris, pour moi c’est du chinois (mais peut-être est ce le cas)…

[Aerya]

C’était une app vibe codée par l’IA. Perso j’y vois rien de mal, quand on sait à minima guider l’IA et comprendre le code, en grande partie (l’IA a tendance à mettre des API quand on ne le demande pas par exemple).

Là, Huntarr permettait de récupérer, via son API, tous les identifiants/clés configurés dedans. Bon, c’est pas terrible parce que ça veut dire que le gars regardait pas son code et on peut se dire que filer un user:pwd de Radarr ou Sonarr c’est pas la mort.
Sauf que la plupart des gens utilisant les mêmes identifiants partout, ça permettait de se faire des listes pour aller tester d’autres services. Un leak gratuit et à la portée de tout le monde en somme.
Un compte Plex leaké, c’est déjà plus pénible, les gens y mettant souvent un email:pwd plus “habituel” que pour Radarr/Sonarr.

Perso, ce qui me déplaît , c’est surtout sa manière de réagir. Tout le monde fait des conneries, il aurait pu simplement s’excuser, avertir tout le monde avec transparence et demander de la PR à la communauté.
Là il s’est cramé, tout simplement.