Información básica de Github

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Estructura básica

La estructura básica del entorno de github de una gran company es poseer una enterprise que a su vez posee varias organizations y cada una de ellas puede contener varios repositories y varios teams.. Las empresas más pequeñas pueden simplemente poseer una organization y no enterprises.

Desde el punto de vista de un usuario, un user puede ser member de diferentes enterprises y organizations. Dentro de ellas el usuario puede tener diferentes enterprise, organization y repository roles.

Además, un usuario puede ser parte de diferentes teams con distintos enterprise, organization o repository roles.

Y finalmente los repositories pueden tener mecanismos especiales de protección.

Privilegios

Enterprise Roles

  • Enterprise owner: Las personas con este rol pueden gestionar administradores, gestionar organizations dentro de la enterprise, gestionar la configuración de la enterprise y aplicar políticas a través de las organizations. Sin embargo, no pueden acceder a la configuración o al contenido de una organization a menos que se les haga organization owner o se les otorgue acceso directo a un repository propiedad de la organization.
  • Enterprise members: Los miembros de las organizations que pertenecen a tu enterprise también son automáticamente members de la enterprise.

Organization Roles

En una organization los usuarios pueden tener diferentes roles:

  • Organization owners: Los organization owners tienen acceso administrativo completo a tu organization. Este rol debe limitarse, pero no a menos de dos personas, en tu organization.
  • Organization members: El rol por defecto, no administrativo para las personas en una organization es organization member. Por defecto, los organization members tienen una serie de permisos.
  • Billing managers: Los billing managers son usuarios que pueden gestionar la configuración de facturación de tu organization, como la información de pago.
  • Security Managers: Es un rol que los organization owners pueden asignar a cualquier team en una organization. Cuando se aplica, otorga a cada miembro del team permisos para gestionar alertas y configuraciones de seguridad en toda tu organization, así como permisos de lectura para todos los repositories en la organization.
  • Si tu organization tiene un security team, puedes usar el rol de security manager para dar a los miembros del team el menor acceso que necesiten a la organization.
  • Github App managers: Para permitir que usuarios adicionales gestionen GitHub Apps propiedad de una organization, un owner puede otorgarles permisos de Github App manager.
  • Outside collaborators: Un outside collaborator es una persona que tiene acceso a uno o más repositories de la organization pero que no es explícitamente member de la organization.

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

Members Privileges

En https://github.com/organizations/<org_name>/settings/member_privileges puedes ver los permisos que los users tendrán solo por ser parte de la organization.

La configuración aquí definida indicará los siguientes permisos de los members de la organization:

  • Ser admin, writer, reader o no tener permiso sobre todos los repositories de la organization.
  • Si los members pueden crear repositories private, internal o public.
  • Si es posible forkear repositories.
  • Si es posible invitar outside collaborators.
  • Si se pueden publicar sitios public o private.
  • Los permisos que los admins tienen sobre los repositories.
  • Si los members pueden crear nuevos teams.

Repository Roles

Por defecto se crean los siguientes repository roles:

  • Read: Recomendado para colaboradores que no tocan el código y que solo quieren ver o comentar tu proyecto.
  • Triage: Recomendado para colaboradores que necesitan gestionar proactivamente issues y pull requests sin acceso de escritura.
  • Write: Recomendado para colaboradores que realmente hacen push en tu proyecto.
  • Maintain: Recomendado para project managers que necesitan gestionar el repository sin acceso a acciones sensibles o destructivas.
  • Admin: Recomendado para personas que necesitan acceso completo al proyecto, incluyendo acciones sensibles y destructivas como gestionar seguridad o borrar un repository.

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

Teams

Puedes listar los teams creados en una organization en https://github.com/orgs/<org_name>/teams. Ten en cuenta que para ver los teams que son hijos de otros teams necesitas acceder a cada parent team.

Users

Los users de una organization pueden ser listados en https://github.com/orgs/<org_name>/people.

En la información de cada user puedes ver los teams de los que el user es member, y los repos a los que el user tiene acceso.

Github Authentication

Github ofrece diferentes formas de autenticarse en tu cuenta y realizar acciones en tu nombre.

Web Access

Accediendo a github.com puedes iniciar sesión usando tu username y password (y potencialmente un 2FA).

SSH Keys

Puedes configurar tu cuenta con una o varias claves públicas permitiendo que la clave privada relacionada realice acciones en tu nombre. https://github.com/settings/keys

GPG Keys

No puedes suplantar al user con estas claves, pero si no las usas podría ser posible que se detecte que envías commits sin firma. Aprende más sobre el vigilant mode aquí.

Personal Access Tokens

Puedes generar personal access token para dar a una aplicación acceso a tu cuenta. Al crear un personal access token el user necesita especificar los permisos que el token tendrá. https://github.com/settings/tokens

Oauth Applications

Oauth applications pueden pedirte permisos para acceder a parte de tu información de github o para suplantarte y realizar algunas acciones. Un ejemplo común de esta funcionalidad es el botón de login with github que podrías encontrar en algunas plataformas.

