ghrc.io semble être un site malveillant

• Une simple confusion typographique entre ghcr.io et ghrc.io crée une grave menace de sécurité
• ghrc.io ressemble au premier abord à un serveur nginx par défaut, mais il a été observé qu’il imite en interne l’API OCI
• Ce site incite les clients de conteneurs à envoyer des informations d’authentification sensibles via l’en-tête www-authenticate
• En cas de saisie accidentelle d’identifiants, par exemple avec docker login, ou d’utilisation d’un mauvais registre, une fuite d’identifiants peut se produire
• Si vous vous êtes connecté au mauvais serveur, il faut changer le mot de passe, révoquer le PAT et vérifier toute activité anormale sur le compte GitHub

---

Aperçu

Une simple faute de frappe, fréquente entre ghcr.io et ghrc.io, illustre un cas entraînant un problème de sécurité très dangereux. Une tentative de vol d’identifiants a été détectée sur ghrc.io, une version fautive de GitHub Container Registry (ghcr.io) utilisée par de nombreux développeurs et équipes.

Qu’est-ce que ghcr.io ?

• ghcr.io est un registre compatible OCI pour les images de conteneurs et les artefacts OCI
• Faisant partie de GitHub, il est utilisé comme registre populaire par de très nombreux projets open source

ghrc.io : ce qu’on voit en surface

• En accédant à ghrc.io, on voit simplement l’écran par défaut de nginx
• Les comportements de base, comme les erreurs 404 classiques, sont identiques à ceux d’un serveur nginx ordinaire

La nature du comportement malveillant

• Le problème central apparaît lors des appels à l’API OCI sous le préfixe /v2/
• Lorsqu’on accède à ce chemin, le site renvoie une réponse 401 avec un en-tête www-authenticate, reproduisant un comportement très proche d’un registre de conteneurs officiel
• L’en-tête www-authenticate: Bearer realm="https://ghrc.io/token"; est présent
• À cause de cet en-tête, des clients comme Docker, containerd, podman, Kubernetes, etc. tentent automatiquement d’envoyer les informations d’authentification de l’utilisateur vers https://ghrc.io/token
• La configuration par défaut de nginx ne comporte pas cet en-tête, il s’agit donc d’un paramétrage manifestement intentionnel

Risque : scénario de vol d’identifiants

• Ce schéma est considéré comme une attaque de vol d’identifiants par typo-squatting
• Le risque n’existe que si le client de l’utilisateur a saisi ou enregistré des identifiants pour ghrc.io
• Exemples de situations où de vrais identifiants peuvent être exposés
  • Exécuter docker login ghrc.io
  • Dans une GitHub Action, utiliser docker/login-action en définissant le registre sur ghrc.io
  • Enregistrer des identifiants de registre pour ghrc.io dans un secret Kubernetes puis tenter un image pull
• Tenter simplement de push/pull une image vers ghrc.io n’expose pas les informations d’authentification (une tentative de jeton anonyme est faite puis une erreur est renvoyée)

Mesures à prendre

• Si vous vous êtes connecté par erreur à ghrc.io, vous devez immédiatement changer votre mot de passe et révoquer le PAT (personal access token) utilisé
• Il faut impérativement vérifier sur le compte GitHub toute connexion inhabituelle ou activité malveillante
• Un attaquant pourrait s’en servir pour ajouter des images malveillantes dans des dépôts ghcr.io ou obtenir l’accès au compte

Conclusion

• Il faut se méfier des sites de phishing utilisant des adresses proches de ghcr.io
• Une politique encore plus rigoureuse est nécessaire pour la gestion des informations de sécurité comme les identifiants, les jetons et les mots de passe

[ndrgrd]

Il ne vaudrait pas mieux le remplacer simplement par un sous-domaine de github.com ?

[GN⁺]

Avis Hacker News

• Souligne le caractère grave du fait que GitHub Container registry ne prend en charge que les anciens tokens classiques, et non des tokens à granularité fine
  Ajoute aussi des liens vers la documentation et un ticket associé
  Documentation officielle
  Discussion communautaire
  Issue de la roadmap

  • À cause de ce problème, il est impossible de désactiver complètement les PAT classiques
    Comme mesure compensatoire supplémentaire, on peut raccourcir la durée de validité des sessions et imposer une réauthentification via l’SSO d’entreprise, mais c’est une option lourde pour le seul PAT classique réellement nécessaire

  • Ce serait bien que quelqu’un rachète tous les domaines typo par bienveillance puis les transfère à Microsoft
    Estime que Microsoft devrait renommer le registre
    Le nom prête tellement à confusion que lui aussi s’est souvent trompé en le tapant

• Il a fallu relire plusieurs fois le problème de domaine avant de comprendre l’attaque, ce qui en fait un vecteur d’attaque assez convaincant

  • Il n’est pas le seul, plusieurs personnes ont eu la même expérience
    Après plusieurs essais infructueux, et même après avoir redémarré leur ordinateur, le même problème persistait
    Donne aussi comme références une réponse Stack Overflow et une discussion sur le forum Docker

• Partage un lien vers les résultats de recherche de code liés à ghrc.io

• N’avait pas remarqué le problème avant que l’article ne signale explicitement l’inversion du c et du r

  • C’est exactement le genre de faute de frappe qu’il fait facilement plus de dix fois par jour

  • Le vrai problème ici, c’est que le nom de domaine de GitHub est mal fichu
    Le nom du registre de conteneurs est vraiment mauvais

• Partage un ancien lien de discussion Hacker News

• Vérifie via whois que ce domaine a été enregistré chez dynadot
  Il semble donc utile de le signaler à [e-mail]

• Mentionne que de nombreux projets open source utilisent ce domaine et repartage une nouvelle fois les résultats de recherche de code

  • GitHub aurait besoin en interne d’un outil capable de proposer et de déployer automatiquement des corrections à grande échelle

  • Souligne que les résultats de recherche de code GitHub représentent effectivement un volume important

• Exprime l’inquiétude qu’une faute de frappe dans un job CI puisse provoquer de gros problèmes

• Conseille d’éviter autant que possible les TLD dont la valeur en matière de sécurité est plus faible
  La sécurité doit passer avant toute tentative de paraître plus « mignon »
  La désactivation d’un domaine malveillant peut ne pas être aussi rapide que pour un .com, et il juge donc le .com, géré par l’américain Verisign, plus rassurant
  Dépendre du Territoire britannique de l’océan Indien, de la Colombie ou d’Anguilla lui semble inapproprié

  • Ajoute que le TLD .io est géré par l’entreprise américaine Afilias

• Demande si le vrai risque ici est bien la réutilisation de tokens
  Un token Bearer ne donne pas directement le mot de passe, et en citant la RFC et la documentation de Mozilla, il se demande si le vrai problème n’est pas plutôt la procédure permettant d’obtenir de nouveau un token pour l’authentification, plutôt que le token d’authentification lui-même
  Si l’OAuth inter-domaines ne réutilise pas les tokens, alors un faux domaine ne devrait-il pas simplement être incapable d’en obtenir un ?

  • Réponse de l’auteur du blog, qui est aussi mainteneur OCI
    Lors de la requête visant à obtenir un token Bearer, le mot de passe ou le PAT est envoyé encodé en base64 dans l’en-tête d’authentification Basic, donc en pratique transmis en clair
    Une fois la requête reçue, un en-tête www-authenticate est émis, un token d’authentification est obtenu pour valider l’accès au registre, puis ce token expire
    L’attaquant ne cherche donc pas à voler le token lui-même, mais à pousser la victime à envoyer les identifiants servant à obtenir le token Bearer