El token caduca. La clave no.
La autenticación de GitHub App depende de una private key que genera un JSON Web Token (JWT) con una vida útil máxima de 10 minutos. Este JWT solicita luego un token de acceso de instalación, válido por hasta una hora. GitHub aplica estrictamente estas caducidades de tokens posteriores, creando una ilusión de acceso transitorio.
Sin embargo, la private key raíz, la fuente de estas credenciales, no posee un tiempo de vida (TTL) nativo. Puede generar nuevos tokens perpetuamente hasta que sea revocada explícitamente. Esta elección arquitectónica fundamental significa que una clave comprometida u olvidada sigue siendo una amenaza persistente, a diferencia de los tokens de corta duración que produce.
Aunque algunos argumentan que esto refleja el comportamiento de las claves SSH, que también suelen carecer de caducidad impuesta por la plataforma, el alcance de los permisos de GitHub App aumenta drásticamente el riesgo. Las aplicaciones a menudo ejercen un acceso amplio a múltiples repositorios, incluyendo:
- Privilegios administrativos de la organización
- Acceso de escritura a código privado
- Control sobre self-hosted runners y ejecución de flujos de trabajo
La investigación de GitGuardian encontró 474 claves activas, con 44 otorgando derechos completos de administrador de organización. Una clave, vinculada a los CDC de EE. UU., proporcionó acceso de escritura a código privado durante 17 meses después de su filtración. Esto destaca por qué las claves de GitHub App no gestionadas representan un riesgo de gobernanza significativo y duradero, mucho más allá del de una clave SSH típica.
474 claves filtradas aún abrían la puerta
La investigación reciente de GitGuardian descubrió una realidad cruda: de más de 500,000 claves RSA expuestas, 4,802 estaban vinculadas a un ID de GitHub App. Unas asombrosas 474 de estas claves aún se autenticaban, representando 440 aplicaciones distintas, a pesar de estar expuestas públicamente. Esto demuestra una vulnerabilidad crítica en la cadena de seguridad.
Las implicaciones de estas exposiciones persistentes son graves. Cuarenta y cuatro aplicaciones válidas tenían acceso completo de administrador de organización, mientras que el 72% podía leer repositorios privados. Además, 207 aplicaciones poseían permisos de escritura, abriendo la puerta a la inyección arbitraria de código y al envenenamiento de pipelines, un riesgo significativo para la seguridad de la cadena de suministro.
La persistencia del problema es preocupante. Una clave de Crusher.dev había sido pública desde 2020 y permaneció activa. Se informó que una clave vinculada a los CDC de EE. UU. permaneció válida durante 17 meses después de su exposición. Otra aplicación ampliamente utilizada, "Access Tokens for GitHub Actions", filtró una private key en enero de 2024, afectando a aproximadamente 300 organizaciones, incluido el contratista de defensa Sierra Nevada Corp.
Estos ejemplos subrayan el peligro de las GitHub App private keys: a diferencia de los JWT y los tokens de acceso de instalación de corta duración que generan, las private keys raíz no tienen caducidad nativa. Este descuido arquitectónico transforma una sola filtración en una amenaza de seguridad perpetua, lo que exige atención inmediata y estrategias sólidas de rotación de claves.
Una aplicación olvidada puede convertirse en un punto de apoyo en la cadena de suministro
Una aplicación olvidada presenta un punto de apoyo significativo en la cadena de suministro. Las claves filtradas pueden permitir a un atacante leer código privado, escribir en repositorios, manipular flujos de trabajo o administrar self-hosted runners. Dicho acceso facilita directamente la manipulación de código, el compromiso de CI/CD y, en última instancia, la toma de control de la organización.
Las integraciones obsoletas se pasan por alto fácilmente. GitGuardian descubrió que el 59% de las 440 aplicaciones distintas con claves activas tenían solo una instalación, a menudo para automatización ad-hoc. Cuando los ingenieros se marchan o los proyectos se abandonan, la propiedad de estas aplicaciones desaparece con frecuencia, dejando una vulnerabilidad persistente. La clave de la aplicación Crusher.dev, expuesta desde 2020, permaneció activa años después de que el proyecto dejara de recibir mantenimiento.
La organización US Centers for Disease Control and Prevention (CDC), por ejemplo, tuvo una clave privada filtrada con acceso de escritura a repositorios privados durante 17 meses, mediando el acceso a su infraestructura de Microsoft Azure. De manera similar, la aplicación ampliamente utilizada "Access Tokens for GitHub Actions" filtró una clave privada, exponiendo a aproximadamente 300 organizaciones.
Si bien una clave válida no prueba automáticamente una explotación activa, significa una exposición persistente. Los atacantes, una vez que obtienen una clave válida, pueden actuar con los permisos otorgados a la aplicación en cualquier momento. Para obtener más detalles sobre estas amenazas persistentes, consulte la investigación de GitGuardian: GitHub App Private Keys: 474 Leaked Keys Still Work. Esto destaca la necesidad crítica de una gestión rigurosa de las GitHub App private keys y sus permisos asociados para mitigar los supply-chain risks.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Rote sin tiempo de inactividad y retire lo que nadie posee
Los propietarios de aplicaciones deben implementar una estrategia sólida de rotación de claves. Genere una nueva private key, despliéguela y verifique su funcionalidad, luego revoque la anterior. GitHub permite hasta 25 claves privadas activas por aplicación, lo que permite una rotación por etapas sin interrupción del servicio.
Establezca una cadencia de rotación documentada, protocolos de almacenamiento seguro de claves e integre secret scanning en todos los repositorios, incluidos los forks públicos propiedad de los desarrolladores. Aplique el acceso de menor privilegio, limitando los permisos de la aplicación solo a los repositorios y acciones estrictamente necesarios para su función. Esto minimiza el radio de explosión de cualquier posible compromiso.
Los administradores de la organización enfrentan un mandato crítico para auditar las aplicaciones instaladas. Identifique y asigne propietarios responsables para cada integración. Elimine rápidamente las aplicaciones abandonadas o sin mantenimiento, ya que se convierten en objetivos principales para los atacantes que buscan un punto de apoyo persistente.
Finalmente, verifique que todas las aplicaciones sobrevivientes operen con los permisos mínimos necesarios. Revisar y ajustar estos controles de acceso reduce la superficie de ataque, evitando que una aplicación olvidada se convierta en una puerta abierta a los activos más sensibles de su organización.
Preguntas frecuentes
¿Las GitHub App private keys caducan automáticamente?
No. Las GitHub App private keys no tienen una fecha de caducidad integrada, por lo que los propietarios deben rotarlas y revocarlas.
¿Cómo se puede utilizar una clave de GitHub App no caducada?
Puede firmar un JWT de corta duración, que puede intercambiarse por un token de acceso de instalación que dura hasta una hora.
¿Cuántas GitHub App private keys pueden estar activas a la vez?
GitHub permite hasta 25 claves privadas para una aplicación, lo que permite a los equipos implementar un reemplazo antes de eliminar la clave antigua.
¿Qué debe hacer una organización con las aplicaciones que nadie mantiene?
Audite las GitHub Apps instaladas, elimine las integraciones obsoletas o sin propietario, y restrinja los permisos y repositorios otorgados a las que permanezcan.