Algunas recomendaciones de seguridad:

  • Un OAuth App siempre debería actuar como el GitHub user autenticado a lo largo de todo GitHub (por ejemplo, al proporcionar notificaciones al user) y con acceso solo a los scopes especificados.
  • Un OAuth App puede usarse como proveedor de identidad habilitando un “Login with GitHub” para el user autenticado.
  • No construyas un OAuth App si quieres que tu aplicación actúe sobre un solo repository. Con el scope repo, OAuth Apps pueden actuar sobre todos los repositories del usuario autenticado.
  • No construyas un OAuth App para actuar como aplicación de tu team o company. Los OAuth Apps se autentican como un single user, por lo que si una persona crea un OAuth App para que la company lo use y luego esa persona deja la company, nadie más tendrá acceso a él.
  • Más en aquí.

Github Applications

Github applications pueden pedir permisos para acceder a tu información de github o suplantarte para realizar acciones específicas sobre recursos concretos. En Github Apps necesitas especificar los repositories a los que la app tendrá acceso.

Algunas recomendaciones de seguridad:

  • Una GitHub App debería realizar acciones independientes de un user (a menos que la app esté usando un user-to-server token). Para mantener más seguros los access tokens user-to-server, puedes usar access tokens que expiren después de 8 horas y un refresh token que se pueda intercambiar por un nuevo access token. Para más información, consulta “Refreshing user-to-server access tokens.”
  • Asegúrate de que la GitHub App se integre con repositorios específicos.
  • La GitHub App debe conectarse a una personal account o a una organization.
  • No esperes que la GitHub App conozca y haga todo lo que un user puede hacer.
  • No uses una GitHub App si solo necesitas un servicio de “Login with GitHub”. Pero una GitHub App puede usar un user identification flow para iniciar sesión a los users y hacer otras cosas.
  • No construyas una GitHub App si solo quieres actuar como un GitHub user y hacer todo lo que ese user puede hacer.
  • Si estás usando tu app con Github Actions y quieres modificar archivos de workflow, debes autenticarte en nombre del user con un OAuth token que incluya el scope workflow. El user debe tener permisos de admin o write en el repository que contiene el archivo de workflow. Para más información, consulta “Understanding scopes for OAuth apps.”
  • Más en aquí.

Github Actions

Esto no es una forma de autenticarse en github, pero una Github Action maliciosa podría obtener acceso no autorizado a github y, dependiendo de los privilegios otorgados a la Action, se podrían realizar varios ataques. Ver más abajo para más información.

Git Actions

Git actions permite automatizar la ejecución de código cuando ocurre un evento. Normalmente el código ejecutado está de algún modo relacionado con el código del repository (por ejemplo, construir un contenedor docker o comprobar que el PR no contiene secrets).

Configuration

En https://github.com/organizations/<org_name>/settings/actions es posible comprobar la configuración de las github actions para la organization.

Es posible deshabilitar completamente el uso de github actions, permitir todas las github actions, o solo permitir ciertas actions.

También es posible configurar quién necesita aprobación para ejecutar una Github Action y los permisos del GITHUB_TOKEN de una Github Action cuando se ejecuta.

Git Secrets

Las Github Actions normalmente necesitan algún tipo de secret para interactuar con github o aplicaciones de terceros. Para evitar ponerlos en texto plano en el repo, github permite almacenarlos como Secrets.

Estos secrets pueden configurarse para el repo o para toda la organization. Entonces, para que la Action pueda acceder al secret necesitas declararlo así:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Ejemplo usando Bash 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Los secretos solo pueden ser accedidos desde los Github Actions que los hayan declarado.

Una vez configurados en el repo o en las organizations, los usuarios de github no podrán acceder a ellos de nuevo, 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).

Entornos de Git

Github permite crear entornos donde puedes guardar secretos. Luego, puedes dar a la github action acceso a los secretos dentro del entorno con algo como:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

You can configure an environment to be accedido por todas las ramas (por defecto), solo ramas protegidas o especificar qué ramas pueden acceder a él.
Además, las protecciones del environment incluyen:

  • Revisores requeridos: bloquee jobs que apunten al environment hasta que sean aprobados. Habilita Prevent self-review para forzar un principio de cuatro ojos en la propia aprobación.
  • Deployment branches and tags: restrinja qué ramas/tags pueden desplegar al environment. Prefiera seleccionar ramas/tags específicos y asegúrese de que esas ramas estén protegidas. Nota: la opción “Protected branches only” se aplica a las protecciones clásicas de ramas y puede no comportarse como se espera si usa rulesets.
  • Wait timer: retrase los despliegues por un periodo configurable.

También se puede configurar un número de revisiones requeridas antes de ejecutar una acción usando un environment o esperar algún tiempo antes de permitir que los despliegues procedan.

Git Action Runner

Un Github Action puede ser ejecutado dentro del github environment o puede ejecutarse en una infraestructura de terceros configurada por el usuario.

