Cualquiera puede acceder en GitHub a datos de repositorios eliminados o privados

• En GitHub es posible acceder a datos de forks eliminados, repositorios eliminados e incluso repositorios privados
• GitHub conoce esto y así fue diseñado intencionalmente
  • Dado que representa un enorme vector de ataque para cualquier organización que use GitHub, se introduce un nuevo término: "Cross Fork Object Reference (CFOR)"
• Una vulnerabilidad CFOR ocurre cuando un fork de un repositorio puede acceder a datos sensibles de otro fork, incluidos datos de forks privados y eliminados

Cómo acceder a datos de forks eliminados

• Si pensamos en un flujo de trabajo común en GitHub, alguien puede hacer fork de un repositorio público, hacer commits en su fork y luego eliminarlo
• El código confirmado en ese fork sigue siendo accesible y lo será para siempre
• Podría pensarse que está protegido porque hay que conocer el hash del commit, pero ese hash puede descubrirse
• Encontrar datos en forks eliminados ocurre con bastante frecuencia

Cómo acceder a datos de repositorios eliminados

• Si consideramos un escenario donde hay un repositorio público en GitHub, un usuario hace fork, hace commits de datos después del fork y luego elimina todo el repositorio,
• el código confirmado después del fork sigue siendo accesible
• GitHub almacena los repositorios y sus forks en una red de repositorios, donde el repositorio "upstream" original actúa como nodo raíz
• Si el repositorio público "upstream" que fue forkeado se "elimina", GitHub reasigna el rol de nodo raíz a uno de los forks descendientes
• Sin embargo, todos los commits del repositorio "upstream" siguen existiendo y se puede acceder a ellos a través de cualquiera de los forks

Cómo acceder a datos de repositorios privados

• Si pensamos en un flujo de trabajo común para open sourcear una nueva herramienta en GitHub,
• puede ocurrir que se cree un repositorio privado que eventualmente será público, se haga una versión interna privada de ese repositorio (mediante un fork), se hagan commits con código adicional para funciones que no se publicarán, luego se haga público el repositorio "upstream" y se mantenga privado el fork
• Las funciones privadas y el código relacionado (del paso 2), dependiendo de si pueden verse públicamente, son accesibles desde el repositorio público
• Todo lo que se haya commiteado en el fork privado después de hacer público el repositorio "upstream" no puede verse

¿Cómo se accede realmente a los datos?

• Accediendo directamente al commit
• En la red de repositorios de GitHub, las acciones destructivas (como los 3 escenarios mencionados arriba) eliminan las referencias a los datos del commit en la UI estándar de GitHub y en las operaciones normales de git
• Pero esos datos siguen existiendo y pueden consultarse si se conoce el hash del commit
• El hash del commit es un valor SHA-1, y si un usuario conoce el hash SHA-1 del commit específico que quiere ver, puede ir directamente a ese commit en el endpoint https://github.com/<user/org>/…;
• El hash del commit puede obtenerse por fuerza bruta a través de la UI de GitHub
• También se puede consultar el hash del commit mediante el endpoint de la API de eventos públicos de GitHub

Política de GitHub

• Estos hallazgos se enviaron recientemente a través del programa VDP de GitHub, y GitHub dejó claro que los repositorios fueron diseñados para funcionar de esta manera
• Al revisar la documentación, se puede ver que GitHub sí documenta claramente qué deben esperar los usuarios en los casos descritos arriba

Impacto

• Mientras exista хотя бы un fork, todos los commits de esa red de repositorios (ya sean del repositorio "upstream" o de un fork "downstream") existirán para siempre
• La arquitectura de repositorios de GitHub requiere este defecto de diseño, y la gran mayoría de los usuarios de GitHub no entiende realmente cómo funciona la red de repositorios, por lo que estará menos protegida
• A medida que el secret scanning evolucione hasta poder escanear todos los commits de una red de repositorios, podrá alertar sobre secretos que ni siquiera son propios
• Estos 3 escenarios son impactantes, pero no cubren todas las formas en que GitHub puede conservar datos eliminados de un repositorio

Opinión de GN⁺

• Este artículo plantea un problema de seguridad importante para las organizaciones que usan GitHub. Que los datos de repositorios eliminados o privados sigan siendo accesibles es impactante. Parece ser un defecto fundamental de diseño derivado de la arquitectura de red de repositorios de GitHub
• Los desarrolladores deben ser conscientes de este problema y tener cuidado al commitear datos sensibles o secretos en GitHub. Una vez que se hace push a un repositorio público, puede quedar accesible para siempre. Si un secreto crítico se filtra, solo puede resolverse por completo mediante rotación de claves
• GitHub está siendo transparente al divulgar y documentar este problema, pero la mayoría de los usuarios probablemente no comprende del todo cómo funciona la red de repositorios. GitHub debería hacer un mayor esfuerzo para crear conciencia y educar a los usuarios sobre este tema
• Problemas similares pueden existir en otros sistemas de control de versiones. Los desarrolladores y las organizaciones deben entender bien la arquitectura y las limitaciones de las herramientas que usan al gestionar datos sensibles
• Para prevenir la filtración de datos importantes, se necesitan medidas de seguridad en múltiples frentes, como controles de acceso estrictos, aplicación del principio de mínimo privilegio y secret scanning y monitoreo regulares. Por encima de todo, es fundamental una alta conciencia de seguridad por parte de los desarrolladores

[GN⁺]

Comentarios en Hacker News

• Se reportó a HackerOne en 2018, pero GitHub no lo corrigió porque dijo que era el comportamiento esperado. Conclusión: mejor copiar el repositorio en vez de usar un fork privado
• GitHub está obsesionado con hacer todo público e inmutable. Por ejemplo, para borrar un comentario hay que enviar por correo electrónico una identificación real al propietario del repositorio
• Los usuarios no deberían necesitar saber de este tipo de problemas con la función de "privacidad", y que GitHub lo considere una característica en vez de un bug muestra desinterés por la seguridad. Sería más apropiado llamar a los repositorios privados repositorios "no listados"
• Si usas un repositorio privado y forks privados, y luego cambias el repositorio a público, los forks también se vuelven públicos. GitHub puede decir que es el comportamiento esperado, pero debería obligar a hacer público tanto el repositorio como el fork al mismo tiempo
• Este comportamiento parece un patrón oscuro, y aunque el sustento de la gente está en juego, a GitHub no le importa. Eso es porque la negación plausible deliberada y unos términos de uso ambiguos valen más que el daño reputacional
• Sorprende ver comentarios que minimizan este problema. He usado GitHub durante mucho tiempo, pero no habría anticipado este resultado y me hace sentir intranquilo. Recomiendo leer el artículo directamente
• Este problema no es nuevo. Mucha gente ya lo había descubierto antes
• El OSPO de GitHub está desarrollando una GitHub App de código abierto para mantener un espejo privado de forks públicos. Planean una versión beta esta semana
• La verdadera vulnerabilidad es la forma en que el archivo de GitHub Events expone los hashes SHA1 de repositorios vulnerables. Se puede escanear toda la red para acceder a repositorios privados eliminados
• El problema es cómo los datos privados pueden depender de datos públicos. Por ejemplo, si un commit privado depende del commit público C, cuando C se elimina del repositorio público, GitHub tiene que conservarlo. De lo contrario, el commit privado se rompe
• Todos los commits sobreviven para siempre después de enviarse a GitHub, y un commit que alguna vez fue público siempre puede consultarse mediante el hash del commit