Ataques a la cadena de suministro hay de muchos tipos, como ya se sabe, a veces y solo a veces te topas con unos buenos controles y medidas de seguridad en una empresa u organismo, con lo cual tanto los investigadores (como será el caso que comentaré), como los “malos” van a intentar buscar un camino más sencillo, explotar las vulnerabilidades humanas (ingeniería social) o bien intentarlo con la cadena de suministro (proveedores de servicios, de software, hardware, etc.), a ver si ellos tienen unas defensas más débiles que lleve menos tiempo explotar.
También se da el caso de los ataques a la cadena de suministro cuando no se tiene un objetivo concreto y se pretende acceder a múltiples objetivos, sean quienes sean de forma más indiscriminada, al final según el objetivo escogido en la cadena de suministro, si este tiene una amplia difusión en clientes, se pueden pescar muchas ballenas de una sola tacada.
Este es el caso expuesto por el investigador JOHN STAWINSKI y su equipo, que describe un caso que puede recordar a otros como SolarWinds o Ledger, dado que se consiguió explotar estos productos que una vez distribuidos en sus clientes hacían vulnerables a estos. En este caso la vulnerabilidad se propaga por la cadena de CI/CD de PyTorch a través de varios repositorios de Github unos con código de las librerías auxiliares y con yaml de automatización para la construcción de las diferentes releases que componen PyTorch, una librería muy utilizada en AI/ML (Inteligencia Artificial/Machine Learning) y usada por grandes empresas como Google o Meta, etc.
Por lo tanto con posible afectación a dichas empresas y a todo el que use su tecnología, ya que se ha conseguido modificar el código de esta librería ya que se utiliza el propio Github como servidor de C2 que normalmente debería estar abierto el acceso para poder realizar las actualizaciones (como mínimo en las empresas que usan en sus productos esta librería), lo que se ha conseguido es un backdoor incluido en el código final de la librería.
A que se debe esto, aquí me meto en un terreno un poco pantanoso para mi, porque no soy un experto en automatizar procesos de CI/CD, tengo una ligera idea de como funcionan en Github y como se permite la actualización y la creación de releases mediante la aplicación de cambios “merge” en el código con el código principal que normalmente tiene un responsable de autorización de cambios y responsable de la release de ese componente. Esta como muchas otras librerías complejas tiene varios componentes y tiene una pipeline de CI/CD en la que participan varios desarrolladores con el rol de “Contributors”, al parecer al conseguir introducirse como “contributors” han podido alterar el código y no solo eso, en el proceso de creación de la release que se hace con yaml que automatizan el proceso se tiene acceso a repositorio de secrets de AWS y API Tokens de otros repositorios.
Creo que con esta breve explicación y sin tener un gran conocimiento de automatización de procesos de CI/CD se puede hacer uno una idea de como se introduce un cambio en la cadena y como esta llega a la versión final.
Se propone una mitigación para corregir la posibilidad de añadir código malicioso (PoC), no olvidemos que son unos investigadores y que además todo lo que han encontrado lo han reportado debidamente, es decir, no han realizado ninguna acción maliciosa al respecto. En este tipo de automatizaciones de desarrollos con múltiples componentes y que consiste en varios “Contributors”, varios desarrolladores e incluso varios repositorios, lo que indican los investigadores es que bastaría con cambiar los permisos ‘Require approval for first-time contributors’ to ‘Require approval for all outside collaborators’, es decir, que en lugar de requerir la aprobación la primera vez, requerir aprobación de todos los cambios introducidos para cualquiera de fuera de tu organización en todos los cambios.
Es la forma de mitigar riesgos de que se introduzca código desde otros repositorios que puedes no tener controlados, esta solución vale para este caso concreto que se ha dado en esta investigación y seguramente para casos similares, ya que la forma de trabajo colaborativo en ciertas librerías es algo que se da muy a menudo, es muy común, pero pueden existir otros problemas y otras casuísticas, por lo tanto vulnerabilidades que no hemos visto y para las cuales esta mitigación por tanto no nos serviría.
Por ej. en la plataforma de elearning de THM en el AOC2023 había un caso bastante sencillo en el que se podía modificar el proceso de automatización de construcción de la release, era un caso muy sencillo y pedagógico, pero que mostraba las debilidades que puede haber en ese tipo de código que solo sirve para construir la versión del software dentro de la pipeline de CI/CD, pero que tiene que tener tanta importancia o cuidado como el propio código de la aplicación a nivel de quien puede modificarlo, es un caso mucho más simple y fácil de entender hay un proyecto con el código de la aplicación y otro que contiene la automatización para construir la release, el código yaml no había permisos para modificarlo, pero en la construcción de la release había un Makefile que si se podía modificar y de esta forma podíamos ejecutar el código que nos interesara introducir cada vez que el yaml invocara al comando make, como era un caso pedagógico se solicitaba ejecutar un whoami y ver el contenido de un path de fichero concreto.
Se puede ver toda la información completa de la investigación y con lujo de detalles, acciones realizadas, timelines, etc. podemos leerlo en el siguiente enlace:
Playing with Fire – How We Executed a Critical Supply Chain Attack on PyTorch – John Stawinski IV