Varias organizaciones permiten ejecutar Github Actions en una infraestructura de terceros ya que suele ser más barato.

Puedes listar los self-hosted runners de una organización en https://github.com/organizations/<org_name>/settings/actions/runners

La forma de encontrar qué Github Actions se están ejecutando en infraestructura no-github es buscar runs-on: self-hosted en el yaml de configuración del Github Action.

No es posible ejecutar un Github Action de una organización dentro de una máquina self-hosted de una organización diferente porque se genera un token único para el Runner al configurarlo para saber a qué runner pertenece.

Si el custom Github Runner está configurado en una máquina dentro de AWS o GCP por ejemplo, la Action podría tener acceso al metadata endpoint y robar el token de la service account con la que la máquina está ejecutándose.

Git Action Compromise

Si todas las actions (o una action maliciosa) están permitidas, un usuario podría usar una Github action que sea maliciosa y comprometer el contenedor donde se está ejecutando.

Caution

Una Github Action maliciosa podría ser abusada por el atacante para:

  • Robar todos los secretos a los que la Action tenga acceso
  • Moverse lateralmente si la Action se ejecuta dentro de una infraestructura de terceros donde se puede acceder al token de la SA usado para ejecutar la máquina (probablemente vía el metadata service)
  • Abusar del token usado por el workflow para robar el código del repo donde se ejecuta la Action o incluso modificarlo.

Branch Protections

Las protecciones de rama están diseñadas para no dar control completo de un repositorio a los usuarios. El objetivo es poner varios métodos de protección antes de poder escribir código dentro de alguna rama.

Las branch protections de un repositorio se pueden encontrar en https://github.com/<orgname>/<reponame>/settings/branches

Note

No es posible establecer una protección de rama a nivel de organización. Por lo tanto, todas deben declararse en cada repo.

Diferentes protecciones pueden aplicarse a una rama (como a master):

  • Puedes requerir un PR antes de hacer merge (para que no puedas fusionar código directamente sobre la rama). Si esto está seleccionado, pueden aplicarse otras protecciones:
  • Requerir un número de aprobaciones. Es muy común requerir 1 o 2 personas adicionales para aprobar tu PR de modo que un solo usuario no pueda fusionar código directamente.
  • Descartar aprobaciones cuando se empujan nuevos commits. Si no, un usuario puede aprobar código legítimo y luego añadir código malicioso y hacer merge.
  • Requerir la aprobación del push revisable más reciente. Asegura que cualquier commit nuevo después de una aprobación (incluyendo pushes de otros colaboradores) re-dispare la revisión para que un atacante no pueda empujar cambios post-aprobación y fusionar.
  • Requerir revisiones de Code Owners. Al menos 1 code owner del repo debe aprobar el PR (para que usuarios “aleatorios” no puedan aprobarlo).
  • Restringir quién puede descartar revisiones de pull request. Puedes especificar personas o equipos permitidos para descartar revisiones.
  • Permitir actores especificados para omitir los requisitos de pull request. Estos usuarios podrán eludir las restricciones previas.
  • Requerir que los status checks pasen antes de fusionar. Algunas comprobaciones deben pasar antes de poder mergear el commit (como una GitHub App que reporte resultados SAST). Consejo: vincula los checks requeridos a una GitHub App específica; de lo contrario, cualquier app podría suplantar el check vía la Checks API, y muchos bots aceptan directivas de skip (p. ej., “@bot-name skip”).
  • Requerir resolución de conversaciones antes de fusionar. Todos los comentarios en el código deben resolverse antes de que el PR pueda ser merged.
  • Requerir commits firmados. Los commits deben estar firmados.
  • Requerir historial lineal. Evita que commits de merge sean empujados a ramas que coincidan.
  • Incluir administradores. Si esto no está activado, los admins pueden eludir las restricciones.
  • Restringir quién puede pushear a ramas coincidentes. Restringe quién puede enviar un PR.

Note

Como puedes ver, incluso si logras obtener credenciales de un usuario, los repos pueden estar protegidos evitando que hagas push a master por ejemplo para comprometer el pipeline CI/CD.

Tag Protections

Los tags (como latest, stable) son mutables por defecto. Para imponer un flujo de cuatro ojos en las actualizaciones de tags, protege los tags y encadena protecciones a través de environments y ramas:

  1. En la regla de protección de tags, habilita Require deployments to succeed y exige un despliegue exitoso a un environment protegido (p. ej., prod).
  2. En el environment objetivo, restringe Deployment branches and tags a la rama de release (p. ej., main) y, opcionalmente, configura Requerir revisores con Prevent self-review.
  3. En la rama de release, configura las protecciones de rama para Requerir un pull request, establece aprobaciones ≥ 1 y habilita tanto Descartar aprobaciones cuando se empujan nuevos commits como Requerir la aprobación del push revisable más reciente.

Esta cadena evita que un único colaborador vuelva a etiquetar o publique forzadamente releases editando los YAML del workflow, ya que las puertas de despliegue se hacen cumplir fuera de los workflows.

References

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks