GitHub, bajo ataque: roban secretos de la nube
Los ciberdelincuentes utilizaron varias funciones de GitHub para distribuir malware que roba datos y sustraer credenciales de servicios en la nube y otros secretos. Los investigadores de Aikido descubrieron que los atacantes utilizaron 4.837 cuentas de GitHub comprometidas y enviaron solicitudes de cambio a 61.764 repositorios. Al menos 1.835 proyectos ejecutaron código malicioso, tras lo cual los datos fueron enviados a los atacantes.
GitHub es una plataforma para el desarrollo colaborativo de software. Cada proyecto se almacena en un repositorio, una carpeta con el código fuente, la configuración y otros archivos. Los cambios en un proyecto suelen proponerse mediante una pull request, o solicitud de cambio: otros desarrolladores la revisan y deciden si la aceptan o la rechazan.
GitHub también cuenta con Actions, un servicio de automatización que puede ejecutar tareas, entre ellas las relacionadas con las pull requests. Los conjuntos de comandos para estas tareas se llaman workflows, o flujos de trabajo. Si es necesario para su funcionamiento, un workflow puede acceder a los secretos del proyecto. Precisamente esta posibilidad convirtió la automatización en una puerta de entrada ideal para quienes roban credenciales.
Según Aikido, las solicitudes masivas sirvieron primero para realizar un reconocimiento: los atacantes comprobaban en qué proyectos podían introducir cambios las cuentas. Los investigadores no determinaron cómo se robaron o comprometieron las propias cuentas. La campaña recibió el nombre de wfx-loot, por el malware y la denominación de los secretos robados que utilizaban los atacantes. Las solicitudes se titulaban «docs: dependency audit notes» («documentación: notas sobre la auditoría de dependencias») y las ramas, wfx-docs.
De las más de 60.000 pull requests similares, más de 10.000 se dirigieron a repositorios que no pertenecían a las cuentas comprometidas, pero en los que estas podían editar. Una vez obtenidos permisos de escritura, los atacantes introducían código malicioso de una de estas tres formas: modificaban workflows ya existentes de GitHub Actions, añadían un script de shell que se ejecutaba al instalar un paquete npm o creaban un nuevo archivo de workflow en una rama temporal. npm es un popular gestor de paquetes para JavaScript, y los scripts de shell son comandos ejecutados por el intérprete de comandos.
En todos los casos se utilizó una carga maliciosa de unas 1.500 líneas de código. Buscaba en el entorno infectado secretos de GitHub Actions, tokens de autenticación, credenciales de AWS, Azure y Google Cloud, configuraciones de Docker y Kubernetes, claves SSH, claves de API de servicios de inteligencia artificial, incluidos OpenAI y Anthropic, así como el historial de comandos de los desarrolladores. Además, el malware inspeccionaba archivos .env, claves privadas y credenciales de npm, PyPI, HashiCorp Vault y Terraform.
El programa no se limitaba a robar los secretos ya disponibles. Intentaba ampliar sus permisos: intercambiaba los tokens robados por sesiones en la nube, suplantaba cuentas de servicio y creaba nuevas credenciales. Para no perder el acceso tras el cambio de las contraseñas y claves comprometidas, el código malicioso también modificaba la configuración de AWS y Azure.
Aikido informa de al menos 1.835 repositorios en los que la carga maliciosa llegó a ejecutarse y de los que se robaron credenciales. Después, los atacantes revertían los cambios introducidos y eliminaban los registros de ejecución de los workflows, a veces en menos de un minuto. Esto ayudaba a ocultar sus huellas y dificultaba la detección del ataque.
Al parecer, la campaña también afectó a la cadena de suministro de software: Aikido detectó paquetes PHP comprometidos en Packagist y dos versiones afectadas de módulos de Go. No obstante, los investigadores contemplan que la publicación de estos paquetes pudiera ser una consecuencia secundaria del abuso de procesos automatizados, y no un objetivo previsto de antemano.
Aikido recomienda a los propietarios de los repositorios en los que se ejecutó código malicioso que consideren comprometidos todos los secretos y credenciales de nube a los que tuvieran acceso los workflows correspondientes y que los sustituyan urgentemente. La publicación original también señalaba que los atacantes afirmaban haber comprometido ya 4.800 cuentas; la cifra exacta aportada por los investigadores es 4.837.
Fuente: BleepingComputer.
PEREC.RU
Los ciberataques contra las herramientas de desarrollo hace tiempo que dejaron de ser una historia sobre un hacker misterioso con capucha. Ahora basta con una cuenta robada, una solicitud de cambio con un nombre de lo más discreto y una automatización a la que se han confiado las llaves de la nube. El pirateo digital se parece ya a una tarea de oficina: el acceso está concedido, el proceso configurado y solo queda esperar que a nadie se le ocurra seguir las instrucciones al pie de la letra.
El contraste entre la finalidad de GitHub Actions y el resultado es especialmente ilustrativo. La automatización debería librar a los desarrolladores de tareas repetitivas, pero, si se utiliza sin cuidado, se convierte en un mensajero que recoge los secretos por su cuenta, los empaqueta y se los lleva a un destinatario desconocido. La tecnología no traicionó a nadie: simplemente ejerció los permisos que le habían concedido. Al parecer, las máquinas no tienen un sentido innato del pudor.
El ataque demuestra que la seguridad de un proyecto no depende solo de la contraseña de la cuenta ni del código visible en el repositorio. También importan los permisos concedidos a la automatización, los tokens, las claves de los servicios en la nube y los registros de actividad. Si un solo workflow puede acceder a todo de una vez, deja de ser un asistente y se convierte en un manojo de llaves abandonado en el felpudo.
Mención aparte merece la rapidez con la que se borran las huellas. Se revierten los cambios, se eliminan los registros y el propietario del proyecto tiene la oportunidad de detectar el problema cuando los secretos ya han empezado a llevar una vida desenfrenada por su cuenta. En un sistema así, «lo hemos automatizado todo» no suena a logro, sino a una petición al atacante para que no se olvide de pulsar el botón.
Los investigadores no aportan pruebas de que cada paquete afectado fuera el objetivo de una operación independiente. Es probable que algunas consecuencias se debieran al abuso de la publicación automática. Pero para las víctimas, la diferencia entre un ataque deliberado y un efecto secundario viene a ser como la que hay entre un incendio provocado a propósito y otro causado por una tostadora mal configurada: en ambos casos hay que ventilar el local.
La conclusión práctica resulta desagradable por su sencillez: si se ha ejecutado código sospechoso, hay que considerar potencialmente expuestos los secretos a los que podía acceder la automatización. Deben sustituirse y hay que revisar los permisos de los procesos, limitándolos estrictamente a lo imprescindible. Es un trabajo aburrido, que no promete una nota de prensa espectacular, pero que precisamente impide que el siguiente script «accidentalmente afiliado» consiga las llaves de toda la casa.
Las plataformas añadirán nuevos mecanismos cómodos, las empresas los incorporarán para ganar velocidad y siempre habrá alguien que decida que los secretos se pueden poner al alcance de un montón de procesos y que luego bastará con borrar el registro. Así funciona el progreso: primero automatizamos las tareas rutinarias y después automatizamos el alcance de las consecuencias. Solo tras el incidente descubrimos que el botón de «revertir cambios» no devuelve las credenciales robadas de la nube.
