Comment Hacktron assure la sécurité de Rocket.Chat 24 h/24, 7 j/7
- 1 à 2 minutes en moyenne
- pour vérifier la sécurité d’une PR
- 17 vraies vulnérabilités
- trouvées et triées au cours des 20 premiers jours
- 73 % des problèmes trouvés
- étaient actionnables et ont été traités
« Nous pouvons désormais étendre l’analyse de sécurité à toutes nos PR.
« Hacktron signale les problèmes potentiels, ce qui nous permet de concentrer nos efforts de revue sur les pull requests qui demandent plus d’attention. »
Julio Araujo
Directeur de la sécurité
À propos de Rocket.Chat
Rocket.Chat est une plateforme de communication open source et entièrement personnalisable, utilisée par des équipes gouvernementales, de défense et d’entreprise dans le monde entier. La sécurité est une priorité absolue pour un logiciel de cette envergure, et l’un des moments les moins coûteux pour détecter les vulnérabilités se situe tôt dans le cycle de vie du développement logiciel, grâce à une meilleure conception et à des revues de code continues avant la mise en production.
Le défi : un écart croissant entre la vitesse du code et la revue de sécurité
Pourtant, même avant l’IA, le ratio entre développeurs et ingénieurs sécurité rendait irréaliste l’examen minutieux de chaque PR à la recherche de vulnérabilités. Maintenant que l’IA accélère l’écriture et la livraison du code, vérifier la sécurité de chaque modification est devenu plus crucial que jamais.
« Nous n’avons tout simplement pas assez d’ingénieurs pour effectuer une revue approfondie de chaque PR. Les outils traditionnels de SAST, de SCA et de détection de secrets peuvent être très utiles, et nous les utilisons toujours, mais il leur manque souvent le contexte nécessaire pour identifier des problèmes complexes comme les vulnérabilités de logique métier.
« Ils ont aussi du mal à raisonner sur plusieurs étapes ou à enchaîner des vulnérabilités pour comprendre comment un système pourrait réellement être exploité. »
Julio Araujo
Directeur de la sécurité
Étendre la revue de sécurité à chaque PR avec Hacktron
Pour combler cet écart, Rocket.Chat utilise Hacktron Review pour une revue continue du code et de la sécurité, 24 h/24 et 7 j/7, ce qui aide à repérer des vulnérabilités coûteuses avant qu’elles n’atteignent la production.
Pour chaque PR, Hacktron :
- Effectue une revue de sécurité approfondie des modifications de code.
- Signale les vulnérabilités directement dans la PR avec des commentaires clairs.
- Permet aux développeurs de corriger les problèmes actionnables avant la fusion.
- Aide l’équipe sécurité à suivre et à regrouper les découvertes de moindre priorité pour une remédiation périodique.
- Maintient une revue de sécurité continue, au lieu de s’appuyer uniquement sur des audits périodiques ou des revues manuelles.
« Hacktron apprend de notre base de code et de nos retours au fil du temps.
« À mesure que nous fournissons plus de contexte sur les fonctionnalités prévues, les risques acceptés et les exigences de sécurité, les faux positifs se font plus rares, ce qui améliore la précision et réduit le temps passé à trier des non-problèmes. »
Julio Araujo
Directeur de la sécurité
Passons en revue l’analyse des revues de Hacktron sur Rocket.Chat : quels types de vulnérabilités il trouve, quelle est la précision de ces découvertes, et comment il aide l’équipe à livrer plus vite. Au cours des 20 premiers jours, il a vérifié 155 PR et fait remonter de vrais problèmes. Parmi eux, un bug d’autorisation critique qui aurait permis à n’importe quel utilisateur connecté de télécharger l’export complet des données d’un autre utilisateur, deux failles critiques dans Apple OAuth qui affaiblissaient la frontière de connexion sur l’ensemble des déploiements, et quelques vulnérabilités XSS.
Analyse des découvertes
Au cours des 20 premiers jours (du 5 au 25 juin 2026), Hacktron a vérifié chaque pull request dès son arrivée, en exécutant 490 analyses sur 10 744 fichiers modifiés. Voici la répartition des PR vérifiées, des problèmes trouvés, de leur tri et de la sévérité réelle des vrais positifs.
Chaque PR a été vérifiée automatiquement, et les revues elles-mêmes prenaient environ 1 à 2 minutes pour une PR typique (une médiane de 1,4 minute et 5,3 minutes au 95e centile), assez vite pour s’intégrer à la CI sans ralentir personne. Il faut toutefois noter que si une PR contient beaucoup de modifications, Hacktron prend le temps nécessaire pour être exhaustif dans ses tests.
Quels types de vulnérabilités trouve-t-il ?
La question importante est maintenant de savoir quels types de vulnérabilités il a détectés. Hacktron n’est pas un simple outil de recherche de motifs ; il lit le code et raisonne dessus comme un chercheur en sécurité. Les découvertes couvraient donc la majeure partie de l’OWASP Top 10 : contrôle d’accès défaillant, contournements de l’authentification/2FA, XSS, SSRF/open redirect, défaillances cryptographiques, exposition de secrets et failles de logique métier.
Entrons dans le détail des 3 principales vulnérabilités repérées par Hacktron.
Prise de contrôle de compte via Apple OAuth
C’est la première vulnérabilité que Hacktron a trouvée juste après que Rocket.Chat l’a intégré à ses workflows, et c’est un bug très élégant et critique.
Un détail important : Hacktron a trouvé un bug en dehors des modifications de la PR. La raison est que les revues de Hacktron ne se limitent pas strictement au diff de la PR ; il parcourt les dépendances et les effets dans toute la base de code pour trouver des vulnérabilités de second ordre.
Élevée
Prise de contrôle de compte via un e-mail non vérifié lors de la connexion Apple OAuth
apps/
Le gestionnaire de connexion Apple OAuth dans loginHandler.ts contient une vulnérabilité : il fait confiance à une adresse e-mail fournie par le client si le jeton d’identité Apple n’en contient pas. Comme le champ email fourni par le client dans la loginRequest n’est pas vérifié cryptographiquement, un attaquant peut fournir une adresse e-mail arbitraire (par exemple, celle d’une victime). Le hook accounts_meld.js utilise alors cet e-mail non vérifié pour rechercher un utilisateur existant et lier l’identifiant de service Apple de l’attaquant au compte de la victime. L’attaquant peut ainsi se connecter au compte de la victime avec son propre identifiant Apple, ce qui entraîne une prise de contrôle complète du compte.
Étapes pour reproduire
- L’attaquant lance une connexion Apple avec son propre identifiant Apple, en s’assurant que l’
identityTokenApple ne contient pas de claimemail(par exemple, en utilisant un identifiant Apple qui n’a pas partagé son e-mail, ou lors d’une connexion ultérieure où Apple omet l’e-mail). - L’attaquant intercepte la requête de connexion envoyée au serveur Rocket.Chat (par exemple, l’appel à la méthode DDP
login). - L’attaquant modifie le payload
loginRequestpour inclure l’adresse e-mail de la victime dans le champemail:{"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}. - Le serveur traite la requête. Dans
loginHandler.ts,serviceData.emailest vide, il affecte doncserviceData.email = email(l’e-mail de la victime). - Le hook
accounts_meld.jsrecherche l’utilisateur par l’e-mail de la victime, trouve le compte de la victime et y lie l’identifiant Apple de l’attaquant (Users.setServiceId(user._id, serviceName, serviceData.id)). - L’attaquant est désormais connecté au compte de la victime et peut y accéder à tout moment avec son identifiant Apple.
Dans apps/meteor/app/apple/server/loginHandler.ts, le flux Apple Sign-In se rabattait sur un e-mail fourni par le client lorsque le JWT Apple n’en contenait pas :
const serviceData = await handleIdentityToken(identityToken);if (!serviceData.email && email) { serviceData.email = email; // attacker-controlled fallback}Un attaquant pouvait forger un JWT Apple sans claim email et fournir un email arbitraire dans la requête,
ce qui lui permettait de s’authentifier en tant que n’importe quel utilisateur. Rocket.Chat a publié cette vulnérabilité dans un avis de sévérité critique
(GHSA-wx3c-76rf-wpwf, CVE-
La connexion Apple ignore la validation des claims du JWT
Le même gestionnaire contenait un autre bug : il vérifiait la signature du JWT mais ignorait la validation des claims.
Il utilisait JWS.verify (signature uniquement) au lieu de JWS.verifyJWT, et ne vérifiait jamais aud, exp ni nbf.
N’importe quel jeton signé par Apple avec un iss non vide était accepté, si bien qu’un jeton divulgué ou destiné à une autre audience pouvait être rejoué pour se connecter en tant que victime,
sans limite de durée pour ce rejeu. Rocket.Chat a publié cette vulnérabilité dans un avis de sévérité élevée
(GHSA-c75c-5hc7-j4vp, CVE-
Critique
Absence de validation de l’audience (aud) du JWT dans le gestionnaire de jetons d’identité Apple, menant à une prise de contrôle de compte
La fonction handlePassportIdentityToken dans apps/meteor/app/apple/lib/handlePassportIdentityToken.ts est chargée d’analyser et de valider les jetons d’identité Apple pendant le flux Sign in with Apple basé sur Passport.js (apps/meteor/app/apple/server/applePassportOAuth.ts). Si elle valide correctement la signature cryptographique du jeton, son émetteur (iss) et son expiration (exp), elle ne valide pas le claim d’audience (aud).
Dans les flux d’authentification fondés sur des JWT comme OpenID Connect, le claim aud indique le destinataire prévu du jeton (le Client ID). Sans vérifier que l’aud correspond au Client ID Apple configuré pour l’instance Rocket.Chat, l’application acceptera n’importe quel jeton d’identité Apple valide.
Un attaquant peut l’exploiter en créant sa propre application avec « Sign in with Apple » activé. Lorsqu’une victime se connecte à l’application de l’attaquant, celui-ci reçoit un jeton d’identité Apple valide pour cette victime. L’attaquant peut ensuite soumettre ce jeton à l’endpoint de callback Apple OAuth du serveur Rocket.Chat. Comme le jeton est réellement signé par Apple, possède un émetteur valide et n’a pas expiré, handlePassportIdentityToken renverra les données de la victime. La stratégie Passport en amont (AppleStrategy dans applePassportOAuth.ts) utilise ensuite ces données pour connecter l’attaquant en tant que victime, ce qui entraîne une prise de contrôle complète du compte.
Notez qu’une autre fonction, handleIdentityToken dans apps/meteor/app/apple/lib/handleIdentityToken.ts, implémente correctement la validation de l’audience, mais que handlePassportIdentityToken l’omet complètement.
N’importe quel utilisateur pouvait télécharger l’export de données d’un autre utilisateur
Dans le chemin de téléchargement des exports de données RGPD, la vérification d’accès était appelée sans l’objet fichier, si bien qu’elle échouait en mode ouvert et autorisait n’importe quel utilisateur connecté. Avec un ID de fichier d’export valide, un attaquant pouvait récupérer l’export complet des données d’un autre utilisateur : messages privés, profil et données des salons. Repéré dans la PR #40889 et corrigé avant la fusion.
Critique
Autorisation au niveau objet défaillante (BOLA) dans UserDataFiles, permettant à tout utilisateur authentifié de télécharger les exports de données RGPD
apps/
Une vulnérabilité de contournement d’autorisation existe dans le mécanisme de contrôle d’accès aux fichiers téléversés de Rocket.Chat. Lorsqu’un utilisateur demande à télécharger un fichier de la collection UserDataFiles (qui contient les exports de données RGPD des utilisateurs, très sensibles, y compris les messages privés, les messages directs et les données personnelles), le serveur ne vérifie pas si l’utilisateur à l’origine de la requête est le propriétaire de l’export de données.
Le résultat : une meilleure posture de sécurité, et moins de temps passé à trier des non-problèmes
Pour Rocket.Chat, l’impact principal est l’effet de levier. Hacktron donne à l’équipe sécurité un moyen d’appliquer une revue experte de manière cohérente dans tout le flux de développement, sans faire de la sécurité un frein à la vélocité de l’ingénierie.
Le résultat est une boucle de retour plus courte entre l’ingénierie et la sécurité : les vulnérabilités sont détectées plus tôt, les développeurs reçoivent des indications plus claires au moment de la modification, et l’équipe sécurité passe moins de temps à trier le bruit et plus de temps sur les problèmes qui comptent vraiment.