ghrc.io parece ser un sitio malicioso

• La simple confusión por un error tipográfico entre ghcr.io y ghrc.io provoca una grave amenaza de seguridad
• ghrc.io a primera vista parece un servidor nginx básico, pero internamente se detectó que imita la API de OCI
• Este sitio usa el encabezado www-authenticate para inducir a clientes de contenedores a enviar credenciales sensibles
• Si se ingresan credenciales por error con docker login o se usa un registro equivocado, puede ocurrir una filtración de credenciales
• Si iniciaste sesión en el servidor equivocado, es necesario cambiar la contraseña, revocar el PAT y revisar actividad anómala en la cuenta de GitHub

---

Resumen general

La confusión frecuente entre ghcr.io y ghrc.io por un simple error tipográfico puede causar un problema de seguridad muy peligroso. Se detectó un intento de robo de credenciales en ghrc.io, una versión con typo de GitHub Container Registry (ghcr.io), usado por muchos desarrolladores y equipos.

Qué es ghcr.io

• ghcr.io es un registro compatible con OCI para imágenes de contenedor y artefactos OCI
• Forma parte de GitHub y se usa como un registro popular en muchísimos proyectos de código abierto

ghrc.io: lo que se ve en la superficie

• Al entrar a ghrc.io se muestra una simple pantalla predeterminada de nginx
• Su comportamiento básico, como el típico error 404, es igual al de un servidor nginx común

La naturaleza de la actividad maliciosa

• El problema central aparece al hacer llamadas a la API de OCI bajo el prefijo /v2/
• Al acceder por esa ruta, responde con un encabezado www-authenticate y un 401, con un comportamiento muy similar al de un registro oficial de contenedores
• Está presente el encabezado www-authenticate: Bearer realm="https://ghrc.io/token";
• Por este encabezado, clientes como Docker, containerd, podman y Kubernetes intentan enviar automáticamente las credenciales del usuario a https://ghrc.io/token
• Como la configuración predeterminada de nginx no incluye ese encabezado, queda claro que fue configurado intencionalmente

El riesgo: escenario de robo de credenciales

• Este patrón parece ser un ataque de robo de credenciales basado en typo-squatting
• El riesgo existe solo si el cliente del usuario ingresó o guardó credenciales para ghrc.io
• Ejemplos de situaciones en las que credenciales reales pueden quedar expuestas
  • Ejecutar docker login ghrc.io
  • Usar docker/login-action dentro de GitHub Action y especificar ghrc.io como registro
  • Guardar credenciales de registro para ghrc.io en un secreto de Kubernetes e intentar hacer pull de imágenes
• Si simplemente se intenta hacer push/pull de imágenes a ghrc.io, la información de autenticación no se expone (intenta un token anónimo y luego devuelve error)

Medidas de respuesta

• Si alguna vez iniciaste sesión por error en ghrc.io, debes cambiar de inmediato la contraseña y revocar el PAT (token de acceso personal) usado
• También debes revisar sin falta si hay inicios de sesión anómalos o actividad maliciosa en tu cuenta de GitHub
• Un atacante podría aprovechar esto para agregar imágenes maliciosas a repositorios de ghcr.io o conseguir acceso a la cuenta

Conclusión

• Hay que tener cuidado con sitios de phishing que usan direcciones similares a ghcr.io
• Se requiere una política aún más estricta para gestionar credenciales, tokens, contraseñas y otra información de seguridad

[ndrgrd]

¿No sería mejor simplemente cambiarlo a un subdominio de github.com?

[GN⁺]

Comentarios de Hacker News

• Se enfatiza la gravedad de que GitHub Container registry solo soporte tokens clásicos existentes en lugar de tokens granulares.
  También se adjuntan enlaces a la documentación y a issues relacionados.
  Documentación oficial
  Discusión en la comunidad
  Issue del roadmap

  • Debido a este problema, no es posible desactivar por completo los PAT clásicos.
    Como medida complementaria, se puede usar una vigencia de sesión corta y forzar la reautenticación con Enterprise SSO, pero para el único PAT clásico que realmente se necesita, es una opción engorrosa.

  • Estaría bien que alguien comprara todos los dominios con errores tipográficos de buena fe y se los entregara a Microsoft.
    Cree que Microsoft debería cambiar el nombre del registry.
    El nombre es tan confuso que incluso él mismo se ha equivocado al escribirlo muchas veces.

• Dice que solo después de leer varias veces el tema del dominio pudo entender el problema, lo que lo convierte en un vector de ataque bastante convincente.

  • No solo le pasó a él, sino también a varias personas más.
    Intentaron varias veces, fallaron y hasta reiniciaron la computadora, pero el mismo problema seguía ocurriendo.
    Como casos de referencia, también están esta respuesta en Stack Overflow y esta discusión en el foro de Docker.

• Presenta como enlace los resultados de búsqueda de código relacionados con ghrc.io.

• No se dio cuenta del problema hasta que en el artículo señalaron directamente que la c y la r estaban invertidas.

  • Dice que es el tipo de error tipográfico que comete casi más de 10 veces al día.

  • El problema aquí es que el nombre de dominio de GitHub es un desastre.
    El nombre del container registry realmente es muy malo.

• Comparte un enlace a una discusión anterior de Hacker News.

• Menciona que se puede confirmar con whois que este dominio fue registrado en dynadot.
  Por eso, considera que vale la pena reportarlo a [e-mail].

• Señala que muchos proyectos open source están usando este dominio y vuelve a compartir los resultados de búsqueda de código.

  • GitHub necesita internamente una herramienta que pueda sugerir y desplegar correcciones automáticas en masa.

  • Menciona que los resultados de búsqueda de código en GitHub realmente son de una escala considerable.

• Expresa preocupación por que un error tipográfico en un trabajo de CI podría causar un problema serio.

• Aconseja evitar, en la medida de lo posible, el uso de TLD (dominios de nivel superior) con poco valor de seguridad.
  La seguridad debe ir antes que intentar verse simpático.
  Como la baja de dominios maliciosos podría no ser tan rápida como en .com, considera que .com, administrado por la estadounidense Verisign, inspira más confianza.
  Depender del Territorio Británico del Océano Índico, Colombia o Anguila le parece inapropiado.

  • Añade que el TLD .io es administrado por la empresa estadounidense Afilias.

• Pregunta si el verdadero riesgo aquí es en realidad el problema de reutilización de tokens.
  Un token Bearer no entrega la contraseña directamente, y citando documentos de RFC y Mozilla, se pregunta si el problema real no será el proceso de volver a obtener un token para autenticación, más que el token de autenticación en sí.
  Si OAuth entre dominios no reutiliza tokens, entonces se pregunta si al final un dominio falso no sería incapaz de obtener el token.

  • Responde el autor del blog y mantenedor de OCI.
    En la solicitud para obtener un token Bearer, la contraseña o el PAT se envían codificados en base64 dentro del encabezado de autenticación básica, pero en la práctica se transmiten como texto plano.
    Cuando se recibe la solicitud, se genera el encabezado www-authenticate, se obtiene un token de autenticación para validar el acceso al registry y luego ese token expira,
    pero la estructura del flujo no hace que el atacante robe el token real, sino que logre solicitar las credenciales mismas necesarias para obtener el token Bearer.