GitHub confirmó el martes que los atacantes obtuvieron acceso no autorizado a sus repositorios internos tras comprometer un dispositivo de un empleado mediante una extensión de Visual Studio Code envenenada. La plataforma propiedad de Microsoft detectó y contuvo el compromiso, eliminó la extensión maliciosa, aisló el punto afectado y comenzó inmediatamente la respuesta al incidente.
La empresa dijo que su evaluación actual es que la brecha implicó solo la extracción de repositorios internos de GitHub. No se cree que se hayan visto afectados los repositorios de clientes, organizaciones empresariales ni los datos de usuarios almacenados fuera de los sistemas internos de GitHub.
La magnitud de la brecha
GitHub confirmó que las afirmaciones del atacante sobre aproximadamente 3,800 repositorios internos son coherentes con su propia investigación. El grupo de amenazas TeamPCP se ha atribuido la responsabilidad del ataque y se informa que está intentando vender el conjunto de datos robado en foros cibernéticos subterráneos por más de $50,000. El grupo afirma que los datos incluyen código fuente propietario de la plataforma y archivos internos de la organización de aproximadamente 4,000 repositorios privados.
GitHub dijo que actuó rápidamente para rotar las credenciales críticas tras detectar la brecha, priorizando primero los secretos de mayor impacto. La empresa continúa analizando registros, validando la rotación de secretos y monitoreando actividades posteriores.
Por qué el acceso al repositorio interno es grave
La empresa dijo que no tiene evidencia de impacto en la información de los clientes almacenada fuera de los repositorios internos. Los investigadores de seguridad señalaron que la redacción específica es importante. No tener evidencia de impacto no es una confirmación de que los datos de los clientes estén seguros. Significa que la investigación está en curso y que el alcance completo del daño aún no se ha determinado.
Los repositorios internos suelen contener configuraciones de infraestructura, scripts de despliegue, documentación de API interna, credenciales de staging, banderas de función, hooks de monitoreo y servicios sin documentar. El acceso al código fuente interno proporciona efectivamente un plano de la arquitectura de todo el sistema, incluso sin acceso directo a los datos de los clientes.
Los profesionales de seguridad también consideraron significativa la mención explícita de GitHub sobre la supervisión de actividades posteriores. Los ataques modernos rara vez se detienen en el acceso inicial. La progresión típica avanza desde el punto de entrada inicial hasta la reconstrucción, escalada de privilegios, persistencia y luego una segunda ola de actividad dirigida después de que los defensores creen que la amenaza ha sido contenida.
Qué está haciendo GitHub
GitHub dijo que los secretos críticos se rotaron el mismo día en que se detectó la brecha, abordando primero las credenciales más sensibles. La empresa continúa monitoreando la infraestructura en busca de cualquier actividad secundaria y publicará un informe completo sobre el incidente una vez que la investigación esté completa. Los clientes serán notificados a través de los canales establecidos de respuesta a incidentes si se descubre algún impacto en sus datos.
Se ha aconsejado a los desarrolladores que usan GitHub que revisen y cambien cualquier clave de API almacenada en los repositorios como medida preventiva, incluso en aquellos casos en que no se cree que los repositorios de los clientes hayan sido afectados directamente.