Github Security
¿Qué es Github?
(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.
Información Básica
pageBasic Github InformationReconocimiento Externo
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 al usuario, repositorio u organización que deseas atacar, puedes utilizar dorks de Github para encontrar información sensible o buscar filtraciones de información sensible en cada repositorio.
Dorks de Github
Github permite buscar algo especificando como alcance un usuario, un repositorio o una organización. Por lo tanto, con una lista de cadenas que van a aparecer cerca de información sensible, puedes buscar fácilmente información sensible potencial en tu objetivo.
Herramientas (cada herramienta contiene su lista de dorks):
Filtraciones de Github
Ten en cuenta que los dorks de Github 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 repositorio 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 repositorio y ejecutes algo como git log -p, ¡no olvides que podría haber otras ramas con otros commits que contengan secretos!
Forks Externos
Es posible comprometer repositorios abusando de solicitudes de extracción. Para saber si un repositorio es vulnerable, principalmente necesitas leer las configuraciones yaml de Github Actions. Más información al respecto abajo.
Fortalecimiento de la Organización
Privilegios de Miembros
Existen algunos privilegios predeterminados que se pueden asignar a los miembros de la organización. Estos pueden ser controlados 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 permiso Ninguno/Lectura/Escritura/Administrador sobre los repositorios de la organización. Se recomienda Ninguno o Lectura.
Creación de repositorios derivados: Si no es necesario, es mejor no permitir a los miembros hacer repositorios derivados de la organización.
Creación de páginas: Si no es necesario, es mejor no permitir a los miembros publicar páginas desde los repositorios de la organización. Si es necesario, se puede 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 u OAuth accedan a esta organización y sus recursos. Por lo general, es necesario, pero si no lo es, 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 de administrador 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 deseas 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 de administrador 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.
Configuraciones de Acciones
Varias configuraciones relacionadas con la seguridad se pueden configurar 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: Te permite indicar qué repositorios pueden ejecutar flujos de trabajo y qué flujos de trabajo deben permitirse. Se recomienda especificar qué repositorios deben permitirse y no permitir que se ejecuten todas las acciones.
Flujos de trabajo de solicitudes de extracción de repositorios derivados 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 solicitudes de extracción de repositorios derivados: Se desaconseja ejecutar flujos de trabajo desde solicitudes de extracción, ya que los mantenedores del origen del fork 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 flujos de trabajo: Se recomienda solo dar permisos de lectura de repositorio. Se desaconseja dar permisos de escritura y crear/aprobar solicitudes de extracción para evitar el abuso del GITHUB_TOKEN dado para ejecutar flujos de trabajo.
Integraciones
¡Avísame si conoces el punto final de la API para acceder a esta información!
Política de acceso de 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).
Reconocimiento y Ataques abusando credenciales
Para este escenario vamos a suponer que has obtenido acceso a una cuenta de github.
Con Credenciales de Usuario
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 sin procesar, verificar qué permisos tienen los miembros sin procesar, en qué grupos estás, qué permisos tienes sobre qué repositorios, y cómo están protegidos los repositorios.
Ten en cuenta que puede estar en uso la autenticación de dos factores (2FA), por lo que solo podrás acceder a esta información si también puedes superar esa verificación.
Ten en cuenta que si logras robar la cookie de sesión de usuario (actualmente configurada con SameSite: Lax) puedes hacerte pasar completamente por el usuario sin necesidad de credenciales o 2FA.
Consulta la sección a continuación sobre bypass de protecciones de rama en caso de que sea útil.
Con Clave SSH de Usuario
Github permite a los usuarios configurar claves SSH que se utilizarán como método de autenticación para implementar 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 repositorios y usuarios a los 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 se puede usar.
Las claves SSH también se pueden configurar en repositorios como claves de implementación. Cualquier persona con acceso a esta clave podrá lanzar proyectos desde un repositorio. Por lo general, en un servidor con diferentes claves de implementación, el archivo local ~/.ssh/config te dará información sobre qué clave está relacionada.
Claves GPG
Como se explica aquí a veces es necesario firmar los commits o podrías ser descubierto.
Verifica localmente si el usuario actual tiene alguna clave con:
Con Token de Usuario
Para obtener 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 sobre HTTPS, o puede ser utilizado para autenticarse en la API mediante Autenticación Básica. Dependiendo de los privilegios asociados, podrías realizar diferentes acciones.
Un token de usuario se ve así: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Con Aplicación Oauth
Para obtener 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 privilegiados de los usuarios que los 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/repositorios/acciones relacionadas con la organización.
Con Aplicación de Github
Para obtener 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 privilegiados de los usuarios que los 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/repositorios/acciones relacionadas con la organización.
Compromiso y Abuso de Acciones de Github
Existen varias técnicas para comprometer y abusar de una Acción de Github, consúltalas aquí:
pageAbusing Github ActionsBypass de Protección de Ramas
Requerir un número de aprobaciones: Si comprometes varias cuentas, podrías aceptar tus PR desde otras cuentas. Si solo tienes acceso a la cuenta desde la que creaste el PR, no puedes aceptar tu propio PR. Sin embargo, si tienes acceso a un entorno de Acción de Github dentro del repositorio, usando el GITHUB_TOKEN podrías aprobar tu PR y obtener una aprobación de esta manera.
Nota para esto y para la restricción de Propietarios de Código, por lo general un usuario no podrá aprobar sus propios PR, pero si puedes, puedes abusar para aceptar tus PR.
Descartar aprobaciones cuando se empujan nuevos commits: Si esto no está configurado, puedes enviar código legítimo, esperar a que alguien lo apruebe, y poner código malicioso y fusionarlo en la rama protegida.
Requerir revisiones de los Propietarios de Código: Si esto está activado y eres un Propietario de Código, podrías hacer que una Acción de Github 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, su protección de Propietarios de Código no se aplica.
Permitir que actores especificados eviten los requisitos de pull request: Si eres uno de estos actores, puedes evitar las protecciones de pull request.
Incluir administradores: Si esto no está configurado y eres administrador del repositorio, puedes evitar estas protecciones de rama.
Secuestro de PR: Podrías ser capaz de modificar el PR de otra persona agregando 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 volver a establecer las protecciones.
Burlar protecciones de empuje: Si un repositorio solo permite a ciertos usuarios enviar empujes (fusionar código) en ramas (la protección de la 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 empujar código debido a la protección de la rama, aún puedes crear una nueva rama y dentro de ella crear una acción de Github que se active cuando se empuje código. Como la protección de la rama no protegerá la rama hasta que se cree, este primer empuje de código a la rama ejecutará la acción de Github.
Burlar Protecciones de Entornos
Para obtener una introducción sobre Entornos 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 repositorios donde todas las ramas están protegidas (especificando sus nombres o usando *), en ese escenario, encuentra una rama donde puedas empujar código y puedes exfiltrar los secretos creando una nueva acción de Github (o modificando una).
Ten en cuenta que podrías encontrar el caso excepcional donde todas las ramas están protegidas (a través del comodín *) se especifica quién puede empujar código a las ramas (puedes especificarlo en la protección de la rama) y tu usuario no está permitido. Aún puedes ejecutar una acción personalizada de Github porque puedes crear una rama y usar el disparador de empuje sobre sí misma. La protección de la rama permite el empuje a una nueva rama, por lo que la acción de Github se activará.
Ten en cuenta 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ás modificarla, pero para ese momento ya habrás extraído las claves secretas.
Persistencia
Generar token de usuario
Robar tokens de Github de secretos
Eliminación de resultados de flujo de trabajo y ramas
Dar más permisos a toda la organización
Crear webhooks para exfiltrar información
Invitar colaboradores externos
Eliminar webhooks utilizados por el SIEM
Crear/modificar Acción de Github con una puerta trasera
Encontrar Acción de Github vulnerable a inyección de comandos mediante modificación de valores de secreto
Commits de impostores - Puerta trasera a través de commits de repositorio
En Github es posible crear una PR a un repositorio desde un fork. Incluso si la PR no es aceptada, se creará un id de commit dentro del repositorio original para la versión fork del código. Por lo tanto, un atacante podría fijarse en usar un commit específico de un repositorio aparentemente legítimo que no fue creado por el propietario del repositorio.
Como este:
Para obtener más información, visita https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Última actualización