Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Ataques a la cadena de suministro por motivos de ciberseguridad iniciados por el propietario
Joao Correia
23 de septiembre de 2022 - Evangelista técnico
Los ataques a la cadena de suministro son de todo tipo. Un ejemplo es la apropiación de cuentas legítimas para desplegar código malicioso en bibliotecas de uso generalizado. Otro es el despliegue de cambios durante la compilación a través de herramientas maliciosas.
Podríamos seguir: piense en contenidos mal etiquetados con la intención de engañar a usuarios incautos, o en archivos adicionales añadidos que subvierten el comportamiento de la aplicación.
Pero está surgiendo otro ataque a la cadena de suministro especialmente malicioso perpetrado por el propietario real del código o el desarrollador original que está detrás del código, y está demostrando ser increíblemente perturbador.
Una nueva y peligrosa amenaza para la cadena de suministro
Este vector de ataque surgió a principios de 2022, cuando los desarrolladores se dieron cuenta de que un par de bibliotecas muy utilizadas ("faker.js" y "colors.js") habían sido manipuladas para incluir código que no guardaba relación con la intención original de estas bibliotecas.
Peor aún, el código "adicional" estaba rompiendo las aplicaciones que dependían de él al crear un bucle infinito en el código. Dado que el código de estas bibliotecas es abierto y está alojado en repositorios públicos, fue posible analizar los commits e identificar quién había añadido ese código malicioso.
La comunidad de desarrolladores quedó desconcertada al descubrir que el código había sido añadido por el desarrollador original.
Al parecer, descontento por no poder rentabilizar el tiempo que empleó en desarrollar el código y por el hecho de que lo utilizaran tantos desarrolladores, el programador decidió sabotear sus propias bibliotecas.
Sabotaje que afecta a millones
Puede parecer que no es nada: al fin y al cabo, es el código del desarrollador. Pero para ponerlo todo en contexto, las bibliotecas afectadas tenían un total de 25 millones de descargas... no a lo largo de su vida útil, sino cada semana.
La política del código abierto y cómo se monetiza -incluidas las medidas que un desarrollador puede tomar para abordarla- es realmente un artículo entero en sí mismo, y las opiniones pueden variar mucho. Pero, por razones obvias, la reacción de un desarrollador que manipuló un código utilizado por millones de personas fue inmensa.
De hecho, GitHub, donde está alojado el código, suspendió la cuenta del desarrollador (aunque GitHub la restauró unos días después). El desarrollador afirmaba tener cientos de proyectos, no solo en esas dos bibliotecas, pero claro, las dos bibliotecas en cuestión tienen una inmensa cantidad de seguidores.
Acción maliciosa con impacto real en los desarrolladores
Las bibliotecas terminaron siendo bloqueadas para su distribución, el código fue revertido y se crearon nuevas bibliotecas para reemplazar la funcionalidad.
Lo que esto significaba para los desarrolladores que utilizaban esas bibliotecas era el trabajo extra de comprobar el código, actualizarlo y cambiar las dependencias. Las acciones de un individuo obligaron a realizar pruebas adicionales y todas las demás tareas necesarias para garantizar la correcta ejecución del software. Se invirtieron incontables horas de trabajo en responder a un actor malicioso, horas que podrían haberse empleado de forma más productiva en otra cosa.
Fue una acción deliberada de un único desarrollador que afectó a miles de aplicaciones. Pero hay otras situaciones en las que no es deliberada, pero sin embargo proviene de la fuente, el desarrollador. O, al menos, de la cuenta del desarrollador.
Un servidor git comprometido
Apenas un par de meses después, en marzo, el servidor git que contiene el código del lenguaje de programación de servidores web más popular, PHP, se vio comprometido. Sí, has leído bien, el repositorio git oficial de PHP del equipo PHP fue manipulado.
Los atacantes consiguieron cambiar el código fuente de PHP 8.1 e introducir commits maliciosos en el sistema bajo la apariencia de "correcciones de erratas", que ocultaban código malicioso que, si se integraba con éxito en la base de código PHP, se propagaría a millones de despliegues PHP y crearía una puerta trasera en millones de sitios web y servicios orientados a Internet escritos en PHP.
¿Cómo ha ocurrido? Git es una gran herramienta, pero tiene un fallo por el que es posible firmar confirmaciones de código como otra persona. Otra persona que revise las ediciones de código puede ser engañada y pensar que las ediciones fueron hechas por, digamos, el desarrollador principal del proyecto.
El resultado es que cualquier revisión podría depender en gran medida de la confianza: la confianza en que la persona correcta editó el código e hizo cambios aceptables. Por tanto, las revisiones pueden ser menos estrictas, lo que permite que el código malicioso pase desapercibido sin ser detectado.
Y no es sólo PHP...
El código malicioso añadido a PHP 8.1 fue detectado y los commits rechazados, por lo que el código nunca llegó a formar parte de la base de código PHP que millones de personas utilizan a diario. Sin embargo, el problema que creó llevó al equipo a trasladarse de su propio repositorio git a GitHub.
En mayo, la biblioteca ctx de Python y la biblioteca phpass de PHP fueron comprometidas en una operación que el atacante afirmó que era simplemente "con fines de investigación"una afirmación que finalmente fue imposible de probar o refutar.
En una enrevesada serie de pasos, el atacante se hizo con el control de los repositorios de estas bibliotecas suplantando la identidad de los desarrolladores originales: se hizo con direcciones de correo electrónico que ya no existían, solicitó la recuperación de las contraseñas de esas cuentas y creó dominios falsos para validar la propiedad de los que habían expirado.
Esto engañaba a los anfitriones de los repositorios para que dieran la administración de los mismos al atacante, que se hacía pasar por el desarrollador original que había perdido el acceso a su propio código. El atacante procedió a incluir código de robo de credenciales en esas bibliotecas, incluidas las credenciales de AWS. Las afirmaciones del atacante de que todas las credenciales recopiladas se habían eliminado también eran imposibles de verificar.
Las amenazas invierten en ataques a la cadena de suministro
Estos ejemplos ponen de manifiesto la necesidad de una respuesta rápida a las amenazas en la cadena de suministro de códigos. La amenaza a las cadenas de suministro de código no es nueva en sí misma. Sin embargo, los ataques que estamos viendo últimamente son diferentes porque el tiempo invertido va mucho más allá del tiempo de respuesta habitual de los ataques, que es de días o semanas.
Los últimos ejemplos de compromisos implican una enorme cantidad de tiempo para ejecutar el compromiso. En muchos sentidos, se trata de un ejemplo mucho más grave de ataque a la cadena de suministro, que ataca el corazón de un código que utilizan -a ciegas- millones de organizaciones de todo el mundo.
Otro punto que agrava el asunto: hay que tener en cuenta la gran cantidad de trabajo que requiere cambiar las versiones de las bibliotecas para responder a un compromiso. Ejecutar, probar y desplegar nuevas bibliotecas lleva un tiempo considerable cada vez que se produce un suceso de este tipo.
Aquí es donde un servicio como Extended Lifecycle Support para PHP y Ciclo de vida ampliado para Python pueden ayudar. TuxCare proporciona rápidamente actualizaciones de seguridad para los problemas a nivel de lenguaje y para los módulos relacionados, lo que ayuda a cerrar los agujeros creados por algunos de los ataques que hemos descrito más rápido y con menos trabajo que las alternativas.
