Repositorios huérfanos, la técnica para colar malware que puede afectar a la cadena de suministro
La propia forma de funcionar de GitHub ofrece una arquitectura que no elimina este tipo de repositorios, que podrían acabar afectando al conjunto del código.
Prácticamente todas las aplicaciones que utilizamos a diario en móviles y ordenadores se basan en otras piezas de código que han sido previamente fabricadas por terceros, como si fuera una especie de producto de Lego.
Esto ofrece una mayor rapidez y lógica durante el desarrollo y las consiguientes actualizaciones o parches, pero si una sola pieza está envenenada por algún actor malicioso, automáticamente la infección pasará al conjunto.
Precisamente, los expertos del sector han hecho sonar las alarmas ante una modalidad especialmente difícil de detectar y que ya está siendo explotada por grupos de cibercriminales: lo que se conocen como repositorios huérfanos –dangling commits en el término original–.
En este contexto, GitHub, la mayor fábrica de software del mundo, se ha convertido en una biblioteca perfecta para colar este tipo malware, ya que la mayor parte de desarrolladores comparten aquí sus proyectos; cada colaboración de un programador, se conoce como commit o entrada de código.
GitHub funciona de esta forma como una especie de libro numerado, pero los conocidos como commits huérfanos o colgados no forman parte de dicho índice, ya que en estos casos el programador no vincula las entradas a ninguna sección pública, los llamados branches. Por tanto, el commit queda en una especie de limbo.
En definitiva, el código sí esta subido a los servidores de la plataforma y dentro del proyecto, pero es invisible, una arquitectura que está favoreciendo algunos de los últimos ataques, perfectamente orquestados para alcanzar a la cadena de suministro.
Commits huérfanos y deuda de seguridad en código de terceros
A nivel técnico, esta técnica de ataque ha sido denominado como CHOR –Cross-Fork Object References– por la firma de ciberseguridad Truffle Security, quienes descubrieron que un atacante puede subir malware a una copia de un repositorio, para quedar alojado permanentemente y de forma invisible en la URL legítima de una empresa en GitHub.
Esta forma de ataque no busca así a numerosos individuos, sino la base en la que todos los desarrolladores y compañías confían, aunque los datos a este nivel son cada vez más preocupantes.
En la práctica, además, es capaz de evadir los firewalls, o cortafuegos, que las empresas suelen utilizar para bloquear descargas procedentes de servidores extraños, no precisamente de github.com, que es un sitio de confianza.
Al introducir un commit huérfano, el atacante tiene la grandísima ventaja de que los creadores del proyecto no verán nada extraño en sus paneles de control, por lo que este tipo de código malicioso puede permanecer ahí sin ser visto.
Por si fuera poco, otras firmas como Veracode aseguran que la cadena de suministro de software es cada vez más una diana para los ciberdelincuentes, con actores maliciosos que se dirigen a repositorios de código abierto muy usados, como NPM o PyPI.
Según uno de sus últimos informes, el 82% de organizaciones tienen actualmente deudas de seguridad, con un 60% en un nivel de seguridad crítica; curiosamente, el 66% de la deuda de seguridad crítica proviene de código de terceros.
Desafortunadamente, aunque este tipo de ataques tienen que ver con el propio diseño de la herramienta, GitHub continúa en el punto de mira, con las mismas amenazas que están presentes en todo el conjunto de la cadena de suministro.
Cuando el enemigo no es el código de terceros
El mayor punto de inflexión en esta lucha constante por blindar los servicios que usan miles y miles de programadores, la brecha de seguridad que confirmó recientemente haber sufrido GitHub, con más de 3.700 repositorios privados afectados, es solo una muestra más de que las técnicas siguen evolucionando, pero con los mismos objetivos.
A diferencia de lo que ocurre con los repositorios huérfanos, este último ataque se basó en el robo de las credenciales corporativas de un empleado, el que suele ser el eslabón más débil de la cadena, ya que está expuesto a campañas de phishing que mejoran notablemente con el uso de la inteligencia artificial.
Básicamente, fue una intrusión directa en GitHub, ya que al contar con las claves y el acceso legítimo del empleado, pudieron saltarse todos los controles y acceder ilegalmente a los repositorios infectados.
Por el contrario, la técnica del repositorio huérfano no implica un robo de credenciales ni una alteración del código que la empresa mantiene vigilado, sino más bien un ataque que aprovecha las bifurcaciones de GitHub para subir código malicioso.
De tal forma, el archivo se mantiene en los servidores centrales de GitHub bajo la URL legítima de la compañía afectada, por lo que es totalmente invisible en el historial público del proyecto.
Así, mientras que en el último caso de GitHub los expertos pudieron identificar actividades anómalas desde las cuentas comprometidas, en los repositorios huérfanos el malware puede mantenerse durante mucho tiempo sin que nadie sea capaz de verlo.
O lo que es lo mismo, los ciberdelincuentes utilizan una dirección legítima para ocultarse sin ningún tipo de sospecha, debido a que el archivo se encuentra en esa especie de limbo invisible a antivirus y demás herramientas de ciberseguridad.
De momento, este tipo de repositorios huérfanos son una de las técnicas más elaboradas que existen, ya que los atacantes no necesitan distribuir su código, ya que las plataformas de confianza que lo utilizan lo harían de forma totalmente involuntaria.
La solución de GitHub no reside en eliminar esta funcionalidad –que depende Git–, sino en advertir a quienes acceden a un commit huérfano que no forma parte de las ramas principales del proyecto, algo que lamentablemente funciona como ayuda para los humanos, pero no frena los scripts automatizados o virus ocultos,