Basic Github Information
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
La estructura básica del entorno de github de una empresa grande es poseer una empresa que posee varias organizaciones y cada una de ellas puede contener varios repositorios y varios equipos. Las empresas más pequeñas pueden poseer solo una organización y ninguna empresa.
Desde el punto de vista de un usuario, un usuario puede ser miembro de diferentes empresas y organizaciones. Dentro de ellas, el usuario puede tener diferentes roles de empresa, organización y repositorio.
Además, un usuario puede ser parte de diferentes equipos con diferentes roles de empresa, organización o repositorio.
Y finalmente, los repositorios pueden tener mecanismos de protección especiales.
Propietario de la empresa: Las personas con este rol pueden gestionar administradores, gestionar organizaciones dentro de la empresa, gestionar configuraciones de la empresa, hacer cumplir políticas en las organizaciones. Sin embargo, no pueden acceder a la configuración o contenido de la organización a menos que se les haga propietario de la organización o se les dé acceso directo a un repositorio de la organización.
Miembros de la empresa: Los miembros de las organizaciones propiedad de tu empresa también son miembros automáticos de la empresa.
En una organización, los usuarios pueden tener diferentes roles:
Propietarios de la organización: Los propietarios de la organización tienen acceso administrativo completo a tu organización. Este rol debe ser limitado, pero no a menos de dos personas, en tu organización.
Miembros de la organización: El rol predeterminado, no administrativo para las personas en una organización es el miembro de la organización. Por defecto, los miembros de la organización tienen una serie de permisos.
Gerentes de facturación: Los gerentes de facturación son usuarios que pueden gestionar la configuración de facturación de tu organización, como la información de pago.
Gerentes de Seguridad: Es un rol que los propietarios de la organización pueden asignar a cualquier equipo en una organización. Cuando se aplica, otorga a cada miembro del equipo permisos para gestionar alertas de seguridad y configuraciones en toda tu organización, así como permisos de lectura para todos los repositorios en la organización.
Si tu organización tiene un equipo de seguridad, puedes usar el rol de gerente de seguridad para dar a los miembros del equipo el acceso mínimo que necesitan a la organización.
Gerentes de Aplicaciones de Github: Para permitir que usuarios adicionales gestiónen las Aplicaciones de GitHub propiedad de una organización, un propietario puede otorgarles permisos de gerente de Aplicaciones de GitHub.
Colaboradores externos: Un colaborador externo es una persona que tiene acceso a uno o más repositorios de la organización pero no es explícitamente un miembro de la organización.
Puedes comparar los permisos de estos roles en esta tabla: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
En https://github.com/organizations/<org_name>/settings/member_privileges puedes ver los permisos que los usuarios tendrán solo por ser parte de la organización.
La configuración aquí indicada indicará los siguientes permisos de los miembros de la organización:
Ser administrador, escritor, lector o sin permiso sobre todos los repositorios de la organización.
Si los miembros pueden crear repositorios privados, internos o públicos.
Si es posible bifurcar repositorios.
Si es posible invitar a colaboradores externos.
Si se pueden publicar sitios públicos o privados.
Los permisos que tienen los administradores sobre los repositorios.
Si los miembros pueden crear nuevos equipos.
Por defecto, se crean roles de repositorio:
Lectura: Recomendado para contribuidores no técnicos que desean ver o discutir tu proyecto.
Triage: Recomendado para contribuidores que necesitan gestionar proactivamente problemas y solicitudes de extracción sin acceso de escritura.
Escritura: Recomendado para contribuyentes que empujan activamente a tu proyecto.
Mantenimiento: Recomendado para gerentes de proyecto que necesitan gestionar el repositorio sin acceso a acciones sensibles o destructivas.
Administrador: Recomendado para personas que necesitan acceso completo al proyecto, incluidas acciones sensibles y destructivas como gestionar la seguridad o eliminar un repositorio.
Puedes comparar los permisos de cada rol en esta tabla https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
También puedes crear tus propios roles en https://github.com/organizations/<org_name>/settings/roles
Puedes listar los equipos creados en una organización en https://github.com/orgs/<org_name>/teams. Ten en cuenta que para ver los equipos que son hijos de otros equipos, necesitas acceder a cada equipo padre.
Los usuarios de una organización pueden ser listados en https://github.com/orgs/<org_name>/people.
En la información de cada usuario puedes ver los equipos de los que el usuario es miembro, y los repos a los que el usuario tiene acceso.
Github ofrece diferentes formas de autenticarte en tu cuenta y realizar acciones en tu nombre.
Accediendo a github.com puedes iniciar sesión usando tu nombre de usuario y contraseña (y un 2FA potencialmente).
Puedes configurar tu cuenta con una o varias claves públicas que permiten que la clave privada relacionada realice acciones en tu nombre. https://github.com/settings/keys
No puedes suplantar al usuario con estas claves, pero si no las usas, podría ser posible que se te descubra por enviar commits sin una firma. Aprende más sobre modo vigilante aquí.
Puedes generar un token de acceso personal para dar acceso a una aplicación a tu cuenta. Al crear un token de acceso personal, el usuario necesita especificar los permisos que tendrá el token. https://github.com/settings/tokens
Las aplicaciones Oauth pueden pedirte permisos para acceder a parte de tu información de github o para suplantarte para realizar algunas acciones. Un ejemplo común de esta funcionalidad es el botón de inicio de sesión con github que podrías encontrar en algunas plataformas.
Puedes crear tus propias aplicaciones Oauth en https://github.com/settings/developers
Puedes ver todas las aplicaciones Oauth que tienen acceso a tu cuenta en https://github.com/settings/applications
Puedes ver los alcances que las Apps Oauth pueden pedir en https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Puedes ver el acceso de terceros de aplicaciones en una organización en https://github.com/organizations/<org_name>/settings/oauth_application_policy
Algunas recomendaciones de seguridad:
Una Aplicación OAuth siempre debe actuar como el usuario autenticado de GitHub en toda la plataforma (por ejemplo, al proporcionar notificaciones al usuario) y con acceso solo a los alcances especificados.
Una Aplicación OAuth puede ser utilizada como un proveedor de identidad habilitando un "Inicio de sesión con GitHub" para el usuario autenticado.
No construyas una Aplicación OAuth si deseas que tu aplicación actúe sobre un solo repositorio. Con el alcance repo, las Aplicaciones OAuth pueden actuar sobre _todos_** los repositorios del usuario autenticado**.
No construyas una Aplicación OAuth para actuar como una aplicación para tu equipo o empresa. Las Aplicaciones OAuth se autentican como un solo usuario, por lo que si una persona crea una Aplicación OAuth para que la use una empresa, y luego deja la empresa, nadie más tendrá acceso a ella.
Más en aquí.
Las aplicaciones de Github pueden pedir permisos para acceder a tu información de github o suplantarte para realizar acciones específicas sobre recursos específicos. En las Aplicaciones de Github, necesitas especificar los repositorios a los que la aplicación tendrá acceso.
Para instalar una Aplicación de GitHub, debes ser un propietario de la organización o tener permisos de administrador en un repositorio.
La Aplicación de GitHub debe conectarse a una cuenta personal o a una organización.
Puedes crear tu propia aplicación de Github en https://github.com/settings/apps
Puedes ver todas las aplicaciones de Github que tienen acceso a tu cuenta en https://github.com/settings/apps/authorizations
Estos son los Puntos de Acceso API para Aplicaciones de Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Dependiendo de los permisos de la Aplicación, podrá acceder a algunos de ellos.
Puedes ver aplicaciones instaladas en una organización en https://github.com/organizations/<org_name>/settings/installations
Algunas recomendaciones de seguridad:
Una Aplicación de GitHub debe realizar acciones de forma independiente de un usuario (a menos que la aplicación esté utilizando un token de usuario a servidor). Para mantener los tokens de acceso de usuario a servidor más seguros, puedes usar tokens de acceso que expiren después de 8 horas, y un token de actualización que se puede intercambiar por un nuevo token de acceso. Para más información, consulta "Actualizando tokens de acceso de usuario a servidor."
Asegúrate de que la Aplicación de GitHub se integre con repositorios específicos.
La Aplicación de GitHub debe conectarse a una cuenta personal o a una organización.
No esperes que la Aplicación de GitHub sepa y haga todo lo que un usuario puede.
No uses una Aplicación de GitHub si solo necesitas un servicio de "Inicio de sesión con GitHub". Pero una Aplicación de GitHub puede usar un flujo de identificación de usuario para iniciar sesión a los usuarios y hacer otras cosas.
No construyas una Aplicación de GitHub si solo deseas actuar como un usuario de GitHub y hacer todo lo que ese usuario puede hacer.
Si estás usando tu aplicación con GitHub Actions y deseas modificar archivos de flujo de trabajo, debes autenticarte en nombre del usuario con un token OAuth que incluya el alcance workflow. El usuario debe tener permisos de administrador o escritura en el repositorio que contiene el archivo de flujo de trabajo. Para más información, consulta "Entendiendo los alcances para aplicaciones OAuth."
Más en aquí.
Esto no es una forma de autenticarte en github, pero una acción maliciosa de Github podría obtener acceso no autorizado a github y dependiendo de los privilegios otorgados a la Acción, se podrían realizar diferentes ataques. Consulta a continuación para más información.
Las acciones de Git permiten automatizar la ejecución de código cuando ocurre un evento. Generalmente, el código ejecutado está relacionado de alguna manera con el código del repositorio (quizás construir un contenedor docker o verificar que la PR no contenga secretos).
En https://github.com/organizations/<org_name>/settings/actions es posible verificar la configuración de las acciones de github para la organización.
Es posible deshabilitar el uso de acciones de github por completo, permitir todas las acciones de github, o solo permitir ciertas acciones.
También es posible configurar quién necesita aprobación para ejecutar una Acción de Github y los permisos del GITHUB_TOKEN de una Acción de Github cuando se ejecuta.
Las Acciones de Github generalmente necesitan algún tipo de secretos para interactuar con github o aplicaciones de terceros. Para evitar ponerlos en texto claro en el repositorio, github permite ponerlos como Secretos.
Estos secretos pueden configurarse para el repositorio o para toda la organización. Luego, para que la Acción pueda acceder al secreto, necesitas declararlo así:
Los secretos solo pueden ser accedidos desde las Github Actions que los tienen declarados.
Una vez configurados en el repositorio o en las organizaciones, los usuarios de github no podrán acceder a ellos nuevamente, solo podrán cambiarlos.
Por lo tanto, la única forma de robar secretos de github es poder acceder a la máquina que está ejecutando la Github Action (en ese escenario solo podrás acceder a los secretos declarados para la Action).
Github permite crear entornos donde puedes guardar secretos. Luego, puedes dar acceso a la acción de github a los secretos dentro del entorno con algo como:
Puedes configurar un entorno para ser accedido por todas las ramas (por defecto), solo ramas protegidas o especificar qué ramas pueden acceder a él. También se puede establecer un número de revisiones requeridas antes de ejecutar una acción utilizando un entorno o esperar algún tiempo antes de permitir que las implementaciones continúen.
Una acción de Github puede ser ejecutada dentro del entorno de github o puede ser ejecutada en una infraestructura de terceros configurada por el usuario.
Varias organizaciones permitirán ejecutar acciones de Github en una infraestructura de terceros ya que suele ser más barato.
Puedes listar los runners autoalojados de una organización en https://github.com/organizations/<org_name>/settings/actions/runners
La forma de encontrar qué acciones de Github se están ejecutando en infraestructura no github es buscar runs-on: self-hosted en la configuración yaml de la acción de Github.
No es posible ejecutar una acción de Github de una organización dentro de una caja autoalojada de una organización diferente porque se genera un token único para el Runner al configurarlo para saber a qué runner pertenece.
Si el Github Runner personalizado está configurado en una máquina dentro de AWS o GCP, por ejemplo, la acción podría tener acceso al endpoint de metadatos y robar el token de la cuenta de servicio con la que se está ejecutando la máquina.
Si se permiten todas las acciones (o una acción maliciosa), un usuario podría usar una acción de Github que sea maliciosa y comprometer el contenedor donde se está ejecutando.
Una acción maliciosa de Github podría ser abusada por el atacante para:
Robar todos los secretos a los que la acción tiene acceso
Moverse lateralmente si la acción se ejecuta dentro de una infraestructura de terceros donde se puede acceder al token de SA utilizado para ejecutar la máquina (probablemente a través del servicio de metadatos)
Abusar del token utilizado por el workflow para robar el código del repo donde se ejecuta la acción o incluso modificarlo.
Las protecciones de ramas están diseñadas para no dar control completo de un repositorio a los usuarios. El objetivo es implementar varios métodos de protección antes de poder escribir código dentro de alguna rama.
Las protecciones de ramas de un repositorio se pueden encontrar en https://github.com/<orgname>/<reponame>/settings/branches
No es posible establecer una protección de rama a nivel de organización. Por lo tanto, todas deben ser declaradas en cada repo.
Se pueden aplicar diferentes protecciones a una rama (como a master):
Puedes requerir un PR antes de fusionar (por lo que no puedes fusionar código directamente sobre la rama). Si esto se selecciona, se pueden implementar otras protecciones:
Requerir un número de aprobaciones. Es muy común requerir que 1 o 2 personas más aprueben tu PR para que un solo usuario no pueda fusionar código directamente.
Desestimar aprobaciones cuando se envían nuevos commits. De lo contrario, un usuario puede aprobar código legítimo y luego el usuario podría agregar código malicioso y fusionarlo.
Requerir revisiones de los Propietarios de Código. Al menos 1 propietario de código del repo necesita aprobar el PR (por lo que los usuarios "aleatorios" no pueden aprobarlo)
Restringir quién puede desestimar revisiones de solicitudes de extracción. Puedes especificar personas o equipos autorizados para desestimar revisiones de solicitudes de extracción.
Permitir que actores especificados eviten los requisitos de solicitudes de extracción. Estos usuarios podrán eludir restricciones anteriores.
Requerir que las verificaciones de estado pasen antes de fusionar. Algunas verificaciones deben pasar antes de poder fusionar el commit (como una acción de github que verifica que no haya ningún secreto en texto claro).
Requerir resolución de conversaciones antes de fusionar. Todos los comentarios sobre el código deben ser resueltos antes de que el PR pueda ser fusionado.
Requerir commits firmados. Los commits deben estar firmados.
Requerir un historial lineal. Evitar que se envíen commits de fusión a ramas coincidentes.
Incluir administradores. Si esto no se establece, los administradores pueden eludir las restricciones.
Restringir quién puede enviar a ramas coincidentes. Restringir quién puede enviar un PR.
Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, los repos pueden estar protegidos evitando que envíes código a master por ejemplo para comprometer el pipeline de CI/CD.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
