La empresa Truffle Security ha publicado guiones de ataque sobre varias técnicas comunes de trabajo con repositorios en GitHub, que permiten extraer datos de repositorios remotos que tienen forks públicos o que se han creado como forks.
La posibilidad de acceder a los commits por hash en todos los forks relacionados del repositorio se debe a que GitHub, con el fin de optimizar y evitar duplicados, almacena todos los objetos del repositorio principal y de los forks juntos, separando lógicamente la pertenencia de los commits. Este tipo de almacenamiento permite visualizar en el repositorio principal cualquier commit de cualquier fork, especificando su hash en la URL. Por ejemplo, un usuario puede crear un fork del repositorio '/torvalds/linux' y añadir cualquier código, tras lo cual ese código será accesible a través de un enlace directo al hash en el repositorio '/torvalds/linux'. En caso de que se elimine el repositorio, si existe al menos un fork público, los datos del repositorio eliminado permanecen disponibles a través del hash del commit.
Se proponen tres escenarios que representan una amenaza a la seguridad:
- El primer escenario se refiere a situaciones en las que los desarrolladores crean forks de repositorios públicos, añaden cambios, experimentan y luego eliminan. Además de la filtración de código que no estaba destinado a publicarse, existe el peligro de que en las experimentaciones se añadan claves de acceso API funcionales en los archivos de ejemplo. En este caso, un atacante podría acceder al cambio mediante el hash del commit, que es accesible después de eliminar el fork a través del repositorio principal. Por ejemplo, de esta manera, los investigadores pudieron identificar 30 claves de acceso API funcionales, estudiando tres repositorios relacionados con el aprendizaje automático que tenían un gran número de forks.
- El segundo escenario se refiere a la posibilidad de acceder a los datos después de la eliminación del repositorio primario, si se han creado forks de ese repositorio. Como ejemplo, se menciona un caso en el que en un repositorio público de una empresa se publicaron accidentalmente las claves privadas de uno de sus empleados, que permiten obtener acceso completo a todos los repositorios de esa empresa en GitHub. La empresa eliminó el repositorio a través del cual se produjo la filtración, pero las claves seguían estando disponibles para su extracción a través de las solicitudes basadas en el hash del commit en los repositorios con forks.
- El tercer escenario está relacionado con el modelo de desarrollo de proyectos que desarrollan una versión abierta básica en un repositorio público y una versión propietaria ampliada en uno privado. Si una empresa inicialmente desarrolló el proyecto en un repositorio privado y luego, después de abrir el código del proyecto, lo trasladó a una categoría pública, pero continuó desarrollando una versión interna cerrada o ampliada en un fork privado, existe la posibilidad de acceder a los cambios añadidos en el fork privado a través de los hashes de los commits a través del repositorio público. Sin embargo, el acceso solo es posible a los cambios añadidos al fork privado antes de que el repositorio principal se categorice como público (los depósitos de repositorios privados y públicos están separados, pero, cuando dos repositorios eran privados, los commits se almacenaron en conjunto, por lo que quedaron en el repositorio después de su conversión a público).
El truco que permite acceder a los commits en los forks de un repositorio mediante un enlace al repositorio principal ha sido conocido durante muchos años y se utiliza periódicamente para diversas bromas y para engañar a los desarrolladores (por ejemplo, los bromistas a veces crean la apariencia de la inserción de backdoors en el repositorio del núcleo de Linux en GitHub de esta manera). Como medida para contrarrestar tales bromas, GitHub agregó una advertencia que indica que el commit solicitado no pertenece a las ramas en el repositorio actual y podría pertenecer a un fork. Sin embargo, la posibilidad de acceso a los commits por hash en cualquier fork relacionado con los repositorios se consideraba inofensiva, ya que para acceder a los datos en forks remotos y privados se requiere conocimiento del hash del commit.
No es posible encontrar un hash de commit, generado a partir del algoritmo SHA-1 y que incluya 32 caracteres, pero resulta que no es necesario. GitHub soporta una forma abreviada de referencia a los commits, permitiendo dirigir cambios a los primeros caracteres del hash, siempre que no haya colisiones con otros commits. El número mínimo de caracteres para la referencia abreviada del hash es 4, lo que corresponde a 65 mil combinaciones posibles (16^4). Además, puede que no sea necesario realizar un intento, ya que la API de GitHub permite conectar manejadores para interceptar eventos utilizados por proyectos externos que mantienen un archivo completo de todas las operaciones, donde la información sobre los hashes de los commits permanece incluso después de eliminar repositorios.
Fuente: opennet.ru
