{"id":118226,"date":"2024-07-25T15:43:00","date_gmt":"2024-07-25T13:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki"},"modified":"2024-07-25T15:43:00","modified_gmt":"2024-07-25T13:43:02","slug":"dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","title":{"rendered":"Acceso a datos de repositorios remotos y privados en GitHub, que tienen forks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La empresa Truffle Security ha publicado guiones de ataque sobre varias t\u00e9cnicas comunes de trabajo con repositorios en GitHub, que permiten extraer datos de repositorios remotos que tienen forks p\u00fablicos o que se han creado como forks. <\/p>\n
La capacidad de acceso a los commits por hash en todos los forks relacionados de un repositorio se debe a que GitHub, con el fin de optimizar y eliminar duplicados, almacena juntos todos los objetos del repositorio principal y de los forks, separando l\u00f3gicamente la pertenencia de los commits. Este tipo de almacenamiento permite ver en el repositorio principal cualquier commit de cualquier fork, indicando expl\u00edcitamente su hash en la URL. Por ejemplo, un usuario puede crear un fork del repositorio '\/torvalds\/linux' y agregar cualquier c\u00f3digo, despu\u00e9s de lo cual este c\u00f3digo se volver\u00e1 accesible a trav\u00e9s de un enlace directo por hash en el repositorio '\/torvalds\/linux'. En caso de que se elimine el repositorio, si hay al menos un fork p\u00fablico, los datos del repositorio eliminado permanecen accesibles por el hash del commit. <\/p>\n
Se proponen tres escenarios que representan una amenaza a la seguridad: <\/p>\n
\n
El primer escenario se refiere a situaciones en las que los desarrolladores crean forks de repositorios p\u00fablicos, a\u00f1aden cambios, experimentan y luego eliminan. Adem\u00e1s de la filtraci\u00f3n de c\u00f3digo que no estaba destinado a publicarse, existe el peligro de que en las experimentaciones se a\u00f1adan claves de acceso API funcionales en los archivos de ejemplo. En este caso, un atacante podr\u00eda acceder al cambio mediante el hash del commit, que es accesible despu\u00e9s de eliminar el fork a trav\u00e9s 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\u00e1tico que ten\u00edan un gran n\u00famero de forks.\n
El segundo escenario se refiere a la posibilidad de acceder a los datos despu\u00e9s de la eliminaci\u00f3n del repositorio primario, si se han creado forks de ese repositorio. Como ejemplo, se menciona un caso en el que en un repositorio p\u00fablico 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\u00f3 el repositorio a trav\u00e9s del cual se produjo la filtraci\u00f3n, pero las claves segu\u00edan estando disponibles para su extracci\u00f3n a trav\u00e9s de las solicitudes basadas en el hash del commit en los repositorios con forks.
<\/center>\n
El tercer escenario est\u00e1 relacionado con el modelo de desarrollo de proyectos que desarrollan una versi\u00f3n abierta b\u00e1sica en un repositorio p\u00fablico y una versi\u00f3n propietaria ampliada en uno privado. Si una empresa inicialmente desarroll\u00f3 el proyecto en un repositorio privado y luego, despu\u00e9s de abrir el c\u00f3digo del proyecto, lo traslad\u00f3 a una categor\u00eda p\u00fablica, pero continu\u00f3 desarrollando una versi\u00f3n interna cerrada o ampliada en un fork privado, existe la posibilidad de acceder a los cambios a\u00f1adidos en el fork privado a trav\u00e9s de los hashes de los commits a trav\u00e9s del repositorio p\u00fablico. Sin embargo, el acceso solo es posible a los cambios a\u00f1adidos al fork privado antes de que el repositorio principal se categorice como p\u00fablico (los dep\u00f3sitos de repositorios privados y p\u00fablicos est\u00e1n separados, pero, cuando dos repositorios eran privados, los commits se almacenaron en conjunto, por lo que quedaron en el repositorio despu\u00e9s de su conversi\u00f3n a p\u00fablico).
<\/center> <\/ul>\n
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\u00f1os y se utiliza peri\u00f3dicamente para diversas bromas y para enga\u00f1ar a los desarrolladores (por ejemplo, los bromistas a veces crean la apariencia de la inserci\u00f3n de backdoors en el repositorio del n\u00facleo de Linux en GitHub de esta manera). Como medida para contrarrestar tales bromas, GitHub agreg\u00f3 una advertencia que indica que el commit solicitado no pertenece a las ramas en el repositorio actual y podr\u00eda 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. <\/p>\n
Determinar el hash del commit, que se genera a partir del algoritmo SHA-1 y que incluye 32 caracteres, no es realista, pero resulta que no es necesario. GitHub admite una forma abreviada de referirse a los commits, permitiendo dirigir cambios utilizando los primeros caracteres del hash, siempre que no haya coincidencias con otros commits. El n\u00famero m\u00ednimo de caracteres para la direcci\u00f3n abreviada del hash es 4, lo que corresponde a un total de 65 mil combinaciones (16^4). Adem\u00e1s, puede que no sea necesario realizar la b\u00fasqueda, ya que la API de GitHub permite conectar controladores para interceptar eventos, que son utilizados por proyectos externos que llevan un archivo con un registro completo de todas las operaciones, donde la informaci\u00f3n sobre los hashes de los commits permanece incluso despu\u00e9s de la eliminaci\u00f3n de los repositorios. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Acceso](\"\/wp-content\/uploads\/2024\/07\/45381deb03eaa5be40baf8b4dbf7b481.png\")
<\/center>\n![\"Acceso](\"\/wp-content\/uploads\/2024\/07\/23342cf907bd300699e913297d29b310.png\")
<\/center> <\/ul>\n