Planète Warez

undefined

@Flyfree Bonsoir, je remets ça sur pied ce week-end et je laisse un petit message dès que c’est OK !

PS : J’ai été très pris à cause de soucis perso et de beaucoup de travail ces derniers temps…

undefined

@Pluton9 sérieusement!

undefined

@Raccoon a dit dans 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 :

j’ai été banni

Avoue que ça a quand même une autre gueule que d’être banni d’ygg.

undefined

@Psyckofox a dit dans Trump Make America Great Again, again :

si c’est vraiment avéré, il s’en tirera sans aucun problème

J’en mettrais pas ma main à couper!

undefined

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.

undefined

Merci, je connais plutôt bien le principe de Usenet.
Bonne continuation, si possible, pensez à Postie par exemple (Windaube/Linux/macOS) pour poster.

undefined

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

undefined

Idem, je préfère Batocera, plus optimisé, démarre automatiquement les jeux en français.

undefined

Salut @im-hana, bienvenue sur le forum!

undefined

Auditionné devant un jury à Los Angeles dans l’affaire qui oppose, entre autres, Meta à une jeune femme reprochant la mise en place de mécanismes d’addiction sur les plateformes de réseaux sociaux, Mark Zuckerberg a du expliquer pourquoi, comme l’indiquait un document de 2018, son entreprise estimait qu’il y avait 4 millions d’utilisateurs d’Instagram de 10 à 12 ans. Il a défendu la mise à disposition de « filtres de beauté » sur Instagram comme une liberté d’expression des utilisateurs.

Une jeune femme de 20 ans, Kaley G. M., et sa mère accusent les géants des réseaux sociaux, et notamment Google (via YouTube) et Meta (via Facebook et surtout Instagram), de provoquer et d’entretenir l’addiction chez les jeunes.

Après Adam Mosseri, patron d’Instagram, c’était ce mercredi 18 février à Mark Zuckerberg de s’y rendre. Le patron de Meta est arrivé au tribunal encadré par plusieurs personnes portant des lunettes connectées de l’entreprise.

Comme l’explique le Los Angeles Times, la juge Carolyn B. Kuhl a estimé nécessaire de prendre un moment pour avertir la salle que l’usage de ces lunettes était interdit : « Si vos lunettes enregistrent, vous devez les retirer. La cour ordonne qu’il ne doit y avoir aucune reconnaissance faciale du jury. Si vous l’avez fait, vous devez supprimer l’enregistrement. C’est très sérieux. »

Un filtre des enfants peu efficace

Les débats se sont notamment concentrés sur la politique de Meta concernant la création de comptes de jeunes enfants. Comme le Los Angeles Times l’explique, Mark Zuckerberg a rappelé qu’Instagram n’a jamais autorisé, dans ses conditions d’utilisation, les enfants de moins de 13 ans à s’inscrire.

Mais la plaignante, Kaley G. M., affirme dans sa plainte avoir créé son compte à l’âge de 9 ans. « Je pense généralement qu’il existe un groupe de personnes, potentiellement assez important, qui mentent sur leur âge afin d’utiliser nos services », a affirmé Mark Zuckerberg, évoquant également « une autre question séparée et très importante concerne la mise en application, et celle-ci est très difficile ».

Le patron de Meta en a profité pour réaffirmer que, selon lui, c’était aux responsables des systèmes d’exploitation comme Apple et Google que devrait revenir la charge de contrôler l’âge des utilisateurs.

Cibler les préados pour attirer les ados

[…]

Source : next.ink

Planète Warez

GNU-Linux User

Messages

Le processus

Un filtre des enfants peu efficace

Cibler les préados pour attirer les ados

Liste des membres

Planète Warez

Light

Dim

Dark

GNU-Linux User

Messages

Le processus

Un filtre des enfants peu efficace

Cibler les préados pour attirer les ados

Liste des membres