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)
(De aquí) A un alto nivel, GitHub es un sitio web y un servicio basado en la nube que ayuda a los desarrolladores a almacenar y gestionar su código, así como a rastrear y controlar los cambios en su código.
Los repositorios de Github pueden configurarse como públicos, privados e internos.
Privado significa que solo las personas de la organización podrán acceder a ellos.
Interno significa que solo las personas de la empresa (una empresa puede tener varias organizaciones) podrán acceder a él.
Público significa que todo internet podrá acceder a él.
En caso de que conozcas el usuario, repo u organización que deseas atacar, puedes usar github dorks para encontrar información sensible o buscar filtraciones de información sensible en cada repo.
Github permite buscar algo especificando como alcance un usuario, un repo o una organización. Por lo tanto, con una lista de cadenas que van a aparecer cerca de información sensible, puedes fácilmente buscar información sensible potencial en tu objetivo.
Herramientas (cada herramienta contiene su lista de dorks):
Por favor, ten en cuenta que los github dorks también están destinados a buscar filtraciones utilizando las opciones de búsqueda de github. Esta sección está dedicada a aquellas herramientas que descargarán cada repo y buscarán información sensible en ellos (incluso revisando cierta profundidad de commits).
Herramientas (cada herramienta contiene su lista de regexes):
Cuando busques filtraciones en un repo y ejecutes algo como git log -p, no olvides que puede haber otras ramas con otros commits que contengan secretos.
Es posible comprometer repos abusando de pull requests. Para saber si un repo es vulnerable, principalmente necesitas leer las configuraciones yaml de Github Actions. Más información sobre esto a continuación.
Incluso si están eliminados o internos, puede ser posible obtener datos sensibles de forks de repositorios de github. Revísalo aquí:
Accessible Deleted Data in GithubHay algunos privilegios predeterminados que se pueden asignar a los miembros de la organización. Estos se pueden controlar desde la página https://github.com/organizations/<org_name>/settings/member_privileges o desde la API de Organizaciones.
Permisos base: Los miembros tendrán el permiso Ninguno/Leer/escribir/Administrar sobre los repositorios de la organización. Se recomienda Ninguno o Leer.
Forking de repositorios: Si no es necesario, es mejor no permitir que los miembros hagan fork de los repositorios de la organización.
Creación de páginas: Si no es necesario, es mejor no permitir que los miembros publiquen páginas desde los repositorios de la organización. Si es necesario, puedes permitir crear páginas públicas o privadas.
Solicitudes de acceso a integraciones: Con esto habilitado, los colaboradores externos podrán solicitar acceso para que las aplicaciones de GitHub o OAuth accedan a esta organización y sus recursos. Generalmente es necesario, pero si no, es mejor deshabilitarlo.
No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces
Cambio de visibilidad del repositorio: Si está habilitado, los miembros con permisos administrativos para el repositorio podrán cambiar su visibilidad. Si está deshabilitado, solo los propietarios de la organización pueden cambiar las visibilidades de los repositorios. Si no quieres que las personas hagan cosas públicas, asegúrate de que esto esté deshabilitado.
No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces
Eliminación y transferencia de repositorios: Si está habilitado, los miembros con permisos administrativos para el repositorio podrán eliminar o transferir repositorios públicos y privados.
No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces
Permitir a los miembros crear equipos: Si está habilitado, cualquier miembro de la organización podrá crear nuevos equipos. Si está deshabilitado, solo los propietarios de la organización pueden crear nuevos equipos. Es mejor tener esto deshabilitado.
No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces
Se pueden configurar más cosas en esta página, pero las anteriores son las más relacionadas con la seguridad.
Se pueden configurar varias configuraciones relacionadas con la seguridad para las acciones desde la página https://github.com/organizations/<org_name>/settings/actions.
Ten en cuenta que todas estas configuraciones también se pueden establecer en cada repositorio de forma independiente.
Políticas de acciones de Github: Permite indicar qué repositorios pueden ejecutar flujos de trabajo y qué flujos de trabajo deben ser permitidos. Se recomienda especificar qué repositorios deben ser permitidos y no permitir que todas las acciones se ejecuten.
Flujos de trabajo de pull requests de forks de colaboradores externos: Se recomienda requerir aprobación para todos los colaboradores externos.
No pude encontrar una API con esta información, comparte si lo haces
Ejecutar flujos de trabajo desde pull requests de forks: Es muy desaconsejado ejecutar flujos de trabajo desde pull requests ya que los mantenedores del fork de origen tendrán la capacidad de usar tokens con permisos de lectura en el repositorio fuente.
No pude encontrar una API con esta información, comparte si lo haces
Permisos de flujo de trabajo: Se recomienda dar solo permisos de lectura de repositorio. Se desaconseja dar permisos de escritura y crear/aprobar pull requests para evitar el abuso del GITHUB_TOKEN dado a los flujos de trabajo en ejecución.
Házmelo saber si conoces el endpoint de la API para acceder a esta información!
Política de acceso a aplicaciones de terceros: Se recomienda restringir el acceso a cada aplicación y permitir solo las necesarias (después de revisarlas).
Aplicaciones de GitHub instaladas: Se recomienda permitir solo las necesarias (después de revisarlas).
Para este escenario vamos a suponer que has obtenido algún acceso a una cuenta de github.
Si de alguna manera ya tienes credenciales para un usuario dentro de una organización, puedes simplemente iniciar sesión y verificar qué roles de empresa y organización tienes, si eres un miembro normal, verifica qué permisos tienen los miembros normales, en qué grupos estás, qué permisos tienes sobre qué repos, y cómo están protegidos los repos.
Ten en cuenta que 2FA puede estar en uso, por lo que solo podrás acceder a esta información si también puedes pasar esa verificación.
Ten en cuenta que si logras robar la cookie user_session (actualmente configurada con SameSite: Lax) puedes suplantar completamente al usuario sin necesidad de credenciales o 2FA.
Revisa la sección a continuación sobre eliminaciones de protección de ramas en caso de que sea útil.
Github permite a los usuarios establecer claves SSH que se utilizarán como método de autenticación para desplegar código en su nombre (no se aplica 2FA).
Con esta clave puedes realizar cambios en repositorios donde el usuario tiene algunos privilegios, sin embargo, no puedes usarla para acceder a la API de github para enumerar el entorno. Sin embargo, puedes enumerar configuraciones locales para obtener información sobre los repos y el usuario al que tienes acceso:
Si el usuario ha configurado su nombre de usuario como su nombre de usuario de github, puedes acceder a las claves públicas que ha establecido en su cuenta en https://github.com/<github_username>.keys, podrías verificar esto para confirmar que la clave privada que encontraste puede ser utilizada.
Las claves SSH también se pueden establecer en los repositorios como claves de despliegue. Cualquiera con acceso a esta clave podrá lanzar proyectos desde un repositorio. Usualmente, en un servidor con diferentes claves de despliegue, el archivo local ~/.ssh/config te dará información sobre a qué clave está relacionada.
Como se explicó aquí, a veces es necesario firmar los commits o podrías ser descubierto.
Verifica localmente si el usuario actual tiene alguna clave con:
Para una introducción sobre Tokens de Usuario consulta la información básica.
Un token de usuario puede ser utilizado en lugar de una contraseña para Git a través de HTTPS, o puede ser utilizado para autenticarse en la API a través de la Autenticación Básica. Dependiendo de los privilegios asociados, podrías realizar diferentes acciones.
Un token de usuario se ve así: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Para una introducción sobre Aplicaciones Oauth de Github consulta la información básica.
Un atacante podría crear una Aplicación Oauth maliciosa para acceder a datos/acciones privilegiadas de los usuarios que las aceptan, probablemente como parte de una campaña de phishing.
Estos son los alcances que una aplicación Oauth puede solicitar. Siempre se debe verificar los alcances solicitados antes de aceptarlos.
Además, como se explica en la información básica, las organizaciones pueden otorgar/denegar acceso a aplicaciones de terceros a información/repos/acciones relacionadas con la organización.
Para una introducción sobre Aplicaciones de Github consulta la información básica.
Un atacante podría crear una Aplicación de Github maliciosa para acceder a datos/acciones privilegiadas de los usuarios que las aceptan, probablemente como parte de una campaña de phishing.
Además, como se explica en la información básica, las organizaciones pueden otorgar/denegar acceso a aplicaciones de terceros a información/repos/acciones relacionadas con la organización.
Hay varias técnicas para comprometer y abusar de un Github Action, consúltalas aquí:
Abusing Github ActionsRequerir un número de aprobaciones: Si has comprometido varias cuentas, podrías simplemente aceptar tus PRs desde otras cuentas. Si solo tienes la cuenta desde donde creaste el PR, no puedes aceptar tu propio PR. Sin embargo, si tienes acceso a un entorno de Github Action dentro del repositorio, usando el GITHUB_TOKEN podrías aprobar tu PR y obtener 1 aprobación de esta manera.
Nota para esto y para la restricción de Propietarios de Código que generalmente un usuario no podrá aprobar sus propios PRs, pero si puedes, puedes abusar de ello para aceptar tus PRs.
Desestimar aprobaciones cuando se envían nuevos commits: Si esto no está configurado, puedes enviar código legítimo, esperar a que alguien lo apruebe, y luego poner código malicioso y fusionarlo en la rama protegida.
Requerir revisiones de Propietarios de Código: Si esto está activado y eres un Propietario de Código, podrías hacer que un Github Action cree tu PR y luego lo apruebes tú mismo.
Cuando un archivo CODEOWNER está mal configurado, Github no se queja pero no lo utiliza. Por lo tanto, si está mal configurado, la protección de Propietarios de Código no se aplica.
Permitir a actores especificados eludir los requisitos de solicitud de extracción: Si eres uno de estos actores, puedes eludir las protecciones de solicitud de extracción.
Incluir administradores: Si esto no está configurado y eres administrador del repositorio, puedes eludir estas protecciones de rama.
Secuestro de PR: Podrías ser capaz de modificar el PR de otra persona añadiendo código malicioso, aprobando el PR resultante tú mismo y fusionando todo.
Eliminar Protecciones de Ramas: Si eres un administrador del repositorio, puedes desactivar las protecciones, fusionar tu PR y restablecer las protecciones.
Eludir protecciones de push: Si un repositorio solo permite ciertos usuarios enviar push (fusionar código) en ramas (la protección de rama podría estar protegiendo todas las ramas especificando el comodín *).
Si tienes acceso de escritura sobre el repositorio pero no se te permite enviar código debido a la protección de rama, aún puedes crear una nueva rama y dentro de ella crear un github action que se activa cuando se envía código. Como la protección de rama no protegerá la rama hasta que se cree, este primer envío de código a la rama ejecutará el github action.
Para una introducción sobre Entorno de Github consulta la información básica.
En caso de que un entorno pueda ser accedido desde todas las ramas, no está protegido y puedes acceder fácilmente a los secretos dentro del entorno. Ten en cuenta que podrías encontrar repos donde todas las ramas están protegidas (especificando sus nombres o usando *), en ese escenario, encuentra una rama donde puedas enviar código y puedes exfiltrar los secretos creando un nuevo github action (o modificando uno).
Ten en cuenta que podrías encontrar el caso extremo donde todas las ramas están protegidas (a través del comodín *) se especifica quién puede enviar código a las ramas (puedes especificar eso en la protección de rama) y tu usuario no está permitido. Aún puedes ejecutar un github action personalizado porque puedes crear una rama y usar el disparador de push sobre sí misma. La protección de rama permite el push a una nueva rama, por lo que el github action será activado.
Note que después de la creación de la rama, la protección de la rama se aplicará a la nueva rama y no podrá modificarla, pero para ese momento ya habrá extraído los secretos.
Generar token de usuario
Robar tokens de github de secretos
Eliminación de resultados y ramas de flujo de trabajo
Dar más permisos a toda la organización
Crear webhooks para exfiltrar información
Invitar a colaboradores externos
Eliminar webhooks utilizados por el SIEM
Crear/modificar Github Action con una puerta trasera
Encontrar Github Action vulnerable a inyección de comandos a través de la modificación del valor de secreto
En Github es posible crear un PR a un repositorio desde un fork. Incluso si el PR no es aceptado, se va a crear un commit id dentro del repositorio original para la versión fork del código. Por lo tanto, un atacante podría fijar el uso de un commit específico de un repositorio aparentemente legítimo que no fue creado por el propietario del repositorio.
Como este:
Para más información, consulta https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-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)
