Access Data From Deleted Forks
Exposición de Datos en Repositorios Eliminados de GitHub
GitHub, una de las plataformas más utilizadas para el alojamiento de código fuente, permite el acceso a datos de repositorios eliminados y privados de forma indefinida. Esta característica, conocida por GitHub y diseñada intencionalmente de esta manera, representa un vector de ataque significativo para las organizaciones que utilizan la plataforma.
Vulnerabilidad de Referencia de Objetos entre Forks (CFOR)
Presentamos 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, incluyendo datos de forks privados y eliminados. Al igual que una referencia directa de objeto insegura (IDOR), en CFOR los usuarios suministran hashes de commits para acceder directamente a datos de commits que de otro modo no serían visibles para ellos.
Veamos algunos ejemplos.
Acceso a Datos de Forks Eliminados
Considere este flujo de trabajo común en GitHub:
1. Haces un fork de un repositorio público.
2. Realizas commits en tu fork.
3. Eliminas tu fork.
¿Esos commits siguen siendo accesibles? La respuesta es sí. Aunque elimines tu fork, los datos siguen siendo accesibles indefinidamente.
En un video, demostramos cómo, al hacer un fork de un repositorio, realizar commits, eliminar el fork y luego acceder a los datos del commit "eliminado" a través del repositorio original, los datos permanecen accesibles.
VIDEO: https://www.youtube.com/watch?v=eF-_mTvk7TQ
Acceso a Datos de Repositorios Eliminados
Otra situación es:
1. Tienes un repositorio público en GitHub.
2. Un usuario hace un fork de tu repositorio.
3. Haces commits después de que el usuario ha hecho el fork (y nunca sincronizan su fork con tus actualizaciones).
4. Eliminas el repositorio completo.
¿Son accesibles los commits realizados después del fork?
La respuesta, nuevamente, es sí. GitHub almacena repositorios y forks en una red de repositorios, con el repositorio "upstream" original como el nodo raíz. Cuando un repositorio público "upstream" que ha sido forked es "eliminado", GitHub reasigna el rol de nodo raíz a uno de los forks downstream. Sin embargo, todos los commits del repositorio "upstream" aún existen y son accesibles a través de cualquier fork.
Acceso a Datos de Repositorios Privados
Considere este flujo de trabajo para open-source:
1. Creas un repositorio privado que eventualmente será público.
2. Creas una versión privada interna de ese repositorio (a través de un fork) y haces commits adicionales con características que no vas a hacer públicas.
3. Haces público tu repositorio "upstream" y mantienes tu fork privado.
¿Los datos privados (del paso 2) son visibles para el público?
Sí. Cualquier commit realizado entre el momento en que creaste un fork interno y cuando hiciste público el repositorio, esos commits son accesibles en el repositorio público.
Cómo Acceder a los Datos
Las acciones destructivas en la red de repositorios de GitHub (como los escenarios mencionados) eliminan las referencias a datos de commits desde la UI estándar de GitHub y las operaciones normales de git. Sin embargo, estos datos aún existen y son accesibles si se conoce el hash del commit. Los hashes de commits son valores SHA-1.
Si un usuario conoce el hash SHA-1 de un commit particular que desea ver, puede navegar directamente a ese commit en la URL:
https://github.com/<usuario/org>/<repo>/commit/<commit_hash>.
Verán un banner amarillo explicando que "este commit no pertenece a ninguna rama de este repositorio, y puede pertenecer a un fork fuera del repositorio."
Políticas de GitHub
GitHub diseñó los repositorios para funcionar de esta manera.
Implicaciones
Las conclusiones son:
- Mientras exista un fork, cualquier commit en esa red de repositorios existirá para siempre.
- La única forma segura de remediar una clave filtrada en un repositorio público de GitHub es mediante la rotación de claves.
- La arquitectura de repositorios de GitHub requiere estos defectos de diseño y, lamentablemente, la mayoría de los usuarios de GitHub nunca entenderán cómo funciona realmente una red de repositorios y serán menos seguros debido a ello.
A medida que la escaneo de secretos evoluciona, es importante considerar que estos problemas también pueden existir en otros productos de sistemas de control de versiones.
Este artículo destaca la necesidad de una mayor diligencia y conciencia sobre cómo se manejan y protegen los datos en plataformas de desarrollo colaborativo como GitHub.
Fuente: https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
Comentarios